[jboss-dev] Re: AOP 2.1.0 in AS 5?
Ales Justin
ales.justin at gmail.com
Thu Apr 2 06:44:36 EDT 2009
I've actually just changed ClassLoading
to have a set of ModuleRegistry-ies.
- https://jira.jboss.org/jira/browse/JBCL-96
public void addModule(Module module)
{
if (module == null)
throw new IllegalArgumentException("Null module");
String domainName = module.getDeterminedDomainName();
boolean parentFirst = module.isJ2seClassLoadingCompliance();
String parentDomainName = module.getDeterminedParentDomainName();
Domain domain = getDomain(domainName, parentDomainName, parentFirst);
domain.addModule(module);
Set<ModuleRegistry> added = new HashSet<ModuleRegistry>();
try
{
for (ModuleRegistry mr : moduleRegistries)
{
mr.addModule(module);
added.add(mr);
}
}
catch (Exception e)
{
for (ModuleRegistry mr : added)
{
try
{
mr.removeModule(module);
}
catch (Exception ignored)
{
}
}
module.release();
throw new IllegalArgumentException("Exception while
registering Module.", e);
}
}
public void removeModule(Module module)
{
if (module == null)
throw new IllegalArgumentException("Null module");
for (ModuleRegistry mr : moduleRegistries)
{
try
{
mr.removeModule(module);
}
catch (Exception e)
{
log.warn("Exception unregistering module, registry: " + mr
+ ", cause: " + e);
}
}
module.release();
}
We also need to add another callback to ClassLoading:
<incallback method="addModuleRegistry"/>
<uncallback method="removeModuleRegistry"/>
Then all you need to do is to implement ModuleRegistry. ;-)
Ales Justin wrote:
>> 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
>>>>
>>>>
>>>
>>>
>>
>>
>
More information about the jboss-development
mailing list