I'm using org.apache.catalina.filters.CorsFilter in my webapp. So I specify the maven dependency
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>tomcat-catalina</artifactId>
<version>7.0.50</version>
</dependency>
Now, If I say the scope is "provide" or "runtime" the server doesn't start, because of
java.lang.ClassNotFoundException: org.apache.catalina.filters.CorsFilter
This class is not available in the catalina jar from jbossews/lib which is 7.0.40
Is it easy to "upgrade" tomcat on openshift? or if anybody can suggest a solution, it is much appreciated.
Many thanks,
This worked for me:
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>tomcat-catalina</artifactId>
<version>7.0.42</version>
<scope>provided</scope>
</dependency>
Trying 7.0.50 also worked. Can you double-check that there are no competing jar file versions lying around? Perhaps there is an older version without the class actually getting used by the JVM. Under Linux, "ls -l /proc/$CATALINA_PID/fd", may show which jar file is being used.
Also make sure to run this in a recent enough version of the Tomcat server.
You can add the jar to your repository and modify the .openshift/config/catalina.properties to let tomcat see it:
shared.loader=${catalina.home}/../app-root/runtime/repo/_your_jar_folder_
You can also use the common.loader - look up tomcat's refs for difference.
Related
I have an Eclipse based application which is being ported from Java 8 to Java 11. Since javax.xml and friends was removed from the JDK, I had to add it as an Import-Package to every plug-in that needed them.
Now however, when run this code
Marshaller marshaller = JAXBContext.newInstance(MyClass.class).createMarshaller();
I get the following exception:
java.lang.ClassNotFoundException: com.sun.xml.internal.bind.v2.ContextFactory
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at org.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:135)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:480)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:184)
I can add com.sun.xml.bind, which should have the dependency, but nothing happens. This is understandable, since OSGi rules prevents hacking into another plug-in via reflection.
However I cannot add Require-Bundle nor Import-Package to the JDK or the bundle around javax.xml.bind.
There is a bug surrounding this issue, but I cannot find a good solution for my application in the comments. Still I assume it can be fixed for an Eclipse application, else Eclipse itself shouldn't be able to run on Java 11.
How do I fix this exception?
We found an OSGi compatible way to fix this exception:
add the following implementations to the target platform
org.apache.servicemix.specs.jaxb-api-2.2 (from Maven central)
com.sun.xml.bind (from the Eclipse platform; this is the one that contains the ContextFactory)
make sure these bundles are started with your application
make sure the Apache bundle is started before everything else
So in Tycho, this would look like this:
<bundleStartLevel>
<bundle>
<id>org.apache.servicemix.specs.jaxb-api-2.2</id>
<autoStart>true</autoStart>
<level>1</level>
</bundle>
</bundleStartLevel>
<dependencies>
<dependency>
<artifactId>org.eclipse.e4.rcp</artifactId>
<type>eclipse-feature</type>
</dependency>
<dependency>
<type>p2-installable-unit</type>
<artifactId>org.apache.servicemix.specs.jaxb-api-2.2</artifactId>
</dependency>
<dependency>
<type>p2-installable-unit</type>
<artifactId>com.sun.xml.bind</artifactId>
</dependency>
</dependencies>
I'm too using jaxb in my application (JMSToolBox) and too migrated from Java 1.8 to Java 11 and didn't had this problem
In my plugin, I have a "lib" directory with the"jaxb-ri"jar and its dependencies (from maven):
jaxb-api-2.3.1.jar
jaxb-runtime-2.3.2.jar
javax.activation-api-1.2.0.jar
istack-commons-runtime-3.0.7.jar
Then the plugin references those jars (MANIFEST.MF + build.properties) and I don't have any problem
The plugin is here
All of a sudden all my Mule Maven projects are throwing this error when running mvn clean test:
java.lang.NoClassDefFoundError: org/apache/commons/cli/ParseException
at org.mule.tck.junit4.AbstractMuleTestCase.(AbstractMuleTestCase.java:71)
I can add a dependency for it, but I shoudln't really have to.
Nothings changed in my code. I am using Mule 3.4
You need commons-cli.jar in your classpath, add this Maven dependency to your pom
<dependency>
<groupId>commons-cli</groupId>
<artifactId>commons-cli</artifactId>
<version>1.1</version>
</dependency>
Update: OP's code was fixed after adding commons-cli 1.1 dependency.
Issue description and how to fix it: http://ricston.com/blog/mule-classnotfoundexception-tests-commons-cli/
In a nutshell, you probably have an incorrect JAR named commons-cli-1.2. Delete that and rerun your maven build. You should be good after that.
If the follogin dependency in available in the POM. it should be working fine.
<dependency>
<groupId>org.mule.tests</groupId>
<artifactId>mule-tests-functional</artifactId>
<version>3.4.0</version>
<scope>test</scope>
</dependency>
Then use mvn clean compile to update the dependency.
mvn eclipse:clean eclipse:eclipse clean compile
Hope this helps.
Maven behaviour isn't reproducible from one run to the next: apart from generic network problems and repository corruption problems, anything might be updated automatically at any time, breaking any step of the execution, even if you don't change any of your files.
Your error message about a class in some Apache Commons library suggests a disagreement between the version of that library Mule should be using (one that has the ParseException class) and the library version it actually loads (without the class and causing the exception).
Plausible version mismatch scenarios include an update to a buggy new version of Mule (maybe only to a wrong or corrupted POM) which specifies an incompatible library version, or a random upgrade or downgrade of the latest library version in your repository as a consequence of adding or updating something unrelated to Mule.
Analysis suggestions:
What plugins in your Maven repository have a snapshot version? Which ones of these snapshots were updated around the time the error first appeared?
Which library jars, and which versions, include the ParseException class? What depends on specific versions or on the latest version of those jars?
I am trying to add a WSDL module to my existing application, but I'm struggling to get the dependencies resolved.
According to their website, this is the correct dependency
<dependency>
<groupId>org.ow2.easywsdl</groupId>
<artifactId>easywsdl-wsdl</artifactId>
<version>2.1</version>
</dependency>
After a search (search.maven.org), I already changed the version to 2.3 and there are a bunch of files that are downloaded into my local repository, but when running the application (with the websites demo code), I bump into this error:
java.lang.ClassNotFoundException: com.ebmwebsourcing.easycommons.uri.UriManager
And I believe it has something to do with the missing artifacts :
com.ebmwebsourcing.easycommons:easycommons.uri:jar:1.1
com.ebmwebsourcing.easycommons:easycommons.logger:jar:1.1
In particular the first one. Now, I'm relatively new to using Maven... How would I go about solving this?
Thanks.
The solution is to add the petalslink repository. Appearantly the standard maven repository doesn't contain the easycommons dependency. The petalslink repository does.
I have a test project requiring some heavy jars which i put in ${M2_HOME}\test\src\main\resources\ and add them in the pom.xml using :
<dependency>
<groupId>server</groupId>
<artifactId>server</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${M2_HOME}\test\src\main\resources\server.jar</systemPath>
</dependency>
<dependency>
<groupId>client</groupId>
<artifactId>client</artifactId>
<version>6.0</version>
<scope>system</scope>
<systemPath>${M2_HOME}\test\src\main\resources\client.jar</systemPath>
</dependency>
I want to know if it possible to exclude them during sonar analysis, or generally just analyze java sources folder.
If the problem is that these JARs are included in sonar analysis because they are located in src/main/resources, then one obvious solution would be to put them somewhere else (see the post scriptum). If for whatever reason this is not possible, please clarify (I'd really like to know why you put these JARs under resources).
If the problem is that these JARs are declared as dependencies, you could use a specific profile not including them to run sonar.
PS: Note that using the system scope is a bad practice and has several drawbacks (as mentioned here or here). A cleaner approach would be to use a file based repository as suggested in this answer.
I have a dependency which is scoped as "system".
I'd like to know if there's a way to define the attached source and javadoc for the dependency. This seems like something that should've been taken care of, but I can't seem to fine any documentation on it or why it was neglected.
I am specifically looking for the configuration solution, not installing it to my local repo, or deploying it to a common repo. For the sake of this discussion, those options are out.
Do you mean attach sources using m2eclipse?
If so, you just need to ensure the sources jar is in the same directory. I tried this by copying commons-io-1.4.jar to some other directory and setting the system path, if commons-io-1.4-sources.jar is in the same directory, m2eclipse finds and attaches the sources.
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>1.4</version>
<scope>system</scope>
<systemPath>C:\test\lib\commons-io-1.4.jar</systemPath>
</dependency>
And the source jar is
C:\test\lib\commons-io-1.4-sources.jar
I guess it'll work the same for javadoc, not tried it though.