Last response to myself:
Brian Stansberry wrote:
> The "addModule" method isn't being called either. Neither callback is
> happening; only the call to registerModule made by
> JBossClDelegatingClassPoolFactory.create(...) happens.
>
> Is the VFSDeploymentClassLoaderPolicyModule an MC bean?
>
No, it's not. It's a DeploymentUnit attachment created by
VFSClassLoaderDescribeDeployer. MC is unaware of it, so no
install/uninstall callbacks are made.
Afaik, the callback mechanism only applies to
<classloader ...> element, which is parsed into 2 BeanMetaData(s).
See VFSClassLoaderFactory in JBoss Classloading.
One of those beans is a VFSClassLoaderPolicyModule, which is Module's
subclass.
This one gets picked up by the ClassLoading (and Kabir) bean's callback
mechanism.
For the deployment's Module, as Brian noted, it doesn't register against MC.
But it still registers with ClassLoading bean - programmatically in
AbstractClassLoaderDescribeDeployer.
Perhaps a solution would be to have some ModuleRegistry interface
(with add/removeModule methods) + AbstractClassLoaderDescribeDeployer
would keep a record of them via MR's callback.
e.g.
<bean name="ClassLoaderDescribeDeployer"
class="org.jboss.deployers....AbstractClassLoaderDescribeDeployer">
<incallback method="addModuleRegistry"/>
<uncallback method="removeModuleRegistry" />
</bean>
and then instead of just registering newly created deployment's Module
against ClassLoading (which would implement MR),
we would register it against all MR's, Kabir's being one of those.
// Create the module
ClassLoaderPolicyModule module = createModule(unit, deployment);
if (module != null)
{
// pseudo (need to handle possible exception, rollingback ...)
for (MR mr : mrs)
mr.addModule(module);
unit.addAttachment(Module.class, module);
}
> Brian Stansberry wrote:
>> Hmm, perhaps that's not it then -- at least not directly. A debugger
>> shows me that method isn't called. But there's other stuff on that
>> report; so perhaps the Module isn't uninstalled properly. I'll keep
>> poking tonight.
>>
>> Kabir Khan wrote:
>>> Actually, RegisterModuleCallback.removeModule() should be called by
>>> the MC. From bootstrap/aop.xml:
>>> <bean name="AOPRegisterModuleCallback"
>>>
class="org.jboss.aop.asintegration.jboss5.RegisterModuleCallback">
>>> <incallback method="addModule"
state="Installed"/>
>>> <uncallback method="removeModule"
state="Installed"/>
>>> </bean>
>>>
>>> Anyway, I'll have a proper look tomorrow
>>>
>>> On 1 Apr 2009, at 20:02, Brian Stansberry wrote:
>>>
>>>> I've been looking into the cause of the classloader leak test
>>>> failures[1] and am seeing leaks leading through
>>>>
org.jboss.aop.asintegration.jboss5.RegisterModuleCallback.registeredModules
>>>>
>>>>
>>>> Looking further into it, I see
>>>> RegisterModuleCallback.registerModule(Module) is called, but
>>>> nowhere is removeModule(Module) called. The registerModule call is
>>>> from JBossClDelegatingClassPoolFactory.create(...).
>>>>
>>>> [1]
>>>>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test...
>>>>
>>>>
>>>> Kabir Khan wrote:
>>>>> I've released AOP 2.1.0.CR2 and upgraded AS Branch_5_x to use
that
>>>>> On 1 Apr 2009, at 18:38, Jason T. Greene wrote:
>>>>>> Great thanks.
>>>>>>
>>>>>> Kabir Khan wrote:
>>>>>>> It seems the classloader used to deploy the tx, security etc.
>>>>>>> aspects is wrong so it cannot find the base-aspects.xml file
>>>>>>> before running these tests. I'll fix and deploy a new
CR.
>>>>>>> On 1 Apr 2009, at 11:13, Kabir Khan wrote:
>>>>>>>> I tested these when I commited, and reverting my local
copy to
>>>>>>>> my last commit (revision 86202) the aop tests all work.
It must
>>>>>>>> be something commited later. The main problems are
anything
>>>>>>>> involving the transaction aspects (ScopedUnitTestCase,
>>>>>>>> ScopedAttachUnitTestCase, TxLockTestCase, TxTestCase,
>>>>>>>> VersionedObjectTestCase) and security aspects
>>>>>>>> (SecurityUnitTestCase).
>>>>>>>>
>>>>>>>> Looking at the changes to thirdparty jars nothing springs
out
>>>>>>>>
http://fisheye.jboss.com/browse/~br=Branch_5_x/JBossAS/branches/Branch_5_...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 31 Mar 2009, at 12:20, Kabir Khan wrote:
>>>>>>>>
>>>>>>>>> Sure
>>>>>>>>> On 30 Mar 2009, at 21:30, Jason T. Greene wrote:
>>>>>>>>>
>>>>>>>>>> Kabir Khan wrote:
>>>>>>>>>>> I have upgraded Branch_5_x to use AOP
2.1.0.CR1 and switched
>>>>>>>>>>> to use the new classpools that understand AS
classloading
>>>>>>>>>>> better. If there are no problems I'll do
a GA over the next
>>>>>>>>>>> week or so
>>>>>>>>>>
>>>>>>>>>> It looks like a number of AOP tests are now
failing after
>>>>>>>>>> this update. Can you look into these?
>>>>>>>>>>
>>>>>>>>>>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jason T. Greene
>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> jboss-development mailing list
>>>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> jboss-development mailing list
>>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jason T. Greene
>>>>>> JBoss, a division of Red Hat
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Lead, AS Clustering
>>>> JBoss, a division of Red Hat
>>>> brian.stansberry(a)redhat.com
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
>
>