Re: [aspectj-users] AspectJ and metadata

[Adrian Powell <apowell@xxxxxxxxxx>]

Robert,

Thanks for your insight.  Our project
isn't as advanced as yours, so it is really helpful to learn from you.

You're right that an automated refactoring
of metadata would be a great help, especially now that Hibernate is adding
real metadata support (and presumably other tools will follow).  Did
you do all of this extraction manually?  Did you end up having to
manually maintain a lot of .hbm.xml files, and how did this compare to
the earlier XDoclet implementation?

cheers,
-adrian.
--
Adrian Powell
Centre for IBM e-Business Innovation :: Vancouver
apowell@xxxxxxxxxx / 604-297-3194

robert kuzelj <robert_kuzelj@xxxxxxxxx>
Sent by: aspectj-users-admin@xxxxxxxxxxx

01/17/2005 09:27 AM

Please respond to
aspectj-users

To	aspectj-users@xxxxxxxxxxx
cc
Subject	Re: [aspectj-users] AspectJ and metadata

hi adrian,

 >So my question for the group is: do you prefer to separate out these
 >sorts of concerns with AspectJ, or unify them with XDoclet or >metadata?

i guess there is a simple and and a more verbose aswer to this.

a) metadata for for example hibernate is certainly an aspect
    of a class and should therefore be separated into its own
    physical module so that the normal flow can be easily read.

b) so the question is not so much IF but WHEN. at which stage
    of your development process should you start to move metadata
    (be it xdoclet or annotations) into its own file?
    just to give you an example: our product (100kloc+ java and
    120kloc+ xml) started by using xdoclet for hibernate.
    this was very convinient at the beginning as we where just
    exploring features of what we where building. also we
    where new to hibernate. so changes to accessors where easily
    handled by xdoclet.
    now after almost 9 month and 100kloc java xdoclet was starting
    to get into our way. we had classes of 800 lines java. where
    200 were simple accessors, 300 lines where xdoclet and another
    300 where some sort of business-logic.
    so the most obvious way to cut down the size and make the
class
    maintainable again was to move the persistence aspect into
its
    own location (of course we split up the structure into its
own
    base class that was easily reused by other modules). this
was
    also easy as class(es) have become more stable and their
    underlying  persistence schemas as well. this of course
was
    also a natural effect as more and more clients were depending
    on the class as well as on the schema.

so what would really help is a sort of refactoring tool that would
be able to move annotations from a .java file into a .aj file
using "declare annotation".

ciao robertj



Adrian Powell wrote:
> 
> In the "Eclipse AspectJ" book, the integration between Hibernate
and 
> AspectJ came up several times, both in the initial example and then
> towards the end of the book where it is refactored to use Spring.
 The 
> example raises an interesting design philosophy question which I've
been 
> trying to hash out with collegues, but we haven't come up with any
> clinching arguments.
> 
> The problem is this: in our applications, we have been using XDoclet
to 
> add Hibernate information into our Java source files.  The goal
is 
> ostensibly to centralize the functions of a class into one location
so 
> that its functionality is clear and easier to maintain.  On the
other 
> hand, the AspectJ example goes the opposite direction and tries to
> separate out all of the Hibernate functionality.  In the XDoclet
> solution, we have a single .java file and an ant script which will
build 
> the .hbm.xml files.  In the AspectJ solution, we have a .java
file, a 
> .aj file, and a hand-coded .hbm.xml file.  I recognize that the
AspectJ 
> example is just that, an example, but it does have some interesting
> advantages.  With metadata entering Java 5, I think the issue
of how to 
> decompose and modularize a solution will continue to gain attention.
> 
> 
> 
> cheers,
> -adrian.
> --
> Adrian Powell
> Centre for IBM e-Business Innovation :: Vancouver
> apowell@xxxxxxxxxx / 604-297-3194

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