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.
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
A standalone release of aop which includes a security aspect depending on the
implementation details of jboss-4.0.x makes no sense.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3874332#3874332
Reply to the post :
[EMAIL PROTECTED] 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:
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()
| {
| }
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.
View the
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?
View the
