From: <sco...@jb...> - 2005-05-04 07:09:23
|
As of 4.0.2, the web container does use child first deployment as the default. However, it explicitly ignores loading classes from commons logging because the interaction of tomcat in jboss results in mbeans bound by the web container service that use commons logging in the scope of the tomcat sar class loader, and these mbeans are used as root mbeans for subsequent war deployments and allowing the war to override the commons logging classes results in type conflicts. jboss would have to rename its use of the commons logging package to break the interaction. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876396#3876396 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876396 |
From: <sco...@jb...> - 2005-05-04 07:16:40
|
Also, this discussion is somewhat silly because in general you have no control over the class loading structure in j2ee. Show me the spec other than the servlet spec that has any notion of class loader ordering. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876397#3876397 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876397 |
From: bstansberry <nu...@jb...> - 2005-05-05 05:38:40
|
Thanks, Scott. Good to know about the commons-logging interaction problem; this means a static binding approach won't work in a webapp deployed on JBoss 4.0.2. There are other cases where it won't work properly, even in webapps with child-first classloading, so I expect dynamic discovery is here to stay. I'm curious where the type conflicts are coming from (i.e. why the container mbeans are interacting with the webapps loggers); I'll have to dig into that sometime. anonymous wrote : Show me the spec other than the servlet spec that has any notion of class loader ordering. None that I know of :) Actually, a couple weeks back I looked around (a little) expecting to find parent-first specified somewhere, but found nothing. I interpreted that as meaning containers had freedom to offer child-first classloading for all deployment types if they wanted. I'd thought JBoss allowed that, but now realize I'd confused the meaning of the Java2ParentDelegation flag in the deployment descriptors -- it controls whether a scoped loader will search in a parent repository for a class, not how classloading delegation works if the class is not in a repository. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876548#3876548 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876548 |
From: n2 <nu...@jb...> - 2005-05-13 13:28:27
|
Hello, i have a problem that i related to your topic. My environment: Cluster with two Servers. SuSE Linux Enterprise Server 8, SUN JDK 1.4.2, JBoss 4.0.2, I use the all configuration and made it J2EE 1.4 compatible. My app has the following structure: JFleet.ear | | | +-... | +-avww.war | | | +-... | +-WEB-INF | | | +-... | +-lib | | | +-.. | +-commons-logging-1.2.8.jar | +-log4j-1.2.8.jar When i deploy it i get the an error: org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Log4JLogger does not implement Log | at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:511) | at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:150) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) | at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeployInternal(TomcatDeployer.java:274) | at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeploy(TomcatDeployer.java:91) | at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:357) | ... 49 more | Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Log4JLogger does not implement Log | at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:532) | at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:272) | at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414) | at org.apache.catalina.core.ContainerBase.getLogger(ContainerBase.java:380) | at org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:3563) | at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4249) | at org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1131) | at org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4358) | at org.apache.catalina.core.StandardContext.init(StandardContext.java:5008) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:324) | at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503) | ... 54 more | Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Log4JLogger does not implement Log | at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:416) | at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:525) | ... 67 more | Caused by: org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Log4JLogger does not implement Log | at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:412) | ... 68 more This i really strange because class org.apache.commons.logging.impl.Log4JLogger is part of commons logging and of course implements interface Log. Here is the code of commons logging LogFactoryImpl where the error occured: protected Constructor getLogConstructor() | throws LogConfigurationException { | // Return the previously identified Constructor (if any) | if (logConstructor != null) { | return logConstructor; | } | String logClassName = getLogClassName(); | // Attempt to load the Log implementation class | Class logClass = null; | try { | logClass = loadClass(logClassName); | if (logClass == null) { | throw new LogConfigurationException | ("No suitable Log implementation for " + logClassName); | } | if (!Log.class.isAssignableFrom(logClass)) { | throw new LogConfigurationException | ("Class " + logClassName + " does not implement Log"); | } | } catch (Throwable t) { | throw new LogConfigurationException(t); | } | ... I think logClassName i loaded by i different class loader than class Log. I tried to add a jboos-app.xml tom y ear: <?xml version="1.0"?> | <jboss-app> | <loader-repository> | cob.akuratus.com:loader=JFleet-1.10.4.ear | <loader-repository-config> | java2ParentDelegation=false | </loader-repository-config> | </loader-repository> | </jboss-app> but it does not help. Can you help me? Daniel. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877635#3877635 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877635 |