November 2009 - jboss-dev-forums - Jboss List Archives

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"flavia.rainone(a)jboss.com" wrote : But I'm not sure about a deployer that is only used for calling initMapsForLoader. I see Ales answered that question before I pressed the submit button :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264321#4264321 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264321

14 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"kabir.khan(a)jboss.com" wrote : org.jboss.aop.asintegration.jboss5.AOPClassLoaderDeployer is set up in AS to do this. | | It calls AOPClassLoaderInitializer.initializeForUnit() which in turn ends up in DomainRegistry.initMapsForLoader() Yes, but that's something AOP-related. I want to have an approach that is independent of JBoss AOP. I plan to split that DomainRegistry related stuff away from AOP, as it is now a classpool related thing (the new AOP impl that uses the classpool project contains already a split, but I think I'll work some more on that before considering it done). Do you think that using a deployer for only calling DomainRegistry.initMapsForLoader is appropriate? I see that AOPClassLoaderDeployer adds the AspetManager as an attachment to the unit, which IMO justifies the need for a deployer. But I'm not sure about a deployer that is only used for calling initMapsForLoader. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264319#4264319 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264319

14 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by alesj

"kabir.khan(a)jboss.com" wrote : org.jboss.aop.asintegration.jboss5.AOPClassLoaderDeployer is set up in AS to do this. | | It calls AOPClassLoaderInitializer.initializeForUnit() which in turn ends up in DomainRegistry.initMapsForLoader() We should do this w/o AOP being present. And as Flavia suggests - and which is correct, as CLs/Modules can bypass Deployers - this should be done via ModuleRegistry - as I described it in my previous post. I guess this calls for a test that would create a CL from -beans.xml, and see if the Classpools still work. Flavia, will you create one or should I, and you just fix the issues if they are present? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264318#4264318 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264318

14 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by alesj

"flavia.rainone(a)jboss.com" wrote : I thought on using a ModuleRegistry, but I can't find out how to get to the parameters required for initMapsForLoader from the module. I'm clueless on what is the correct approach for calling initMapsForLoader method. Any ideas? ModuleRegistry gets Module passed in. Perhaps this then: | ClassLoader cl = ClassLoading.getClassLoaderForModule(module); | DeploymentUnit unit = AbstractDeploymentClassLoaderPolicyModule.class.cast(module).getDeploymentUnit(); | ClassLoader parentUnitLoader = unit.isTopLevel() ? null : unit.getParent().getClassLoader(); | Dunno how we would then handle if you register CL directly in -beans.xml --> VFSClassLoaderPolicyModule. But I guess this falls into parentUL = null category. | ClassLoader cl = ClassLoading.getClassLoaderForModule(module); | DeploymentUnit unit = null; | if (module instance of AbstractDeploymentClassLoaderPolicyModule) | unit = AbstractDeploymentClassLoaderPolicyModule.class.cast(module).getDeploymentUnit(); | ClassLoader parentUnitLoader = unit == null || unit.isTopLevel() ? null : unit.getParent().getClassLoader(); | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264316#4264316 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264316

14 years, 6 months

1
0
0 / 0

[JBoss Tools Development] - Re: Integrate with XText/JET/Xpand: Drop Freemarker as gener

by max.andersen＠jboss.com

Does it run from ant without massive dependencies and overhead ? If not, then no. And are you willing to migrate all our templates to JET or Xpand ? Stuff like this does not happen without someone with the time to do it. Plus the fixes we got waiting in freemarker component did not work when I applied them last (too many changes in one patch). Care to make them smaller so we can apply them ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264314#4264314 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264314

14 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by kabir.khan＠jboss.com

org.jboss.aop.asintegration.jboss5.AOPClassLoaderDeployer is set up in AS to do this. It calls AOPClassLoaderInitializer.initializeForUnit() which in turn ends up in DomainRegistry.initMapsForLoader() View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264313#4264313 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264313

14 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"flavia.rainone(a)jboss.com" wrote : I think that we should look into the class pool tests and see what they are missing before we proceed to deployers tests. I'll start adding a test to reproduce the failure I caught yesterday. This is related to JBREFLECT-65. As a matter of fact, I found out that there is already a test that should catch this failure in the classpool tests. The tests Kabir wrote are very complete :) The difference between the classpool test environment and the deployers one is that this one is lacking the calls to DomainRegistry.initMapsForLoader(loader, module, parentUnitLoader) method. Fixing that completely replaces the ugly hack, because parentUnitLoader is the loader we want when defining the parent of a class pool domain. In JBoss AOP, the initMapsForLoader method is invoked by the AOPClassLoaderInitializer class. This class is indirectly invoked by the AOPDeployer and uses the DeploymentUnit to get to the arguments needed for initMapsForLoader. I've created a temporary deployer to test this on ClassPoolTestCase: public void deploy(VFSDeploymentUnit unit) throws DeploymentException | { | if (unit.isTopLevel() || unit.getParent().getClassLoader() != unit.getClassLoader()) | { | //Only bother doing all this if we are a different loader from the parent unit | Module module = getModuleRecursively(unit); | if (module == null) | { | throw new IllegalStateException("No " + Module.class.getName() + | " attachment could be found in the following deployment unit or its parents: " + unit); | } | ClassLoader parentUnitLoader = unit.isTopLevel() ? null : unit.getParent().getClassLoader(); | domainRegistry.initMapsForLoader(unit.getClassLoader(), module, parentUnitLoader); | } | } It works :). However, I'm afraid this is not the correct way of doing this. We are not deploying anything at all, only registering the classloader structure created for the deployed unit. I thought on using a ModuleRegistry, but I can't find out how to get to the parameters required for initMapsForLoader from the module. I'm clueless on what is the correct approach for calling initMapsForLoader method. Any ideas? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264309#4264309 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264309

14 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: AS weld-int

by alesj

"kabir.khan(a)jboss.com" wrote : | Should I rename KCCC to something more descriptive like BeanMetaDataDeployerPlugin? I guess so, as we don't just create KCC anymore. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264307#4264307 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264307

14 years, 6 months

1
0
0 / 0

[Clustering Development] - Re: mod_cluster version problem

by bstansberry＠jboss.com

Suggest you post on the mod_cluster user forum at http://www.jboss.org/index.html?module=bb&op=viewforum&f=288 where more people may see it and help. I'm going out in a minute so have no time for a full reply, but will say this: That message is coming from JGroups, not from mod_cluster itself. One *possibility* is one of the JBoss AS clustering channels is inadvertently picking up the "advertise" multicasts that httpd can send out if the "advertise" feature is enabled. If so, that becomes a configuration issue to separate the traffic. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264255#4264255 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264255

14 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: AS weld-int

by kabir.khan＠jboss.com

Cool, Should I rename KCCC to something more descriptive like BeanMetaDataDeployerPlugin? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264176#4264176 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264176

14 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2009