You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Richard Wallace <rw...@thewallacepack.net> on 2006/03/17 18:23:18 UTC
NoClassDefFoundError deployment errors
Greetings all,
I'm new to Geronimo. I'm trying to deploy one of my web applications
that had previously just been deployed in a standalone tomcat container
in Geronimo 1.0. I've tried this with both the version with Jetty and
with Tomcat bundled. The web app uses a Hibernate/Spring/JSF framework
stack. The jars for each project are bundled in the war file in the
WEB-INF/lib directory.
But when I deploy the application I'm getting NoClassDefFoundErrors for
javax/faces/el/VariableResolver and org/hibernate/HibernateException.
Any ideas what I'm missing here?
Thanks,
Rich
Re: NoClassDefFoundError deployment errors
Posted by Brill Pappin <jo...@gmail.com>.
You and me both!
I find I'm actually disapointed that it's not following the spec...
after all, how else do we ensure that our portable code can run on
Geronimo?
Who do I have to poke, bug and generally hastly to get this choice reviewed?
Yes, I can be mouthy, and I do appreciate all the hardwork thats gone
into Geronimo, but I'd also like to be able to use it and as I
mentioned in another post, not a single webapp that I've tried runs
without major surgery... not a good situation.
Anyway, the key here is *isolation*... don't share anything with the
webapp unless specifically configured to do so.
I suspect this has security implecations as well, but don't have the
time at the moment to dig for them.
- Brill Pappin
On 3/20/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
[...]
> To Brill:
>
> It wouldn't break my heart to see Geronimo default to the spec
> behavior for class loading. I'm not sure that would solve this
> problem (e.g. if the class is already loaded it may not load it
> *again* from the web app loader), but I'd have to check the spec to be
> sure.
Re: NoClassDefFoundError deployment errors
Posted by David Jencks <da...@yahoo.com>.
I would try putting a breakpoint in the code where the exception
occurs (ClayConfigureListener if possible) and finding out exactly
which classloader is being used and what is in it.
thanks
david jencks
On Mar 20, 2006, at 11:00 AM, Richard Wallace wrote:
> It's a biggie, but here you go:
>
> 12:00:02,932 ERROR [[/mpl]] Error configuring application listener
> of class org.apache.shale.clay.config.ClayConfigureListener
> java.lang.ExceptionInInitializerError
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
> (Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance
> (Unknown Source)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
> (Unknown Source)
> at java.lang.reflect.Constructor.newInstance(Unknown Source)
> at java.lang.Class.newInstance0(Unknown Source)
> at java.lang.Class.newInstance(Unknown Source)
> at org.apache.catalina.core.StandardContext.listenerStart
> (StandardContext.java:3618)
> at org.apache.catalina.core.StandardContext.start
> (StandardContext.java:4104)
> at org.apache.geronimo.tomcat.GeronimoStandardContext.access
> $101(GeronimoStandardContext.java:64)
> at org.apache.geronimo.tomcat.GeronimoStandardContext
> $SystemMethodValve.invoke(GeronimoStandardContext.java:267)
> at
> org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke
> (TransactionContextValve.java:53)
> at
> org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke
> (ComponentContextValve.java:47)
> at
> org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke
> (InstanceContextValve.java:60)
> at org.apache.geronimo.tomcat.GeronimoStandardContext.start
> (GeronimoStandardContext.java:187)
> at org.apache.catalina.core.ContainerBase.addChildInternal
> (ContainerBase.java:759)
> at org.apache.catalina.core.ContainerBase.addChild
> (ContainerBase.java:739)
> at org.apache.catalina.core.StandardHost.addChild
> (StandardHost.java:524)
> at org.apache.geronimo.tomcat.TomcatContainer.addContext
> (TomcatContainer.java:287)
> at org.apache.geronimo.tomcat.TomcatContainer$
> $FastClassByCGLIB$$9370b073.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:118)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:800)
> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> (RawInvoker.java:57)
> at
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> (RawOperationInvoker.java:36)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> (ProxyMethodInterceptor.java:96)
> at org.apache.geronimo.tomcat.TomcatContainer$
> $EnhancerByCGLIB$$b361688f.addContext(<generated>)
> at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart
> (TomcatWebAppContext.java:407)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance
> (GBeanInstance.java:936)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(
> GBeanInstanceState.java:325)
> at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start
> (GBeanInstanceState.java:110)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive
> (GBeanInstanceState.java:132)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive
> (GBeanInstance.java:537)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean
> (BasicKernel.java:208)
> at
> org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans
> (Configuration.java:315)
> at org.apache.geronimo.kernel.config.Configuration$
> $FastClassByCGLIB$$7f4b4a9b.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:118)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:835)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> (BasicKernel.java:178)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> (BasicKernel.java:173)
> at
> org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start
> (ConfigurationManagerImpl.java:142)
> at org.apache.geronimo.kernel.config.ConfigurationManagerImpl
> $$FastClassByCGLIB$$fbed85d2.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:118)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:835)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> (BasicKernel.java:178)
> at org.apache.geronimo.kernel.KernelGBean.invoke
> (KernelGBean.java:125)
> at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$
> $1cccefc9.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:118)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:835)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> (BasicKernel.java:178)
> at org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke
> (MBeanServerDelegate.java:117)
> at javax.management.remote.rmi.RMIConnectionImpl.doOperation
> (Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl.access$100
> (Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl
> $PrivilegedOperation.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation
> (Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl.invoke
> (Unknown Source)
> at sun.reflect.GeneratedMethodAccessor274.invoke(Unknown
> Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> at sun.rmi.transport.Transport$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown
> Source)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run
> (Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class
> loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
> (Caused by org.apache.commons.logging.LogConfigurationException:
> Invalid class loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.)
> (Caused by org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class
> loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
> (Caused by org.apache.commons.logging.LogConfigurationException:
> Invalid class loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.))
> at org.apache.commons.logging.impl.LogFactoryImpl.newInstance
> (LogFactoryImpl.java:543)
> at org.apache.commons.logging.impl.LogFactoryImpl.getInstance
> (LogFactoryImpl.java:235)
> at org.apache.commons.logging.impl.LogFactoryImpl.getInstance
> (LogFactoryImpl.java:209)
> at org.apache.commons.logging.LogFactory.getLog
> (LogFactory.java:351)
> at
> org.apache.shale.clay.config.ClayConfigureListener.<clinit>
> (ClayConfigureListener.java:52)
> ... 73 more
> Caused by: org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class
> loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
> (Caused by org.apache.commons.logging.LogConfigurationException:
> Invalid class loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor
> (LogFactoryImpl.java:397)
> at org.apache.commons.logging.impl.LogFactoryImpl.newInstance
> (LogFactoryImpl.java:529)
> ... 77 more
> Caused by: org.apache.commons.logging.LogConfigurationException:
> Invalid class loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor
> (LogFactoryImpl.java:385)
> ... 78 more
> 12:00:02,966 ERROR [[/mpl]] Error configuring application listener
> of class org.apache.myfaces.webapp.StartupServletContextListener
> java.lang.ExceptionInInitializerError
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
> (Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance
> (Unknown Source)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
> (Unknown Source)
> at java.lang.reflect.Constructor.newInstance(Unknown Source)
> at java.lang.Class.newInstance0(Unknown Source)
> at java.lang.Class.newInstance(Unknown Source)
> at org.apache.catalina.core.StandardContext.listenerStart
> (StandardContext.java:3618)
> at org.apache.catalina.core.StandardContext.start
> (StandardContext.java:4104)
> at org.apache.geronimo.tomcat.GeronimoStandardContext.access
> $101(GeronimoStandardContext.java:64)
> at org.apache.geronimo.tomcat.GeronimoStandardContext
> $SystemMethodValve.invoke(GeronimoStandardContext.java:267)
> at
> org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke
> (TransactionContextValve.java:53)
> at
> org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke
> (ComponentContextValve.java:47)
> at
> org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke
> (InstanceContextValve.java:60)
> at org.apache.geronimo.tomcat.GeronimoStandardContext.start
> (GeronimoStandardContext.java:187)
> at org.apache.catalina.core.ContainerBase.addChildInternal
> (ContainerBase.java:759)
> at org.apache.catalina.core.ContainerBase.addChild
> (ContainerBase.java:739)
> at org.apache.catalina.core.StandardHost.addChild
> (StandardHost.java:524)
> at org.apache.geronimo.tomcat.TomcatContainer.addContext
> (TomcatContainer.java:287)
> at org.apache.geronimo.tomcat.TomcatContainer$
> $FastClassByCGLIB$$9370b073.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:118)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:800)
> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> (RawInvoker.java:57)
> at
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> (RawOperationInvoker.java:36)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> (ProxyMethodInterceptor.java:96)
> at org.apache.geronimo.tomcat.TomcatContainer$
> $EnhancerByCGLIB$$b361688f.addContext(<generated>)
> at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart
> (TomcatWebAppContext.java:407)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance
> (GBeanInstance.java:936)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(
> GBeanInstanceState.java:325)
> at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start
> (GBeanInstanceState.java:110)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive
> (GBeanInstanceState.java:132)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive
> (GBeanInstance.java:537)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean
> (BasicKernel.java:208)
> at
> org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans
> (Configuration.java:315)
> at org.apache.geronimo.kernel.config.Configuration$
> $FastClassByCGLIB$$7f4b4a9b.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:118)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:835)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> (BasicKernel.java:178)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> (BasicKernel.java:173)
> at
> org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start
> (ConfigurationManagerImpl.java:142)
> at org.apache.geronimo.kernel.config.ConfigurationManagerImpl
> $$FastClassByCGLIB$$fbed85d2.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:118)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:835)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> (BasicKernel.java:178)
> at org.apache.geronimo.kernel.KernelGBean.invoke
> (KernelGBean.java:125)
> at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$
> $1cccefc9.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:118)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:835)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> (BasicKernel.java:178)
> at org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke
> (MBeanServerDelegate.java:117)
> at javax.management.remote.rmi.RMIConnectionImpl.doOperation
> (Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl.access$100
> (Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl
> $PrivilegedOperation.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation
> (Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl.invoke
> (Unknown Source)
> at sun.reflect.GeneratedMethodAccessor274.invoke(Unknown
> Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> at sun.rmi.transport.Transport$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown
> Source)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run
> (Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class
> loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
> (Caused by org.apache.commons.logging.LogConfigurationException:
> Invalid class loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.)
> (Caused by org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class
> loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
> (Caused by org.apache.commons.logging.LogConfigurationException:
> Invalid class loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.))
> at org.apache.commons.logging.impl.LogFactoryImpl.newInstance
> (LogFactoryImpl.java:543)
> at org.apache.commons.logging.impl.LogFactoryImpl.getInstance
> (LogFactoryImpl.java:235)
> at org.apache.commons.logging.impl.LogFactoryImpl.getInstance
> (LogFactoryImpl.java:209)
> at org.apache.commons.logging.LogFactory.getLog
> (LogFactory.java:351)
> at
> org.apache.myfaces.webapp.StartupServletContextListener.<clinit>
> (StartupServletContextListener.java:39)
> ... 73 more
> Caused by: org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class
> loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
> (Caused by org.apache.commons.logging.LogConfigurationException:
> Invalid class loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor
> (LogFactoryImpl.java:397)
> at org.apache.commons.logging.impl.LogFactoryImpl.newInstance
> (LogFactoryImpl.java:529)
> ... 77 more
> Caused by: org.apache.commons.logging.LogConfigurationException:
> Invalid class loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor
> (LogFactoryImpl.java:385)
> ... 78 more
> 12:00:02,972 ERROR [[/mpl]] Error configuring application listener
> of class org.apache.commons.chain.web.ChainListener
> java.lang.ExceptionInInitializerError
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
> (Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance
> (Unknown Source)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
> (Unknown Source)
> at java.lang.reflect.Constructor.newInstance(Unknown Source)
> at java.lang.Class.newInstance0(Unknown Source)
> at java.lang.Class.newInstance(Unknown Source)
> at org.apache.catalina.core.StandardContext.listenerStart
> (StandardContext.java:3618)
> at org.apache.catalina.core.StandardContext.start
> (StandardContext.java:4104)
> at org.apache.geronimo.tomcat.GeronimoStandardContext.access
> $101(GeronimoStandardContext.java:64)
> at org.apache.geronimo.tomcat.GeronimoStandardContext
> $SystemMethodValve.invoke(GeronimoStandardContext.java:267)
> at
> org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke
> (TransactionContextValve.java:53)
> at
> org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke
> (ComponentContextValve.java:47)
> at
> org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke
> (InstanceContextValve.java:60)
> at org.apache.geronimo.tomcat.GeronimoStandardContext.start
> (GeronimoStandardContext.java:187)
> at org.apache.catalina.core.ContainerBase.addChildInternal
> (ContainerBase.java:759)
> at org.apache.catalina.core.ContainerBase.addChild
> (ContainerBase.java:739)
> at org.apache.catalina.core.StandardHost.addChild
> (StandardHost.java:524)
> at org.apache.geronimo.tomcat.TomcatContainer.addContext
> (TomcatContainer.java:287)
> at org.apache.geronimo.tomcat.TomcatContainer$
> $FastClassByCGLIB$$9370b073.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:118)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:800)
> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> (RawInvoker.java:57)
> at
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> (RawOperationInvoker.java:36)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> (ProxyMethodInterceptor.java:96)
> at org.apache.geronimo.tomcat.TomcatContainer$
> $EnhancerByCGLIB$$b361688f.addContext(<generated>)
> at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart
> (TomcatWebAppContext.java:407)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance
> (GBeanInstance.java:936)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(
> GBeanInstanceState.java:325)
> at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start
> (GBeanInstanceState.java:110)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive
> (GBeanInstanceState.java:132)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive
> (GBeanInstance.java:537)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean
> (BasicKernel.java:208)
> at
> org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans
> (Configuration.java:315)
> at org.apache.geronimo.kernel.config.Configuration$
> $FastClassByCGLIB$$7f4b4a9b.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:118)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:835)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> (BasicKernel.java:178)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> (BasicKernel.java:173)
> at
> org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start
> (ConfigurationManagerImpl.java:142)
> at org.apache.geronimo.kernel.config.ConfigurationManagerImpl
> $$FastClassByCGLIB$$fbed85d2.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:118)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:835)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> (BasicKernel.java:178)
> at org.apache.geronimo.kernel.KernelGBean.invoke
> (KernelGBean.java:125)
> at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$
> $1cccefc9.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:118)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:835)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> (BasicKernel.java:178)
> at org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke
> (MBeanServerDelegate.java:117)
> at javax.management.remote.rmi.RMIConnectionImpl.doOperation
> (Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl.access$100
> (Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl
> $PrivilegedOperation.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation
> (Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl.invoke
> (Unknown Source)
> at sun.reflect.GeneratedMethodAccessor274.invoke(Unknown
> Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
> at sun.rmi.transport.Transport$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Unknown Source)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown
> Source)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run
> (Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class
> loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
> (Caused by org.apache.commons.logging.LogConfigurationException:
> Invalid class loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.)
> (Caused by org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class
> loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
> (Caused by org.apache.commons.logging.LogConfigurationException:
> Invalid class loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.))
> at org.apache.commons.logging.impl.LogFactoryImpl.newInstance
> (LogFactoryImpl.java:543)
> at org.apache.commons.logging.impl.LogFactoryImpl.getInstance
> (LogFactoryImpl.java:235)
> at org.apache.commons.logging.impl.LogFactoryImpl.getInstance
> (LogFactoryImpl.java:209)
> at org.apache.commons.logging.LogFactory.getLog
> (LogFactory.java:351)
> at org.apache.commons.chain.web.ChainListener.<clinit>
> (ChainListener.java:144)
> ... 73 more
> Caused by: org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class
> loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
> (Caused by org.apache.commons.logging.LogConfigurationException:
> Invalid class loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor
> (LogFactoryImpl.java:397)
> at org.apache.commons.logging.impl.LogFactoryImpl.newInstance
> (LogFactoryImpl.java:529)
> ... 77 more
> Caused by: org.apache.commons.logging.LogConfigurationException:
> Invalid class loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor
> (LogFactoryImpl.java:385)
> ... 78 more
> 12:00:03,019 ERROR [[/mpl]] Skipped installing application
> listeners due to previous error(s)
> 12:00:03,020 ERROR [StandardContext] Error listenerStart
> 12:00:03,021 ERROR [StandardContext] Context [/mpl] startup failed
> due to previous errors
>
>
> Aaron Mulder wrote:
>> Can you post the stack trace? Or is it just a message?
>>
>> Thanks,
>> Aaron
>>
>> On 3/20/06, Richard Wallace <rw...@thewallacepack.net> wrote:
>>
>>> Sorry, forgot to mention that I had tried adding the commons-
>>> logging to
>>> the hidden-classes. That didn't work either. The second
>>> configuration
>>> option was a no-go too, gave me the same error.
>>>
>>> Any other suggestions?
>>>
>>> Thanks,
>>> Rich
>>>
>>> Aaron Mulder wrote:
>>>
>>>> OK, then try adding the hidden classes for commons-logging too:
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <web-app
>>>> xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
>>>> configId="MPLCommon">
>>>> <hidden-classes><filter>org.springframework</filter></hidden-
>>>> classes>
>>>> <hidden-classes><filter>org.apache.commons.logging</filter></
>>>> hidden-classes>
>>>> <context-root>/mpl</context-root>
>>>> <context-priority-classloader>true</context-priority-classloader>
>>>> </web-app>
>>>>
>>>> Alternately, if that still gives you trouble, or if you want to use
>>>> Geronimo's commons logging instead of the one built in to your
>>>> application, you could try hiding the one in your application
>>>> instead:
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <web-app
>>>> xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
>>>> configId="MPLCommon">
>>>> <hidden-classes><filter>org.springframework</filter></hidden-
>>>> classes>
>>>> <non-overridable-classes><filter>org.apache.commons.logging</
>>>> filter></non-overridable-classes>
>>>> <context-root>/mpl</context-root>
>>>> <context-priority-classloader>true</context-priority-classloader>
>>>> </web-app>
>>>>
>>>> I haven't seen this commons-logging problem before, but maybe it's
>>>> just that I haven't deployed apps that use commons-logging
>>>> themselves.
>>>>
>>>> Thanks,
>>>> Aaron
>>>>
>>>> On 3/20/06, Richard Wallace <rw...@thewallacepack.net> wrote:
>>>>
>>>>
>>>>> Aaron Mulder wrote:
>>>>>
>>>>>
>>>>>> To the original poster:
>>>>>>
>>>>>> You actually need *Spring* in your hidden classes element. I
>>>>>> believe
>>>>>> everything will work if you just list Spring alone (e.g.
>>>>>> org.springframework) and not Faces, Hibernate, or Commons
>>>>>> Logging.
>>>>>> It's possible that you might need commons logging listed as
>>>>>> well, but
>>>>>> I think once you're using the right Spring, it will get beyond
>>>>>> the
>>>>>> commons logging problem.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> So what should my geronimo-web.xml look like? Right now I've got
>>>>>
>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>> <web-app
>>>>> xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
>>>>> configId="MPLCommon">
>>>>> <hidden-classes><filter>org.springframework</filter></hidden-
>>>>> classes>
>>>>> <context-root>/mpl</context-root>
>>>>> <context-priority-classloader>true</context-priority-
>>>>> classloader>
>>>>> </web-app>
>>>>>
>>>>> And I'm still getting the commons-logging error?
>>>>>
>>>>> Thanks,
>>>>> Rich
>>>>>
>>>>>
>>>>>> To Brill:
>>>>>>
>>>>>> It wouldn't break my heart to see Geronimo default to the spec
>>>>>> behavior for class loading. I'm not sure that would solve this
>>>>>> problem (e.g. if the class is already loaded it may not load it
>>>>>> *again* from the web app loader), but I'd have to check the
>>>>>> spec to be
>>>>>> sure.
>>>>>>
>>>>>> To David J:
>>>>>>
>>>>>> I'd still like to see applications on a class loader that has
>>>>>> only the
>>>>>> spec classes as a parent and not the Geronimo implementation
>>>>>> classes.
>>>>>> That is, we have a CL with all the spec JARs, with one child
>>>>>> for the
>>>>>> server code and a separate child for the application code.
>>>>>> Previously
>>>>>> I think you've said "it might work but we'd need to try it to
>>>>>> be sure"
>>>>>> -- I'll try to experiment with this once the SVN tree
>>>>>> stabilizes a
>>>>>> bit.
>>>>>>
>>>>>> Thanks,
>>>>>> Aaron
>>>>>>
>>>>>> On 3/18/06, Brill Pappin <jo...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Isn't that non-standard?
>>>>>>> I mean, Geronimo should be prefering the libs in the WAR over
>>>>>>> its own
>>>>>>> libs. I thought that was part of the spec for webapps.
>>>>>>>
>>>>>>> I've been having the same trouble myself, and its contrary to
>>>>>>> what I
>>>>>>> expect having used a veriety of other app servers. Geronimo
>>>>>>> should not
>>>>>>> be causing my application to blow up because of library
>>>>>>> conflicts.
>>>>>>>
>>>>>>> I do think its ability to share libs easily is good, but I
>>>>>>> think the
>>>>>>> default should be to isolate the webapp and allow sharing to
>>>>>>> be turned
>>>>>>> on via the geronimo config xml file.
>>>>>>>
>>>>>>> Does anyone know why Geronimo is so loose with its
>>>>>>> classloaders? Was
>>>>>>> this a design choice or an artifact of some other issue?
>>>>>>>
>>>>>>> If it was a design choice, I would *really* like to see the
>>>>>>> justification for it... and if an artifact, it needs to be
>>>>>>> corrected
>>>>>>> ASAP.
>>>>>>>
>>>>>>> - Brill Pappin
>>>>>>>
>>>>>>> On 3/17/06, David Jencks <da...@yahoo.com> wrote:
>>>>>>> [...]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> My first guess is that a copy of spring included in geronimo is
>>>>>>>> getting used in your web app instead of the copy you are
>>>>>>>> trying to
>>>>>>>> use: when our copy tries to load the faces/hibernate classes
>>>>>>>> it can't
>>>>>>>> find them. If this is the problem you should be able to fix
>>>>>>>> it by
>>>>>>>> adding spring and hibernate to the hidden classes list in your
>>>>>>>> geronimo plan for your application.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>
Re: NoClassDefFoundError deployment errors
Posted by Richard Wallace <rw...@thewallacepack.net>.
It's a biggie, but here you go:
12:00:02,932 ERROR [[/mpl]] Error configuring application listener of
class org.apache.shale.clay.config.ClayConfigureListener
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3618)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4104)
at
org.apache.geronimo.tomcat.GeronimoStandardContext.access$101(GeronimoStandardContext.java:64)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:267)
at
org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53)
at
org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47)
at
org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60)
at
org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:187)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at
org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:287)
at
org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$b361688f.addContext(<generated>)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:407)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208)
at
org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315)
at
org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173)
at
org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:142)
at
org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at
org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125)
at
org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at
org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source)
at
javax.management.remote.rmi.RMIConnectionImpl.access$100(Unknown Source)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown
Source)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown
Source)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown
Source)
at sun.reflect.GeneratedMethodAccessor274.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed. (Caused
by org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused
by org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed. (Caused
by org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.))
at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at
org.apache.shale.clay.config.ClayConfigureListener.<clinit>(ClayConfigureListener.java:52)
... 73 more
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed. (Caused
by org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.)
at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397)
at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
... 77 more
Caused by: org.apache.commons.logging.LogConfigurationException: Invalid
class loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.
at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:385)
... 78 more
12:00:02,966 ERROR [[/mpl]] Error configuring application listener of
class org.apache.myfaces.webapp.StartupServletContextListener
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3618)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4104)
at
org.apache.geronimo.tomcat.GeronimoStandardContext.access$101(GeronimoStandardContext.java:64)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:267)
at
org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53)
at
org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47)
at
org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60)
at
org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:187)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at
org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:287)
at
org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$b361688f.addContext(<generated>)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:407)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208)
at
org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315)
at
org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173)
at
org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:142)
at
org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at
org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125)
at
org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at
org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source)
at
javax.management.remote.rmi.RMIConnectionImpl.access$100(Unknown Source)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown
Source)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown
Source)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown
Source)
at sun.reflect.GeneratedMethodAccessor274.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed. (Caused
by org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused
by org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed. (Caused
by org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.))
at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at
org.apache.myfaces.webapp.StartupServletContextListener.<clinit>(StartupServletContextListener.java:39)
... 73 more
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed. (Caused
by org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.)
at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397)
at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
... 77 more
Caused by: org.apache.commons.logging.LogConfigurationException: Invalid
class loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.
at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:385)
... 78 more
12:00:02,972 ERROR [[/mpl]] Error configuring application listener of
class org.apache.commons.chain.web.ChainListener
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3618)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4104)
at
org.apache.geronimo.tomcat.GeronimoStandardContext.access$101(GeronimoStandardContext.java:64)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:267)
at
org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53)
at
org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47)
at
org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60)
at
org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:187)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at
org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:287)
at
org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$b361688f.addContext(<generated>)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:407)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208)
at
org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315)
at
org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173)
at
org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:142)
at
org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at
org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125)
at
org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at
org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source)
at
javax.management.remote.rmi.RMIConnectionImpl.access$100(Unknown Source)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown
Source)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown
Source)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown
Source)
at sun.reflect.GeneratedMethodAccessor274.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed. (Caused
by org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused
by org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed. (Caused
by org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.))
at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at
org.apache.commons.chain.web.ChainListener.<clinit>(ChainListener.java:144)
... 73 more
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed. (Caused
by org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.)
at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397)
at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
... 77 more
Caused by: org.apache.commons.logging.LogConfigurationException: Invalid
class loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.
at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:385)
... 78 more
12:00:03,019 ERROR [[/mpl]] Skipped installing application listeners due
to previous error(s)
12:00:03,020 ERROR [StandardContext] Error listenerStart
12:00:03,021 ERROR [StandardContext] Context [/mpl] startup failed due
to previous errors
Aaron Mulder wrote:
> Can you post the stack trace? Or is it just a message?
>
> Thanks,
> Aaron
>
> On 3/20/06, Richard Wallace <rw...@thewallacepack.net> wrote:
>
>> Sorry, forgot to mention that I had tried adding the commons-logging to
>> the hidden-classes. That didn't work either. The second configuration
>> option was a no-go too, gave me the same error.
>>
>> Any other suggestions?
>>
>> Thanks,
>> Rich
>>
>> Aaron Mulder wrote:
>>
>>> OK, then try adding the hidden classes for commons-logging too:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <web-app
>>> xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
>>> configId="MPLCommon">
>>> <hidden-classes><filter>org.springframework</filter></hidden-classes>
>>> <hidden-classes><filter>org.apache.commons.logging</filter></hidden-classes>
>>> <context-root>/mpl</context-root>
>>> <context-priority-classloader>true</context-priority-classloader>
>>> </web-app>
>>>
>>> Alternately, if that still gives you trouble, or if you want to use
>>> Geronimo's commons logging instead of the one built in to your
>>> application, you could try hiding the one in your application instead:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <web-app
>>> xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
>>> configId="MPLCommon">
>>> <hidden-classes><filter>org.springframework</filter></hidden-classes>
>>> <non-overridable-classes><filter>org.apache.commons.logging</filter></non-overridable-classes>
>>> <context-root>/mpl</context-root>
>>> <context-priority-classloader>true</context-priority-classloader>
>>> </web-app>
>>>
>>> I haven't seen this commons-logging problem before, but maybe it's
>>> just that I haven't deployed apps that use commons-logging themselves.
>>>
>>> Thanks,
>>> Aaron
>>>
>>> On 3/20/06, Richard Wallace <rw...@thewallacepack.net> wrote:
>>>
>>>
>>>> Aaron Mulder wrote:
>>>>
>>>>
>>>>> To the original poster:
>>>>>
>>>>> You actually need *Spring* in your hidden classes element. I believe
>>>>> everything will work if you just list Spring alone (e.g.
>>>>> org.springframework) and not Faces, Hibernate, or Commons Logging.
>>>>> It's possible that you might need commons logging listed as well, but
>>>>> I think once you're using the right Spring, it will get beyond the
>>>>> commons logging problem.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> So what should my geronimo-web.xml look like? Right now I've got
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <web-app
>>>> xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
>>>> configId="MPLCommon">
>>>> <hidden-classes><filter>org.springframework</filter></hidden-classes>
>>>> <context-root>/mpl</context-root>
>>>> <context-priority-classloader>true</context-priority-classloader>
>>>> </web-app>
>>>>
>>>> And I'm still getting the commons-logging error?
>>>>
>>>> Thanks,
>>>> Rich
>>>>
>>>>
>>>>> To Brill:
>>>>>
>>>>> It wouldn't break my heart to see Geronimo default to the spec
>>>>> behavior for class loading. I'm not sure that would solve this
>>>>> problem (e.g. if the class is already loaded it may not load it
>>>>> *again* from the web app loader), but I'd have to check the spec to be
>>>>> sure.
>>>>>
>>>>> To David J:
>>>>>
>>>>> I'd still like to see applications on a class loader that has only the
>>>>> spec classes as a parent and not the Geronimo implementation classes.
>>>>> That is, we have a CL with all the spec JARs, with one child for the
>>>>> server code and a separate child for the application code. Previously
>>>>> I think you've said "it might work but we'd need to try it to be sure"
>>>>> -- I'll try to experiment with this once the SVN tree stabilizes a
>>>>> bit.
>>>>>
>>>>> Thanks,
>>>>> Aaron
>>>>>
>>>>> On 3/18/06, Brill Pappin <jo...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Isn't that non-standard?
>>>>>> I mean, Geronimo should be prefering the libs in the WAR over its own
>>>>>> libs. I thought that was part of the spec for webapps.
>>>>>>
>>>>>> I've been having the same trouble myself, and its contrary to what I
>>>>>> expect having used a veriety of other app servers. Geronimo should not
>>>>>> be causing my application to blow up because of library conflicts.
>>>>>>
>>>>>> I do think its ability to share libs easily is good, but I think the
>>>>>> default should be to isolate the webapp and allow sharing to be turned
>>>>>> on via the geronimo config xml file.
>>>>>>
>>>>>> Does anyone know why Geronimo is so loose with its classloaders? Was
>>>>>> this a design choice or an artifact of some other issue?
>>>>>>
>>>>>> If it was a design choice, I would *really* like to see the
>>>>>> justification for it... and if an artifact, it needs to be corrected
>>>>>> ASAP.
>>>>>>
>>>>>> - Brill Pappin
>>>>>>
>>>>>> On 3/17/06, David Jencks <da...@yahoo.com> wrote:
>>>>>> [...]
>>>>>>
>>>>>>
>>>>>>
>>>>>>> My first guess is that a copy of spring included in geronimo is
>>>>>>> getting used in your web app instead of the copy you are trying to
>>>>>>> use: when our copy tries to load the faces/hibernate classes it can't
>>>>>>> find them. If this is the problem you should be able to fix it by
>>>>>>> adding spring and hibernate to the hidden classes list in your
>>>>>>> geronimo plan for your application.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
Re: NoClassDefFoundError deployment errors
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Can you post the stack trace? Or is it just a message?
Thanks,
Aaron
On 3/20/06, Richard Wallace <rw...@thewallacepack.net> wrote:
> Sorry, forgot to mention that I had tried adding the commons-logging to
> the hidden-classes. That didn't work either. The second configuration
> option was a no-go too, gave me the same error.
>
> Any other suggestions?
>
> Thanks,
> Rich
>
> Aaron Mulder wrote:
> > OK, then try adding the hidden classes for commons-logging too:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <web-app
> > xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
> > configId="MPLCommon">
> > <hidden-classes><filter>org.springframework</filter></hidden-classes>
> > <hidden-classes><filter>org.apache.commons.logging</filter></hidden-classes>
> > <context-root>/mpl</context-root>
> > <context-priority-classloader>true</context-priority-classloader>
> > </web-app>
> >
> > Alternately, if that still gives you trouble, or if you want to use
> > Geronimo's commons logging instead of the one built in to your
> > application, you could try hiding the one in your application instead:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <web-app
> > xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
> > configId="MPLCommon">
> > <hidden-classes><filter>org.springframework</filter></hidden-classes>
> > <non-overridable-classes><filter>org.apache.commons.logging</filter></non-overridable-classes>
> > <context-root>/mpl</context-root>
> > <context-priority-classloader>true</context-priority-classloader>
> > </web-app>
> >
> > I haven't seen this commons-logging problem before, but maybe it's
> > just that I haven't deployed apps that use commons-logging themselves.
> >
> > Thanks,
> > Aaron
> >
> > On 3/20/06, Richard Wallace <rw...@thewallacepack.net> wrote:
> >
> >> Aaron Mulder wrote:
> >>
> >>> To the original poster:
> >>>
> >>> You actually need *Spring* in your hidden classes element. I believe
> >>> everything will work if you just list Spring alone (e.g.
> >>> org.springframework) and not Faces, Hibernate, or Commons Logging.
> >>> It's possible that you might need commons logging listed as well, but
> >>> I think once you're using the right Spring, it will get beyond the
> >>> commons logging problem.
> >>>
> >>>
> >>>
> >> So what should my geronimo-web.xml look like? Right now I've got
> >>
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <web-app
> >> xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
> >> configId="MPLCommon">
> >> <hidden-classes><filter>org.springframework</filter></hidden-classes>
> >> <context-root>/mpl</context-root>
> >> <context-priority-classloader>true</context-priority-classloader>
> >> </web-app>
> >>
> >> And I'm still getting the commons-logging error?
> >>
> >> Thanks,
> >> Rich
> >>
> >>> To Brill:
> >>>
> >>> It wouldn't break my heart to see Geronimo default to the spec
> >>> behavior for class loading. I'm not sure that would solve this
> >>> problem (e.g. if the class is already loaded it may not load it
> >>> *again* from the web app loader), but I'd have to check the spec to be
> >>> sure.
> >>>
> >>> To David J:
> >>>
> >>> I'd still like to see applications on a class loader that has only the
> >>> spec classes as a parent and not the Geronimo implementation classes.
> >>> That is, we have a CL with all the spec JARs, with one child for the
> >>> server code and a separate child for the application code. Previously
> >>> I think you've said "it might work but we'd need to try it to be sure"
> >>> -- I'll try to experiment with this once the SVN tree stabilizes a
> >>> bit.
> >>>
> >>> Thanks,
> >>> Aaron
> >>>
> >>> On 3/18/06, Brill Pappin <jo...@gmail.com> wrote:
> >>>
> >>>
> >>>> Isn't that non-standard?
> >>>> I mean, Geronimo should be prefering the libs in the WAR over its own
> >>>> libs. I thought that was part of the spec for webapps.
> >>>>
> >>>> I've been having the same trouble myself, and its contrary to what I
> >>>> expect having used a veriety of other app servers. Geronimo should not
> >>>> be causing my application to blow up because of library conflicts.
> >>>>
> >>>> I do think its ability to share libs easily is good, but I think the
> >>>> default should be to isolate the webapp and allow sharing to be turned
> >>>> on via the geronimo config xml file.
> >>>>
> >>>> Does anyone know why Geronimo is so loose with its classloaders? Was
> >>>> this a design choice or an artifact of some other issue?
> >>>>
> >>>> If it was a design choice, I would *really* like to see the
> >>>> justification for it... and if an artifact, it needs to be corrected
> >>>> ASAP.
> >>>>
> >>>> - Brill Pappin
> >>>>
> >>>> On 3/17/06, David Jencks <da...@yahoo.com> wrote:
> >>>> [...]
> >>>>
> >>>>
> >>>>> My first guess is that a copy of spring included in geronimo is
> >>>>> getting used in your web app instead of the copy you are trying to
> >>>>> use: when our copy tries to load the faces/hibernate classes it can't
> >>>>> find them. If this is the problem you should be able to fix it by
> >>>>> adding spring and hibernate to the hidden classes list in your
> >>>>> geronimo plan for your application.
> >>>>>
> >>>>>
> >>>> [...]
> >>>>
> >>>>
> >>>>
> >>
>
>
Re: NoClassDefFoundError deployment errors
Posted by Richard Wallace <rw...@thewallacepack.net>.
Sorry, forgot to mention that I had tried adding the commons-logging to
the hidden-classes. That didn't work either. The second configuration
option was a no-go too, gave me the same error.
Any other suggestions?
Thanks,
Rich
Aaron Mulder wrote:
> OK, then try adding the hidden classes for commons-logging too:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app
> xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
> configId="MPLCommon">
> <hidden-classes><filter>org.springframework</filter></hidden-classes>
> <hidden-classes><filter>org.apache.commons.logging</filter></hidden-classes>
> <context-root>/mpl</context-root>
> <context-priority-classloader>true</context-priority-classloader>
> </web-app>
>
> Alternately, if that still gives you trouble, or if you want to use
> Geronimo's commons logging instead of the one built in to your
> application, you could try hiding the one in your application instead:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app
> xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
> configId="MPLCommon">
> <hidden-classes><filter>org.springframework</filter></hidden-classes>
> <non-overridable-classes><filter>org.apache.commons.logging</filter></non-overridable-classes>
> <context-root>/mpl</context-root>
> <context-priority-classloader>true</context-priority-classloader>
> </web-app>
>
> I haven't seen this commons-logging problem before, but maybe it's
> just that I haven't deployed apps that use commons-logging themselves.
>
> Thanks,
> Aaron
>
> On 3/20/06, Richard Wallace <rw...@thewallacepack.net> wrote:
>
>> Aaron Mulder wrote:
>>
>>> To the original poster:
>>>
>>> You actually need *Spring* in your hidden classes element. I believe
>>> everything will work if you just list Spring alone (e.g.
>>> org.springframework) and not Faces, Hibernate, or Commons Logging.
>>> It's possible that you might need commons logging listed as well, but
>>> I think once you're using the right Spring, it will get beyond the
>>> commons logging problem.
>>>
>>>
>>>
>> So what should my geronimo-web.xml look like? Right now I've got
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <web-app
>> xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
>> configId="MPLCommon">
>> <hidden-classes><filter>org.springframework</filter></hidden-classes>
>> <context-root>/mpl</context-root>
>> <context-priority-classloader>true</context-priority-classloader>
>> </web-app>
>>
>> And I'm still getting the commons-logging error?
>>
>> Thanks,
>> Rich
>>
>>> To Brill:
>>>
>>> It wouldn't break my heart to see Geronimo default to the spec
>>> behavior for class loading. I'm not sure that would solve this
>>> problem (e.g. if the class is already loaded it may not load it
>>> *again* from the web app loader), but I'd have to check the spec to be
>>> sure.
>>>
>>> To David J:
>>>
>>> I'd still like to see applications on a class loader that has only the
>>> spec classes as a parent and not the Geronimo implementation classes.
>>> That is, we have a CL with all the spec JARs, with one child for the
>>> server code and a separate child for the application code. Previously
>>> I think you've said "it might work but we'd need to try it to be sure"
>>> -- I'll try to experiment with this once the SVN tree stabilizes a
>>> bit.
>>>
>>> Thanks,
>>> Aaron
>>>
>>> On 3/18/06, Brill Pappin <jo...@gmail.com> wrote:
>>>
>>>
>>>> Isn't that non-standard?
>>>> I mean, Geronimo should be prefering the libs in the WAR over its own
>>>> libs. I thought that was part of the spec for webapps.
>>>>
>>>> I've been having the same trouble myself, and its contrary to what I
>>>> expect having used a veriety of other app servers. Geronimo should not
>>>> be causing my application to blow up because of library conflicts.
>>>>
>>>> I do think its ability to share libs easily is good, but I think the
>>>> default should be to isolate the webapp and allow sharing to be turned
>>>> on via the geronimo config xml file.
>>>>
>>>> Does anyone know why Geronimo is so loose with its classloaders? Was
>>>> this a design choice or an artifact of some other issue?
>>>>
>>>> If it was a design choice, I would *really* like to see the
>>>> justification for it... and if an artifact, it needs to be corrected
>>>> ASAP.
>>>>
>>>> - Brill Pappin
>>>>
>>>> On 3/17/06, David Jencks <da...@yahoo.com> wrote:
>>>> [...]
>>>>
>>>>
>>>>> My first guess is that a copy of spring included in geronimo is
>>>>> getting used in your web app instead of the copy you are trying to
>>>>> use: when our copy tries to load the faces/hibernate classes it can't
>>>>> find them. If this is the problem you should be able to fix it by
>>>>> adding spring and hibernate to the hidden classes list in your
>>>>> geronimo plan for your application.
>>>>>
>>>>>
>>>> [...]
>>>>
>>>>
>>>>
>>
Re: NoClassDefFoundError deployment errors
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
OK, then try adding the hidden classes for commons-logging too:
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
configId="MPLCommon">
<hidden-classes><filter>org.springframework</filter></hidden-classes>
<hidden-classes><filter>org.apache.commons.logging</filter></hidden-classes>
<context-root>/mpl</context-root>
<context-priority-classloader>true</context-priority-classloader>
</web-app>
Alternately, if that still gives you trouble, or if you want to use
Geronimo's commons logging instead of the one built in to your
application, you could try hiding the one in your application instead:
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
configId="MPLCommon">
<hidden-classes><filter>org.springframework</filter></hidden-classes>
<non-overridable-classes><filter>org.apache.commons.logging</filter></non-overridable-classes>
<context-root>/mpl</context-root>
<context-priority-classloader>true</context-priority-classloader>
</web-app>
I haven't seen this commons-logging problem before, but maybe it's
just that I haven't deployed apps that use commons-logging themselves.
Thanks,
Aaron
On 3/20/06, Richard Wallace <rw...@thewallacepack.net> wrote:
> Aaron Mulder wrote:
> > To the original poster:
> >
> > You actually need *Spring* in your hidden classes element. I believe
> > everything will work if you just list Spring alone (e.g.
> > org.springframework) and not Faces, Hibernate, or Commons Logging.
> > It's possible that you might need commons logging listed as well, but
> > I think once you're using the right Spring, it will get beyond the
> > commons logging problem.
> >
> >
> So what should my geronimo-web.xml look like? Right now I've got
>
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app
> xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
> configId="MPLCommon">
> <hidden-classes><filter>org.springframework</filter></hidden-classes>
> <context-root>/mpl</context-root>
> <context-priority-classloader>true</context-priority-classloader>
> </web-app>
>
> And I'm still getting the commons-logging error?
>
> Thanks,
> Rich
> > To Brill:
> >
> > It wouldn't break my heart to see Geronimo default to the spec
> > behavior for class loading. I'm not sure that would solve this
> > problem (e.g. if the class is already loaded it may not load it
> > *again* from the web app loader), but I'd have to check the spec to be
> > sure.
> >
> > To David J:
> >
> > I'd still like to see applications on a class loader that has only the
> > spec classes as a parent and not the Geronimo implementation classes.
> > That is, we have a CL with all the spec JARs, with one child for the
> > server code and a separate child for the application code. Previously
> > I think you've said "it might work but we'd need to try it to be sure"
> > -- I'll try to experiment with this once the SVN tree stabilizes a
> > bit.
> >
> > Thanks,
> > Aaron
> >
> > On 3/18/06, Brill Pappin <jo...@gmail.com> wrote:
> >
> >> Isn't that non-standard?
> >> I mean, Geronimo should be prefering the libs in the WAR over its own
> >> libs. I thought that was part of the spec for webapps.
> >>
> >> I've been having the same trouble myself, and its contrary to what I
> >> expect having used a veriety of other app servers. Geronimo should not
> >> be causing my application to blow up because of library conflicts.
> >>
> >> I do think its ability to share libs easily is good, but I think the
> >> default should be to isolate the webapp and allow sharing to be turned
> >> on via the geronimo config xml file.
> >>
> >> Does anyone know why Geronimo is so loose with its classloaders? Was
> >> this a design choice or an artifact of some other issue?
> >>
> >> If it was a design choice, I would *really* like to see the
> >> justification for it... and if an artifact, it needs to be corrected
> >> ASAP.
> >>
> >> - Brill Pappin
> >>
> >> On 3/17/06, David Jencks <da...@yahoo.com> wrote:
> >> [...]
> >>
> >>> My first guess is that a copy of spring included in geronimo is
> >>> getting used in your web app instead of the copy you are trying to
> >>> use: when our copy tries to load the faces/hibernate classes it can't
> >>> find them. If this is the problem you should be able to fix it by
> >>> adding spring and hibernate to the hidden classes list in your
> >>> geronimo plan for your application.
> >>>
> >> [...]
> >>
> >>
>
>
Re: NoClassDefFoundError deployment errors
Posted by Richard Wallace <rw...@thewallacepack.net>.
Aaron Mulder wrote:
> To the original poster:
>
> You actually need *Spring* in your hidden classes element. I believe
> everything will work if you just list Spring alone (e.g.
> org.springframework) and not Faces, Hibernate, or Commons Logging.
> It's possible that you might need commons logging listed as well, but
> I think once you're using the right Spring, it will get beyond the
> commons logging problem.
>
>
So what should my geronimo-web.xml look like? Right now I've got
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
configId="MPLCommon">
<hidden-classes><filter>org.springframework</filter></hidden-classes>
<context-root>/mpl</context-root>
<context-priority-classloader>true</context-priority-classloader>
</web-app>
And I'm still getting the commons-logging error?
Thanks,
Rich
> To Brill:
>
> It wouldn't break my heart to see Geronimo default to the spec
> behavior for class loading. I'm not sure that would solve this
> problem (e.g. if the class is already loaded it may not load it
> *again* from the web app loader), but I'd have to check the spec to be
> sure.
>
> To David J:
>
> I'd still like to see applications on a class loader that has only the
> spec classes as a parent and not the Geronimo implementation classes.
> That is, we have a CL with all the spec JARs, with one child for the
> server code and a separate child for the application code. Previously
> I think you've said "it might work but we'd need to try it to be sure"
> -- I'll try to experiment with this once the SVN tree stabilizes a
> bit.
>
> Thanks,
> Aaron
>
> On 3/18/06, Brill Pappin <jo...@gmail.com> wrote:
>
>> Isn't that non-standard?
>> I mean, Geronimo should be prefering the libs in the WAR over its own
>> libs. I thought that was part of the spec for webapps.
>>
>> I've been having the same trouble myself, and its contrary to what I
>> expect having used a veriety of other app servers. Geronimo should not
>> be causing my application to blow up because of library conflicts.
>>
>> I do think its ability to share libs easily is good, but I think the
>> default should be to isolate the webapp and allow sharing to be turned
>> on via the geronimo config xml file.
>>
>> Does anyone know why Geronimo is so loose with its classloaders? Was
>> this a design choice or an artifact of some other issue?
>>
>> If it was a design choice, I would *really* like to see the
>> justification for it... and if an artifact, it needs to be corrected
>> ASAP.
>>
>> - Brill Pappin
>>
>> On 3/17/06, David Jencks <da...@yahoo.com> wrote:
>> [...]
>>
>>> My first guess is that a copy of spring included in geronimo is
>>> getting used in your web app instead of the copy you are trying to
>>> use: when our copy tries to load the faces/hibernate classes it can't
>>> find them. If this is the problem you should be able to fix it by
>>> adding spring and hibernate to the hidden classes list in your
>>> geronimo plan for your application.
>>>
>> [...]
>>
>>
Re: NoClassDefFoundError deployment errors
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
To the original poster:
You actually need *Spring* in your hidden classes element. I believe
everything will work if you just list Spring alone (e.g.
org.springframework) and not Faces, Hibernate, or Commons Logging.
It's possible that you might need commons logging listed as well, but
I think once you're using the right Spring, it will get beyond the
commons logging problem.
To Brill:
It wouldn't break my heart to see Geronimo default to the spec
behavior for class loading. I'm not sure that would solve this
problem (e.g. if the class is already loaded it may not load it
*again* from the web app loader), but I'd have to check the spec to be
sure.
To David J:
I'd still like to see applications on a class loader that has only the
spec classes as a parent and not the Geronimo implementation classes.
That is, we have a CL with all the spec JARs, with one child for the
server code and a separate child for the application code. Previously
I think you've said "it might work but we'd need to try it to be sure"
-- I'll try to experiment with this once the SVN tree stabilizes a
bit.
Thanks,
Aaron
On 3/18/06, Brill Pappin <jo...@gmail.com> wrote:
> Isn't that non-standard?
> I mean, Geronimo should be prefering the libs in the WAR over its own
> libs. I thought that was part of the spec for webapps.
>
> I've been having the same trouble myself, and its contrary to what I
> expect having used a veriety of other app servers. Geronimo should not
> be causing my application to blow up because of library conflicts.
>
> I do think its ability to share libs easily is good, but I think the
> default should be to isolate the webapp and allow sharing to be turned
> on via the geronimo config xml file.
>
> Does anyone know why Geronimo is so loose with its classloaders? Was
> this a design choice or an artifact of some other issue?
>
> If it was a design choice, I would *really* like to see the
> justification for it... and if an artifact, it needs to be corrected
> ASAP.
>
> - Brill Pappin
>
> On 3/17/06, David Jencks <da...@yahoo.com> wrote:
> [...]
> > My first guess is that a copy of spring included in geronimo is
> > getting used in your web app instead of the copy you are trying to
> > use: when our copy tries to load the faces/hibernate classes it can't
> > find them. If this is the problem you should be able to fix it by
> > adding spring and hibernate to the hidden classes list in your
> > geronimo plan for your application.
> [...]
>
Re: NoClassDefFoundError deployment errors
Posted by Brill Pappin <jo...@gmail.com>.
Isn't that non-standard?
I mean, Geronimo should be prefering the libs in the WAR over its own
libs. I thought that was part of the spec for webapps.
I've been having the same trouble myself, and its contrary to what I
expect having used a veriety of other app servers. Geronimo should not
be causing my application to blow up because of library conflicts.
I do think its ability to share libs easily is good, but I think the
default should be to isolate the webapp and allow sharing to be turned
on via the geronimo config xml file.
Does anyone know why Geronimo is so loose with its classloaders? Was
this a design choice or an artifact of some other issue?
If it was a design choice, I would *really* like to see the
justification for it... and if an artifact, it needs to be corrected
ASAP.
- Brill Pappin
On 3/17/06, David Jencks <da...@yahoo.com> wrote:
[...]
> My first guess is that a copy of spring included in geronimo is
> getting used in your web app instead of the copy you are trying to
> use: when our copy tries to load the faces/hibernate classes it can't
> find them. If this is the problem you should be able to fix it by
> adding spring and hibernate to the hidden classes list in your
> geronimo plan for your application.
[...]
Re: NoClassDefFoundError deployment errors
Posted by Richard Wallace <rw...@thewallacepack.net>.
Richard Wallace wrote:
> David Jencks wrote:
>> I think <hidden-classes/> should be the first element inside
>> <web-app>. If it's already there and our attempts to improve your
>> xml document are moving it, please let us know :-)
>>
>
> You are correct, I didn't have the hidden-classes element first in the
> file. I moved it there and it deploys now. But I'm still getting the
> error from Commons Logging that I have more than one version available
> which is not allowed. Here's my actual geronimo-web.xml file:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app
> xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
> configId="MPLCommon">
>
> <hidden-classes><filter>org.apache.commons.logging</filter></hidden-classes>
>
> <context-root>/mpl</context-root>
> <context-priority-classloader>true</context-priority-classloader>
> </web-app>
>
I guess it's also fair to mention that I do have the commons-logging jar
in my wars WEB-INF/lib directory. But I thought the <hidden-classes/>
element would make sure that the classloader created for the webapp
would not contain classes matching the filter that are in the parent
classloader. In fact, should I even need that much since I have the
<context-priority-classloader/> set to true? From the docs it seems
that that should cause the classes in the war to supersede those in the
parent classloader. So how come the webapps classloader is still
inheriting the parent classloaders classes?
Thanks,
Rich
Re: NoClassDefFoundError deployment errors
Posted by Richard Wallace <rw...@thewallacepack.net>.
David Jencks wrote:
> I think <hidden-classes/> should be the first element inside
> <web-app>. If it's already there and our attempts to improve your xml
> document are moving it, please let us know :-)
>
You are correct, I didn't have the hidden-classes element first in the
file. I moved it there and it deploys now. But I'm still getting the
error from Commons Logging that I have more than one version available
which is not allowed. Here's my actual geronimo-web.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
configId="MPLCommon">
<hidden-classes><filter>org.apache.commons.logging</filter></hidden-classes>
<context-root>/mpl</context-root>
<context-priority-classloader>true</context-priority-classloader>
</web-app>
Any ideas?
Thanks,
Rich
> thanks
> david jencks
>
> On Mar 17, 2006, at 1:19 PM, Richard Wallace wrote:
>
>> David Jencks wrote:
>>>
>>> On Mar 17, 2006, at 9:23 AM, Richard Wallace wrote:
>>>
>>>> Greetings all,
>>>>
>>>> I'm new to Geronimo. I'm trying to deploy one of my web
>>>> applications that had previously just been deployed in a standalone
>>>> tomcat container in Geronimo 1.0. I've tried this with both the
>>>> version with Jetty and with Tomcat bundled. The web app uses a
>>>> Hibernate/Spring/JSF framework stack. The jars for each project
>>>> are bundled in the war file in the WEB-INF/lib directory.
>>>> But when I deploy the application I'm getting NoClassDefFoundErrors
>>>> for javax/faces/el/VariableResolver and
>>>> org/hibernate/HibernateException.
>>>>
>>>> Any ideas what I'm missing here?
>>>
>>> My first guess is that a copy of spring included in geronimo is
>>> getting used in your web app instead of the copy you are trying to
>>> use: when our copy tries to load the faces/hibernate classes it
>>> can't find them. If this is the problem you should be able to fix
>>> it by adding spring and hibernate to the hidden classes list in your
>>> geronimo plan for your application.
>>>
>>> I think the xml syntax would be (consult
>>> modules/service-builder/src/schema/geronimo-config-1.0.xsd, this is
>>> also somewhere in the distribution such as schema/....)
>>>
>>> <hidden-classes>
>>> <filter>javax.faces.el.</filter>
>>> </hidden-classes>
>>> <hidden-classes>
>>> <filter>org.hibernate.</filter>
>>> </hidden-classes>
>>>
>>> I regard the need for multiple hidden-classes elements as a bug in
>>> the schema, and it is fixed in 1.1 (which doesn't work right now)
>>> (but not yet in 1.2, it will be fixed there when we merge in 1.1)
>>>
>> Ok, while trying that I saw the context-priority-classloader element
>> which should load stuff from the web app classloader before any of
>> the parent classloaders. I set this to true and tried to deploy. I
>> don't get any messages about javax.faces or org.hibernate now, but I
>> am getting this now:
>>
>> org.apache.commons.logging.LogConfigurationException: Invalid class
>> loader hierarchy. You have more than one version of
>> 'org.apache.commons.logging.Log' visible, which is not allowed.
>>
>>
>> So, I tried to hide the parent classloaders
>> org.apache.commons.logging with
>>
>> <hidden-classes><filter>org.apache.commons.logging</filter></hidden-classes>
>>
>>
>> But now Geronimo says there's a problem with my deployment descriptor:
>>
>> Error: Unable to distribute mpl.war: xml problem
>>
>> Invalid deployment descriptor: [error: cvc-complex-type.2.4a:
>> Expected elements
>> 'host@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
>> cross-context@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
>> valve-chain@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
>> tomcat-realm@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
>> manager@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
>> cluster@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
>> gbean-ref@http://geronimo.apache.org/xml/ns/naming-1.0
>> ejb-ref@http://geronimo.apache.org/xml/ns/naming-1.0
>> ejb-local-ref@http://geronimo.apache.org/xml/ns/naming-1.0
>> service-ref@http://geronimo.apache.org/xml/ns/naming-1.0
>> resource-ref@http://geronimo.apache.org/xml/ns/naming-1.0
>> resource-env-ref@http://geronimo.apache.org/xml/ns/naming-1.0
>> message-destination@http://geronimo.apache.org/xml/ns/naming-1.0
>>
>> security-realm-name@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
>>
>> gbean@http://geronimo.apache.org/xml/ns/deployment-1.0' instead of
>> 'hidden-classes@http://geronimo.apache.org/xml/ns/deployment-1.0'
>> here]
>>
>> Descriptor: <xml-fragment configId="MPLCommon"
>> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.0"
>> xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.0"
>> xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1"
>> xmlns:tom="http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0">
>>
>> <tom:context-root>/mpl</tom:context-root>
>>
>>
>>
>> <tom:context-priority-classloader>true</tom:context-priority-classloader>
>>
>>
>> <sys:hidden-classes>
>>
>> <sys:filter>org.apache.commons.logging</sys:filter>
>>
>> </sys:hidden-classes>
>>
>> </xml-fragment>
>>
>> From what I can tell, according to the docs and the schema this
>> should be alright. So what am I missing now?
>>
>> Thanks,
>> Rich
>
Re: NoClassDefFoundError deployment errors
Posted by David Jencks <da...@yahoo.com>.
I think <hidden-classes/> should be the first element inside <web-
app>. If it's already there and our attempts to improve your xml
document are moving it, please let us know :-)
thanks
david jencks
On Mar 17, 2006, at 1:19 PM, Richard Wallace wrote:
> David Jencks wrote:
>>
>> On Mar 17, 2006, at 9:23 AM, Richard Wallace wrote:
>>
>>> Greetings all,
>>>
>>> I'm new to Geronimo. I'm trying to deploy one of my web
>>> applications that had previously just been deployed in a
>>> standalone tomcat container in Geronimo 1.0. I've tried this
>>> with both the version with Jetty and with Tomcat bundled. The
>>> web app uses a Hibernate/Spring/JSF framework stack. The jars
>>> for each project are bundled in the war file in the WEB-INF/lib
>>> directory.
>>> But when I deploy the application I'm getting
>>> NoClassDefFoundErrors for javax/faces/el/VariableResolver and org/
>>> hibernate/HibernateException.
>>>
>>> Any ideas what I'm missing here?
>>
>> My first guess is that a copy of spring included in geronimo is
>> getting used in your web app instead of the copy you are trying to
>> use: when our copy tries to load the faces/hibernate classes it
>> can't find them. If this is the problem you should be able to fix
>> it by adding spring and hibernate to the hidden classes list in
>> your geronimo plan for your application.
>>
>> I think the xml syntax would be (consult modules/service-builder/
>> src/schema/geronimo-config-1.0.xsd, this is also somewhere in the
>> distribution such as schema/....)
>>
>> <hidden-classes>
>> <filter>javax.faces.el.</filter>
>> </hidden-classes>
>> <hidden-classes>
>> <filter>org.hibernate.</filter>
>> </hidden-classes>
>>
>> I regard the need for multiple hidden-classes elements as a bug in
>> the schema, and it is fixed in 1.1 (which doesn't work right now)
>> (but not yet in 1.2, it will be fixed there when we merge in 1.1)
>>
> Ok, while trying that I saw the context-priority-classloader
> element which should load stuff from the web app classloader before
> any of the parent classloaders. I set this to true and tried to
> deploy. I don't get any messages about javax.faces or
> org.hibernate now, but I am getting this now:
>
> org.apache.commons.logging.LogConfigurationException: Invalid class
> loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
>
>
> So, I tried to hide the parent classloaders
> org.apache.commons.logging with
>
> <hidden-classes><filter>org.apache.commons.logging</filter></hidden-
> classes>
>
> But now Geronimo says there's a problem with my deployment descriptor:
>
> Error: Unable to distribute mpl.war: xml problem
>
> Invalid deployment descriptor: [error: cvc-complex-type.2.4a:
> Expected elements
> 'host@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
> cross-context@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
> valve-chain@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
> tomcat-realm@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
> manager@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
> cluster@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
> gbean-ref@http://geronimo.apache.org/xml/ns/naming-1.0
> ejb-ref@http://geronimo.apache.org/xml/ns/naming-1.0
> ejb-local-ref@http://geronimo.apache.org/xml/ns/naming-1.0
> service-ref@http://geronimo.apache.org/xml/ns/naming-1.0
> resource-ref@http://geronimo.apache.org/xml/ns/naming-1.0
> resource-env-ref@http://geronimo.apache.org/xml/ns/naming-1.0
> message-destination@http://geronimo.apache.org/xml/ns/naming-1.0
> security-realm-name@http://geronimo.apache.org/xml/ns/j2ee/web/
> tomcat-1.0
> gbean@http://geronimo.apache.org/xml/ns/deployment-1.0' instead of
> 'hidden-classes@http://geronimo.apache.org/xml/ns/deployment-1.0'
> here]
>
> Descriptor: <xml-fragment configId="MPLCommon"
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.0"
> xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.0"
> xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1"
> xmlns:tom="http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0">
>
> <tom:context-root>/mpl</tom:context-root>
>
>
> <tom:context-priority-classloader>true</tom:context-priority-
> classloader>
>
> <sys:hidden-classes>
>
> <sys:filter>org.apache.commons.logging</sys:filter>
>
> </sys:hidden-classes>
>
> </xml-fragment>
>
> From what I can tell, according to the docs and the schema this
> should be alright. So what am I missing now?
>
> Thanks,
> Rich
Re: NoClassDefFoundError deployment errors
Posted by Paul McMahan <pa...@gmail.com>.
There's an example of using the hidden-classes element here:
http://opensource3.atlassian.com/confluence/oss/display/GERONIMO/Spring#Spring-dCountries
Here's the relevant portion of the sample
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
configId="org/springframework/samples/countries">
<!-- force the usage of the Spring jars deployed with the web application -->
<hidden-classes>
<filter>org.springframework</filter>
</hidden-classes>
<context-root>/countries</context-root>
<context-priority-classloader>false</context-priority-classloader>
</web-app>
Best wishes,
Paul
On 3/17/06, Richard Wallace <rw...@thewallacepack.net> wrote:
> David Jencks wrote:
> >
> > On Mar 17, 2006, at 9:23 AM, Richard Wallace wrote:
> >
> >> Greetings all,
> >>
> >> I'm new to Geronimo. I'm trying to deploy one of my web applications
> >> that had previously just been deployed in a standalone tomcat
> >> container in Geronimo 1.0. I've tried this with both the version
> >> with Jetty and with Tomcat bundled. The web app uses a
> >> Hibernate/Spring/JSF framework stack. The jars for each project are
> >> bundled in the war file in the WEB-INF/lib directory.
> >> But when I deploy the application I'm getting NoClassDefFoundErrors
> >> for javax/faces/el/VariableResolver and
> >> org/hibernate/HibernateException.
> >>
> >> Any ideas what I'm missing here?
> >
> > My first guess is that a copy of spring included in geronimo is
> > getting used in your web app instead of the copy you are trying to
> > use: when our copy tries to load the faces/hibernate classes it can't
> > find them. If this is the problem you should be able to fix it by
> > adding spring and hibernate to the hidden classes list in your
> > geronimo plan for your application.
> >
> > I think the xml syntax would be (consult
> > modules/service-builder/src/schema/geronimo-config-1.0.xsd, this is
> > also somewhere in the distribution such as schema/....)
> >
> > <hidden-classes>
> > <filter>javax.faces.el.</filter>
> > </hidden-classes>
> > <hidden-classes>
> > <filter>org.hibernate.</filter>
> > </hidden-classes>
> >
> > I regard the need for multiple hidden-classes elements as a bug in the
> > schema, and it is fixed in 1.1 (which doesn't work right now) (but not
> > yet in 1.2, it will be fixed there when we merge in 1.1)
> >
> Ok, while trying that I saw the context-priority-classloader element
> which should load stuff from the web app classloader before any of the
> parent classloaders. I set this to true and tried to deploy. I don't
> get any messages about javax.faces or org.hibernate now, but I am
> getting this now:
>
> org.apache.commons.logging.LogConfigurationException: Invalid class
> loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
>
>
> So, I tried to hide the parent classloaders org.apache.commons.logging with
>
> <hidden-classes><filter>org.apache.commons.logging</filter></hidden-classes>
>
> But now Geronimo says there's a problem with my deployment descriptor:
>
> Error: Unable to distribute mpl.war: xml problem
>
> Invalid deployment descriptor: [error: cvc-complex-type.2.4a:
> Expected elements
> 'host@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
> cross-context@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
> valve-chain@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
> tomcat-realm@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
> manager@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
> cluster@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
> gbean-ref@http://geronimo.apache.org/xml/ns/naming-1.0
> ejb-ref@http://geronimo.apache.org/xml/ns/naming-1.0
> ejb-local-ref@http://geronimo.apache.org/xml/ns/naming-1.0
> service-ref@http://geronimo.apache.org/xml/ns/naming-1.0
> resource-ref@http://geronimo.apache.org/xml/ns/naming-1.0
> resource-env-ref@http://geronimo.apache.org/xml/ns/naming-1.0
> message-destination@http://geronimo.apache.org/xml/ns/naming-1.0
>
> security-realm-name@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
> gbean@http://geronimo.apache.org/xml/ns/deployment-1.0' instead of
> 'hidden-classes@http://geronimo.apache.org/xml/ns/deployment-1.0'
> here]
>
> Descriptor: <xml-fragment configId="MPLCommon"
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.0"
> xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.0"
> xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1"
> xmlns:tom="http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0">
>
> <tom:context-root>/mpl</tom:context-root>
>
>
>
> <tom:context-priority-classloader>true</tom:context-priority-classloader>
>
> <sys:hidden-classes>
>
> <sys:filter>org.apache.commons.logging</sys:filter>
>
> </sys:hidden-classes>
>
> </xml-fragment>
>
> From what I can tell, according to the docs and the schema this should
> be alright. So what am I missing now?
>
> Thanks,
> Rich
>
Re: NoClassDefFoundError deployment errors
Posted by Richard Wallace <rw...@thewallacepack.net>.
David Jencks wrote:
>
> On Mar 17, 2006, at 9:23 AM, Richard Wallace wrote:
>
>> Greetings all,
>>
>> I'm new to Geronimo. I'm trying to deploy one of my web applications
>> that had previously just been deployed in a standalone tomcat
>> container in Geronimo 1.0. I've tried this with both the version
>> with Jetty and with Tomcat bundled. The web app uses a
>> Hibernate/Spring/JSF framework stack. The jars for each project are
>> bundled in the war file in the WEB-INF/lib directory.
>> But when I deploy the application I'm getting NoClassDefFoundErrors
>> for javax/faces/el/VariableResolver and
>> org/hibernate/HibernateException.
>>
>> Any ideas what I'm missing here?
>
> My first guess is that a copy of spring included in geronimo is
> getting used in your web app instead of the copy you are trying to
> use: when our copy tries to load the faces/hibernate classes it can't
> find them. If this is the problem you should be able to fix it by
> adding spring and hibernate to the hidden classes list in your
> geronimo plan for your application.
>
> I think the xml syntax would be (consult
> modules/service-builder/src/schema/geronimo-config-1.0.xsd, this is
> also somewhere in the distribution such as schema/....)
>
> <hidden-classes>
> <filter>javax.faces.el.</filter>
> </hidden-classes>
> <hidden-classes>
> <filter>org.hibernate.</filter>
> </hidden-classes>
>
> I regard the need for multiple hidden-classes elements as a bug in the
> schema, and it is fixed in 1.1 (which doesn't work right now) (but not
> yet in 1.2, it will be fixed there when we merge in 1.1)
>
Ok, while trying that I saw the context-priority-classloader element
which should load stuff from the web app classloader before any of the
parent classloaders. I set this to true and tried to deploy. I don't
get any messages about javax.faces or org.hibernate now, but I am
getting this now:
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.
So, I tried to hide the parent classloaders org.apache.commons.logging with
<hidden-classes><filter>org.apache.commons.logging</filter></hidden-classes>
But now Geronimo says there's a problem with my deployment descriptor:
Error: Unable to distribute mpl.war: xml problem
Invalid deployment descriptor: [error: cvc-complex-type.2.4a:
Expected elements
'host@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
cross-context@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
valve-chain@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
tomcat-realm@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
manager@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
cluster@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
gbean-ref@http://geronimo.apache.org/xml/ns/naming-1.0
ejb-ref@http://geronimo.apache.org/xml/ns/naming-1.0
ejb-local-ref@http://geronimo.apache.org/xml/ns/naming-1.0
service-ref@http://geronimo.apache.org/xml/ns/naming-1.0
resource-ref@http://geronimo.apache.org/xml/ns/naming-1.0
resource-env-ref@http://geronimo.apache.org/xml/ns/naming-1.0
message-destination@http://geronimo.apache.org/xml/ns/naming-1.0
security-realm-name@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0
gbean@http://geronimo.apache.org/xml/ns/deployment-1.0' instead of
'hidden-classes@http://geronimo.apache.org/xml/ns/deployment-1.0'
here]
Descriptor: <xml-fragment configId="MPLCommon"
xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.0"
xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.0"
xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1"
xmlns:tom="http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0">
<tom:context-root>/mpl</tom:context-root>
<tom:context-priority-classloader>true</tom:context-priority-classloader>
<sys:hidden-classes>
<sys:filter>org.apache.commons.logging</sys:filter>
</sys:hidden-classes>
</xml-fragment>
From what I can tell, according to the docs and the schema this should
be alright. So what am I missing now?
Thanks,
Rich
Re: NoClassDefFoundError deployment errors
Posted by David Jencks <da...@yahoo.com>.
On Mar 17, 2006, at 9:23 AM, Richard Wallace wrote:
> Greetings all,
>
> I'm new to Geronimo. I'm trying to deploy one of my web
> applications that had previously just been deployed in a standalone
> tomcat container in Geronimo 1.0. I've tried this with both the
> version with Jetty and with Tomcat bundled. The web app uses a
> Hibernate/Spring/JSF framework stack. The jars for each project
> are bundled in the war file in the WEB-INF/lib directory.
> But when I deploy the application I'm getting NoClassDefFoundErrors
> for javax/faces/el/VariableResolver and org/hibernate/
> HibernateException.
>
> Any ideas what I'm missing here?
My first guess is that a copy of spring included in geronimo is
getting used in your web app instead of the copy you are trying to
use: when our copy tries to load the faces/hibernate classes it can't
find them. If this is the problem you should be able to fix it by
adding spring and hibernate to the hidden classes list in your
geronimo plan for your application.
I think the xml syntax would be (consult modules/service-builder/src/
schema/geronimo-config-1.0.xsd, this is also somewhere in the
distribution such as schema/....)
<hidden-classes>
<filter>javax.faces.el.</filter>
</hidden-classes>
<hidden-classes>
<filter>org.hibernate.</filter>
</hidden-classes>
I regard the need for multiple hidden-classes elements as a bug in
the schema, and it is fixed in 1.1 (which doesn't work right now)
(but not yet in 1.2, it will be fixed there when we merge in 1.1)
thanks
david jencks
>
> Thanks,
> Rich