[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] AspectJ and JBoss AOP implementation

> I don't think this is true, you can get the api and the classloader and use
> them in any other set up. That's what the JBoss site says.

That's true, but it's not clear that you can deploy a JBoss
classloader on any significant commercial J2EE application
server.  And no answer, so far, to whether JBoss AOP could be
staticly woven:


To do static weaving would mean coming up with a way to
instantiate the aspects for every client at runtime.

Conversely, aspects in AspectJ do not communicate or
implement cflow across remote invocation layers, unless you
do work to make that happen yourself.  See FAQ on J2EE:


I'd be interested in knowing whether JBoss aspects do by default.


Arun Natarajan wrote:

"vendor (read platform) lock-in" ???
I don't think this is true, you can get the api and the classloader and use
them in any other set up. That's what the JBoss site says.

Arun N
-----Original Message-----
From: aspectj-users-admin@xxxxxxxxxxx
[mailto:aspectj-users-admin@xxxxxxxxxxx]On Behalf Of Nikhil Kumar
Sent: Thursday, January 22, 2004 9:24 AM
To: aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] AspectJ and JBoss AOP implementation

The key issues that I have seen with the JBOSS AOP solution from a commercial adoption perspective.

The first issue is the association with the server.
For example my corporate standard server may be BEA
WLS or IBM WAS then JBOSS AOP adoption is going to
have a lot of roadblocks.  At previous clients, this
would be a very clear reason for pushback from most
corporate IT governance (architecture standards)

The second issue is that AspectJ "weaves" the code in
- i.e. it is a compile-time solution, whereas JBOSS
AOP is a run-time solution. I know at my current
client there was a refusal to use JBOSS AOP over this
issue.  Key arguments given against the use of JBOSS
AOP were reliability, potential class-loader issues,
and potential performance risks with a run-time

Thirdly there is the issue of industry acceptance and
standards.  Currently there seems to be an acceptance
of AspectJ as the direction in which AOP programming
will go and with a great likelihood of it becoming the
industry standard.  There will always be other AOP
implementations, but, similar to C++/ Smalltalk
adoption, it is more likely that AspectJ will become
the initial leader and that the other solutions will
become the Smalltalks of the AOP world.

Fourthly there is the issue of portability (tied to
the 3rd issue) and vendor (read platform) lock-in.
AspectJ is tied to Java (a standard that is
extensively used) and is not tied to a particular
platform/ app. server.

I would recommend that the key "features" that seem to
be compelling in terms of JBOSS AOP, namely
declarative configuration may be adopted by AspectJ,
but again only incorporated into the compile time.
What I mean is that AspectJ programs be able to
support the declarative semantics and then weave that
into components that are used to deply to existing
technologies that are used for hot-deployment.  For
e.g. have the ability to declaratively configure
AspectJ so that you can then compile and deploy a
framework with that capability, wrap it in a component
model (make it an EJB for example) and then deploy
using the current component model standards
hot-deployment support.

Finally here is one more comment:
There does not seem to be the requisite support from
industry and standards organizations.  One of the
things that spurred adoption of XML was the compelling
industry support.  I do not see anything like the
ISO/IEEE/ACM or commercial groups pursuing this. Nor
is there something similar to the JCP. Practically
there will need to be industry support to propel this
into the mainstream.

--- Gregor Kiczales <gregor@xxxxxxxxx> wrote:

Arun Natarajan said:

Has someone recently evaluated AspectJ and the


implementation? I read some old papers talking


the performance related issues with JBoss, but any
other differences? JBoss seems to be more easy to


than AspectJ.

I've seen this said a number of times, that JBoss (and AspectWerkz) are easier to learn than AspectJ. And it shows up in various press articles, where people just repeat what others have said to them.

But I know many people disagree -- that is, many
people think AspectJ
is easier to learn. So I'd like to ask (and perhaps
start a discussion).

Why do you say that JBoss seems easier to learn than

_______________________________________________ aspectj-users mailing list aspectj-users@xxxxxxxxxxx


__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ _______________________________________________ aspectj-users mailing list aspectj-users@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/aspectj-users

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