Classpath Issues with Log4J?

[dchicks]

Hi,

I'm trying to set up the Maven2 Cargo plugin, and I'm getting some
apparent classpath problems from Log4J.  I see that there was a sizable
discussion of a potential defect related to this issue back in August of
2008, but I could not find if there was any kind of resolution or
work-around.

Can someone please enlighten me?
Thanks,
David

PS - in case it helps, this is my current configuration and a snippet of
the exception that is thrown by the plugin:

Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Category
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
        ... 39 more

            <plugin>
                <groupId>org.codehaus.cargo</groupId>
                <artifactId>cargo-maven2-plugin</artifactId>
                <version>1.0-beta-2</version>
                <configuration>
                    <wait>false</wait>
                    <container>
                        <containerId>jetty6x</containerId>
                        <type>embedded</type>
                        <dependencies>
                            <dependency>
                                <groupId>mysql</groupId>
                               
<artifactId>mysql-connector-java</artifactId>
                            </dependency>
                        </dependencies>
                    </container>
                    <properties>
                        <cargo.datasource.datasource.mysql>
                           
cargo.datasource.driver=${harvey.database.driver}|
                            cargo.datasource.url=${harvey.database.url}|
                            cargo.datasource.jndi=jdbc/salientDataSource|
                           
cargo.datasource.username=${harvey.database.username}|
                           
cargo.datasource.password=${harvey.database.password}
                        </cargo.datasource.datasource.mysql>
                        <cargo.resource.resource.homeDirectory>
                            cargo.resource.name=salient/homeDirectory|
                            cargo.resource.type=java.lang.String|
                           
cargo.resource.parameters=${harvey.home.directory}
                        </cargo.resource.resource.homeDirectory>
                    </properties>
                </configuration>
            </plugin>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[RichardS]

I also hit this problem.

Ended up configuring cargo to use an external server.....

Not much help!

On Wed, Feb 25, 2009 at 9:02 AM, David C. Hicks <dhicks@...> wrote:

Hi,

I'm trying to set up the Maven2 Cargo plugin, and I'm getting some apparent classpath problems from Log4J.  I see that there was a sizable discussion of a potential defect related to this issue back in August of 2008, but I could not find if there was any kind of resolution or work-around.
Can someone please enlighten me?
Thanks,
David

PS - in case it helps, this is my current configuration and a snippet of the exception that is thrown by the plugin:

Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Category
      at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
      at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
      ... 39 more

          <plugin>
              <groupId>org.codehaus.cargo</groupId>
              <artifactId>cargo-maven2-plugin</artifactId>
              <version>1.0-beta-2</version>
              <configuration>
                  <wait>false</wait>
                  <container>
                      <containerId>jetty6x</containerId>
                      <type>embedded</type>
                      <dependencies>
                          <dependency>
                              <groupId>mysql</groupId>
                              <artifactId>mysql-connector-java</artifactId>
                          </dependency>
                      </dependencies>
                  </container>
                  <properties>
                      <cargo.datasource.datasource.mysql>
                          cargo.datasource.driver=${harvey.database.driver}|
                          cargo.datasource.url=${harvey.database.url}|
                          cargo.datasource.jndi=jdbc/salientDataSource|
                          cargo.datasource.username=${harvey.database.username}|
                          cargo.datasource.password=${harvey.database.password}
                      </cargo.datasource.datasource.mysql>
                      <cargo.resource.resource.homeDirectory>
                          cargo.resource.name=salient/homeDirectory|
                          cargo.resource.type=java.lang.String|
                          cargo.resource.parameters=${harvey.home.directory}
                      </cargo.resource.resource.homeDirectory>
                  </properties>
              </configuration>
          </plugin>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

[dchicks]

Ewww.  Thanks for the tip, though.  I'll give it a whirl.  It's better
than nothing.  :-)

richard schmidt wrote:

> I also hit this problem.
>
> Ended up configuring cargo to use an external server.....
>
> Not much help!
>
>
>
> On Wed, Feb 25, 2009 at 9:02 AM, David C. Hicks <dhicks@...
> <mailto:dhicks@...>> wrote:
>
>     Hi,
>
>     I'm trying to set up the Maven2 Cargo plugin, and I'm getting some
>     apparent classpath problems from Log4J.  I see that there was a
>     sizable discussion of a potential defect related to this issue
>     back in August of 2008, but I could not find if there was any kind
>     of resolution or work-around.
>     Can someone please enlighten me?
>     Thanks,
>     David
>
>     PS - in case it helps, this is my current configuration and a
>     snippet of the exception that is thrown by the plugin:
>
>     Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Category
>           at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>           at java.security.AccessController.doPrivileged(Native Method)
>           at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>           at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>           at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>           at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>           ... 39 more
>
>               <plugin>
>                   <groupId>org.codehaus.cargo</groupId>
>                   <artifactId>cargo-maven2-plugin</artifactId>
>                   <version>1.0-beta-2</version>
>                   <configuration>
>                       <wait>false</wait>
>                       <container>
>                           <containerId>jetty6x</containerId>
>                           <type>embedded</type>
>                           <dependencies>
>                               <dependency>
>                                   <groupId>mysql</groupId>
>                                  
>     <artifactId>mysql-connector-java</artifactId>
>                               </dependency>
>                           </dependencies>
>                       </container>
>                       <properties>
>                           <cargo.datasource.datasource.mysql>
>                              
>     cargo.datasource.driver=${harvey.database.driver}|
>                               cargo.datasource.url=${harvey.database.url}|
>                              
>     cargo.datasource.jndi=jdbc/salientDataSource|
>                              
>     cargo.datasource.username=${harvey.database.username}|
>                              
>     cargo.datasource.password=${harvey.database.password}
>                           </cargo.datasource.datasource.mysql>
>                           <cargo.resource.resource.homeDirectory>
>                               cargo.resource.name
>     <http://cargo.resource.name>=salient/homeDirectory|
>                               cargo.resource.type=java.lang.String|
>                              
>     cargo.resource.parameters=${harvey.home.directory}
>                           </cargo.resource.resource.homeDirectory>
>                       </properties>
>                   </configuration>
>               </plugin>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
>
>       http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Matt Wringe]

On Tue, 2009-02-24 at 15:37 -0500, David C. Hicks wrote:

> Ewww.  Thanks for the tip, though.  I'll give it a whirl.  It's better
> than nothing.  :-)
>
> richard schmidt wrote:
> > I also hit this problem.
> >
> > Ended up configuring cargo to use an external server.....
> >
> > Not much help!
> >
> >
> >
> > On Wed, Feb 25, 2009 at 9:02 AM, David C. Hicks <dhicks@...
> > <mailto:dhicks@...>> wrote:
> >
> >     Hi,
> >
> >     I'm trying to set up the Maven2 Cargo plugin, and I'm getting some
> >     apparent classpath problems from Log4J.  I see that there was a
> >     sizable discussion of a potential defect related to this issue
> >     back in August of 2008, but I could not find if there was any kind
> >     of resolution or work-around.
> >     Can someone please enlighten me?
> >     Thanks,
> >     David

Does this work normally if you just deploy your webapp to the a server
that is started by hand? I wonder why Cargo would be causing a
ClassNotFoundException in this situation.

> >     PS - in case it helps, this is my current configuration and a
> >     snippet of the exception that is thrown by the plugin:
> >
> >     Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Category
> >           at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> >           at java.security.AccessController.doPrivileged(Native Method)
> >           at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> >           at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> >           at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> >           at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> >           ... 39 more
> >
> >               <plugin>
> >                   <groupId>org.codehaus.cargo</groupId>
> >                   <artifactId>cargo-maven2-plugin</artifactId>
> >                   <version>1.0-beta-2</version>
> >                   <configuration>
> >                       <wait>false</wait>
> >                       <container>
> >                           <containerId>jetty6x</containerId>
> >                           <type>embedded</type>
> >                           <dependencies>
> >                               <dependency>
> >                                   <groupId>mysql</groupId>
> >                                  
> >     <artifactId>mysql-connector-java</artifactId>
> >                               </dependency>
> >                           </dependencies>
> >                       </container>
> >                       <properties>
> >                           <cargo.datasource.datasource.mysql>
> >                              
> >     cargo.datasource.driver=${harvey.database.driver}|
> >                               cargo.datasource.url=${harvey.database.url}|
> >                              
> >     cargo.datasource.jndi=jdbc/salientDataSource|
> >                              
> >     cargo.datasource.username=${harvey.database.username}|
> >                              
> >     cargo.datasource.password=${harvey.database.password}
> >                           </cargo.datasource.datasource.mysql>
> >                           <cargo.resource.resource.homeDirectory>
> >                               cargo.resource.name
> >     <http://cargo.resource.name>=salient/homeDirectory|
> >                               cargo.resource.type=java.lang.String|
> >                              
> >     cargo.resource.parameters=${harvey.home.directory}
> >                           </cargo.resource.resource.homeDirectory>
> >                       </properties>
> >                   </configuration>
> >               </plugin>
> >
> >
> >     ---------------------------------------------------------------------
> >     To unsubscribe from this list, please visit:
> >
> >       http://xircles.codehaus.org/manage_email
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[dchicks]

