Develop Reference

ClassNotFoundException while using apache commons net

Getting the following while using Apache's commons-net library.
Caused by: java.lang.ClassNotFoundException: org.apache.commons.net.SocketFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
This class is loaded transitively by another one.
The environment is maven and commons-net has been loaded via the pom file.
<dependency>
<groupId>commons-net</groupId>
<artifactId>commons-net</artifactId>
<classifier>ftp</classifier>
<version>2.0</version>
</dependency>
There is no SSL connection. Do I need to specify using java.security ?

Unable to resolve a dependency on URLUtil, conflicting requirements

I'm getting the following error when trying to compile my project:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/httpclient/util/URIUtil
at org.apache.commons.vfs2.provider.URLFileName.getPathQueryEncoded(URLFileName.java:91)
at org.apache.commons.vfs2.provider.URLFileName.getURIEncoded(URLFileName.java:161)
at org.apache.commons.vfs2.provider.url.UrlFileObject.createURL(UrlFileObject.java:74)
at org.apache.commons.vfs2.provider.url.UrlFileObject.doAttach(UrlFileObject.java:63)
at org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:1505)
at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:489)
.... (More project-scope traces)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.httpclient.util.URIUtil
at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 13 more
I have the following maven dependencies in my project, among others:
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.3.4</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-vfs2</artifactId>
<version>2.0</version>
</dependency>
I absolutely must depend on a HttpClient version 4.3.4 or greater because of other dependencies and various bugs we ran into with previous versions. After a bit of research, I discovered the class in question (URLUtil) was removed from HttpClient after HttpClient 3.1.
Is there any way to resolve this? Or another library I could use instead of vfs2? I'm attempting to write files over sftp using both user/pass and key authentication schemes.

As it turns out, the artifacts are different between the 3.x and 4.x releases of HttpClient. All I had to do was include:
<dependency>
<groupId>commons-httpclient</groupId>
<artifactId>commons-httpclient</artifactId>
<version>3.1</version>
</dependency>
Silly me, thinking that they'd override each-other.

ClassNotFoundException while executing mvn javadoc:javadoc

My build works fine except when doing a release (or more precisely mvn javadoc:javadoc).
I get the ClassNotFoundException below. Any hints as to how to provide the class would be deeply appreciated
Caused by: java.lang.NoClassDefFoundError: org/apache/http/HttpRequest
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.buildJavadocOptions(AbstractJavadocMojo.java:5843)
at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1857)
at org.apache.maven.plugin.javadoc.JavadocReport.generate(JavadocReport.java:130)
at org.apache.maven.plugin.javadoc.JavadocReport.execute(JavadocReport.java:315)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
Caused by: java.lang.ClassNotFoundException: org.apache.http.HttpRequest
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
... 38 more

It might be a problem of maven transitive dependencies conflict. Some dependencies are transitively depend on two different version of httpclient, try to exclude one with:
<dependency>
<groupId>groupId</groupId>
<artifactId>artifactId</artifactId>
<exclusions>
<exclusion>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
</exclusion>
</exclusions>
</dependency>

Chances are that the OP was running on Maven 2.x. So, the solution would be to use Maven 3.x if they want to work with recent versions of maven-javadoc-plugin (apparently 2.9+). After all the Maven 2 has reached its EOL, so there's no reason to continue to using it.
A combination of changes like the maven-javadoc-plugin upgrade to use a newer version of HttpClient and Maven moving from Plexus to Guice as IoC container may have caused this.
Here are a few ticket links that could help:
Required class missing: org/apache/http/HttpRequest
[Patch]
Port maven-javadoc-plugin from httpclient 3 to httpclient 4
Move
from Plexus to Guice as IoC container

ClassNotFoundException HttpRequestInterceptor

I am getting this weird exception on this line:
HttpSolrServer server = new HttpSolrServer("http://localhost:8080/solr/");
Stack trace:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/http/HttpRequestInterceptor
at com.polgar.dipl.index.SolrIndex.init(SolrIndex.java:36)
at com.polgar.dipl.index.SolrIndex.getInstance(SolrIndex.java:30)
at com.polgar.dipl.main.ArticleIndexer.main(ArticleIndexer.java:44)
Caused by: java.lang.ClassNotFoundException: org.apache.http.HttpRequestInterceptor
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 3 more

Getting the same problem. We both must be playing with Solr 3.6
I had to download the HttpClient jars from the HttpComponents project. They didn't seem to be included with Solr 3.6
http://hc.apache.org/downloads.cgi
3.6 Has a new version of the client that uses the new HttpComponents (4.0) stuff, not the old HttpClient (3.1) stuff. The old 3.1 jar is there, but not the new one.
Once I copied the jars over, it worked.
I copied the following (not all may be needed).
httpclient-4.1.3.jar
httpclient-cache-4.1.3.jar
httpcore-4.1.4.jar
httpmime-4.1.3.jar
works for me, now.

