[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] Drawbacks of AOP
|
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.
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
