I need to deploy my GWT application to an OC4J server using Java 6.
I'm using GWT SDK 2.7.0 - according to the release notes while Java 7 is the default, this can be overridden using -sourceLevel 6 which in Eclipse I am adding as a compiler argument.
This has solved most of the problems the OC4J progress text gave me when deploying my war - but one seems to remain.
Operation failed with error: com/google/gwt/user/server/rpc/RemoteServiceServlet : unsupported classversion 51.0
Ignoring the specificity of OC4J, why is the RemoteServiceServlet a Java 7 class, when I have set the GWT compiler to use Java 6?
It sounds like you aren't using the right version of GWT - either that isn't 2.7.0, or you are using the wrong jar:
$ javap -cp /Users/colin/.m2/repository/com/google/gwt/gwt-servlet/2.7.0/gwt-servlet-2.7.0.jar -v com.google.gwt.user.server.rpc.RemoteServiceServlet
Classfile jar:file:/Users/colin/.m2/repository/com/google/gwt/gwt-servlet/2.7.0/gwt-servlet-2.7.0.jar!/com/google/gwt/user/server/rpc/RemoteServiceServlet.class
Last modified Nov 20, 2014; size 11978 bytes
MD5 checksum ef76115d101d7321764ed74a7d8c1d62
Compiled from "RemoteServiceServlet.java"
public class com.google.gwt.user.server.rpc.RemoteServiceServlet extends com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet implements com.google.gwt.user.server.rpc.SerializationPolicyProvider
minor version: 0
major version: 50
...
I just checked gwt-user also, and it too is 50.0, check that your gwt-servlet is actually the version you think you are using?
Related
Tried to follow the answers to other similar questions here, unfortunately, to no avail. We are upgrading our application from JAVA 7 to JAVA 17. The code compiles just fine, the problem is when we try to run the .war file on apache-tomee-plume-8.0.8.
JAVA_HOME is set properly:
JAVA_HOME
As well as path:
PATH
Here is the log error message:
Caused by: java.lang.RuntimeException: Unable to read class definition for com.ui.AccountListLight$SubListDataModel
at org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1180)
at org.apache.xbean.finder.AnnotationFinder.<init>(AnnotationFinder.java:153)
at org.apache.xbean.finder.AnnotationFinder.<init>(AnnotationFinder.java:166)
at org.apache.openejb.config.FinderFactory$OpenEJBAnnotationFinder.<init>(FinderFactory.java:546)
at org.apache.openejb.config.FinderFactory.newFinder(FinderFactory.java:267)
at org.apache.openejb.config.FinderFactory.create(FinderFactory.java:80)
at org.apache.openejb.config.FinderFactory.createFinder(FinderFactory.java:69)
at org.apache.openejb.config.DeploymentLoader.addWebModule(DeploymentLoader.java:878)
... 46 more
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 61
at org.apache.xbean.asm9.ClassReader.<init>(ClassReader.java:189)
at org.apache.xbean.asm9.ClassReader.<init>(ClassReader.java:170)
at org.apache.xbean.asm9.ClassReader.<init>(ClassReader.java:156)
at org.apache.xbean.asm9.ClassReader.<init>(ClassReader.java:277)
at org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1176)
Yes, I understand that the issue is that I compiled on JAVA 17 and somehow TomEE is trying to run it on an older version (probably JAVA 7 as that was what I had installed before), but considering I removed all JRE/JDK stuff for JAVA 7 on my machine and all there is in it is JAVA 17, how does it keep happening? Thank you for your time.
The problem has nothing to do with Java being unable to read your Java 17-compiled classes. Looking at the stack trace, the problem is that org.apache.xbean.asm9.ClassReader is unable to read your class file. This particular ClassReader is one that TomEE uses to load your application. It is not surprising that TomEE can't read Java 17 applications, since the last release was in August, before Java 17 came out. It was itself compiled using an older version of Java. Hopefully a future version of TomEE will fix this issue.
By setting
System.setProperty(.sun.net.httpserver.HttpServerProvider",
"org.eclipse.jetty.jaxws2spi.JettyHttpServerProvider");
The org.eclipse.jetty.jaxws2spi.JettyHttpServerProvider class is not found.
sun.misc.ServiceConfigurationError: java.lang.ClassNotFoundException: org.eclipse.jetty.jaxws2spi.JettyHttpServerProvider
I have included libs: Jetty 9, jaxws-ri-2.2.10, Jaxb-2.2.7
I already checked out:
Metro + Jetty + OSGi = pain
but the codehaus stuff is afaik moved to eclipse...
Where is the org.eclipse.jetty.jaxws2spi.JettyHttpServerProvider ?
Edit:
Ok i found out that it was renamed to org.eclipse.jetty.http.spi.JettyHttpServerProvider
But now i am getting:
java.lang.UnsupportedClassVersionError: org/eclipse/jetty/http/spi/JettyHttpServerProvider : Unsupported major.minor version 52.0
Solved:
By using Jetty 9.0.6 it is compatible with Java 7
As you can see from the Java Class File format byte offsets 6 and 7 are used to store the class file version. The table here will help
Version 52 is used to indicate that the class file format is Java 8. My guess is that you're using a library with a Java 8 requirement (or just one that was built using Java 8 and not targeting a previous class file format) and running on Java 7.
Jetty 9 is supposed to be Java 1.7 based which means you're either using something newer or you're using somebody's customised version that requires Java 8.
We are trying to run a process (broker) from a SUSE Linux Enterprise Server 11 (java-1_7_0-ibm) which connects to a Javaspace Blackboard (JINI) deployed on another linux machine. (CentOs with Open JDK "1.7.0_05-icedtea" version)
Stack Trace :
INFO: Starting broker
Exception in thread "main" java.lang.ExceptionInInitializerError
at java.lang.J9VMInternals.initialize(J9VMInternals.java:259)
at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:653)
at net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:528)
at com.sun.jini.reggie.$Proxy0.lookup(Unknown Source)
at com.sun.jini.reggie.RegistrarProxy.lookup(RegistrarProxy.java:128)
at edu.vt.ndssl.blackboard.JiniSpaceService.findSpace(JiniSpaceService.java:372)
at edu.vt.ndssl.blackboard.JiniSpaceService.<init>(JiniSpaceService.java:74)
at edu.vt.ndssl.blackboard.JavaSpaceBlackboard.<init>(JavaSpaceBlackboard.java:31)
at edu.vt.ndssl.blackboard.BlackboardFactory.make(BlackboardFactory.java:28)
at edu.vt.ndssl.broker.Broker.<init>(Broker.java:53)
at edu.vt.ndssl.broker.Broker.main(Broker.java:231)
Caused by: java.lang.RuntimeException: Unexpected exception
at com.sun.jini.logging.Levels.createLevel(Levels.java:142)
at com.sun.jini.logging.Levels.<clinit>(Levels.java:52)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:237)
... 10 more
Caused by: java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2667)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1387)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2059)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1984)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1867)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1419)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:420)
at com.sun.jini.logging.Levels.createLevel(Levels.java:138)
... 13 more
Same code works fine with Java 1.6 version upto 26.
I am looking for a correct version of Java to be installed on the SUSE Linux Enterprise Server which will be compatible with this OS and also equivalent to the Oracle JDK Update 5 or Open JDK Version 1.7.0_05 (icedtea).
Apparently, the root cause of the problem is that Oracle has made an incompatible change to the serialization format of the com.sun.jini.logging.Levels class. The change reportedly happened in Oracle JDK 1.6.0_38 and JDK 1.7.0_13, and has presumably made it into recent OpenJDK versions as well.
This problem has manifested in a variety of projects that use JINI. Examples:
https://issues.apache.org/jira/browse/RIVER-415 + https://issues.apache.org/jira/browse/RIVER-416.
https://cloudifysource.zendesk.com/entries/23079726-bootstrap-localcloud-not-working-Could-not-initialize-class-com-sun-jini-logging-Levels
More examples can be found by searching for "com.sun.jini.logging.Levels EOFException".
I can't say what the solution is / would be for you, but I have a couple of ideas:
Avoidance: I think you can avoid the problem if you don't mix pre and post-change JVM versions in your application network.
If you need to upgrade your application JVMs, I suggest that you upgrade them all, and then do a complete shutdown/restart of your JINI applications and services.
Fix your applications: It appears that the Apache River project fixed the problem by modifying the JINI code. As the issue ticket says:
The com.sun.jini.logging.Levels class produces a RuntimeException with the latest version of Java (both 1.6 and 1.7). The issue surrounds creation of custom java.util.logging.Level. The current implementation uses a ClassReplacingObjectOutputStream and the LevelData approach. By removing this approach and creating a subclass of java.util.logging.Level the issue gets resolved.
The issue ticket has a lot of discussion on the best way to do this, proposed patches and links to the checkin where they actually implemented the fix.
As test project I've create a very simple WebService using wsdl and jax-ws. The client runs very well if it is deployed as web application in GlassFish but if I start the same (WebService-)Code in Eclipse directly, I get the following error:
WARNUNG: Input Action on WSDL operation AddNumbers and #Action on its associated Web Method addNumbers did not match and will cause problems in dispatching the requests
Exception in thread "main" java.lang.NoClassDefFoundError: org/glassfish/ha/store/api/BackingStoreException
at com.sun.xml.ws.rx.mc.runtime.McConfigurationFactory.createInstance(McConfigurationFactory.java:66)
at com.sun.xml.ws.rx.mc.runtime.McTubeFactory.createTube(McTubeFactory.java:68)
at com.sun.xml.ws.assembler.TubeCreator.createTube(TubeCreator.java:84)
at com.sun.xml.ws.assembler.TubelineAssemblerFactoryImpl$MetroTubelineAssembler.createClient(TubelineAssemblerFactoryImpl.java:130)
at com.sun.xml.ws.client.Stub.createPipeline(Stub.java:228)
at com.sun.xml.ws.client.Stub.<init>(Stub.java:205)
at com.sun.xml.ws.client.Stub.<init>(Stub.java:178)
at com.sun.xml.ws.client.sei.SEIStub.<init>(SEIStub.java:85)
at com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:608)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:348)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:330)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:312)
at javax.xml.ws.Service.getPort(Service.java:134)
at mnm.namedesdienstes.webservice.service.NameDesDienstesService.getNameDesDienstesPortTypePort(NameDesDienstesService.java:56)
at webserviceClient.NameDesDienstesClient.myTest(NameDesDienstesClient.java:12)
at webserviceClient.NameDesDienstesClient.main(NameDesDienstesClient.java:25)
Caused by: java.lang.ClassNotFoundException: org.glassfish.ha.store.api.BackingStoreException
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 16 more
After some research I found out that it must have something to do with different versions of some library files. So now my question is, how can I "fix" my eclipse java execution to run my webservice client correctly? I've found some tips to copy some jar to an endorsed-directory, but which jars into which directory :-)
I'm using Max OS 10.6.8, Eclipse Project uses JVM 1.6. My Mac Java Version is
xmacbook:~ cstraube$ java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
UPDATE: My first try (thanks to the link from remipod) I performed the following steps:
Get the directory of endorsed lirbaries with System.out.println(System.getProperty("java.endorsed.dirs"));
Next, I copied the two files JAXWS2.1.7-20090419.jar and JAXB2_20080513.jar (both Version 2.1.7) into this directory
Unfortunately I get still the same error
I have similar problem with yours when deploying web service (JAX-WS) in tomcat 7.
The missing class definition could be found in ha-api.jar.
org/glassfish/ha/store/api/BackingStoreException
You should add the ha-api.jar (From JAX-WS distribution) into server lib. For my case, the eclipse run tomcat 7, so the location is (Tomcat 7.0\lib).
You have to copy the fitting versions of jaxws-api.jar and jaxb-api.jar into the directory /Library/Java/Home/lib/endorsed (Mac).
Have a look at this link JAX WS with WS 2.1.1. You will need to give precedence to your version of jaxws to the provided jaxws from the jre 1.6.
Edit:
Glassfish already includes some libraries, as well as java 6. I had to track down version conflicts with jaxws in glassfish 3.1 / 3.1.1 and java 6 / 7. You might check the exact java runtime eclipse uses to start the application and look for duplicate jars on the effective classpath.
The endorsed mechanism just provides an easy and error prone way to override the included jaxws distribution. Error prone, because your colleague will suffer from the same problem.
I havn't seen the exception org.glassfish.ha.store.api.BackingStoreException in the context of jaxws. Your version conflict could be created by another library than jaxws...
I experienced the exact same exception
org.glassfish.ha.store.api.BackingStoreException
And after ensuring my JAX-WS and JAX-B jars were all the same version the issue was still occurring.
THE FIX: I then added the ha-api.jar to the WEB-INF\lib directory and this solved the issue.
The clue here was the "ha" package in the exceptions class path as seen above. Hope this helps!
Hi I'm trying to install this tool 'Sean Corfield's scripting for ColdFusion project.' on my server - problem is I am getting "Class not found: com.caucho.quercus.script.QuercusScriptEngineFactory " errors, I have java 1.6 installed.... I'm not sure how where to get these extra classes ... any help?
[opensuse 11 system, CF8 java 1.6]
-thanks
-sean
Did you follow the installation instructions for the cfphp, as per the "example.cfm" page:
Installation:
1. Copy lib/quercus.jar and lib/resin-util.jar to WEB-INF/cfusion/lib/
(multiserver) or coldfusion8/lib (standalone)
2. Restart ColdFusion 8.
3. Optionally copy customtags/php.cfm into your custom tags path.
The important thing is that the quercus.jar is accessible to the JVM. Your error message indicates that the JVM can't find the jar.