Re: [aspectj-users] Status of using XML config, as opposed to language-b

[Michael Nascimento <misterm@xxxxxxxxx>]

On 4/21/05, Ted Neward <ted@xxxxxxxxxx> wrote:
> > However, an aspect is (and most of the times should be) designed for
> > reusability, so it's important to be able to edit its pointcuts and/or
> > deployment model without touching source code, since aspects could -
> > and I guess they will be more and more - provided by a third party and
> > used more like a library by the final developer.
> >
> If that's the case, then maybe I've been doing Java wrong all these years,
> and I need to be able to configure base class and interface inheritance
> without touching source code, either. Right? (Touching source code is what
> we do; the suggestion that somebody's going to change aspect scenarios
> *without* calling this an intrusive change--and therefore requires awareness
> and intrusivity into the source--is the height of AOP fallacy, IMHO.)
> 
> Similarly, I'd love to see somebody use a library without touching source
> code.

Don't think you quite got it. I'll give you an example: I am one of
the developers of genesis. genesis is being used by our customers and
some other users. I can't think of two projects using genesis (that
I'm aware of, of course) that use exactly the same pointcut definition
or deployment model as our sample.

If users had to touch the aspects source code for that, I'd consider
it bad design. Besides that, most of them would be totally tainted by
LGPL by now (which we are tainted by, btw, but that's a whole
different issue). I'm glad AW allows users to change the way aspects
affect their classes without touching source code and I really would
like to see it in AJ as well.

> > It is obvious there are exceptions to both rules - reusable EJBs, for
> > example, or very specific aspects -, but it's good to be able to
> > override things in a configuration file.
> >
> Sounds like a configuration file is very quickly becoming a source file.

The larger configuration file for genesis I'm aware of is around 50
line long and is a write once file.

> I would find it hard to believe that there's a large difference between
> aspect-writer and aspect-deployer, for the same reason that there's never
> been a large difference between EJB-Author and EJB-Application Assembler, as
> they called it.

I can tell you from experience there is. Our users only know what
genesis aspects do and have learned the minimum they should from the
pointcut language. They cannot write an aspect and I don't think
there's any reason they _had to know_ in order to use our framework.
They could, of course, but that's different from being required to.

> But the fallacy here is that I want to expose any of this via a
> configuration file, because if it's in something that's NOT code, then it
> leads to the possibility that some non-developer (IT admin, perhaps?) could
> reach into this "configuration file" and fundamentally change the program
> itself, and last time I checked, that wasn't what config files were for.
> 
> Otherwise, we're fast approaching the scenario where we're going to have one
> line of source code, and 14,000 lines of configuration that tells that one
> line of source code what to do, and I can't for the life of me figure out
> why that's better than 14,000 lines of source code.
> 
> If you need the ability to change code without recompilation ("Because
> compilation takes too long", one manager once told me), then I humbly
> suggest you examine Ruby or CLOS for an environment that supports AOP-ish
> things, rather than Java, where compilation isn't even an issue.

I hope what I explained above makes you see my point. genesis aspects
module contains 1788 lines. The sample configuration file is 44 line
long. I don't see a problem here.

Regards,
Michael