Re: [jboss-user] [JBoss Microcontainer] - Using a deployer to add jars to a webapp classpath.
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] replied to the discussion
"Using a deployer to add jars to a webapp classpath."
To view the discussion, visit: http://community.jboss.org/message/536381#536381
--------------------------------------------------------------
> Stan Silvert wrote:
>
> But in AS6, Tomcat is no longer able to load the JSF impl classes. The only reason it finds JBossJSFConfigureListener is because I unjarred the class and put it in the root of deployers/jsf.deployer:
>
> > 14:13:54,446 INFO http://community.jboss.org/message/536136#536136/TomcatDeployment http://community.jboss.org/message/536136#536136/TomcatDeployment deploy, ctxPath=/jboss-jsf-20test-jsfunit
> > 14:13:54,507 ERROR [[/jboss-jsf-20test-jsfunit]] Error configuring application listener of class org.jboss.jsf.integration.config.JBossJSFConfigureListener: java.lang.NoClassDefFoundError: com/sun/faces/config/ConfigureListener
> > at java.lang.ClassLoader.defineClass1(Native Method)
> > at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
> > at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
> > at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLo
> > ader.java:70)
> > at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.
> > java:668)
> > at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.
> > java:627)
> > at java.security.AccessController.doPrivileged(Native Method)
> > at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseC
> > lassLoader.java:626)
> > at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseC
> > lassLoader.java:603)
>
>
A really wild guess (since I haven't really looked at this deployer in detail) - The TomcatDeployer (or the entity which is trying to configure the listener class) perhaps isn't using the deployment unit's classloader and instead is using the server level classloader (which doesn't contain those jsf jars in the classpath).
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536381#536381]
Start a new discussion in JBoss Microcontainer at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[JBoss Microcontainer] - How to avoid canonical conversion of AbstractInjectionValueMetaData's value?
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] created the discussion
"How to avoid canonical conversion of AbstractInjectionValueMetaData's value?"
To view the discussion, visit: http://community.jboss.org/message/536376#536376
--------------------------------------------------------------
I have got a piece of code which deploys a MC bean into the kernel:
String beanName = "abc";BeanMetaDataBuilder builder = BeanMetaDataBuilderFactory.createBuilder(beanName, MyClass.class.getName());String constructorParamMCBeanName = "jboss.domain:m=xyz,c=pqr" builder.addConstructorParameter(SomeClass.class.getName(), new AbstractInjectionValueMetaData(constructorParamMCBeanName));
So effectively, it's creating a MC bean for MyClass which accepts an instance of SomeClass as its constructor param:
public class MyClass{ public MyClass(SomeClass param) { ... }}
The SomeClass instance which itself is a MC bean with MC bean name "jboss.domain:m=xyz,c=pqr" gets deployed by some other piece of code.This is simple enough and should have worked. But it doesn't. When the "abc" MC bean is installed, it runs into:
DEPLOYMENTS MISSING DEPENDENCIES: Deployment "abc" is missing the following dependencies: Dependency "jboss.domain:c=pqr,m=xyz" (should be in state "Installed", but is actually in state "** NOT FOUND Depends on 'jboss.domain:c=pqr,m=xyz' **")
Notice that the (injection) dependency MC bean name has been converted to a canonical name. Shouldn't have happened.But looking at the constructor of AbstractInjectionValueMetaData, a call to new AbstractInjectionValueMetaData(constructorParamMCBeanName), leads to:
public AbstractValueMetaData(Object value) { setValue(value); } public void setValue(Object value) { Object jmxHack = null; if (isUseJMXObjectNameFix()) jmxHack = JMXObjectNameFix.needsAnAlias(value); if (jmxHack != null) this.value = jmxHack; else this.value = value; flushJBossObjectCache(); } /** * Do we use jmx object name fix. * * @return do we use jmx object name fix */ protected boolean isUseJMXObjectNameFix() { return true; }
The isUseJMXObjectNameFix always returns true and then JMXObjectNameFix.needsAnAlias(value) converts the MC bean name to its canonical form. I see no way to prevent this from happening (other than create a subclass - which is a bit too much to do for this simple usecase). Am I missing something? Or is there some other way to get around this?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536376#536376]
Start a new discussion in JBoss Microcontainer at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years