I'm migrating my applications from Java 7 on JBoss 7.1, to Java 8 and Wildfly (Jboss 8.1).
When I tried starting Wildfly I got an error, the server was up but my app wasn't loaded. Looking on the Caused By I can see a more descriptive problem:
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set with
qualifiers #Default at injection point [BackedAnnotatedParameter]
Parameter 1 of [BackedAnnotatedConstructor] #Inject
com.google.common.util.concurrent.ServiceManager(Set) at
com.google.common.util.concurrent.ServiceManager.(ServiceManager.java:0)
This ServiceManager class belongs to Google Guava. I have tried Guava 17, 16 and 15 and the problem still persists.
Update: I updated the question to give more details thanks to ColinD answer.
In my pom.xml I have:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>17.0</version>
</dependency>
and the error is related to Guava 15. I took a look at my deployed application directory and saw that my lib directory contains two guava jars: guava-17.0.jar and guava-15.0-cdi1.0.jar.
I removed this strange guava-15.0-cdi1.0 jar file and my server started although my app didn't load. I think this is related to Wildfly dependencies and CDI.
Does anybody know how to resolve this conflict on Wildfly?
ServiceManager hasn't had #Inject or #Singleton on it since Guava 16.0. One way or another, it looks like you have a version of Guava <= 15.0 on your classpath.
Yes, this Sounds like you are packaging guava 15 or so. It definately works with guava 16. I know this because I had the Same problem. I was able to resolute it by packaging a later guava Version with my ears.
May it be that you are declaring a dependency to the guava module of wildfly instead of just packaging a guava lib with your deployment?
Related
I'm currently looking into testing jetty servlets. I found the org.eclipse.jetty.testing.ServletTester class in some old documentation (just by random searching on the web), but it seems to be removed in newer versions.
Is there a replacement for it, and if yes, where can i find it?
If there is no replacement, I would be happy to hear about different ways to accomplish the goal of testing servlets!
Thanks in advance
The class org.eclipse.jetty.testing.ServletTester is the old Jetty 7 and Jetty 8 ServletTester.
It can be found in the following maven artifacts ...
https://search.maven.org/search?q=fc:org.eclipse.jetty.testing.ServletTester
The newer org.eclipse.jetty.servlet.ServletTester (note the package change) is available for Jetty 9.x, Jetty 10.x, and Jetty 11.x in the following artifacts ...
https://search.maven.org/search?q=fc:org.eclipse.jetty.servlet.ServletTester
Standard maven repository behaviors here, as the class is not a runtime class, it sits in the tests jar (also on maven central).
Example:
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-servlet</artifactId>
<version>9.4.35.v20201120</version>
<classifier>tests</classifier>
</dependency>
After upgrading some Glassfish/Grizzly dependencies (in order to be compatible with the latest version of Azure's SDK IOT device client), I started getting an error because com.google.common.EventBus no longer existed. Adding the dependency:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>15.0</version>
</dependency>
fixed that, and it was able to run locally in IntelliJ. However, when I deployed the .deb file that was compiled to a Raspberry Pi, it started producing the error:
java.lang.NoClassDefFoundError: javax/inject/Provider
at com.google.inject.internal.MoreTypes.canonicalizeForKey(MoreTypes.jav
a:81)
at com.google.inject.Key.(Key.java:119)
at com.google.inject.Key.get(Key.java:212)
at com.google.inject.spi.Elements$RecordingBinder.bind(Elements.java:262
)
at com.google.inject.internal.InjectorShell$RootModule.configure(InjectorShell.java:276)
at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:223)
at com.google.inject.spi.Elements.getElements(Elements.java:101)
at com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:133)
at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:103)
at com.google.inject.Guice.createInjector(Guice.java:95)
at com.google.inject.Guice.createInjector(Guice.java:72)
at com.google.inject.Guice.createInjector(Guice.java:62)
at com.infusion.empm.Main.main(Main.java:32) Caused by: java.lang.ClassNotFoundException: javax.inject.Provider
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
I read in a number of places that adding the dependency
<dependency>
<groupId>javax.inject</groupId>
<artifactId>javax.inject</artifactId>
<version>1</version>
</dependency>
is supposed to fix that (I already had the guice & javax-servlet-api dependencies referenced here), but it had no effect. When I do so, the result is two javax.inject jars (the other one being generated would seem to explain why I didn't need to explicitly add version 1 to get it to run locally):
javax.inject-2.5.0-b42.jar
javax.inject-1.jar
Someone else here used exclusions when they had those two jars, but even when I change my hk2 dependency accordingly, both jars are still present. I've also heard that adding javax.ws.rs-api is supposed to help, but that was already there. The imports in the Java code refer directly to com.google.inject.Provider, so I don't think there's any need to call guicify to convert a JSR-330 provider to a Guice one. Replacing every "com.google.inject" import in the local code with "java.inject" results in the same exact behavior, so it must be a dependency referencing google's code, which is in turn failing to find javax.
It turned out the cause was a script on the Pi which hardcoded the jars in the classpath.
After upgrading gwt from version 2.1.1 to 2.8.0, I got the error message
2017-04-20 12:59:19.551:WARN:oejuc.AbstractLifeCycle:main: FAILED c.g.g.d.s.j.WebAppContextWithReload#341fbaf1{/,file:/C:/Users/xxx/.IntelliJIdea2017.1/system/gwt/xxx.97baa614/xxx.fdf824a8/run/www/,STARTING}{C:\Users\xxx\.IntelliJIdea2017.1\system\gwt\xxx.97baa614\xx.fdf824a8\run\www}: java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
I found some other posts with similar messages, like this or this, but the situation seems to be different:
I do not use Maven or Ant, just pure IntelliJ, I have no reference to any Tomcat library, and I am not aware of any JSP in our application.
I found through debugging that first the class loader com.google.gwt.dev.shell.jetty.Jettylauncher$WebAppContextWithReload$WebAppClassLoaderExtension loads class org.eclipse.jetty.apache.jsp.JuliLog including interface org.apache.juli.logging.Log.
Then, later interface org.apache.juli.logging.Log is loaded by sun.misc.Launcher$AppClassLoader triggered indirectly by
org.eclipse.jetty.webapp.WebAppContext.startContext()
which calls method initialize of an
org.eclipse.jetty.jsp.JettyJspServlet
instance.
I have no idea why a JspServlet needs to be initialized at all, as no JSPs are used in the application, as far as I see, just a few Servlets. And it seems all the classes involved in this conflict are contained in the single jar gwt-dev.jar, so I see no possibility to influence any class loading behavior via class path settings.
Any idea how I could resolve this?
I also got this error upgrading from gwt from version 2.4 to 2.8.2.
Jake W's answer helped me.
To solve this, I ran a maven dependency tree on my project to figure out what was referencing jetty's apache-jsp.
To run the dependency tree, in Eclipse I created a new run configuration -> maven build -> with the goals "dependency:tree -Doutput=/dependency/file.txt". Once it's run, the console output will show where it saves the output. It should be the same location that you referenced with the -Doutput option.
Look for something like this in the output file:
- org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile
And then look up in the tree to see where it's being pulled in from. In my case it came from this:
+- com.google.gwt:gwt-dev:jar:2.8.2:compile
+- net.sourceforge.htmlunit:htmlunit:jar:2.19:compile
\- org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile
Once you know where it's coming from, (assuming you're using maven) you can add an exclusion in your pom.xml file for it:
</dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<version>${gwt.version}</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>apache-jsp</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
This worked for me. Thanks :)
I saw this error when I recently upgraded to GWT 2.8.0. Please try to exclude jetty-apache-Jsp related dependencies from your project.
You may see other jetty related issues as well, so please also make sure you are using exactly the same jetty version as GWT 2.8.0 is using.
I'm on mobile at the moment, unable to add more details, but I hope that can be a useful direction to go. Please add your comments if you still see issues, I will then have a look and update the answer when I'm on my laptop.
I have just ran into this exception after adding gwt-test-utils:0.53 dependency (with GWT 2.8.1)
I am using ant and all information found regarding this error indicated there was 2 versions of Juli Logging in the classpath, but every search came up with only gwt-dev.jar. Production builds worked fine, but dev mode did not which needs gwt-dev.jar.
Part of the build process has the jars copied from a local lib directory to war/WEB-INF/lib to pack into the war. The ant script points to the local lib directory for debugging, not the ones meant for the war file. Despite the war location not being listed in the ant file as a class path, it was still loading it.
Ultimately, gwt-dev.jar was conflicting with the copied version of itself.
I'm trying to develop an application which uses a library with a stax-api as a dependency. Build as stand-alone application it works fine, but when I'm trying to load JAR with dependencies assembled in my application using JCL, I get the following error:
javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found
at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:178)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92)
at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136)
at org.codehaus.xfire.util.STAXUtils.<clinit>(STAXUtils.java:48)
at org.codehaus.xfire.transport.http.HttpChannel.writeWithoutAttachments(HttpChannel.java:54)
at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.getByteArrayRequestEntity(CommonsHttpMessageSender.java:422)
at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.send(CommonsHttpMessageSender.java:360)
at org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:123)
at org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48)
at org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26)
at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:79)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:114)
at org.codehaus.xfire.client.Client.invoke(Client.java:336)
at eu.unicore.security.xfireutil.client.ReliableProxy.handleRequest(ReliableProxy.java:122)
at eu.unicore.security.xfireutil.client.ReliableProxy.doInvoke(ReliableProxy.java:102)
at eu.unicore.security.xfireutil.client.ReliableProxy.invoke(ReliableProxy.java:69)
at com.sun.proxy.$Proxy71.QueryResourceProperties(Unknown Source)
at de.fzj.unicore.wsrflite.xmlbeans.client.BaseWSRFClient.queryResourceProperties(BaseWSRFClient.java:372)
at de.fzj.unicore.wsrflite.xmlbeans.client.RegistryClient.listServices(RegistryClient.java:199)
at de.fzj.unicore.wsrflite.xmlbeans.client.RegistryClient.listAccessibleServices(RegistryClient.java:214)
at org.caebeans.wsrf.UNICOREModule.initialize(UNICOREModule.java:53)
... 9 more
It's rather strange, this class is assembled into the JAR, I can find it in archive.
I've seen this kind of message when application server libraries are loaded before application ones. Usually there's a setting that lets you specify the inverse order. If, as it seems, you're using Weblogic this may be achieved by inserting the following definition in your weblogic.xml file:
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
Try adding this Maven dependency:
<dependency>
<groupId>stax</groupId>
<artifactId>stax</artifactId>
<version>1.2.0</version>
</dependency>
I've installed Apache Karaf 2.3.0. One of my bundles that needs to be installed in it uses classes from javax.servlet.http package. When I try to install the bundle it gives me the error message:
karaf#root> ERROR: Bundle com.groupgti.esb.purge [207] Error starting mvn:com.groupgti.esb/esb.purge/1.0.0 (org.osgi.framework.BundleException: Unresolved constraint in b
undle com.groupgti.esb.purge [207]: Unable to resolve 207.0: missing requirement [207.0] osgi.wiring.package; (osgi.wiring.package=com.groupgti.esb.cxf.interceptors) [cau
sed by: Unable to resolve 212.0: missing requirement [212.0] osgi.wiring.package; (&(osgi.wiring.package=javax.servlet.http)(version>=2.6.0)(!(version>=3.0.0)))])
org.osgi.framework.BundleException: Unresolved constraint in bundle com.groupgti.esb.purge [207]: Unable to resolve 207.0: missing requirement [207.0] osgi.wiring.package
; (osgi.wiring.package=com.groupgti.esb.cxf.interceptors) [caused by: Unable to resolve 212.0: missing requirement [212.0] osgi.wiring.package; (&(osgi.wiring.package=jav
ax.servlet.http)(version>=2.6.0)(!(version>=3.0.0)))]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
javax.servlet.http package is exported from: mvn:org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1.2 system bundle. The problem is that its version is 2.5 but and my bundle requires at least 2.6.0. Is there a workaround or something to update the geronimo-servlet to the higher version that would be compatible with my bundle? (This is the system bundle).
Additional information:
CXF Version: 2.7.0
Camel Version 2.10.2
EDIT:
I forgot to mention the important thing. I also updated CXF to 2.7.0 version and CXF is the one which is introducing the dependency of Servlet 3.0. This is the graph from dependency tree:
Maybe will give you some idea on how get around this? The only thing that I could think of is to go back to CXF 2.6.x.
If your bundle really needs something newer than 2.5, you may have problems running it on Karaf 2.3.0. Karaf 2.3 uses Jetty 7.6.7 which is based on Servlet 2.5. It doesn't support any of the newer Servlet 3 based API's and such. You can upgrade the servlet-api bundle and it MAY work, but if your bundle/app uses any of the Servlet 3 functionality, it will likely not work.
Karaf 3 will be upgrading to Jetty 8.1 which does support the Servlet 3 stuff. Any help testing that and getting that out would be greatly appreciated by the Karaf community. :-)
Do you really need to use geronimo servlet spec ? Try replacing it with this:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>