[Design of AOP on JBoss (Aspects/JBoss)] - VFSClassLoaderScopingPolicy needs updating
by adrian@jboss.org
I'm trying to figure out how to fix the VFSClassLoaderScopingPolicy
with the new rules for WAR classloading deployments.
The way it works now is that when a war gets deployed, there's a seperate
deployer that decides whether WARs (subdeployments) should be scoped.
They are by default.
If this is the case, then the war subdeployment will have its own Module
and its own Domain.
You shouldn't need any hacks anymore for "isWar" or "isWebCL"
or looking at the top level classloader. All you need to know is whether
Module.determineDomain() is not the default domain (therefore it is scoped)
and Module.determineParentDomain() to know what it is scoped against.
Of course most subdeployments other than wars will use the top level
classloader of the whole deployment.
I was trying to figure out what needs changing, but I got lost. :-)
OFF TOPIC
One thing I did find is this code in JBoss5ClassPoolFactory
| //It is scoped
| ClassLoaderSystem sys = ClassLoaderSystem.getInstance();
|
| ClassLoaderDomain domain = sys.getDomain(module.getDeterminedDomainName());
| boolean parentFirst = module.isJ2seClassLoadingCompliance();
|
That isn't necessarily correct. It's configurable in bootstrap-beans.xml
what the ClassLoaderSystem is.
It look's like the only reason you do this
is to get the domain, because you're still doing that horrible code
that tries to determine scoping rules based on whether the resource
visibile to the domain is the same as the resource from the classloader.
Like I said before, this isn't going to work if the classloader doesn't export the class.
Probably what you really want is something like the new JMX operation on the domain
findClassLoaderForClass()
except starting from the classloader you're handling rather than the domain?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138806#4138806
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138806
18 years
[Design of POJO Server] - AnnotatedClassFilter is wrong + AOP
by adrian@jboss.org
The AnnotatedClassFilter has a number of problems.
1) It doesn't understand about "subdeployments" or in this particular case
that WEB-INF and WEB-INF/classes are in the classpath
e.g.
| 2008-03-25 18:17:10,505 DEBUG [org.jboss.classloader.spi.base.BaseClassLoader] (RMI TCP Connection(16)-127.0.0.1) Created BaseClassLoader@1e3b325{vfsfile:/home/ejort/j
| boss-head/testsuite/output/lib/aop-scopedear1.ear/aop-scopedear1.war} with policy
| ...
| JarEntryContents(a)27626654[path=aop-scopedear1.war/WEB-INF/classes JarEntryContents(a)28507864[path=aop-scopedear1.war/WEB-INF
| ...
|
It tries to load each class twice
| 2008-03-25 18:17:10,594 ERROR [STDERR] (RMI TCP Connection(16)-127.0.0.1) [error] Error converting class .. Do verbose mode if you want full stack trace.
| 2008-03-25 18:17:10,595 DEBUG [org.jboss.deployment.AnnotatedClassFilter] (RMI TCP Connection(16)-127.0.0.1) Incomplete class: classes.org.jboss.test.aop.scoped.ear.se
| rvlet.EarExampleServlet, NCDFE: java.lang.NoClassDefFoundError: classes/org/jboss/test/aop/scoped/ear/servlet/EarExampleServlet (wrong name: org/jboss/test/aop/scoped/
| ear/servlet/EarExampleServlet)
|
Also, I don't think it understands how AOP is done?
2) With AOP there is also an in memory virtual file to store classes
that AOP has weaved. I think this is going to lead to the classes getting
processed twice? Once using the non-weaved version then using the
weaved version?
Which brings up another unrelated issue in that at the moment,
I believe the in memory virtual file is after the unweaved virtual file in the classpath?
3) The current way of scanning classes for annotations is not scalable
(or even extensible).
It loads a collection of all classes found then runs each class through
the processors. This should be a true visitor pattern otherwise a deployment
with thousands of classes is possibly going to run out memory?
4) It doesn't take into account the classloading policy in that some parts of
the classpath could be excluded by filters.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138798#4138798
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138798
18 years
[Design of EJB 3.0] - Re: @SecurityDomain changes from AS42 to AS5
by alessio.soldano@jboss.com
"wolfc" wrote : "alessio.soldano(a)jboss.com" wrote : Do you mean that the 4.2 package (org.jboss.annotation.security.SecurityDomain) was theoretically not good too?
| Yes, the package name should reflect the defining artifact or domain. Thus we can make sure there is no class name overlap.
| "anil.saldhana(a)jboss.com" wrote : I did not create the annotation. I also did not refactor them or move them. I have just taken the task of cleaning up the ejb3 security integration for AS5. Given this, I feel for AS5, the annotation should be in the security spi project.
| As long as this doesn't create a dependency loop that would be perfect.
|
OK, thanks, if/when the annotation is actually moved to the security spi project, could you please link this to a jira issue and post it here?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138778#4138778
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138778
18 years