Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] pointcut on termination of java program

Title: RE: [aspectj-users] pointcut on termination of java program

"This might be a good tradeoff for widespread adoption of your tool and
framework. I suspect that for those comfortable with AOP using Xdoclet won't
be helpful. It isn't clear to me if you moved away from advice in favor of
interception in your framework. If so I suspect it's a trade off selecting
poorer modularity for easier adoption." - Ron

I am in general reluctant to jump on the open source tool bandwagon and adopt codebases without careful consideration first, but XDoclet provided a easier pathway for those not yet familiar with AspectJ, though it did confirm something - it simply cannot scale for large code bases (OutOfMemory and slowwwww).

At the current customer test site consisting of a large team spread over different locations teams there is only 2 developers who feel comfortable enough with pointcut definitions. We looked at expected usage and determined that a major part of our requirements are solved by basic method (call | execution) pointcuts thus by providing class and method tags within the Java doc we could get the underlying framework adopted even while AspectJ was not integrated in the build factory. XDoclet enabled the code for aspects, which was still under construction, to evolve without too much pain.

There are hand coded aspects which handle the more complex use cases and over time we have moved code from the template and hand coded aspects out into the product so that even mere Java mortals, ;-), could interact and affect the system without understanding AOP. Also the standard Java API allowed the product to support user pointcuts (not in aspectj language) - blocks of code.

I think what I was trying to say in my last email was use AspectJ wisely and in the right context. AspectJ is a great technology but its even better when coupled with good old OO system design.

ASIDE: By the way I think the AOP community should look at getting standard AspectJ specifications out for logging, tracing.... As I do not think its efficient for the whole industry to be off creating another tracing API. I would love to see AspectJ specify a framework (specification) that would have a SPI interface so that users could define tracing and logging in a standard (independent) way while allowing vendors to provide value added via additional context information, tool support and visualizations. The benefit of this is that we can move past these particular use cases and start applying the technology in environments closer to the business goal. Most developers are comfortable with pointscuts and advices based around the language - Java, but are reluctant to consider it at a higher level of abstraction user transactions and business process co-ordination. Looking forward to Attributes as this coupled with AspectJ looks as the killer combination of course it does mean that developers specify attributes that enhance the code and its understanding in relation to system execution.

Regards,

William

-----Original Message-----
From: aspectj-users-admin@xxxxxxxxxxx [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of rbodkin
Sent: Tuesday, December 16, 2003 7:17 PM
To: aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] pointcut on termination of java program


Hi William,

I agree, AspectJ provides superior language support and I believe better
modularity. You can write interceptors and pre-plan out a framework, but as
always you face the architect's dilemna: over-build up front or (and!)
scramble in the face of unexpected requirements. When you need new context or
new extension points you face more works. And littering the code with hooks
is less modular than writing one (or a few) pointcuts to say where the hooks
should be.

AOP in general and AspectJ in particular not only simplifies writing modular
support for crosscutting, but it greatly simplifies reading and maintaining
it and it enables effective tools support.

On Tue, 16 Dec 2003 09:44:01 +0100, Louth, William wrote
> Regarding filter state managment I do not see any less flexibility
> here. Again a developer could easily share state and pass it across
> executions with a current context, which transaction managers have
> done for a very long time.
Global memory results in high coupling, giving poor modularity. But I was
really talking about cooperating in processing a single request. As an
example, I wrote a UI security servlet filter to edit out part of a page:
coordinating flushing buffers and doing work on the "outside" like this was a
major pain that rippled through multiple layers. With an aspect, I could hook
the creation of the output stream in the underlying JSP and it was much
cleaner. I can also use aspects to proactive filter markup by not executing
code that generates instead of using a servlet filter to remove it after the
fact (again an easier programming model).

>... The benefit of AOP in the case of servlet filters is that
> it allows you to extend an architecture such as J2EE where the contract
> defined via interfaces is not comprehensive for your application needs.
This is another benefit, IMHO.

> I have recently created a tool based on AspectJ (it will be released
> in 2004) but as the development proceeded more and more of the code was
> extracted from the aspectj (advices..) ...
That's great news. I'm looking forward to hearing more about it. I favor
writing small aspects that provide adapters and cooperate with classes to do
the real work. So that's good AOP in my book.

> ... and placed in a standard
> framework thus allowing our system to be used by both AspectJ developers
> and Java developers (standard API). We also have an extension that uses
> Xdoclet to automatically generate the AspectJ classes which merely call
> into the product framework.

This might be a good tradeoff for widespread adoption of your tool and
framework. I suspect that for those comfortable with AOP using Xdoclet won't
be helpful. It isn't clear to me if you moved away from advice in favor of
interception in your framework. If so I suspect it's a trade off selecting
poorer modularity for easier adoption.

Ron

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


Back to the top