-
1. Re: Integration of aop/aspects into JBAS and other projects
ben.wang Apr 15, 2005 1:57 PM (in response to starksm64)Well, this is not exactly as an Aspect. But rather an switch inside Tomcat.
Still, I have a tc5-clutster.aop jar that needs to deploy under all/deploy. In addition, I need to access it from testsuite so my POJO can precompile with annotationc and aopc.
What's the best practice? -
2. Re: Integration of aop/aspects into JBAS and other projects
ben.wang Apr 17, 2005 3:02 AM (in response to starksm64)I am going ahead to create a tomcat module so I can reference it from testsuite. In addition, I am deploying tc5-cluster.aop (has jboss-aop.xml) under all/deploy. This is needed for http session fine-grained replication using aop.
I can modify the setup later on if there is a need. -
3. Re: Integration of aop/aspects into JBAS and other projects
adrian.brock Apr 18, 2005 10:44 AM (in response to starksm64)I believe the aspects belong in the module that implements them.
This is the only approach that will allow the aspect to evolve across versions
rather than trying to maintain a monolithic single integration package
jboss-aspects.
The aspect requires the rest of the implementation anyway, e.g. the
authentication/authorization advices require jbosssx. -
4. Re: Integration of aop/aspects into JBAS and other projects
bill.burke Apr 18, 2005 11:36 AM (in response to starksm64)It has actually been much easier to package it as this "monolithic" aspect library over the past few years. If there is a bug or feature addition in any of the aspects in the library, I can easily patch any version of JBoss. It would actually be more "monolithic" if the code was part of Branch_4_0 as I would not be able to do a new release of the aspect library (and EJB 3.0 for instance) without a complete rev of the entire application server. This is quite unacceptable to most users.
So, in summary, although I think it might be asthetically appropriate, I don't see how this change you suggest will make anybody's life easier. It sure will make the EJB3/AOP team's life much harder to do new releases. -
5. Re: Integration of aop/aspects into JBAS and other projects
starksm64 Apr 18, 2005 11:44 AM (in response to starksm64)A standalone release of aop which includes a security aspect depending on the implementation details of jboss-4.0.x makes no sense.
-
6. Re: Integration of aop/aspects into JBAS and other projects
adrian.brock Apr 18, 2005 11:57 AM (in response to starksm64)"bill.burke@jboss.com" wrote:
It has actually been much easier to package it as this "monolithic" aspect library over the past few years.
Ok, one contra example is code to integrate the deployer/classloader across versions:
http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-aspects/src/main/org/jboss/aop/deployment/If there is a bug or feature addition in any of the aspects in the library, I can easily patch any version of JBoss.
How so, are you going to keep up and supply different versions of these advices
as the internal api changes?
It would actually be more "monolithic" if the code was part of Branch_4_0 as I would not be able to do a new release of the aspect library (and EJB 3.0 for instance) without a complete rev of the entire application server.
You need the implementation library anyway for the aspect to work. And the
implementation details (non-published api like SecurityAssociation) is going to
evolve independently across versions.
So, in summary, although I think it might be asthetically appropriate, I don't see how this change you suggest will make anybody's life easier.
Aesthetics are not an issue, it is about each module being responsible for
its own implementation.
It sure will make the EJB3/AOP team's
The EJB3/AOP team should concentrate on delivering containers and the invocation
model, not how to integrate security.
And see above about needing jbosssx.jar anyway.
This is the same mentality that led to the JBossCache project becoming bloated. -
7. Re: Integration of aop/aspects into JBAS and other projects
adrian.brock Apr 18, 2005 12:10 PM (in response to starksm64)The integration point is the annotation (which also belongs in JBossSX)
and that needs to be consistent with the features provided by each version.@SecurityDomain("other") @NewSecurityFeatureNotAvailableInJBoss32 // Shouldn't compile under 3.2.x public void doSomething() { }