If you are using Maven to include SOLRJ, you'll also want the following phrases in your POM:
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.2.1</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpmime</artifactId>
<version>4.2.1</version>
</dependency>

Looks like you are missing the HttpClient Jar file in your runtime classpath.

I was also facing this issue. To resolve this, I have done following:
Checked the versions available of http components in your "~.m2\repository\org\apache\httpcomponents" directory
Based on that add following entries in your pom.xml file and rebuild your project by running mvn clean install and mvn eclipse:eclipse command one by one.
(If you are behind the proxy, make sure you have provided essential configuration in your settings.xml file)
This should resolve the problem, It did for me. :)
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.2.3</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpmime</artifactId>
<version>4.2.3</version>
</dependency>

Atomikos + Jetty in a Maven build environment - Classloader issue?

I am working on a project with multiple JDBC data sources and JTA. I use Maven as a build tool, and I'd like to use the Jetty plugin (6.1.20) to run the application during development.
I am trying to configure Jetty to use Atomikos as the transaction manager. I'm following the Atomikos documentation from Jetty, but the Jetty startup fails with what looks like a class loader issue.
Here are the relevant bits of my configuration.
runtime scope dependencies in my pom.xml:
<dependency>
<groupId>com.atomikos</groupId>
<artifactId>transactions-jta</artifactId>
<version>3.5.7</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.atomikos</groupId>
<artifactId>transactions-jdbc</artifactId>
<version>3.5.7</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>javax.transaction</groupId>
<artifactId>jta</artifactId>
<version>1.1</version>
<scope>runtime</scope>
</dependency>
My jetty-env.xml located in /WEB-INF (autodiscovered by Jetty):
<New id="userTxImpl" class="com.atomikos.icatch.jta.UserTransactionImp" />
<New id="tx" class="org.mortbay.jetty.plus.naming.Transaction">
<Arg>
<Ref id="userTxImpl" />
</Arg>
</New>
The instantiation of tx at the end is the bit that fails, if I leave it out, Jetty starts up fine (but does not expose UserTransaction via JNDI, of course).
The Stacktrace:
2009-09-02 18:42:18.910::WARN: Config error at <New id="tx" class="org.mortbay.jetty.plus.naming.Transaction"><Arg>
<Ref id="userTxImpl"/>
</Arg></New>
2009-09-02 18:42:18.910::WARN: Failed startup of context org.mortbay.jetty.plugin.Jetty6PluginWebAppContext#12515db{/administrator,C:\workspace\administrator\src\main\webapp}
java.lang.IllegalStateException: No Constructor: <New id="tx" class="org.mortbay.jetty.plus.naming.Transaction"><Arg>
<Ref id="userTxImpl"/>
</Arg></New> on org.mortbay.jetty.plugin.Jetty6PluginWebAppContext#12515db{/administrator,C:\workspace\administrator\src\main\webapp}
at org.mortbay.xml.XmlConfiguration.newObj(XmlConfiguration.java:631)
at org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:256)
at org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:190)
at org.mortbay.jetty.plus.webapp.EnvConfiguration.configureWebApp(EnvConfiguration.java:130)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1247)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441)
at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383)
at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210)
at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
This looks like a classloader issue, as org.mortbay.jetty.plus.naming.Transaction has got a Constructor taking a javax.transaction.UserTransaction, and com.atomikos.icatch.jta.UserTransactionImp implements javax.transaction.UserTransaction, yet Jetty complains it does not have a proper constructor to use.
I'm obviously missing something here, but what is it?
Thanks!

You may have multiple copies of the UserTransaction class kicking around in your deployment. If these are loaded from different classloaders, then you can end up with this sort of error.
Check Jetty's libraries for UserTransaction, and then check your application's libraries. You should only have one copy.

I believe that you should not be specifying the JTA jar as a 'runtime' requirement, but rather as a 'provided' requirement. Similar to servlet-api and JMS, the individual implementers provide their own copies of the API and providing the Sun jar can muck them up.

I realize this is already answered, but I wanna put up my experience to save others the grief I just went through.
I had a similar problem, but it was caused by a conflict in versions of geronimo-jta spec. Specifically the one depended on by atomikos wasn't getting along with the one used by jetty. I had to exclude the one from atomikos, e.g.:
com.atomikos
transactions-essentials-all
3.5.9
org.apache.geronimo.specs
geronimo-jta_1.0.1B_spec

Like Taylor, I just blew a couple hours on this exact same issue. I use Hibernate as a JPA provider and it had a Maven depdency on its own JTA User Tranaction. Once I excluded this dependency I got past the issue.