Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] struts

I agree with the below example of the more depth that you can obtain with
AOP.

As for stability, I am also running very stable aspects.  My question is
not the stability of aspectJ itself but the stability of the specification.
If language semantics can still be invalidated (recent emails on the syntax
changes for inter-type declarations) it may mean that something I write
today will force me to not be able to move to the next version until I have
updated my code to handle the new semantics (even if something really
useful in a future version is there that would help).

This is ok and expected as aspectJ is still relatively new so there is not
a big investment in code that must be updated in order to take advantage of
new versions.  Hence remaining clean is the best rule in the beginning.  At
some point when people start taking the full plunge, a change like this
will be a costly re-write IMHO.  Hence the question, are we currently at a
point where I can "take a plunge" vs my current dabbling, or is that
reserved for a future version?  Anyone have any insight to the value of
backward compatibility in future versions from the aspectJ designers?

Again, love what I can do just wondering when I can expand more on my usage
without fear of it "biting" me later.

Regards...djsuarez





Michael Oliver <oliverm@xxxxxxxxxxxxxxxx>@eclipse.org on 05 Feb 2004 22:10

Please respond to aspectj-users@xxxxxxxxxxx

Sent by:    aspectj-users-admin@xxxxxxxxxxx




To:    aspectj-users@xxxxxxxxxxx
Subject:    Re: [aspectj-users] struts


****************************************************************************

 This message originated from the Internet.  Its originator may or
 may not be who they claim to be and the information contained in
 the message and any attachments may or may not be accurate.
****************************************************************************


How many ways to skin a cat?

Filters have their place but filters don't have access to any of the
values IN the Actions, just the request out in front of the actions.  An
aspect can take values that are available as the Actions are being
executed and apply logic at that point, filters cannot.

As for stability, I have an aspect for logging and another for debugging
and the code runs very well with or without the aspects in place...can't
get much more stable than that IMHO.

Ollie

On Thu, 2004-02-05 at 18:28, DAVID SUAREZ wrote:
> Interesting example.  For J2EE web applications there is already the
ability
> to intercept well-known entry/exit calls using filters.
>
> Does anyone have any pros/cons of using filters vs. aspects for an
example
> like the below (security in struts)?  If the security object is already
> encapsulated it could in theory also be used by aspect oriented code in
> different layers/applications if there was a need at some point.
>
> I know it's too general of a question but I'm wondering how stable
aspectJ
> is at this point.  I've been dabbling and I have read recent messages
where
> 1.0 syntax is no longer applicable in 1.1 (I can't find on the website
how
> old 1.0 is compared to 1.1 though).  Is 1.1 at a level where backward
> compatibility will be kept or is that reserved for a future release?  I
> think it would be an important thing to know and haven't seen any
> documentation either way.  With J2EE standards like web filters I can
almost
> guarantee that they will be around for a very long time and work the same
> since Java has been such a good example of remaining backward compatible.
>
> Please don't misunderstand the above message.  I am really enjoying the
> technology and know alot of wonderful applications already using AOP but
i'm
> wondering relatively how ready it is for "prime-time" when an alternative
> viable solution exists that is just as loosely coupled.
>
> Would appreciate your feedback.
>
> Regards...djsuarez
>
> ----- Original Message -----
> From: "Michael Oliver" <oliverm@xxxxxxxxxxxxxxxx>
> To: <aspectj-users@xxxxxxxxxxx>
> Sent: Thursday, February 05, 2004 4:54 PM
> Subject: Re: [aspectj-users] struts
>
>
> > Perhaps, but it is one of those subjects that a little is not enough
and
> > a little more is too much.
> >
> > Security is one thing I have found AJ to be specifically good at.  You
> > could write security into every 'Action' class and many do, and/or
write
> > it into every JSP page and many do.  With AspectJ I can look at every
> > Action class and they all have an execute method and I can write a
> > single aspect that crosscuts every action and does a security check and
> > if the security check fails I can return from my action a forward to a
> > login page or other security action.  Then later if I change security
> > from Tomcat realms to LDAP to BEA, I don't have to modify any of my
> > actions, just recompile with a different aspect.
> >
> > So, Nicolai, is this too little or too much?
> >
> > Ollie
> >
> > On Thu, 2004-02-05 at 14:38, sdojfloasdj wrote:
> > > Hi,
> > >
> > > does anyone can provide me an little example, how to use AspectJ in
the
> > > struts framework?
> > >
> > > Thanks,
> > >
> > > Nicolai
> > >
> > >
> > > ----
> > > Diese Nachricht wurde auf Viren und andere gefaehrliche Inhalte sowie
> Spam untersucht.
> > >
> > >
> > > _______________________________________________
> > > aspectj-users mailing list
> > > aspectj-users@xxxxxxxxxxx
> > > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
 http://dev.eclipse.org/mailman/listinfo/aspectj-users









************************************************************************
 This E-mail is confidential. It may also be legally privileged. If you
 are not the addressee you may not copy, forward, disclose or use any
 part of it. If you have received this message in error, please delete
 it and all copies from your system and notify the sender immediately
 by return E-mail.

 Internet communications cannot be guaranteed to be timely, secure,
 error or virus-free. The sender does not accept liability for any
 errors or omissions.
************************************************************************


Back to the top