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

["Ted Neward" <ted@xxxxxxxxxx>]

> There's a major difference between deployment descriptor (for EJBs,
> for example) and aspects. In the first case, generally the
> configuration is already known by the one writing the component and it
> never make any sense to have to switch to a XML file to configure it.
> Most EJBs and DD-driven components are not reusable by nature.
>
The deployment descriptor wasn't necessarily all about defining component
semantics, though: a lot of it was pure configuration, which is something
that the developer generally doesn't know during development and which needs
to be configurable during runtime/production scenarios (including the
ability to change those settings on the fly). This isn't a scenario where
aspects should apply, yet isn't known by the one writing the component. The
XML file was created solely to have a standardized way of representing this
configuration information--the first approach, remember, was to have a
custom class serialized form. (Anybody else remember EJB 1.0? :-) )

> 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.

> 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.

Wes wrote:
> AspectJ 5, aside from generally supporting AspectWerkz, will introduce
> a limited form of configuration permitting binary abstract aspects to be
> concretized via XML.  This seems like the right approach in situations
> where there is separation between the roles of the aspect-writer
> and the aspect-deployer, and the "native language" of the application
> deployer is as much XML as it is Java.  However, the IDE support does not
> yet extend to the XML files (and runtime configuration means runtime
> errors),
> so there's still significant advantage to working within the programming
> language: to get one view of the crosscutting in the entire program.
>
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.

> If you are writing an AOP-based framework - genesis (
> https://genesis.dev.java.net ), which relies on AspectWerkz is one
> example -, you do want to define certain parts of your aspect in the
> source code itself, but you do want the end user to be able to write
> any pointcuts to want, choose which aspects to apply, change their
> deployment models, provide parameters etc., and all of this without
> changing the source code, which would simply prevent adoption
> depending on the license of your software.
>
See, that's where I find this argument somewhat facetious. 

There's a certain argument to be made (and frequently is) regarding the
application of an aspect, or rather, who is best qualified to decide where
and how an aspect should apply. Old versions of AspectJ very firmly came
down on the side of "the aspect writer has the best knowledge", whereas
other AOP frameworks (and the newer versions of AspectJ, apparently) seem to
say that the developer *using* the aspects has the better knowledge. This is
a critical question, as it essentially forces awareness of all the aspects
upon the developer writing the components/POJOs, whereas the old AspectJ
approach required that knowledge to rest solely with the aspect writer. (The
remainder of the development team could remain blissfully ignorant of the
fact that their code was being woven at all.)

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.

Ted Neward
Author, Instructor, Consultant
Java, .NET, Web services
http://www.neward.net/ted

> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-
> bounces@xxxxxxxxxxx] On Behalf Of Michael Nascimento
> Sent: Sunday, April 17, 2005 11:44 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: Re: [aspectj-users] Status of using XML config,as opposed to
> language-based annotations?
> 
> There's a major difference between deployment descriptor (for EJBs,
> for example) and aspects. In the first case, generally the
> configuration is already known by the one writing the component and it
> never make any sense to have to switch to a XML file to configure it.
> Most EJBs and DD-driven components are not reusable by nature.
> 
> 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.
> 
> 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.
> 
> If you are writing an AOP-based framework - genesis (
> https://genesis.dev.java.net ), which relies on AspectWerkz is one
> example -, you do want to define certain parts of your aspect in the
> source code itself, but you do want the end user to be able to write
> any pointcuts to want, choose which aspects to apply, change their
> deployment models, provide parameters etc., and all of this without
> changing the source code, which would simply prevent adoption
> depending on the license of your software.
> 
> So I guess both approaches are valuable, but external configuration
> files are essential for those writing AOP-based frameworks.
> 
> Regards,
> Michael Nascimento Santos
> https://genesis.dev.java.net/
> 
> On 4/17/05, Ted Neward <ted@xxxxxxxxxx> wrote:
> > Let me suggest that one of the strengths of AspectJ (as opposed to other
> > AOP-ish tools) is that it in fact does everything inside the language,
> as
> > opposed to external files like XML configuration files. One of the
> reasons
> > JSR 175 was formed was to do away with "external" code-like artifacts,
> like
> > deployment descriptors, and I'd hate to see us go back to a mechanism
> that
> > forces developers to keep code-like entities in two places at once.
> >
> > Ted Neward
> > Author, Instructor, Consultant
> > Java, .NET, Web services
> > http://www.neward.net/ted
> >
> > > -----Original Message-----
> > > From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-
> > > bounces@xxxxxxxxxxx] On Behalf Of Karr, David
> > > Sent: Friday, April 15, 2005 9:53 AM
> > > To: aspectj-users@xxxxxxxxxxx
> > > Subject: [aspectj-users] Status of using XML config,as opposed to
> > > language-based annotations?
> > >
> > > Correct me if I'm wrong, but I believe one of the basic differences
> > > between Aspectwerkz and AspectJ is that the former uses an XML file
> for
> > > configuring the pointcuts and aspects, but the latter uses
> > > language-based annotations for specifying the pointcuts.  I believe
> the
> > > fact that Aspectwerkz uses an XML file for pointcut specifications
> helps
> > > to facilitate its ability to do load-time weaving of third-party libs.
> > >
> > > As AspectJ moves forward with integrating features of Aspectwerkz,
> will
> > > it have the ability to specify the aspect integration entirely in an
> XML
> > > file, without requiring language extensions?  I'm hoping I can add
> > > aspects to pointcuts using pure Java code.  Will this be feasible with
> > > the final AspectJ 5.0?
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users