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
Related
It seems that the Nashorn engine has been removed since JDK15 https://openjdk.org/jeps/372 But I don't want to downgrade the JDK to build the Sencha app. Do you have any suggestions? Thanks!
I also found some articles, it seems to relate to the ant <script> tag, someone suggested using GraalVM, but I'm not sure how to integrate this thing.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64469 https://stackoverflow.com/a/60515528/21004428
Someone suggested importing the Nashorn engine and its dependency, I added nashorn-core-15.4.jar, asm-9.4.jar, asm-util-9.4.jar and asm-commons-9.4.jar to a build.xml, it works. But there are too many build.xml (including Sencha's xml) files in the app, not sure how to set them all.
Engine & dependency
https://stackoverflow.com/a/75097969/21004428
I'd be very grateful if someone could provide me the basic steps to install the Play2War Plugin. Like where to put the plugin files?, and which files?
I'm pretty new with Play Framework (Java, I'm not a Scala developer, ...yet), just created my first application, and want to deploy it on my server, with is a CentOS with Tomcat/ Glassfish installed, but unfortunately I found out that the 2.x version didn't have the built in war command anymore. I scoured the documentation and found the links Configuration, Usage and Deployment, but what I want to know are the steps until get there.
I started looking for sbt building tool ('cause Play2War Plugin uses it), until I realize that Play Framework 2.1.1. already have it installed (at least that is what I believe. See: *PLAY_HOME/framework/sbt/sbt-launch.jar* and *PLAY_HOME/framework/build*). Am I correct?
Thanks in advance,
As Play 2.1.1 already has SBT its as simple as doing the following:
Within plugins.sbt add:
addSbtPlugin("com.github.play2war" % "play2-war-plugin" % "1.0")
Then within the Build.scala file add:
import com.github.play2war.plugin._
...
val main = play.Project(appName, appVersion, appDependencies)
.settings(Play2WarPlugin.play2WarSettings: _*)
.settings(Play2WarKeys.servletVersion := "X.X")
The X.X needs to be changed to the required Java Servlet version (usually 3.0 or 2.5 depending on your container)
If you have a working play application, you are already using SBT tools to build. Yes, SBT comes with play.
The play2war plugin tutorial provides a step-by-step instruction. Simply follow the tutorial, you should be fine.
To answer your question, where to put the plugin file?
As the tutorial suggests, you need to modify files like APP_HOME/project/plugins.sbt, APP_HOME/project/Build.scala. You should already have these files, you simply need to add those lines to these existing files.
If you have a specific problem, please provide the error message.
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...
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.
See the JAX-WS Maven repository from java.net - http://download.java.net/maven/2/com/sun/xml/ws/
There are two similar folders - jaxws-rt and jaxws-ri. Currently, I'm using the jaxws-rt and it's working fine.
Here are my questions:
What's the difference between ri and rt?
Does ri stand for reference implementation and rt stand for runtime?
Please advice.
Thanks.
As an answer to your second question: Yes, you are right.
Below is the proof.
RI stands for Reference Implementation.
Quote from the official JAX-WS project home page (an old site, see the UPDATE section below):
Welcome to the JAX-WS Reference Implementation (RI) Project.
Plus in the POM file for the jaxws-ri (version 2.2.8 at the time of writing) we can find the following:
<name>JAX-WS RI Standalone Zipped Bundle</name>
<description>Open source Reference Implementation of JSR-224: Java API for XML Web Services Distribution Bundle</description>
RT stands for Runtime.
In the POM file for the jaxws-rt (version 2.2.8 at the time of writing) we can find the following:
<name>JAX-WS RI Runtime Bundle</name>
(The word Runtime gives us a hint :-))
UPDATE (April 2019)
The were quite a few changes in the Java EE world recently. Java EE was moved to Eclipse Enterprise for Java (EE4J). Read EE4J FAQ for more information.
And JAX-WS project, which is now part of the EE4J, has also moved to another place:
JAX-WS project's home page: https://javaee.github.io/metro-jax-ws/
JAX-WS project's code is hosted on GitHub:
https://github.com/eclipse-ee4j/metro-jax-ws
Looks like -ri generates the zip file for distribution (e.g. for use on the java.net web site), whereas -rt is for use as a Maven dependency. So you should keep using it.
EDIT: The other answer is more accurate and should be accepted