Matt Wringe wrote:

> On Tue, 2009-02-24 at 15:37 -0500, David C. Hicks wrote:
>  
>> Ewww.  Thanks for the tip, though.  I'll give it a whirl.  It's better
>> than nothing.  :-)
>>
>> richard schmidt wrote:
>>    
>>> I also hit this problem.
>>>
>>> Ended up configuring cargo to use an external server.....
>>>
>>> Not much help!
>>>
>>>
>>>
>>> On Wed, Feb 25, 2009 at 9:02 AM, David C. Hicks <dhicks@...
>>> <mailto:dhicks@...>> wrote:
>>>
>>>     Hi,
>>>
>>>     I'm trying to set up the Maven2 Cargo plugin, and I'm getting some
>>>     apparent classpath problems from Log4J.  I see that there was a
>>>     sizable discussion of a potential defect related to this issue
>>>     back in August of 2008, but I could not find if there was any kind
>>>     of resolution or work-around.
>>>     Can someone please enlighten me?
>>>     Thanks,
>>>     David
>>>      
>
> Does this work normally if you just deploy your webapp to the a server
> that is started by hand? I wonder why Cargo would be causing a
> ClassNotFoundException in this situation.
>  

Yes.  In fact, the only reason I'm looking at Cargo is because the Jetty
plugin doesn't support running the WAR file *and* supplying JNDI
resources at the same time.  (At least, I have not found such a
capability.)  Cargo appeared to offer me a way to make that happen.  So,
I started trying to move toward it when I encountered this problem.  The
configuration and exception output is what I see when I replace the
Jetty plugin with the Cargo plugin.  The rest of my Maven config is the
same.

>  
>>>     PS - in case it helps, this is my current configuration and a
>>>     snippet of the exception that is thrown by the plugin:
>>>
>>>     Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Category
>>>           at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>>>           at java.security.AccessController.doPrivileged(Native Method)
>>>           at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>>>           at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>>>           at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>>>           at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>>>           ... 39 more
>>>
>>>               <plugin>
>>>                   <groupId>org.codehaus.cargo</groupId>
>>>                   <artifactId>cargo-maven2-plugin</artifactId>
>>>                   <version>1.0-beta-2</version>
>>>                   <configuration>
>>>                       <wait>false</wait>
>>>                       <container>
>>>                           <containerId>jetty6x</containerId>
>>>                           <type>embedded</type>
>>>                           <dependencies>
>>>                               <dependency>
>>>                                   <groupId>mysql</groupId>
>>>                                  
>>>     <artifactId>mysql-connector-java</artifactId>
>>>                               </dependency>
>>>                           </dependencies>
>>>                       </container>
>>>                       <properties>
>>>                           <cargo.datasource.datasource.mysql>
>>>                              
>>>     cargo.datasource.driver=${harvey.database.driver}|
>>>                               cargo.datasource.url=${harvey.database.url}|
>>>                              
>>>     cargo.datasource.jndi=jdbc/salientDataSource|
>>>                              
>>>     cargo.datasource.username=${harvey.database.username}|
>>>                              
>>>     cargo.datasource.password=${harvey.database.password}
>>>                           </cargo.datasource.datasource.mysql>
>>>                           <cargo.resource.resource.homeDirectory>
>>>                               cargo.resource.name
>>>     <http://cargo.resource.name>=salient/homeDirectory|
>>>                               cargo.resource.type=java.lang.String|
>>>                              
>>>     cargo.resource.parameters=${harvey.home.directory}
>>>                           </cargo.resource.resource.homeDirectory>
>>>                       </properties>
>>>                   </configuration>
>>>               </plugin>
>>>
>>>
>>>     ---------------------------------------------------------------------
>>>     To unsubscribe from this list, please visit:
>>>
>>>       http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>    
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Matt Wringe]

On Tue, 2009-02-24 at 16:03 -0500, David C. Hicks wrote:

>
> Matt Wringe wrote:
> > On Tue, 2009-02-24 at 15:37 -0500, David C. Hicks wrote:
> >  
> >> Ewww.  Thanks for the tip, though.  I'll give it a whirl.  It's better
> >> than nothing.  :-)
> >>
> >> richard schmidt wrote:
> >>    
> >>> I also hit this problem.
> >>>
> >>> Ended up configuring cargo to use an external server.....
> >>>
> >>> Not much help!
> >>>
> >>>
> >>>
> >>> On Wed, Feb 25, 2009 at 9:02 AM, David C. Hicks <dhicks@...
> >>> <mailto:dhicks@...>> wrote:
> >>>
> >>>     Hi,
> >>>
> >>>     I'm trying to set up the Maven2 Cargo plugin, and I'm getting some
> >>>     apparent classpath problems from Log4J.  I see that there was a
> >>>     sizable discussion of a potential defect related to this issue
> >>>     back in August of 2008, but I could not find if there was any kind
> >>>     of resolution or work-around.
> >>>     Can someone please enlighten me?
> >>>     Thanks,
> >>>     David
> >>>      
> >
> > Does this work normally if you just deploy your webapp to the a server
> > that is started by hand? I wonder why Cargo would be causing a
> > ClassNotFoundException in this situation.
> >  
> Yes.  In fact, the only reason I'm looking at Cargo is because the Jetty
> plugin doesn't support running the WAR file *and* supplying JNDI
> resources at the same time.  (At least, I have not found such a
> capability.)  Cargo appeared to offer me a way to make that happen.  So,
> I started trying to move toward it when I encountered this problem.  The
> configuration and exception output is what I see when I replace the
> Jetty plugin with the Cargo plugin.  The rest of my Maven config is the
> same.

Ok, the data provided does really help me.
Jetty doesn't contain a log4j file and cargo doesn't reference any
org.apache.log4j classes. I am guessing the webapp contains the log4j
jar within its web-inf/lib directory and the webapp tries to reference
log4j and the error gets thrown? Any more data you can provide?

> >  
> >>>     PS - in case it helps, this is my current configuration and a
> >>>     snippet of the exception that is thrown by the plugin:
> >>>
> >>>     Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Category
> >>>           at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> >>>           at java.security.AccessController.doPrivileged(Native Method)
> >>>           at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> >>>           at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> >>>           at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> >>>           at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> >>>           ... 39 more
> >>>
> >>>               <plugin>
> >>>                   <groupId>org.codehaus.cargo</groupId>
> >>>                   <artifactId>cargo-maven2-plugin</artifactId>
> >>>                   <version>1.0-beta-2</version>
> >>>                   <configuration>
> >>>                       <wait>false</wait>
> >>>                       <container>
> >>>                           <containerId>jetty6x</containerId>
> >>>                           <type>embedded</type>
> >>>                           <dependencies>
> >>>                               <dependency>
> >>>                                   <groupId>mysql</groupId>
> >>>                                  
> >>>     <artifactId>mysql-connector-java</artifactId>
> >>>                               </dependency>
> >>>                           </dependencies>
> >>>                       </container>
> >>>                       <properties>
> >>>                           <cargo.datasource.datasource.mysql>
> >>>                              
> >>>     cargo.datasource.driver=${harvey.database.driver}|
> >>>                               cargo.datasource.url=${harvey.database.url}|
> >>>                              
> >>>     cargo.datasource.jndi=jdbc/salientDataSource|
> >>>                              
> >>>     cargo.datasource.username=${harvey.database.username}|
> >>>                              
> >>>     cargo.datasource.password=${harvey.database.password}
> >>>                           </cargo.datasource.datasource.mysql>
> >>>                           <cargo.resource.resource.homeDirectory>
> >>>                               cargo.resource.name
> >>>     <http://cargo.resource.name>=salient/homeDirectory|
> >>>                               cargo.resource.type=java.lang.String|
> >>>                              
> >>>     cargo.resource.parameters=${harvey.home.directory}
> >>>                           </cargo.resource.resource.homeDirectory>
> >>>                       </properties>
> >>>                   </configuration>
> >>>               </plugin>
> >>>
> >>>
> >>>     ---------------------------------------------------------------------
> >>>     To unsubscribe from this list, please visit:
> >>>
> >>>       http://xircles.codehaus.org/manage_email
> >>>
> >>>
> >>>
> >>>      
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this list, please visit:
> >>
> >>     http://xircles.codehaus.org/manage_email
> >>
> >>
> >>    
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >  
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[dchicks]

Matt Wringe wrote:
> Ok, the data provided does really help me.
> Jetty doesn't contain a log4j file and cargo doesn't reference any
> org.apache.log4j classes. I am guessing the webapp contains the log4j
> jar within its web-inf/lib directory and the webapp tries to reference
> log4j and the error gets thrown? Any more data you can provide?
>  
Absolutely!  I'll be more than happy to give you tons of information.  I
just didn't want to flood the list, initially.  :-)

Yes, the log4j jar is in WEB-INF/lib.  It is version 1.2.14.  It appears
to me that the exception is thrown by Jetty as it begins the process of
initializing the web context for the embedded application.  (I am trying
to run this in embedded mode.)  A larger chunk of the exception stack is
included below.  One of the first things that happens when the context
initializes (in our app) is that we initialize logging the way we want
it to work.  However, I don't see that class/method in this stack.  So,
I'm not sure if we've even gotten that far along, yet.

If I can provide anything else, please just let me know.  It might take
a bit of time - I'm working on other things, right now, so have to
recreate the environment that causes this exception.  It's easy to
create, though, and I don't mind helping track down a problem, if I can.

Dave

2009-02-24 16:27:52.098::INFO:  Extract
jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/
to
/tmp/Jetty_0_0_0_0_8080_salient-war-0.1.40-SNAPSHOT.war__salient-war-0_1_40-SNAPSHOT__u13vah/webapp
2009-02-24 16:27:53.727::WARN:  failed
org.mortbay.jetty.webapp.WebAppContext@48bc64{/salient-war-0.1.40-SNAPSHOT,jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/}
java.lang.ExceptionInInitializerError
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
        at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at java.lang.Class.newInstance0(Class.java:355)
        at java.lang.Class.newInstance(Class.java:308)
        at
org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:644)
        at
org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:625)
        at
org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:366)
        at
org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:288)
        at
org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:221)
        at
org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:179)
        at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1188)
        at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481)
        at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434)
        at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
        at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
        at
org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120)
        at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
        at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
        at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
        at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
        at org.mortbay.jetty.Server.doStart(Server.java:210)
        at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
        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:597)
        at
org.codehaus.cargo.container.jetty.internal.JettyExecutorThread.run(JettyExecutorThread.java:68)
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: No suitable Log
constructor [Ljava.lang.Class;@18b9a72 for
org.apache.commons.logging.impl.Log4JLogger (Caused by
java.lang.NoClassDefFoundError: org/apache/log4j/Category) (Caused by
org.apache.commons.logging.LogConfigurationException: No suitable Log
constructor [Ljava.lang.Class;@18b9a72 for
org.apache.commons.logging.impl.Log4JLogger (Caused by
java.lang.NoClassDefFoundError: org/apache/log4j/Category))
        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.tiles.web.startup.TilesListener.<clinit>(TilesListener.java:45)
        ... 29 more
Caused by: org.apache.commons.logging.LogConfigurationException: No
suitable Log constructor [Ljava.lang.Class;@18b9a72 for
org.apache.commons.logging.impl.Log4JLogger (Caused by
java.lang.NoClassDefFoundError: org/apache/log4j/Category)
        at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
        at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
        ... 33 more
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Category
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
        at java.lang.Class.getConstructor0(Class.java:2699)
        at java.lang.Class.getConstructor(Class.java:1657)
        at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
        ... 34 more
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Category
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
        ... 39 more


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adrian Cole]

I'm guessing commons-logging is in a parent classloader and can't resolve log4j.  Can you dump your classpath?

Cheers,
-Adrian

On Tue, Feb 24, 2009 at 9:38 PM, David C. Hicks <dhicks@...> wrote:

Matt Wringe wrote:

Ok, the data provided does really help me.
Jetty doesn't contain a log4j file and cargo doesn't reference any
org.apache.log4j classes. I am guessing the webapp contains the log4j
jar within its web-inf/lib directory and the webapp tries to reference
log4j and the error gets thrown? Any more data you can provide?
 

Absolutely!  I'll be more than happy to give you tons of information.  I just didn't want to flood the list, initially.  :-)

Yes, the log4j jar is in WEB-INF/lib.  It is version 1.2.14.  It appears to me that the exception is thrown by Jetty as it begins the process of initializing the web context for the embedded application.  (I am trying to run this in embedded mode.)  A larger chunk of the exception stack is included below.  One of the first things that happens when the context initializes (in our app) is that we initialize logging the way we want it to work.  However, I don't see that class/method in this stack.  So, I'm not sure if we've even gotten that far along, yet.

If I can provide anything else, please just let me know.  It might take a bit of time - I'm working on other things, right now, so have to recreate the environment that causes this exception.  It's easy to create, though, and I don't mind helping track down a problem, if I can.

Dave

2009-02-24 16:27:52.098::INFO:  Extract jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/ to /tmp/Jetty_0_0_0_0_8080_salient-war-0.1.40-SNAPSHOT.war__salient-war-0_1_40-SNAPSHOT__u13vah/webapp
2009-02-24 16:27:53.727::WARN:  failed org.mortbay.jetty.webapp.WebAppContext@48bc64{/salient-war-0.1.40-SNAPSHOT,jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/}
java.lang.ExceptionInInitializerError
      at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
      at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
      at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
      at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
      at java.lang.Class.newInstance0(Class.java:355)
      at java.lang.Class.newInstance(Class.java:308)
      at org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:644)
      at org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:625)
      at org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:366)
      at org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:288)
      at org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:221)
      at org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:179)
      at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1188)
      at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481)
      at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434)
      at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
      at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
      at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120)
      at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
      at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
      at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
      at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
      at org.mortbay.jetty.Server.doStart(Server.java:210)
      at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
      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:597)
      at org.codehaus.cargo.container.jetty.internal.JettyExecutorThread.run(JettyExecutorThread.java:68)
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@18b9a72 for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category) (Caused by org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@18b9a72 for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category))
      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.tiles.web.startup.TilesListener.<clinit>(TilesListener.java:45)
      ... 29 more
Caused by: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@18b9a72 for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category)
      at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
      at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
      ... 33 more
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Category
      at java.lang.Class.getDeclaredConstructors0(Native Method)
      at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
      at java.lang.Class.getConstructor0(Class.java:2699)
      at java.lang.Class.getConstructor(Class.java:1657)
      at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
      ... 34 more

Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Category
      at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
      at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
      ... 39 more

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

[dchicks]

Adrian Cole wrote:
> I'm guessing commons-logging is in a parent classloader and can't
> resolve log4j.  Can you dump your classpath?
If you can give me a method to do that, I'll be happy to.  The only two
possibilities I could come up with are:

1) mvn dependency:tree (which really doesn't show you the classpath)
2) mvn -X cargo:start (from which I'm not finding something that looks
like a classpath being dumped)
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Matt Wringe]

On Tue, 2009-02-24 at 22:09 +0000, Adrian Cole wrote:
> I'm guessing commons-logging is in a parent classloader and can't
> resolve log4j.
OK, he is using the embedded Jetty container in which Cargo
automatically adds a commons-logging jar but not a log4j jar.

It looks like its the Cargo embedded Jetty dependency autoresolver that
bites us again :(
see org.codehaus.cargo.maven2.jetty.JettyArtifactResolver

That really needs to be fixed to allow people to specify the classpath
if needed.

> Can you dump your classpath?
>
> Cheers,
> -Adrian
>
> On Tue, Feb 24, 2009 at 9:38 PM, David C. Hicks <dhicks@...>
> wrote:
>        
>        
>         Matt Wringe wrote:
>                 Ok, the data provided does really help me.
>                 Jetty doesn't contain a log4j file and cargo doesn't
>                 reference any
>                 org.apache.log4j classes. I am guessing the webapp
>                 contains the log4j
>                 jar within its web-inf/lib directory and the webapp
>                 tries to reference
>                 log4j and the error gets thrown? Any more data you can
>                 provide?
>                  
>         Absolutely!  I'll be more than happy to give you tons of
>         information.  I just didn't want to flood the list,
>         initially.  :-)
>        
>         Yes, the log4j jar is in WEB-INF/lib.  It is version 1.2.14.
>          It appears to me that the exception is thrown by Jetty as it
>         begins the process of initializing the web context for the
>         embedded application.  (I am trying to run this in embedded
>         mode.)  A larger chunk of the exception stack is included
>         below.  One of the first things that happens when the context
>         initializes (in our app) is that we initialize logging the way
>         we want it to work.  However, I don't see that class/method in
>         this stack.  So, I'm not sure if we've even gotten that far
>         along, yet.
>        
>         If I can provide anything else, please just let me know.  It
>         might take a bit of time - I'm working on other things, right
>         now, so have to recreate the environment that causes this
>         exception.  It's easy to create, though, and I don't mind
>         helping track down a problem, if I can.
>        
>         Dave
>        
>         2009-02-24 16:27:52.098::INFO:  Extract
>         jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/ to /tmp/Jetty_0_0_0_0_8080_salient-war-0.1.40-SNAPSHOT.war__salient-war-0_1_40-SNAPSHOT__u13vah/webapp
>         2009-02-24 16:27:53.727::WARN:  failed
>         org.mortbay.jetty.webapp.WebAppContext@48bc64{/salient-war-0.1.40-SNAPSHOT,jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/}
>         java.lang.ExceptionInInitializerError
>               at
>         sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>         Method)
>               at
>         sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>               at
>         sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>               at
>         java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>               at java.lang.Class.newInstance0(Class.java:355)
>               at java.lang.Class.newInstance(Class.java:308)
>               at
>         org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:644)
>               at
>         org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:625)
>               at
>         org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:366)
>               at
>         org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:288)
>               at
>         org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:221)
>               at
>         org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:179)
>               at
>         org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1188)
>               at
>         org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481)
>               at
>         org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434)
>               at
>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>               at
>         org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
>               at
>         org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120)
>               at
>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>               at
>         org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
>               at
>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>               at
>         org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
>               at org.mortbay.jetty.Server.doStart(Server.java:210)
>               at
>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>               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:597)
>               at
>         org.codehaus.cargo.container.jetty.internal.JettyExecutorThread.run(JettyExecutorThread.java:68)
>         Caused by:
>         org.apache.commons.logging.LogConfigurationException:
>         org.apache.commons.logging.LogConfigurationException: No
>         suitable Log constructor [Ljava.lang.Class;@18b9a72 for
>         org.apache.commons.logging.impl.Log4JLogger (Caused by
>         java.lang.NoClassDefFoundError: org/apache/log4j/Category)
>         (Caused by
>         org.apache.commons.logging.LogConfigurationException: No
>         suitable Log constructor [Ljava.lang.Class;@18b9a72 for
>         org.apache.commons.logging.impl.Log4JLogger (Caused by
>         java.lang.NoClassDefFoundError: org/apache/log4j/Category))
>               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.tiles.web.startup.TilesListener.<clinit>(TilesListener.java:45)
>               ... 29 more
>         Caused by:
>         org.apache.commons.logging.LogConfigurationException: No
>         suitable Log constructor [Ljava.lang.Class;@18b9a72 for
>         org.apache.commons.logging.impl.Log4JLogger (Caused by
>         java.lang.NoClassDefFoundError: org/apache/log4j/Category)
>               at
>         org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
>               at
>         org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
>               ... 33 more
>         Caused by: java.lang.NoClassDefFoundError:
>         org/apache/log4j/Category
>               at java.lang.Class.getDeclaredConstructors0(Native
>         Method)
>               at
>         java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
>               at java.lang.Class.getConstructor0(Class.java:2699)
>               at java.lang.Class.getConstructor(Class.java:1657)
>               at
>         org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
>               ... 34 more
>        
>         Caused by: java.lang.ClassNotFoundException:
>         org.apache.log4j.Category
>               at java.net.URLClassLoader
>         $1.run(URLClassLoader.java:200)
>               at java.security.AccessController.doPrivileged(Native
>         Method)
>               at
>         java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>               at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>               at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>               at
>         java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>               ... 39 more
>        
>        
>        
>        
>         ---------------------------------------------------------------------
>         To unsubscribe from this list, please visit:
>        
>           http://xircles.codehaus.org/manage_email
>        
>        
>        
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[dchicks]

Well, I hate to have been the bearer of bad news, but glad the
information was helpful.
Is there any kind of work-around that you can suggest?

If there's any more info I can provide, just let me know.

Thanks,
Dave

Matt Wringe wrote:

> On Tue, 2009-02-24 at 22:09 +0000, Adrian Cole wrote:
>  
>> I'm guessing commons-logging is in a parent classloader and can't
>> resolve log4j.
>>    
> OK, he is using the embedded Jetty container in which Cargo
> automatically adds a commons-logging jar but not a log4j jar.
>
> It looks like its the Cargo embedded Jetty dependency autoresolver that
> bites us again :(
> see org.codehaus.cargo.maven2.jetty.JettyArtifactResolver
>
> That really needs to be fixed to allow people to specify the classpath
> if needed.
>
>  
>> Can you dump your classpath?
>>
>> Cheers,
>> -Adrian
>>
>> On Tue, Feb 24, 2009 at 9:38 PM, David C. Hicks <dhicks@...>
>> wrote:
>>        
>>        
>>         Matt Wringe wrote:
>>                 Ok, the data provided does really help me.
>>                 Jetty doesn't contain a log4j file and cargo doesn't
>>                 reference any
>>                 org.apache.log4j classes. I am guessing the webapp
>>                 contains the log4j
>>                 jar within its web-inf/lib directory and the webapp
>>                 tries to reference
>>                 log4j and the error gets thrown? Any more data you can
>>                 provide?
>>                  
>>         Absolutely!  I'll be more than happy to give you tons of
>>         information.  I just didn't want to flood the list,
>>         initially.  :-)
>>        
>>         Yes, the log4j jar is in WEB-INF/lib.  It is version 1.2.14.
>>          It appears to me that the exception is thrown by Jetty as it
>>         begins the process of initializing the web context for the
>>         embedded application.  (I am trying to run this in embedded
>>         mode.)  A larger chunk of the exception stack is included
>>         below.  One of the first things that happens when the context
>>         initializes (in our app) is that we initialize logging the way
>>         we want it to work.  However, I don't see that class/method in
>>         this stack.  So, I'm not sure if we've even gotten that far
>>         along, yet.
>>        
>>         If I can provide anything else, please just let me know.  It
>>         might take a bit of time - I'm working on other things, right
>>         now, so have to recreate the environment that causes this
>>         exception.  It's easy to create, though, and I don't mind
>>         helping track down a problem, if I can.
>>        
>>         Dave
>>        
>>         2009-02-24 16:27:52.098::INFO:  Extract
>>         jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/ to /tmp/Jetty_0_0_0_0_8080_salient-war-0.1.40-SNAPSHOT.war__salient-war-0_1_40-SNAPSHOT__u13vah/webapp
>>         2009-02-24 16:27:53.727::WARN:  failed
>>         org.mortbay.jetty.webapp.WebAppContext@48bc64{/salient-war-0.1.40-SNAPSHOT,jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/}
>>         java.lang.ExceptionInInitializerError
>>               at
>>         sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>         Method)
>>               at
>>         sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>>               at
>>         sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>>               at
>>         java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>>               at java.lang.Class.newInstance0(Class.java:355)
>>               at java.lang.Class.newInstance(Class.java:308)
>>               at
>>         org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:644)
>>               at
>>         org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:625)
>>               at
>>         org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:366)
>>               at
>>         org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:288)
>>               at
>>         org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:221)
>>               at
>>         org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:179)
>>               at
>>         org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1188)
>>               at
>>         org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481)
>>               at
>>         org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434)
>>               at
>>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>>               at
>>         org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
>>               at
>>         org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120)
>>               at
>>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>>               at
>>         org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
>>               at
>>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>>               at
>>         org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
>>               at org.mortbay.jetty.Server.doStart(Server.java:210)
>>               at
>>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>>               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:597)
>>               at
>>         org.codehaus.cargo.container.jetty.internal.JettyExecutorThread.run(JettyExecutorThread.java:68)
>>         Caused by:
>>         org.apache.commons.logging.LogConfigurationException:
>>         org.apache.commons.logging.LogConfigurationException: No
>>         suitable Log constructor [Ljava.lang.Class;@18b9a72 for
>>         org.apache.commons.logging.impl.Log4JLogger (Caused by
>>         java.lang.NoClassDefFoundError: org/apache/log4j/Category)
>>         (Caused by
>>         org.apache.commons.logging.LogConfigurationException: No
>>         suitable Log constructor [Ljava.lang.Class;@18b9a72 for
>>         org.apache.commons.logging.impl.Log4JLogger (Caused by
>>         java.lang.NoClassDefFoundError: org/apache/log4j/Category))
>>               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.tiles.web.startup.TilesListener.<clinit>(TilesListener.java:45)
>>               ... 29 more
>>         Caused by:
>>         org.apache.commons.logging.LogConfigurationException: No
>>         suitable Log constructor [Ljava.lang.Class;@18b9a72 for
>>         org.apache.commons.logging.impl.Log4JLogger (Caused by
>>         java.lang.NoClassDefFoundError: org/apache/log4j/Category)
>>               at
>>         org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
>>               at
>>         org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
>>               ... 33 more
>>         Caused by: java.lang.NoClassDefFoundError:
>>         org/apache/log4j/Category
>>               at java.lang.Class.getDeclaredConstructors0(Native
>>         Method)
>>               at
>>         java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
>>               at java.lang.Class.getConstructor0(Class.java:2699)
>>               at java.lang.Class.getConstructor(Class.java:1657)
>>               at
>>         org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
>>               ... 34 more
>>        
>>         Caused by: java.lang.ClassNotFoundException:
>>         org.apache.log4j.Category
>>               at java.net.URLClassLoader
>>         $1.run(URLClassLoader.java:200)
>>               at java.security.AccessController.doPrivileged(Native
>>         Method)
>>               at
>>         java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>>               at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>>               at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>>               at
>>         java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>>               ... 39 more
>>        
>>        
>>        
>>        
>>         ---------------------------------------------------------------------
>>         To unsubscribe from this list, please visit:
>>        
>>           http://xircles.codehaus.org/manage_email
>>        
>>        
>>        
>>
>>    
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adrian Cole]

Good digging, Matt.  Do we have a Jira on this?  If not, if someone raises one, I'll look into it tomorrow.

Cheers,
-Adrian

On Tue, Feb 24, 2009 at 11:27 PM, Matt Wringe <mwringe@...> wrote:

On Tue, 2009-02-24 at 22:09 +0000, Adrian Cole wrote:
> I'm guessing commons-logging is in a parent classloader and can't
> resolve log4j.

OK, he is using the embedded Jetty container in which Cargo
automatically adds a commons-logging jar but not a log4j jar.

It looks like its the Cargo embedded Jetty dependency autoresolver that
bites us again :(
see org.codehaus.cargo.maven2.jetty.JettyArtifactResolver

That really needs to be fixed to allow people to specify the classpath
if needed.

> Can you dump your classpath?
>
> Cheers,
> -Adrian
>
> On Tue, Feb 24, 2009 at 9:38 PM, David C. Hicks <dhicks@...>
> wrote:
>
>
>         Matt Wringe wrote:
>                 Ok, the data provided does really help me.
>                 Jetty doesn't contain a log4j file and cargo doesn't
>                 reference any
>                 org.apache.log4j classes. I am guessing the webapp
>                 contains the log4j
>                 jar within its web-inf/lib directory and the webapp
>                 tries to reference
>                 log4j and the error gets thrown? Any more data you can
>                 provide?
>
>         Absolutely!  I'll be more than happy to give you tons of
>         information.  I just didn't want to flood the list,
>         initially.  :-)
>
>         Yes, the log4j jar is in WEB-INF/lib.  It is version 1.2.14.
>          It appears to me that the exception is thrown by Jetty as it
>         begins the process of initializing the web context for the
>         embedded application.  (I am trying to run this in embedded
>         mode.)  A larger chunk of the exception stack is included
>         below.  One of the first things that happens when the context
>         initializes (in our app) is that we initialize logging the way
>         we want it to work.  However, I don't see that class/method in
>         this stack.  So, I'm not sure if we've even gotten that far
>         along, yet.
>
>         If I can provide anything else, please just let me know.  It
>         might take a bit of time - I'm working on other things, right
>         now, so have to recreate the environment that causes this
>         exception.  It's easy to create, though, and I don't mind
>         helping track down a problem, if I can.
>
>         Dave
>
>         2009-02-24 16:27:52.098::INFO:  Extract
>         jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/ to /tmp/Jetty_0_0_0_0_8080_salient-war-0.1.40-SNAPSHOT.war__salient-war-0_1_40-SNAPSHOT__u13vah/webapp
>         2009-02-24 16:27:53.727::WARN:  failed
>         org.mortbay.jetty.webapp.WebAppContext@48bc64{/salient-war-0.1.40-SNAPSHOT,jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/}
>         java.lang.ExceptionInInitializerError
>               at
>         sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>         Method)
>               at
>         sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>               at
>         sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>               at
>         java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>               at java.lang.Class.newInstance0(Class.java:355)
>               at java.lang.Class.newInstance(Class.java:308)
>               at
>         org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:644)
>               at
>         org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:625)
>               at
>         org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:366)
>               at
>         org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:288)
>               at
>         org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:221)
>               at
>         org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:179)
>               at
>         org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1188)
>               at
>         org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481)
>               at
>         org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434)
>               at
>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>               at
>         org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
>               at
>         org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120)
>               at
>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>               at
>         org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
>               at
>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>               at
>         org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
>               at org.mortbay.jetty.Server.doStart(Server.java:210)
>               at
>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>               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:597)
>               at
>         org.codehaus.cargo.container.jetty.internal.JettyExecutorThread.run(JettyExecutorThread.java:68)
>         Caused by:
>         org.apache.commons.logging.LogConfigurationException:
>         org.apache.commons.logging.LogConfigurationException: No
>         suitable Log constructor [Ljava.lang.Class;@18b9a72 for
>         org.apache.commons.logging.impl.Log4JLogger (Caused by
>         java.lang.NoClassDefFoundError: org/apache/log4j/Category)
>         (Caused by
>         org.apache.commons.logging.LogConfigurationException: No
>         suitable Log constructor [Ljava.lang.Class;@18b9a72 for
>         org.apache.commons.logging.impl.Log4JLogger (Caused by
>         java.lang.NoClassDefFoundError: org/apache/log4j/Category))
>               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.tiles.web.startup.TilesListener.<clinit>(TilesListener.java:45)
>               ... 29 more
>         Caused by:
>         org.apache.commons.logging.LogConfigurationException: No
>         suitable Log constructor [Ljava.lang.Class;@18b9a72 for
>         org.apache.commons.logging.impl.Log4JLogger (Caused by
>         java.lang.NoClassDefFoundError: org/apache/log4j/Category)
>               at
>         org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
>               at
>         org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
>               ... 33 more
>         Caused by: java.lang.NoClassDefFoundError:
>         org/apache/log4j/Category
>               at java.lang.Class.getDeclaredConstructors0(Native
>         Method)
>               at
>         java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
>               at java.lang.Class.getConstructor0(Class.java:2699)
>               at java.lang.Class.getConstructor(Class.java:1657)
>               at
>         org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
>               ... 34 more
>
>         Caused by: java.lang.ClassNotFoundException:
>         org.apache.log4j.Category
>               at java.net.URLClassLoader
>         $1.run(URLClassLoader.java:200)
>               at java.security.AccessController.doPrivileged(Native
>         Method)
>               at
>         java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>               at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>               at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>               at
>         java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>               ... 39 more
>
>
>
>
>         ---------------------------------------------------------------------
>         To unsubscribe from this list, please visit:
>
>           http://xircles.codehaus.org/manage_email
>
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Matt Wringe]

On Tue, 2009-02-24 at 23:48 +0000, Adrian Cole wrote:
> Good digging, Matt.  Do we have a Jira on this?  If not, if someone
> raises one, I'll look into it tomorrow.

This is related to a few embedded Jetty issues, the specific one to this
case is http://jira.codehaus.org/browse/CARGO-692.

We really need to rethink how we are going to provide dependencies for
embedded Jetty.

>
> Cheers,
> -Adrian
>
> On Tue, Feb 24, 2009 at 11:27 PM, Matt Wringe <mwringe@...>
> wrote:
>        
>         On Tue, 2009-02-24 at 22:09 +0000, Adrian Cole wrote:
>         > I'm guessing commons-logging is in a parent classloader and
>         can't
>         > resolve log4j.
>        
>         OK, he is using the embedded Jetty container in which Cargo
>         automatically adds a commons-logging jar but not a log4j jar.
>        
>         It looks like its the Cargo embedded Jetty dependency
>         autoresolver that
>         bites us again :(
>         see org.codehaus.cargo.maven2.jetty.JettyArtifactResolver
>        
>         That really needs to be fixed to allow people to specify the
>         classpath
>         if needed.
>        
>        
>         > Can you dump your classpath?
>         >
>         > Cheers,
>         > -Adrian
>         >
>         > On Tue, Feb 24, 2009 at 9:38 PM, David C. Hicks
>         <dhicks@...>
>         > wrote:
>         >
>         >
>         >         Matt Wringe wrote:
>         >                 Ok, the data provided does really help me.
>         >                 Jetty doesn't contain a log4j file and cargo
>         doesn't
>         >                 reference any
>         >                 org.apache.log4j classes. I am guessing the
>         webapp
>         >                 contains the log4j
>         >                 jar within its web-inf/lib directory and the
>         webapp
>         >                 tries to reference
>         >                 log4j and the error gets thrown? Any more
>         data you can
>         >                 provide?
>         >
>         >         Absolutely!  I'll be more than happy to give you
>         tons of
>         >         information.  I just didn't want to flood the list,
>         >         initially.  :-)
>         >
>         >         Yes, the log4j jar is in WEB-INF/lib.  It is version
>         1.2.14.
>         >          It appears to me that the exception is thrown by
>         Jetty as it
>         >         begins the process of initializing the web context
>         for the
>         >         embedded application.  (I am trying to run this in
>         embedded
>         >         mode.)  A larger chunk of the exception stack is
>         included
>         >         below.  One of the first things that happens when
>         the context
>         >         initializes (in our app) is that we initialize
>         logging the way
>         >         we want it to work.  However, I don't see that
>         class/method in
>         >         this stack.  So, I'm not sure if we've even gotten
>         that far
>         >         along, yet.
>         >
>         >         If I can provide anything else, please just let me
>         know.  It
>         >         might take a bit of time - I'm working on other
>         things, right
>         >         now, so have to recreate the environment that causes
>         this
>         >         exception.  It's easy to create, though, and I don't
>         mind
>         >         helping track down a problem, if I can.
>         >
>         >         Dave
>         >
>         >         2009-02-24 16:27:52.098::INFO:  Extract
>         >
>         jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/ to /tmp/Jetty_0_0_0_0_8080_salient-war-0.1.40-SNAPSHOT.war__salient-war-0_1_40-SNAPSHOT__u13vah/webapp
>         >         2009-02-24 16:27:53.727::WARN:  failed
>         >
>         org.mortbay.jetty.webapp.WebAppContext@48bc64{/salient-war-0.1.40-SNAPSHOT,jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/}
>         >         java.lang.ExceptionInInitializerError
>         >               at
>         >
>         sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>         >         Method)
>         >               at
>         >
>         sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>         >               at
>         >
>         sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>         >               at
>         >
>         java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>         >               at
>         java.lang.Class.newInstance0(Class.java:355)
>         >               at java.lang.Class.newInstance(Class.java:308)
>         >               at
>         >
>         org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:644)
>         >               at
>         >
>         org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:625)
>         >               at
>         >
>         org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:366)
>         >               at
>         >
>         org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:288)
>         >               at
>         >
>         org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:221)
>         >               at
>         >
>         org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:179)
>         >               at
>         >
>         org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1188)
>         >               at
>         >
>         org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481)
>         >               at
>         >
>         org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434)
>         >               at
>         >
>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>         >               at
>         >
>         org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
>         >               at
>         >
>         org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120)
>         >               at
>         >
>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>         >               at
>         >
>         org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
>         >               at
>         >
>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>         >               at
>         >
>         org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
>         >               at
>         org.mortbay.jetty.Server.doStart(Server.java:210)
>         >               at
>         >
>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>         >               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:597)
>         >               at
>         >
>         org.codehaus.cargo.container.jetty.internal.JettyExecutorThread.run(JettyExecutorThread.java:68)
>         >         Caused by:
>         >
>         org.apache.commons.logging.LogConfigurationException:
>         >
>         org.apache.commons.logging.LogConfigurationException: No
>         >         suitable Log constructor [Ljava.lang.Class;@18b9a72
>         for
>         >         org.apache.commons.logging.impl.Log4JLogger (Caused
>         by
>         >         java.lang.NoClassDefFoundError:
>         org/apache/log4j/Category)
>         >         (Caused by
>         >
>         org.apache.commons.logging.LogConfigurationException: No
>         >         suitable Log constructor [Ljava.lang.Class;@18b9a72
>         for
>         >         org.apache.commons.logging.impl.Log4JLogger (Caused
>         by
>         >         java.lang.NoClassDefFoundError:
>         org/apache/log4j/Category))
>         >               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.tiles.web.startup.TilesListener.<clinit>(TilesListener.java:45)
>         >               ... 29 more
>         >         Caused by:
>         >
>         org.apache.commons.logging.LogConfigurationException: No
>         >         suitable Log constructor [Ljava.lang.Class;@18b9a72
>         for
>         >         org.apache.commons.logging.impl.Log4JLogger (Caused
>         by
>         >         java.lang.NoClassDefFoundError:
>         org/apache/log4j/Category)
>         >               at
>         >
>         org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
>         >               at
>         >
>         org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
>         >               ... 33 more
>         >         Caused by: java.lang.NoClassDefFoundError:
>         >         org/apache/log4j/Category
>         >               at
>         java.lang.Class.getDeclaredConstructors0(Native
>         >         Method)
>         >               at
>         >
>         java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
>         >               at
>         java.lang.Class.getConstructor0(Class.java:2699)
>         >               at
>         java.lang.Class.getConstructor(Class.java:1657)
>         >               at
>         >
>         org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
>         >               ... 34 more
>         >
>         >         Caused by: java.lang.ClassNotFoundException:
>         >         org.apache.log4j.Category
>         >               at java.net.URLClassLoader
>         >         $1.run(URLClassLoader.java:200)
>         >               at
>         java.security.AccessController.doPrivileged(Native
>         >         Method)
>         >               at
>         >
>         java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>         >               at
>         java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>         >               at
>         java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>         >               at
>         >
>         java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>         >               ... 39 more
>         >
>         >
>         >
>         >
>         >
>         ---------------------------------------------------------------------
>         >         To unsubscribe from this list, please visit:
>         >
>         >           http://xircles.codehaus.org/manage_email
>         >
>         >
>         >
>         >
>        
>        
>         ---------------------------------------------------------------------
>         To unsubscribe from this list, please visit:
>        
>            http://xircles.codehaus.org/manage_email
>        
>        
>        
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[dchicks]

Hey guys,

I just wanted to ask if anyone has any thoughts on a work-around for
this problem?  It's not critical for me, but it would sure make life
simpler if I could get Jetty to run this way.  I can appreciate that it
may just not be possible right now, though.

Thanks,
Dave


Matt Wringe wrote:

> On Tue, 2009-02-24 at 23:48 +0000, Adrian Cole wrote:
>  
>> Good digging, Matt.  Do we have a Jira on this?  If not, if someone
>> raises one, I'll look into it tomorrow.
>>    
>
> This is related to a few embedded Jetty issues, the specific one to this
> case is http://jira.codehaus.org/browse/CARGO-692.
>
> We really need to rethink how we are going to provide dependencies for
> embedded Jetty.
>
>  
>> Cheers,
>> -Adrian
>>
>> On Tue, Feb 24, 2009 at 11:27 PM, Matt Wringe <mwringe@...>
>> wrote:
>>        
>>         On Tue, 2009-02-24 at 22:09 +0000, Adrian Cole wrote:
>>         > I'm guessing commons-logging is in a parent classloader and
>>         can't
>>         > resolve log4j.
>>        
>>         OK, he is using the embedded Jetty container in which Cargo
>>         automatically adds a commons-logging jar but not a log4j jar.
>>        
>>         It looks like its the Cargo embedded Jetty dependency
>>         autoresolver that
>>         bites us again :(
>>         see org.codehaus.cargo.maven2.jetty.JettyArtifactResolver
>>        
>>         That really needs to be fixed to allow people to specify the
>>         classpath
>>         if needed.
>>        
>>        
>>         > Can you dump your classpath?
>>         >
>>         > Cheers,
>>         > -Adrian
>>         >
>>         > On Tue, Feb 24, 2009 at 9:38 PM, David C. Hicks
>>         <dhicks@...>
>>         > wrote:
>>         >
>>         >
>>         >         Matt Wringe wrote:
>>         >                 Ok, the data provided does really help me.
>>         >                 Jetty doesn't contain a log4j file and cargo
>>         doesn't
>>         >                 reference any
>>         >                 org.apache.log4j classes. I am guessing the
>>         webapp
>>         >                 contains the log4j
>>         >                 jar within its web-inf/lib directory and the
>>         webapp
>>         >                 tries to reference
>>         >                 log4j and the error gets thrown? Any more
>>         data you can
>>         >                 provide?
>>         >
>>         >         Absolutely!  I'll be more than happy to give you
>>         tons of
>>         >         information.  I just didn't want to flood the list,
>>         >         initially.  :-)
>>         >
>>         >         Yes, the log4j jar is in WEB-INF/lib.  It is version
>>         1.2.14.
>>         >          It appears to me that the exception is thrown by
>>         Jetty as it
>>         >         begins the process of initializing the web context
>>         for the
>>         >         embedded application.  (I am trying to run this in
>>         embedded
>>         >         mode.)  A larger chunk of the exception stack is
>>         included
>>         >         below.  One of the first things that happens when
>>         the context
>>         >         initializes (in our app) is that we initialize
>>         logging the way
>>         >         we want it to work.  However, I don't see that
>>         class/method in
>>         >         this stack.  So, I'm not sure if we've even gotten
>>         that far
>>         >         along, yet.
>>         >
>>         >         If I can provide anything else, please just let me
>>         know.  It
>>         >         might take a bit of time - I'm working on other
>>         things, right
>>         >         now, so have to recreate the environment that causes
>>         this
>>         >         exception.  It's easy to create, though, and I don't
>>         mind
>>         >         helping track down a problem, if I can.
>>         >
>>         >         Dave
>>         >
>>         >         2009-02-24 16:27:52.098::INFO:  Extract
>>         >
>>         jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/ to /tmp/Jetty_0_0_0_0_8080_salient-war-0.1.40-SNAPSHOT.war__salient-war-0_1_40-SNAPSHOT__u13vah/webapp
>>         >         2009-02-24 16:27:53.727::WARN:  failed
>>         >
>>         org.mortbay.jetty.webapp.WebAppContext@48bc64{/salient-war-0.1.40-SNAPSHOT,jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/}
>>         >         java.lang.ExceptionInInitializerError
>>         >               at
>>         >
>>         sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>         >         Method)
>>         >               at
>>         >
>>         sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>>         >               at
>>         >
>>         sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>>         >               at
>>         >
>>         java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>>         >               at
>>         java.lang.Class.newInstance0(Class.java:355)
>>         >               at java.lang.Class.newInstance(Class.java:308)
>>         >               at
>>         >
>>         org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:644)
>>         >               at
>>         >
>>         org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:625)
>>         >               at
>>         >
>>         org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:366)
>>         >               at
>>         >
>>         org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:288)
>>         >               at
>>         >
>>         org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:221)
>>         >               at
>>         >
>>         org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:179)
>>         >               at
>>         >
>>         org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1188)
>>         >               at
>>         >
>>         org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481)
>>         >               at
>>         >
>>         org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434)
>>         >               at
>>         >
>>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>>         >               at
>>         >
>>         org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
>>         >               at
>>         >
>>         org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120)
>>         >               at
>>         >
>>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>>         >               at
>>         >
>>         org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
>>         >               at
>>         >
>>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>>         >               at
>>         >
>>         org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
>>         >               at
>>         org.mortbay.jetty.Server.doStart(Server.java:210)
>>         >               at
>>         >
>>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
>>         >               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:597)
>>         >               at
>>         >
>>         org.codehaus.cargo.container.jetty.internal.JettyExecutorThread.run(JettyExecutorThread.java:68)
>>         >         Caused by:
>>         >
>>         org.apache.commons.logging.LogConfigurationException:
>>         >
>>         org.apache.commons.logging.LogConfigurationException: No
>>         >         suitable Log constructor [Ljava.lang.Class;@18b9a72
>>         for
>>         >         org.apache.commons.logging.impl.Log4JLogger (Caused
>>         by
>>         >         java.lang.NoClassDefFoundError:
>>         org/apache/log4j/Category)
>>         >         (Caused by
>>         >
>>         org.apache.commons.logging.LogConfigurationException: No
>>         >         suitable Log constructor [Ljava.lang.Class;@18b9a72
>>         for
>>         >         org.apache.commons.logging.impl.Log4JLogger (Caused
>>         by
>>         >         java.lang.NoClassDefFoundError:
>>         org/apache/log4j/Category))
>>         >               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.tiles.web.startup.TilesListener.<clinit>(TilesListener.java:45)
>>         >               ... 29 more
>>         >         Caused by:
>>         >
>>         org.apache.commons.logging.LogConfigurationException: No
>>         >         suitable Log constructor [Ljava.lang.Class;@18b9a72
>>         for
>>         >         org.apache.commons.logging.impl.Log4JLogger (Caused
>>         by
>>         >         java.lang.NoClassDefFoundError:
>>         org/apache/log4j/Category)
>>         >               at
>>         >
>>         org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
>>         >               at
>>         >
>>         org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
>>         >               ... 33 more
>>         >         Caused by: java.lang.NoClassDefFoundError:
>>         >         org/apache/log4j/Category
>>         >               at
>>         java.lang.Class.getDeclaredConstructors0(Native
>>         >         Method)
>>         >               at
>>         >
>>         java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
>>         >               at
>>         java.lang.Class.getConstructor0(Class.java:2699)
>>         >               at
>>         java.lang.Class.getConstructor(Class.java:1657)
>>         >               at
>>         >
>>         org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
>>         >               ... 34 more
>>         >
>>         >         Caused by: java.lang.ClassNotFoundException:
>>         >         org.apache.log4j.Category
>>         >               at java.net.URLClassLoader
>>         >         $1.run(URLClassLoader.java:200)
>>         >               at
>>         java.security.AccessController.doPrivileged(Native
>>         >         Method)
>>         >               at
>>         >
>>         java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>>         >               at
>>         java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>>         >               at
>>         java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>>         >               at
>>         >
>>         java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>>         >               ... 39 more
>>         >
>>         >
>>         >
>>         >
>>         >
>>         ---------------------------------------------------------------------
>>         >         To unsubscribe from this list, please visit:
>>         >
>>         >           http://xircles.codehaus.org/manage_email
>>         >
>>         >
>>         >
>>         >
>>        
>>        
>>         ---------------------------------------------------------------------
>>         To unsubscribe from this list, please visit:
>>        
>>            http://xircles.codehaus.org/manage_email
>>        
>>        
>>        
>>
>>    
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Matt Wringe]

On Tue, 2009-03-03 at 16:39 -0500, David C. Hicks wrote:
> Hey guys,
>
> I just wanted to ask if anyone has any thoughts on a work-around for
> this problem?  It's not critical for me, but it would sure make life
> simpler if I could get Jetty to run this way.  I can appreciate that it
> may just not be possible right now, though.

I don't think a work around is possible right now.

It would only be a small change to the code to make it work with your
situation (one line to add the log4j jar to the embedded jetty
classpath).
The problem is that its bigger than just this one issue, the way we add
dependencies to Jetty needs to be fixed so that it will work better in
the future.

> Thanks,
> Dave
>
>
> Matt Wringe wrote:
> > On Tue, 2009-02-24 at 23:48 +0000, Adrian Cole wrote:
> >  
> >> Good digging, Matt.  Do we have a Jira on this?  If not, if someone
> >> raises one, I'll look into it tomorrow.
> >>    
> >
> > This is related to a few embedded Jetty issues, the specific one to this
> > case is http://jira.codehaus.org/browse/CARGO-692.
> >
> > We really need to rethink how we are going to provide dependencies for
> > embedded Jetty.
> >
> >  
> >> Cheers,
> >> -Adrian
> >>
> >> On Tue, Feb 24, 2009 at 11:27 PM, Matt Wringe <mwringe@...>
> >> wrote:
> >>        
> >>         On Tue, 2009-02-24 at 22:09 +0000, Adrian Cole wrote:
> >>         > I'm guessing commons-logging is in a parent classloader and
> >>         can't
> >>         > resolve log4j.
> >>        
> >>         OK, he is using the embedded Jetty container in which Cargo
> >>         automatically adds a commons-logging jar but not a log4j jar.
> >>        
> >>         It looks like its the Cargo embedded Jetty dependency
> >>         autoresolver that
> >>         bites us again :(
> >>         see org.codehaus.cargo.maven2.jetty.JettyArtifactResolver
> >>        
> >>         That really needs to be fixed to allow people to specify the
> >>         classpath
> >>         if needed.
> >>        
> >>        
> >>         > Can you dump your classpath?
> >>         >
> >>         > Cheers,
> >>         > -Adrian
> >>         >
> >>         > On Tue, Feb 24, 2009 at 9:38 PM, David C. Hicks
> >>         <dhicks@...>
> >>         > wrote:
> >>         >
> >>         >
> >>         >         Matt Wringe wrote:
> >>         >                 Ok, the data provided does really help me.
> >>         >                 Jetty doesn't contain a log4j file and cargo
> >>         doesn't
> >>         >                 reference any
> >>         >                 org.apache.log4j classes. I am guessing the
> >>         webapp
> >>         >                 contains the log4j
> >>         >                 jar within its web-inf/lib directory and the
> >>         webapp
> >>         >                 tries to reference
> >>         >                 log4j and the error gets thrown? Any more
> >>         data you can
> >>         >                 provide?
> >>         >
> >>         >         Absolutely!  I'll be more than happy to give you
> >>         tons of
> >>         >         information.  I just didn't want to flood the list,
> >>         >         initially.  :-)
> >>         >
> >>         >         Yes, the log4j jar is in WEB-INF/lib.  It is version
> >>         1.2.14.
> >>         >          It appears to me that the exception is thrown by
> >>         Jetty as it
> >>         >         begins the process of initializing the web context
> >>         for the
> >>         >         embedded application.  (I am trying to run this in
> >>         embedded
> >>         >         mode.)  A larger chunk of the exception stack is
> >>         included
> >>         >         below.  One of the first things that happens when
> >>         the context
> >>         >         initializes (in our app) is that we initialize
> >>         logging the way
> >>         >         we want it to work.  However, I don't see that
> >>         class/method in
> >>         >         this stack.  So, I'm not sure if we've even gotten
> >>         that far
> >>         >         along, yet.
> >>         >
> >>         >         If I can provide anything else, please just let me
> >>         know.  It
> >>         >         might take a bit of time - I'm working on other
> >>         things, right
> >>         >         now, so have to recreate the environment that causes
> >>         this
> >>         >         exception.  It's easy to create, though, and I don't
> >>         mind
> >>         >         helping track down a problem, if I can.
> >>         >
> >>         >         Dave
> >>         >
> >>         >         2009-02-24 16:27:52.098::INFO:  Extract
> >>         >
> >>         jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/ to /tmp/Jetty_0_0_0_0_8080_salient-war-0.1.40-SNAPSHOT.war__salient-war-0_1_40-SNAPSHOT__u13vah/webapp
> >>         >         2009-02-24 16:27:53.727::WARN:  failed
> >>         >
> >>         org.mortbay.jetty.webapp.WebAppContext@48bc64{/salient-war-0.1.40-SNAPSHOT,jar:file:/home/dhicks/workspace/salient/war/target/salient-war-0.1.40-SNAPSHOT.war!/}
> >>         >         java.lang.ExceptionInInitializerError
> >>         >               at
> >>         >
> >>         sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> >>         >         Method)
> >>         >               at
> >>         >
> >>         sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> >>         >               at
> >>         >
> >>         sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> >>         >               at
> >>         >
> >>         java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> >>         >               at
> >>         java.lang.Class.newInstance0(Class.java:355)
> >>         >               at java.lang.Class.newInstance(Class.java:308)
> >>         >               at
> >>         >
> >>         org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:644)
> >>         >               at
> >>         >
> >>         org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:625)
> >>         >               at
> >>         >
> >>         org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:366)
> >>         >               at
> >>         >
> >>         org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:288)
> >>         >               at
> >>         >
> >>         org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:221)
> >>         >               at
> >>         >
> >>         org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:179)
> >>         >               at
> >>         >
> >>         org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1188)
> >>         >               at
> >>         >
> >>         org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481)
> >>         >               at
> >>         >
> >>         org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434)
> >>         >               at
> >>         >
> >>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> >>         >               at
> >>         >
> >>         org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
> >>         >               at
> >>         >
> >>         org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120)
> >>         >               at
> >>         >
> >>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> >>         >               at
> >>         >
> >>         org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
> >>         >               at
> >>         >
> >>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> >>         >               at
> >>         >
> >>         org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
> >>         >               at
> >>         org.mortbay.jetty.Server.doStart(Server.java:210)
> >>         >               at
> >>         >
> >>         org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> >>         >               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:597)
> >>         >               at
> >>         >
> >>         org.codehaus.cargo.container.jetty.internal.JettyExecutorThread.run(JettyExecutorThread.java:68)
> >>         >         Caused by:
> >>         >
> >>         org.apache.commons.logging.LogConfigurationException:
> >>         >
> >>         org.apache.commons.logging.LogConfigurationException: No
> >>         >         suitable Log constructor [Ljava.lang.Class;@18b9a72
> >>         for
> >>         >         org.apache.commons.logging.impl.Log4JLogger (Caused
> >>         by
> >>         >         java.lang.NoClassDefFoundError:
> >>         org/apache/log4j/Category)
> >>         >         (Caused by
> >>         >
> >>         org.apache.commons.logging.LogConfigurationException: No
> >>         >         suitable Log constructor [Ljava.lang.Class;@18b9a72
> >>         for
> >>         >         org.apache.commons.logging.impl.Log4JLogger (Caused
> >>         by
> >>         >         java.lang.NoClassDefFoundError:
> >>         org/apache/log4j/Category))
> >>         >               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.tiles.web.startup.TilesListener.<clinit>(TilesListener.java:45)
> >>         >               ... 29 more
> >>         >         Caused by:
> >>         >
> >>         org.apache.commons.logging.LogConfigurationException: No
> >>         >         suitable Log constructor [Ljava.lang.Class;@18b9a72
> >>         for
> >>         >         org.apache.commons.logging.impl.Log4JLogger (Caused
> >>         by
> >>         >         java.lang.NoClassDefFoundError:
> >>         org/apache/log4j/Category)
> >>         >               at
> >>         >
> >>         org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
> >>         >               at
> >>         >
> >>         org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
> >>         >               ... 33 more
> >>         >         Caused by: java.lang.NoClassDefFoundError:
> >>         >         org/apache/log4j/Category
> >>         >               at
> >>         java.lang.Class.getDeclaredConstructors0(Native
> >>         >         Method)
> >>         >               at
> >>         >
> >>         java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
> >>         >               at
> >>         java.lang.Class.getConstructor0(Class.java:2699)
> >>         >               at
> >>         java.lang.Class.getConstructor(Class.java:1657)
> >>         >               at
> >>         >
> >>         org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
> >>         >               ... 34 more
> >>         >
> >>         >         Caused by: java.lang.ClassNotFoundException:
> >>         >         org.apache.log4j.Category
> >>         >               at java.net.URLClassLoader
> >>         >         $1.run(URLClassLoader.java:200)
> >>         >               at
> >>         java.security.AccessController.doPrivileged(Native
> >>         >         Method)
> >>         >               at
> >>         >
> >>         java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> >>         >               at
> >>         java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> >>         >               at
> >>         java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> >>         >               at
> >>         >
> >>         java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> >>         >               ... 39 more
> >>         >
> >>         >
> >>         >
> >>         >
> >>         >
> >>         ---------------------------------------------------------------------
> >>         >         To unsubscribe from this list, please visit:
> >>         >
> >>         >           http://xircles.codehaus.org/manage_email
> >>         >
> >>         >
> >>         >
> >>         >
> >>        
> >>        
> >>         ---------------------------------------------------------------------
> >>         To unsubscribe from this list, please visit:
> >>        
> >>            http://xircles.codehaus.org/manage_email
> >>        
> >>        
> >>        
> >>
> >>    
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >  
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[dchicks]

I understand, Matt.  I had to ask, though.  :-)

Matt Wringe wrote:

> On Tue, 2009-03-03 at 16:39 -0500, David C. Hicks wrote:
>  
>> Hey guys,
>>
>> I just wanted to ask if anyone has any thoughts on a work-around for
>> this problem?  It's not critical for me, but it would sure make life
>> simpler if I could get Jetty to run this way.  I can appreciate that it
>> may just not be possible right now, though.
>>    
>
> I don't think a work around is possible right now.
>
> It would only be a small change to the code to make it work with your
> situation (one line to add the log4j jar to the embedded jetty
> classpath).
> The problem is that its bigger than just this one issue, the way we add
> dependencies to Jetty needs to be fixed so that it will work better in
> the future.
>
>  
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Matt Wringe]

On Tue, 2009-03-03 at 17:00 -0500, David C. Hicks wrote:
> I understand, Matt.  I had to ask, though.  :-)
I can make the change to the log4j file and create a snapshot if you are
able to test and make sure it works in your situation (you would need to
use the Cargo 1.0-SNAPSHOT jars)

