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!
Related
When I upgrade MatlabRuntime from 2019b to 2021b and I hava a springboot service used matlab, I have a problem,I import newest javabulider.jar(2021b) into my springboot service, then I package and publish my service into server,then report an error,can someone help me,thank you
Caused by: java.lang.UnsatisfiedLinkError: Failed to find the required library libmwmclmcrrt.so.9.7 on java.library.path.
This library is typically installed along with MATLAB or the MATLAB Runtime. Its absence may indicate an issue with that installation or
the current path configuration, or a mismatch with the architecture of the Java interpreter on the path.
MATLAB Runtime version this component is attempting to use: 9.7.
Java interpreter architecture: glnxa64.
I need someone can help me
The message:
Failed to find the required library libmwmclmcrrt.so.9.7
Indicates that the application you are trying to execute was compiled with Matlab 2019b and that the corresponding MCR is not installed.
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.
When I try to fill a JasperReport in my Servlet running on Websphere 6.1 I get an UnsupportedClassVersionError: Bad major version at offset=6.
I guess that the compiled JasperReport has a different version (java 6?) than the jre on websphere can execute (which would be java 5), but I can not figure out why. Compiling the reports with maven or in the application (in the servlet) both leads to the error.
According to the demo which was provided with JasperReports, which also shows how to use it with Java 1.5, I added following config to the jasperreports.properties:
org.eclipse.jdt.core.compiler.source=1.5
org.eclipse.jdt.core.compiler.compliance=1.5
org.eclipse.jdt.core.compiler.codegen.TargetPlatform=1.5
But the error still exists.
The language used in the report is Java, so which compiler is the correct one to use? net.sf.jasperreports.engine.design.JRJdtCompiler or net.sf.jasperreports.engine.design.JRJavacCompiler?
Unfortunately, the documentation does not explain the difference between those two compilers...
Edit: so fare I have been using the JRJavacCompiler. With the JRJdtCompiler I get a NullPointer Exception:
java.lang.NullPointerException
at java.lang.Class.isAssignableFrom(Native Method)
at net.sf.jasperreports.engine.fill.JRFillTextField.getFormat(JRFillTextField.java:706)
at net.sf.jasperreports.engine.fill.JRFillTextField.evaluateText(JRFillTextField.java:394)
at net.sf.jasperreports.engine.fill.JRFillTextField.evaluate(JRFillTextField.java:368)
at net.sf.jasperreports.engine.fill.JRFillElementContainer.evaluate(JRFillElementContainer.java:258)
at net.sf.jasperreports.engine.fill.JRFillBand.evaluate(JRFillBand.java:499)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillColumnBand(JRVerticalFiller.java:2036)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillDetail(JRVerticalFiller.java:760)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportStart(JRVerticalFiller.java:270)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:128)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:946)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:864)
at net.sf.jasperreports.engine.fill.JRFiller.fillReport(JRFiller.java:84)
at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:624)
at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:540)
at com.swissre.sod.jone.web.server.FileStreamingServlet.doGet(FileStreamingServlet.java:48)
It might be that you are using libraries in you application that are compiled in java 6.
You could check the MANIFEST information of your dependencies to find out more.
I'm getting this error when starting the JBoss server in Eclipse.
Failed to boot JBoss:
java.lang.IllegalStateException: Incompletely deployed.
DEPLOYMENTS IN ERROR
Deployment "AttachmentStore" is in error due to: java.lang.IllegalArgumentException: wrong arguments. new for taget java.land.reflect.Constructor expected=[java.net.URI] actual=[java.io.File]
I've googled the AttachementStore error and most suggested modifying the profile.xml (conf/bootstrap/profile.xml) file by adding a class to the constructor parameter node like this...
constructor parameter class="java.io.File"
Adding the class="java.io.File" seems to be the accepted solution everywhere since it's a known bug in JBoss but it didn't work for me.
I know I added the class correctly, I checked, rechecked and rechecked again the profile.xml file but JBoss is still throwing the same error when starting. I'm completely baffled. Anyone have any other ideas?
Error mainly occurred due to upgrade java 6 to java 7 or 8. Previously I used jdk 6u10 and it is changed to jdk 7u45.
Run the projects using java release of jdk 6u10 or Sun JDK 1.6.0_13. JBOSS runs with these JDK version successfully.
I've found a similar issue described in detail in the scala mailing list (also here). It seems to be related to this change in classpath management when creating scala interpretation environments.
In my case both scala-library and scala-compiler are included in the war being deployed to WebLogic 10.3 (camel version: 2.8.0, jvm: oracle 1.6).
The exception is shown below:
com.sun.jersey.api.container.ContainerException: org.fusesource.scalate.TemplateException: object scala not found.
at org.fusesource.scalate.jersey.ScalateTemplateProcessor.writeToUsingServletTemplateEngine(ScalateTemplateProcessor.scala:190)
at org.fusesource.scalate.jersey.ScalateTemplateProcessor.writeTo(ScalateTemplateProcessor.scala:136)
at org.fusesource.scalate.jersey.ScalateTemplateProcessor.writeTo(ScalateTemplateProcessor.scala:44)
at com.sun.jersey.spi.template.ResolvedViewable.writeTo(ResolvedViewable.java:103)
at com.sun.jersey.server.impl.template.ViewableMessageBodyWriter.writeTo(ViewableMessageBodyWriter.java:83)
Truncated. see log file for complete stacktrace
Caused By: org.fusesource.scalate.TemplateException: object scala not found.
at org.fusesource.scalate.TemplateEngine.compileAndLoad(TemplateEngine.scala:784)
at org.fusesource.scalate.TemplateEngine.compileAndLoadEntry(TemplateEngine.scala:643)
at org.fusesource.scalate.TemplateEngine.liftedTree1$1(TemplateEngine.scala:374)
at org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:368)
at org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:426)
Truncated. see log file for complete stacktrace
Caused By: scala.tools.nsc.MissingRequirementError: object scala not found.
at scala.tools.nsc.symtab.Definitions$definitions$.getModuleOrClass(Definitions.scala:653)
at scala.tools.nsc.symtab.Definitions$definitions$.getModule(Definitions.scala:603)
at scala.tools.nsc.symtab.Definitions$definitions$.ScalaPackage(Definitions.scala:145)
at scala.tools.nsc.symtab.Definitions$definitions$.ScalaPackageClass(Definitions.scala:146)
at scala.tools.nsc.symtab.Definitions$definitions$.AnyClass(Definitions.scala:176)
The question: is it possible to make camel web-console work in this environment?
No its a problem with WebLogic. Scalaete needs to add special support for WebLogic, as WebLogic does classloading a bit differently, than the usual practice.