[
https://jira.jboss.org/jira/browse/JBAS-6032?page=com.atlassian.jira.plug...
]
Kabir Khan closed JBAS-6032.
----------------------------
Fix Version/s: JBossAS-5.0.0.GA
Resolution: Done
I have reworked the existing aop classpools to do this as shown in the linked issue. The
plan is to completely replace this: JBAOP-666
Refactor AOPClassLoaderDeployer
--------------------------------
Key: JBAS-6032
URL:
https://jira.jboss.org/jira/browse/JBAS-6032
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: AOP
Reporter: Kabir Khan
Assignee: Kabir Khan
Fix For: JBossAS-5.0.0.GA
From devlist
http://lists.jboss.org/pipermail/jboss-development/2008-October/012613.html
Kabir, can you modify your deployer to specify
java.lang.ClassLoader as an input instead of using the relative
ordering.
Also this deployer says it needs a VFS deployment.
Other than the names used within AOP;
ScopedVFSClassLoaderDomain
VFSClassLoaderDomainRegistry
I don't see any dependency on the VFS api?
It might have done in the past until we refactored the
way in the memory url part of the classpath is done?
Finally, this still hasn't been updated to understand
how subdeployment classloaders work. It should be asking
whether the (sub-)deployment has an
org.jboss.classloading.spi.dependency.Module
attachment and hence its own classloader.
Even the old code which has some hardwiring for JBossWebMetaData
looks broken since it only unregisters top level deployment
classloaders in undeploy() ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira