camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pablo Gra\\~na (JIRA)" <j...@apache.org>
Subject [jira] Created: (CAMEL-3533) classpath problem with camel:dot and provided dependencies
Date Wed, 12 Jan 2011 12:27:45 GMT
classpath problem with camel:dot and provided dependencies
----------------------------------------------------------

                 Key: CAMEL-3533
                 URL: https://issues.apache.org/jira/browse/CAMEL-3533
             Project: Camel
          Issue Type: Improvement
          Components: tooling
    Affects Versions: 2.5.0
         Environment: Running on linux, jdk 1.6. Looks irrelevant.
            Reporter: Pablo Gra\~na
         Attachments: depends_on_test_classpath.txt

camel:dot in is failing with a class not found exception when the application context instantiates
a class in a jar with provided scope.

If in your maven project you have:

     <dependency>
       <groupId>javax.servlet</groupId>
       <artifactId>servlet-api</artifactId>
       <version>2.5</version>
       <scope>provided</scope>
     </dependency>

and in your application context there is, for example, a subclass of ServletContextListener,
mvn camel:dot fails with:

...
Caused by: java.lang.ClassNotFoundException:
javax.servlet.ServletContextListener
       at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
       at java.security.AccessController.doPrivileged(Native Method)
       at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
       ... 92 more

If you change it to:

     <dependency>
       <groupId>javax.servlet</groupId>
       <artifactId>servlet-api</artifactId>
       <version>2.5</version>
       <scope>compile</scope>
     </dependency>

then camel-maven-plugin correctly generates the output. The fact is
that the servlet-api jar must not be included in the final war.

I don't know the correct way to fix this. One option would be to add the includePluginDependencies
option in the plugin and add the provided jars as runtime dependencies of the plugin.

The other, very easy to implement, option would be to change the requiresDependencyResolution
from runtime to test.

The third option would be to make the requiresDependencyResolution configurable.

Attached is a patch for the 2nd option (lazy me).


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message