[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] AspectJ and JBoss AOP implementation
|
Arun,
I agree with Wes. The other key points to keep in
mind are:
1. From a Standards and Architecture perspective,
using the JBOSS AOP solution becomes pracitcally like
using a product/ framework to be embedded in the App
Server's (whichever one) environment. To have
Enterprise-wide adoption this can be a major issue.
Especially as most App Server vendors will provide
their own framework (e.g. BEA) as AOP is not a part of
the J2EE spec. Obviously support for JBOSS AOP will
be bottom of their agenda.
2. Integration with every App. Server platform
releases now becomes an issue. Whereas the binding of
AspectJ to the Java platform reduces the domain and
makes it a problem for the AspectJ group to keep up,
not that of a particular corporation.
3. Why would I like to replace programming language
semantics with a declarative structure? It would be
acceptable to provide declarative encapsulation of
advices for example, if I were planning to be able to
hot-deploy/ replace advices. However I would still
like to have the ability to program in a progamming
langauge - it is just simpler and easier to do. That
is why while we have J2EE descriptors to describe
defined, repetitive actions, we dont replace Java with
J2EE deployment descriptors.
Again, I have to caveat with I dont have much
experience with JBOSS AOP, though I do intend to test
it out soon. Also, JBOSS AOP needs JBOSS 4.X which is
still not a production release ( another reason why I
could not consider it in my project).
I would also like to note that I do not have a problem
with JBOSS as an Application Server/ EJB engine. I am
using it for my client, will be using it in my
products, etc. I have also used BEA, Websphere, etc.
for years and while JBOSS does not have the adoption
of those App Servers, it will become a valid player
(similar to Tomcat and Apache).
Regards,
Nikhil
--- Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:
> > 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:
>
>
>
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=44473
>
> 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:
>
>
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/aspectj-home/doc/faq.html#q:aspectjandj2ee
>
> I'd be interested in knowing whether JBoss aspects
> do by default.
>
> Wes
>
> 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.
> >
> > Regards,
> > 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)
> > groups.
> >
> > 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
> > implementation.
> >
> > 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.
> >
> > Regards,
> > Nikhil
> > --- Gregor Kiczales <gregor@xxxxxxxxx> wrote:
> >
> >>Arun Natarajan said:
> >>
> >>
> >>>Has someone recently evaluated AspectJ and the
> >>
> >>JBoss
> >>
> >>>implementation? I read some old papers talking
> >>
> >>about
> >>
> >>>the performance related issues with JBoss, but
> any
> >>>other differences? JBoss seems to be more easy to
> >>
> >>learn
> >>
> >>>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?
> >>
> >>
> >>_______________________________________________
> >>aspectj-users mailing list
> >>aspectj-users@xxxxxxxxxxx
> >>
> >
> >
>
http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >
> > __________________________________
> > 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
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
