RE: [aspectj-users] Drawbacks of AOP

["John Rayburn" <John.Rayburn@xxxxxxxxxxxxx>]

> But the problem here is that the deployment descriptor/ejb container 
> approach to transactions is very specific and binds my transaction
service 
> to a very specific specification. What if I want to produce a
container that 
> can use different "plug-in" declarative services? Ask anyone that
works with 
> HIPPA in security or web services with transactions as to why.

However, this is not always a requirement for a project, so both ways
(descriptor/container vs AspectJ) scale differently, and per project
this would be a decision that would be made by the team.  They both
provide solutions to implementing aspect oriented cross-cutting
concerns...

>From: "Marc Tremblay" <marc@xxxxxxxxxxxxx>
>Reply-To: aspectj-users@xxxxxxxxxxx
>To: <aspectj-users@xxxxxxxxxxx>
>Subject: RE: [aspectj-users] Drawbacks of AOP
>Date: Thu, 17 Apr 2003 14:54:36 -0600
>
> > > To me this is the kind of thing that should be handled
declaratively 
>in a deployment descriptor and
> > > applied by some sort of runtime container (not nesc. EJB, but
along 
>those lines).  To me, implementing
> > > things like transaction management, security, etc. as an aspect
leads 
>to hidden complexity and thereby
> > > can render the code unmaintainable.
> >
> > ...
> >
> > > I certainly agree with you that these crosscutting concerns don't 
>belong in the code itself, but I just
> > > think the deployment descriptor approach is a better one than
using 
>aspects.  Just because we can solve
> > > these problems with aspects, doesn't mean aspects are the best way
to 
>solve these problems.  These
> > > concerns are the kind that should be handled in a container or
runtime 
>framework in my opinion.
> >
> > That's identical, though. One could write an aspect that parses that

>exact same deployment
> > descriptor and accomplish the same thing with an aspect.
> >
> > It's simply a matter of syntax for maintenance.
>
>It's identical with respect to the effect to be achieved.  However,
it's 
>very different with respect to on the
>one hand I'm writing aspects to manage these concerns, and on the other
I'm 
>relying on some 3rd party
>container/framework provider to take care of it for me.  With the later
I 
>really don't care how they handle
>these concerns so long as they do.
>
>I guess what I'm getting at is that I see the problems of transactions,

>security, etc. as already being solved
>well enough that I'm not interested in finding other solutions for
them.
>
>Logging, resource pooling, and enforcing design by contract ideas have
not, 
>to my knowledge, been solved in an
>adequate manner in the Java environment.
>
>-- Marc
>
>
>
>_______________________________________________
>aspectj-users mailing list
>aspectj-users@xxxxxxxxxxx
>http://dev.eclipse.org/mailman/listinfo/aspectj-users


_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

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