In my project, I'm using both glassfish-embedded 3.1.1 and the guava lib... The problem is that glassfish comes with the old implementation of guava (ie google-collections)...
This results in NoSuchMethodError at runtime, for example when using Lists.reverse(), or Sets.newIdentityHashSet() which were introduced later in guava.
I don't find any solution to solve this... (the only one is to manually trash the com/google classes directory in the glassfish jar...)
You can overcome this be specifying the below. Read the Delegation section of the Class Loaders chapter.
<class-loader delegate="false" />
Check this SO post for class loading in Java EE apps in general: Java EE class loading standard
Glassfish should never have included com.google classes in their own jar. That was an error.
UPDATE[#sly7_7]: It seems like glassfish does not include guava in their own jar anymore, but it depends on the guava artifact instead. This should resolve the problem.
Thanks to #JagWire for pointing this.
I was able to make the error go away by using the following Glassfish v4 build:
http://grepcode.com/snapshot/maven.java.net/content/groups/promoted/org.glassfish.main.extras/glassfish-embedded-all/4.0.1-b01
Might be worth taking a look.
Related
I'm using NetBeans 7.2 as IDE, Java 7 and I have a lot of issues with different versions of a library.
Let's call the library in question as Lib (JAR file).
I have to realize a project A in Java, that uses package B and package C. Now B has dependency on Lib_v1.jar and C has dependency on Lib_v2.jar. Lib_v1 and Lib_v2 are 2 version of the same library and they aren't compatible, nevertheless they have a lot of class in common, so it is possible that a class can be loaded from a different version of the
library.
How can I manage this issue?
Unfortunately there is no real way to solve this problem. Even if you put both JAR files into the classpath one will get picked up by preference to the other.
If the library versions are not backwards compatible and the people who made the change didn't change package or something then you are pretty much out of luck.
isn't lib_v2 backwards compatible ? So you could use only lib_v2.jar ?
I saw a googlecode project(jar jar) which seems to solve your problem, have a look: https://code.google.com/p/jarjar/
I have a web service and I'm using the Endpoint.publish("http://0.0.0.0:8080")
Thing is that JAX-WS 2.0 and 2.1 is affected by an issue that throw a NullPointerException when executing endpoint.stop().
The issue is fixed in 2.2 but when adding the dependency in the pom.xml publishing fails due to a java.lang.NoSuchMethodError: javax.xml.ws.WebFault.messageName()Ljava/lang/String; since I'm using java 1.6.
The workaround is to add to the endorsed folder some libs. But I want to pack it all in jar-with-dependencies. An executable java jar.
Said this, I would be thankful if you help me:
Publishing the endpoint in 2.0 or 2.1 listening to all addresses (0.0.0.0)
or
Configuring dependencies in maven to pack everything using 2.2.x
but executable with JDK6
EDIT:
Requirements are a deliverable jar. A single jar that pack all of the dependencies (2 so far, about a 400k jar).
But if you think that the only way to make it work is to add an external shell script please let me know too.
Thank you!
The executable jar format does not allow for endorsed folders required for JAX-WS replacement (and neither does the Java WebStart launcher apparently).
You need to use something that can construct and execute a new "java" command on the fly. The best way from here is most likely to look for an installer which can run the program directly without needing to install.
What exactly do you need to happen?
EDIT: As the requirement is a runnable jar you simply cannot do this with JAX-WS 2.2 Find a workaround with the JAX-WS present in the latest release of the Java version you are targetting.
It is very nice that the JAX-WS stack ship with core Java allowign for very small deployments, but a pain that you cannot easily provide your own.
Note that you can provide your own with Java 5 but then you need to bring your own Endpoint implementation.
Do you need to use the JAX-WS RI? You could use CXF instead which is a fine JAX-WS implementation and doesn't suffer the same collision problems as the RI.
Edit: You could try to generate the classes with the RI, but use CXF in the deployment. JAX-WS is a spec after all so it should work...
this is a follow-up post to the twitter discussion i had on Google App Engine (Twitter Conversation)
The Problem is that Jersey and GAE won't work together with datanuceleus 2.0, since GAE needs ASM 4.0 but Jersey needs 3.1. A detailed description and easy solution on that is available here: GAE and Jersey Problem description
There are several posts on questions here on Stackoverflow, so I opened this thread to collaborate with Google's Teams to solve this issue.
I simply switched from Datanuceleus 2.0 to 1.0 and Jersey was working again. Do you have any other suggestions? Especially since 2.0 would be great to use.
Greetings,
Mario
Another solution is to use version 1.18.1 of Jersey, which is no more dependent on asm 3.0 and contains a repackaged version of asm, you can check it here: http://mvnrepository.com/artifact/com.sun.jersey/jersey-bundle/1.18.1
This will work in GAE.
You should try jarjar, which embeds a jar into another jar and fixes code references on bytecode level.
See this excellent blogpost: http://blog.harrywye.com/post/30160964741/running-java-jersey-with-jdo-3-0-on-google-app-engine
As #peter-knego said, with jarjar is really easy, and you can still use JDO/JPA > 1.0
Download jarjar
Create a text file: testrules.txt with the following content:
rule org.objectweb.asm.** org.objectweb.asm3.#1
With asm-3.1.jar and jersey-server-1.1.5-ea-SNAPSHOT.jar (or whatever you have) execute the following commands:
java -jar jarjar-1.4.jar process testrules.txt asm-3.1.jar asm-3.1r.jar
java -jar jarjar-1.4.jar process testrules.txt jersey-server-1.1.5-ea-SNAPSHOT.jar jjersey-server-1.1.5r-ea-SNAPSHOT.jar
And finally just replace the asm-3.1.jar and jersey-server-1.1.5-ea-SNAPSHOT.jar with the repackaged libraries.
I am using it with the 1.8.3 SDK and it worked to me.
Reference here
My problem is, that when the <c:if tag is reached the following problem occurs.
I am using Spring on google app engine.
java.lang.AbstractMethodError: javax.servlet.jsp.PageContext.getELContext()Ljavax/el/ELContext;
at javax.servlet.jsp.jstl.core.LoopTagSupport.unExposeVariables(LoopTagSupport.java:620)
at javax.servlet.jsp.jstl.core.LoopTagSupport.doFinally(LoopTagSupport.java:354)
at org.apache.jsp.WEB_002dINF.views.templates.master_005fb_jsp._jspx_meth_c_forEach_0(master_005fb_jsp.java:544)
at org.apache.jsp.WEB_002dINF.views.templates.master_005fb_jsp._jspx_meth_c_if_0(master_005fb_jsp.java:482)
at org.apache.jsp.WEB_002dINF.views.templates.master_005fb_jsp._jspService(master_005fb_jsp.java:314)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
The java.lang.AbstractMethodError means that an abstract method as mentioned in the error message which is declared in some (abstract) API in the current runtime classpath is missing in the concrete implementation in the current runtime classpath.
In this case it's the javax.servlet.jsp.PageContext.getELContext() method. As per the javadocs this abstract method was introduced in JSP 2.1. The concrete implementation is the server you're currently using.
This can be caused by having a jsp-api.jar of a different server make/version supporting JSP 2.1 in the runtime classpath of your webapp, most likely in /WEB-INF/lib folder, while the GAE server you're using doesn't implement JSP 2.1. Get rid of all server-specific libraries in the runtime classpath of your webapp. They doesn't belong there. They belongs (and are already) in the server's library.
Try using an older version of JSTL. It looks like you're using 1.2 and you should probably be using 1.1.
Most probably a library version issues. Google AppEngine provides a default JSTL library and you don't have to include your own on the WEB-INF/lib directory. Just remove the library you might have added to that directory and clean build to test again.
you don´t have to add any jstl library to web-inf/lib directory, just run
I am new to Java and experiencing problems understanding exceptions thrown by the framework.
Right now, I am trying to implement a regular expression validator into an application consisting of Java 5 EE with myFaces 1.2 and Tobago running in an apache tomcat 5.5.
I followed a couple of tutorials (including the Java 5 EE tut from SUN) and came pretty far. However, when calling my jsp, I get the following error message:
java.lang.LinkageError: loader constraints violated when linking javax/faces/validator/Validator class
Can anyone explain to me what I need to do to solve this problem?
So far, it seems as if MyFaces 1.1.7 has a version conflict to TomCat 5.5. Both contain javax.* packages (one of them namely javax.faces.validator). The validator class has a different version in the packages. The corresponding MyFaces library is called myfaces-api-1.1.7.jar and the TomCat library is called javaee.jar.
The included javax packages in the myfaces lib is a subset of the packages from within the javaee lib. However... I cannot skip any of both, because the project will fail to start then.
Any tipps?
This is almost certainly caused by your application having its own copy of Validator (in one of its JAR files), and this is clashing with the server's own copy. Something this can cause a LinkageError.
Find out which of your WAR or EAR's JAR files contains that, and remove it (along with the rest of the javax.faces classes).
Sounds like a classpath problem. Check your classpath for two jars with conflicting versions (both containing the javax.faces.validator.Validator class)
According to the MyFaces homepage. Tomcat Config: Tomcat 5.5.x
Some users have reported problems when
using MyFaces with Tomcat 5.5.x. Here
is a short guide that will hopefully
help you not run into the same
problems :-)
If your are using the binary version
of MyFaces: MyFaces is packaged so
that it works with Tomcat 5.0.x so
the WEB-INF/lib/jsp-2.0.jar and
WEB-INF/lib/commons-el.jar JAR files must be removed from your
WAR files (including the examples).
If you are building from source: If
you want to build MyFaces from scratch
to work with Tomcat 5.5.x, you have to
set the property
tomcat.pre.5.5.version in the
$MYFACES_HOME/build/build.default.properties
file to the value false.
Perhaps you've got two conflicting versions of the same library available on your classpath. For example, you might have a jar file in WEB-INF/lib that's already provided in TOMCAT_HOME/lib. (el-api.jar is a common culprit, but there are other possibilities.)