[jboss-dev] Re: AOP 2.1.0 in AS 5?

Thu Apr 2 04:09:35 EDT 2009

> 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-testSuite-sun15/169/testReport/org.jboss.test.classloader.leak.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_x/component-matrix/pom.xml?r1=86546&r2=86201 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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-testSuite-sun15/lastBuild/testReport/ 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> Jason T. Greene
>>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> jboss-development mailing list
>>>>>>>>>> jboss-development at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> jboss-development mailing list
>>>>>>>>> jboss-development at 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 at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>>>
>>>>> -- 
>>>>> Brian Stansberry
>>>>> Lead, AS Clustering
>>>>> JBoss, a division of Red Hat
>>>>> brian.stansberry at redhat.com
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>>
>>
>>
> 
> 