geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Aspect based design ?
Date Sat, 09 Aug 2003 12:33:07 GMT

On Friday, August 8, 2003, at 01:53  pm, Dhananjay Nene wrote:

>> On Friday, August 8, 2003, at 09:51  am, Stefan Arentz wrote:
>>> On Thursday, August 7, 2003, at 19:30, James Strachan wrote:
>>> Personally I don't care much (yet) about a service for users of the
>>> servers but I think it should be given some serious thoughts for
>>> container development.
>> Agreed. Though lets get the J2EE server ready first then lets figure
>> out how to weave J2EE aspects nicely into POJOs later on - or in a
>> separate parallel project.
>> Incidentally if there was gonna be some J2EE aspects, they should
>> hopefully be mostly J2EE standard apsects and so work with any J2EE
>> container right? So maybe its time for a separate AspectJ2ee project?
>> I'm sure Geronimo could eventually supply some custom 
>> Geronimo-specific
>> aspects later on down the road.
> Assuming one started development without any existing code, AOP would
> deliver two advantages.
> a. For Developers - Offer a better mechanism of expressing cross 
> cutting
> design constructs and thus the code

FWIW (whenever you get to see it) the initial Geronimo code already has 
an interceptor stack - so its quite ready for use in an AOP framework.

> b. For Developers and End users - Offer a better mechanism of 
> expressing
> geronimo features which can be perceived to be cross cutting for the 
> users.
> The most obvious ones here are transaction / security / logging /
> persistence
> etc.
> An aspect based design would support a scenario where geronimo ships 
> with
> j2ee aspects, and would allow "unsatisfied" users to tweak the aspects 
> or
> write their own.

I agree in principle, Geronimo is already gonna have several modules 
(core container, web container connector, WS connector etc). So why 
don't we start an experimental AOP module? Then the folks developing 
the AOP module can focus on AOP stuff and the Geronimo server 
developers can focus on getting the J2EE server working. If some of the 
AOP work ends up getting used inside the core container - cool. 
Otherwise they can be separate, parallel modules that work together.

>  I believe it would be important to have a considered
> strategy on whether such a feature would be required and if so how and 
> when
> should it be brought in.

AOP is certainly not required for J2EE compliance; though it is a nice 
feature for folks wanting to use POJOs and so forth. So I'd recommend a 
separate project somwhere or a parallel separate module in Geronimo.

> The implementation could be phased, but if the
> approach isnt in place, then it may never take off. Hence I dont think 
> one
> can "defer" this issue.

I disagree. If you look at AspectWerkz and Nanning, already they've 
gone a long way to adding many J2EE style aspects to any POJOs quite 
easily with very little development. I don't see why a group of folks 
can't get together, do a groovy J2EE aspects project - try and work 
with most J2EE servers and by all means write some Geronimo-specific 
extras - but I don't think we need to interfere with the general 
Geronimo server development to do this.

> You do bring out an interesting option of a separate AspectJ2EE 
> project, but
> I think it would be useful to consider how such a project could 
> cooperate
> with geronimo for example.

We could start off as a module of Geronimo. Or it could start elsewhere 
too. (I'd like to get the AspectWerkz & Nanning guys involved too if we 

> I suspect making aspects into a separate project
> and hoping that they would cooperate nicely with geronimo would be a 
> lot
> harder than it seems.

I disagree - many folks on this list work on various separate projects 
which work together. Whether the AOP project is a module in Geronimo or 
a separate project elsewhere I'm sure we'd work closely together to 
make it work. I'm sure plenty of folks on both sides of the fence can 
understand each others perspectives and try to help each other. (I 
myself might swap hats occasionally, sitting in both camps since I 
think both projects are very useful). However I don't want AOP 
considerations to slow down Geronimo getting a fully working & tested 
J2EE stack.

> I ask myself - how would I build a new container from scratch today, 
> and I
> am unable to really have a satisfactory answer which does not involve
> aspects.

Aspects and an interceptor stack are quite similar in many ways - from 
a containers perspective. I don't see any reason why the Geronimo 
interceptor stack can't be easily integrated into any J2EE AOP project.


View raw message