Re: [cinjug-users] Looking for AOP framework

[Matt Avery <mavery@xxxxxxxxxxxxxxx>]

True, I could force the issue by moving some stuff around to ensure that 
any object doing persistence is a subclass of BrokerSupport.  I would 
have to come up with a new name for BrokerSupport I think.  That would 
be like extending an adjective to produce a noun.  This is probably what 
I'm going to do for the project I'm working on right now, but I was 
looking for the general "adjective" functionality in that question.

The "Introduction" support in AspectJ is the answer I was looking for. 
Just curious though, if I "introduced" the getBroker() method, will 
Eclipse support the use of getBroker() in the class knowing that an 
aspect is applied or will it give me a compiler error?


Thanks guys!

James Carman wrote:
> There is something you should consider here.  Maybe having different "type"
> of classes all doing the same thing (persistence manipulation) isn't such a
> good approach.  Usually, whenever a class needs to manipulate (create, read,
> update, or delete) a "domain" or "business" object's persistence, it uses a
> DAO object.  I would introduce a DAO "layer" here and that should solve your
> problem with having to use AOP to "introduce" fields/methods into your
> classes that your IDE won't know about.
>
>
> -----Original Message-----
> From: Matt Avery [mailto:mavery@xxxxxxxxxxxxxxx] 
> Sent: Tuesday, May 11, 2004 10:36 AM
> To: users@xxxxxxxxxx
> Subject: Re: [cinjug-users] Looking for AOP framework
>
> Chris,
>
> I'm not using AspectJ yet, but I'm considering using it for the project 
> I'm working on.  I'm doing exactly the same thing you described with 
> Hibernate only I'm using OJB.
>
> The version of OJB I'm using has a bug in it, so I wrote an object to 
> work around the bug called "BrokerSupport" (think 
> PropertyChangeSupport).  Every object that needs to access the database 
> has this code in it:
>
>         protected BrokerSupport fieldBrokerSupport;
>         
>         protected PersistenceBroker getBroker()
>         {
>                 return getBrokerSupport().getBroker();
>         }
>         
>         protected BrokerSupport getBrokerSupport()
>         {
>                 if (fieldBrokerSupport == null)
>                 {
>                         fieldBrokerSupport = new BrokerSupport( );
>                 }
>                 return fieldBrokerSupport;
>         }
>
>         protected void closeBroker()
>         {
>                 getBrokerSupport().closeBroker();
>         }
>
> Since the business objects extend different superclasses, I can't move 
> this code to a single abstract superclass.  So much for "once and only 
> once".
>
> I was thinking of making a "BrokerSupportAspect" that would intercept 
> the getBroker() and closeBroker() methods in those objects.  My question 
> is, what is the best practice for using aspects in a situation like 
> this?  Do I just add a blank implementation of getBroker() and 
> closeBroker() to each class and then use the aspect to fill in the guts 
> at runtime, or is there some other technique I should use?
>
> Thanks,
>
>
> Chris Nelson wrote:
>
> > Mike,
> >
> > It's important to consider what you are doing when
> > choosing an AOP implementation.  Are you wanting to
> > develop your own custom aspects or merely use other
> > prebuilt aspects to solve a given problem?  How
> > dynamic do you need your aspects to be?  I've use
> > AspectJ a bit, and am using it now on an project.  For
> > applying custom developed aspects to a largish
> > codebase I find it to be very productive.  I find the
> > AspectJ language to be quite expressive, and by using
> > the Eclipse plugin it is easy to see what your aspects
> > are going to affect (what your pointcuts actually pick
> > out).  
> >
> > However, we are also considering using Spring so we
> > can use its' ready made aspects for transaction
> > handling and opening/closing of the Hibernate session.
> > We could, of course, write our own AspectJ aspects to
> > deal with these issues, but the fact that Spring has
> > premade aspects to do this is attractive.
> >
> > A couple other issues to think about when choosing AOP
> > implementations are:
> >
> > 1) Dynamic/Compile time:
> >
> > AspectJ applies aspects to a code base by using a
> > compiler/weaver at compile time.  This means your
> > classes are just plain old Java code and only require
> > a small library at run time.  However, if you want to
> > add/remove aspects you need to recompile, no different
> > than if you were changing other code.
> >
> > Other AOP implementations(AspectWerkz, JBoss AOP)
> > apply aspects at runtime by modifying the bytecode of
> > your classes at runtime.  This means, of course,
> > aspects can be added/removed at runtime.  The price
> > for this is having to use a custom classloader, and
> > being willing to trust your AOP modifying your
> > classes' bytecodes at runtime "on the fly".  Though
> > this made me squeamish initially, the fact that so
> > many implementations are doing this successfully has
> > made me less so over time.
> >
> > 2)  Language extension?
> >
> > AspectJ is an actual language extension vs other
> > implementations that use another format (XML config
> > files for instance) to specify how to apply aspects.  
> >
> > Well, I've already rambled enough for now.  Great to
> > see someone else bring up AOP on the Cinjug list!  As
> > you can see, it's kind of a pet interest of mine.
> >
> > Later,
> >
> > Chris
> >
> > --- "Witt, Mike (OH35)" <mike.witt@xxxxxxxxxxxxx>
> > wrote:
> >
> >
> > > I'm planning to spend some time experimenting with
> > > AOP.  I'm wondering if a
> > > de facto AOP framwork is emerging.  Right now, I'm
> > > looking at AspectJ and
> > > Spring, there are probably others as well.  So, I'm
> > > looking for an opinion
> > > on which framework to use based on:
> > >
> > > - What's the standard
> > > - Which one is the most newbie friendly - available
> > > documentation and
> > > tutorials
> > > - Eclipse plug-in support
> > > - Hibernate support
> > > - Most active development community
> > >
> > > Thanks for the suggestions.
> > >
> > > Mike Witt
> > >
> > >
> > >
> > > ---------
> > > You may unsubscribe from this mailing list
> > > by sending a blank email addressed to:
> > > users-unsubscribe@xxxxxxxxxx
> > >
> > > --
> > > Find additional help by sending a blank email
> > > addressed to:
> > > users-help@xxxxxxxxxx
> >
> >
> >
> >
> > 	
> > 		
> > __________________________________
> > Do you Yahoo!?
> > Win a $20,000 Career Makeover at Yahoo! HotJobs  
> > http://hotjobs.sweepstakes.yahoo.com/careermakeover 
> >
> > ---------
> > You may unsubscribe from this mailing list
> > by sending a blank email addressed to:
> > users-unsubscribe@xxxxxxxxxx
> >
> > --
> > Find additional help by sending a blank email
> > addressed to:
> > users-help@xxxxxxxxxx

--
Matthew Avery
Senior Developer
(513) 470-5316
http://www.einnovation.com/