We still need to fix the other issues, but that should at least get what
you need working.

>
> Matt Wringe wrote:
> > On Tue, 2009-03-03 at 16:39 -0500, David C. Hicks wrote:
> >  
> >> Hey guys,
> >>
> >> I just wanted to ask if anyone has any thoughts on a work-around for
> >> this problem?  It's not critical for me, but it would sure make life
> >> simpler if I could get Jetty to run this way.  I can appreciate that it
> >> may just not be possible right now, though.
> >>    
> >
> > I don't think a work around is possible right now.
> >
> > It would only be a small change to the code to make it work with your
> > situation (one line to add the log4j jar to the embedded jetty
> > classpath).
> > The problem is that its bigger than just this one issue, the way we add
> > dependencies to Jetty needs to be fixed so that it will work better in
> > the future.
> >
> >  
> >  
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[dchicks]

I appreciate that, but like I said, it's not critical.  I'll just keep
my eyes and ears open for updates.  If you do happen to make that
change, I'll be more than happy to give it a test for you.

Matt Wringe wrote:

> On Tue, 2009-03-03 at 17:00 -0500, David C. Hicks wrote:
>  
>> I understand, Matt.  I had to ask, though.  :-)
>>    
> I can make the change to the log4j file and create a snapshot if you are
> able to test and make sure it works in your situation (you would need to
> use the Cargo 1.0-SNAPSHOT jars)
>
> We still need to fix the other issues, but that should at least get what
> you need working.
>
>  
>> Matt Wringe wrote:
>>    
>>> On Tue, 2009-03-03 at 16:39 -0500, David C. Hicks wrote:
>>>  
>>>      
>>>> Hey guys,
>>>>
>>>> I just wanted to ask if anyone has any thoughts on a work-around for
>>>> this problem?  It's not critical for me, but it would sure make life
>>>> simpler if I could get Jetty to run this way.  I can appreciate that it
>>>> may just not be possible right now, though.
>>>>    
>>>>        
>>> I don't think a work around is possible right now.
>>>
>>> It would only be a small change to the code to make it work with your
>>> situation (one line to add the log4j jar to the embedded jetty
>>> classpath).
>>> The problem is that its bigger than just this one issue, the way we add
>>> dependencies to Jetty needs to be fixed so that it will work better in
>>> the future.
>>>
>>>  
>>>  
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>    
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email