I deployed an EAR in Websphere 8.5 with JDK 1.7 (IBM). My application is a spring based app that expose only web services; it have the following features:
Classloader is set to PARENT_LAST
Has shared libraries, one of them has Spring Framework (4.3.2) and Apache CXF (3.1.9) jars.
I invoke it through SOAPUI(5.2.1).
The application starts without problems.
When I invoke it I receive the following error message:
00000146 ServletWrappe E com.ibm.ws.webcontainer.servlet.ServletWrapper
service Uncaught service() exception thrown by servlet CXFServlet:
java.lang.VerifyError: **JVMVRFY012** tamaño de pila incoherente;
clase=com/sun/xml/messaging/saaj/soap/SOAPDocumentImpl,
método=createDocumentFragment()Lorg/w3c/dom/DocumentFragment;, pc=5
I read a related answer to that error and aplied this solution, but got the following error:
javax.xml.soap.SOAPException: **Unable to create message factory for SOAP:
com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
incompatible with javax.xml.soap.MessageFactory**
I am going to debug Apache CXF libraries to try figure it out the problem. Thanks in advance for your answers.
I finally solve my problem. It was a conflicting library problem between WAS and app libs. I deleted the following libraries from my WEB-INF/lib folder:
javax.xml.soap-api
saaj-impl
Thanks!
Related
I am porting an old IBM Process Server application to IBM WebSphere Liberty. It contains a lot of code based on Service Data Objects (SDO). I have some good working code, running as standalone Java, using JDK8. I am using eclipselink 2.7.7, specifically 2 jar files;
eclipselink.jar
commonj.sdo_2.1.1v20111051852.jar
I have built this code into a Servlet to handle SOAP requests, and packaged it, along with other code, into an EAR file, which I deployed under IBM WebSphere Liberty 20. It doesn't work. There seems to be a clash with the Liberty version of EclipseLink.
If I deploy the code as a WAR file, and add a classloader of "PARENT_LAST", the code works fine.
However, if I try to deploy the code in an EAR file, and set a classloader of "PARENT_LAST" for the ear file, I get this error;
[ERROR ] CWWKZ0106E: Could not start web application S21.
[ERROR ] CWWKZ0002E: An exception occurred while starting the application S21. The exception message was: com.ibm.ws.container.service.state.StateChangeException: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.eclipse.persistence.jpa.PersistenceProvider.getProviderUtil()Ljavax/persistence/spi/ProviderUtil;" the class loader (instance of com/ibm/ws/classloading/internal/ParentLastClassLoader) of the current class, org/eclipse/persistence/jpa/PersistenceProvider, and the class loader (instance of org/eclipse/osgi/internal/loader/EquinoxClassLoader) for interface javax/persistence/spi/PersistenceProvider have different Class objects for the type javax/persistence/spi/ProviderUtil used in the signature
Does anyone know whether I can replace the IBM Liberty implementation of EclipseLink with my version 2.7.7 version?
My application also uses JPA, which is working fine under Liberty, so I don't want to break that.
Any help / guidance appreciated... it's been a very long saturday.
PS:
I tried running the java code using only the SDO library (commonj.sdo_2.1.1v20111051852.jar), and relying on the WebSphere Liberty runtime jars to provide Eclipselink functionality, and I got the following errors, which is why I then moved to adding the "matching pair" of Eclipselink / SDO jars mentioned above;
Caught Exception : org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getSystemPropertyBoolean(Ljava/lang/String;Z)Z
java.lang.NoSuchMethodError: org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getSystemPropertyBoolean(Ljava/lang/String;Z)Z
at org.eclipse.persistence.sdo.helper.SDOHelperContext.<init>(SDOHelperContext.java:93)
at org.eclipse.persistence.sdo.helper.SDOHelperContext$DefaultHelperContextResolver.getHelperContext(SDOHelperContext.java:1432)
at org.eclipse.persistence.sdo.helper.SDOHelperContext.getHelperContext(SDOHelperContext.java:492)
at org.eclipse.persistence.sdo.helper.SDOHelperContext.getHelperContext(SDOHelperContext.java:471)
at org.eclipse.persistence.sdo.helper.SDOHelperContext.getHelperContext(SDOHelperContext.java:456)
at org.eclipse.persistence.sdo.helper.delegates.SDOXMLHelperDelegator.getXMLHelperDelegate(SDOXMLHelperDelegator.java:178)
at org.eclipse.persistence.sdo.helper.delegates.SDOXMLHelperDelegator.load(SDOXMLHelperDelegator.java:78)
at com.ebs.solas2021.port.adapter.ui.SOAPRequestHandler.main(SOAPRequestHandler.java:237)
It's amazing what you find whgen you re-read the documentation in the cold light of a new day. It turns out that it's possible to install a JPA 2.2 Container on Liberty, while supplying one's own implementation of EclipseLink. Works like a charm.
Documented here: https://openliberty.io/blog/2018/06/29/full_java_ee_8_liberty_18002.html
I have a SpringBoot 2.2.6 Web Application and I want to run it under JBoss EAP 7.
I manage to start the server but from the log I can see many warning about several classes. These warnings are all simiral to the follow one:
WARN [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0003: Could not index class module-info.class at /C:/server/jboss-eap-7.0/bin/content/TEST-EAR.ear/WEB-TEST.war/WEB-INF/lib/lombok-1.18.12.jar: java.lang.IllegalStateException: Unknown tag! pos=3 poolCount = 44
The classes involved are:
classmate-1.5.1.jar
jackson-annotations-2.10.3.jar
jackson-core-2.10.3.jar
jackson-databind-2.10.3.jar
jackson-datatype-jdk8-2.10.3.jar
jackson-datatype-jsr310-2.10.3.jar
jackson-module-parameter-names-2.10.3.jar
lombok-1.18.12.jar
Except for lombok, the other libraries come with spring-boot-starter-web dependency. Googlin around I read that problem is the libraries version.. but I hope there's another way to solve this WARN (is not a proper issue because the server starts) because exclude all these libraries from spring artifact and then re-import another version of them seems really an overkill to me..
Thank you
Googling around I have read many posts on this problem and various solution but noone works.
Finally I found a solution officially supported by redhat.
This is a warning message, it occured because of jandex supports Java9 is to simply ignore module-info.class files in dependent archives. To avoid this warning messages, replace jandex jar present in
JBOSS_HOME\modules\system\layers\base\org\jboss\jandex\main\jandex-2.0.2.Final-redhat-1.jar
with jandex-2.0.5.Final-redhat-1 and the respective module.xml.
You can found jandex-2.0.5.Final-redhat-1 on maven repos.
The link at the official issue is this.
Hope helps.
I am trying to set up an application on an ESB server. We have an OSGi bundle with all of the dependencies we'd need, but we're now having a weird problem. On runtime the server will be unable to instantiate the CXF client for our app server. The stack trace is
java.lang.LinkageError: loader constraint violation: when resolving method "javax.xml.ws.Service.<init>(Ljava/net/URL;Ljavax/xml/namespace/QName;)V" the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current class, mil/sddc/fltmgt/ws/api/FleetManagementWSServiceService, and the class loader (instance of <bootloader>) for resolved class, javax/xml/ws/Service, have different Class objects for the type <init> used in the signature
at mil.sddc.fltmgt.ws.api.FleetManagementWSServiceService.<init>(FleetManagementWSServiceService.java:39)
at mil.sddc.ibs.mediators.fleetManagement.TestClient.mediate(TestClient.java:28)
at org.apache.synapse.mediators.ext.ClassMediator.mediate(ClassMediator.java:78)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:77)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:47)
at org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:131)
at org.apache.synapse.rest.Resource.process(Resource.java:297)
at org.apache.synapse.rest.API.process(API.java:341)
at org.apache.synapse.rest.RESTRequestHandler.dispatchToAPI(RESTRequestHandler.java:76)
at org.apache.synapse.rest.RESTRequestHandler.process(RESTRequestHandler.java:63)
at org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:220)
at org.apache.synapse.core.axis2.SynapseMessageReceiver.receive(SynapseMessageReceiver.java:83)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
at org.apache.synapse.transport.passthru.ServerWorker.processNonEntityEnclosingRESTHandler(ServerWorker.java:344)
at org.apache.synapse.transport.passthru.ServerWorker.run(ServerWorker.java:168)
at org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
I haven't seen this particular stack trace before but it looks like WSO2's bootup classloader are both providing an instance of FleetManagementWSServiceService, Service, or both, resulting in a conflict.
It sounds like WSO2's bootup classloader and the classloader for my OSGi bundle are both providing FleetManagementWSServiceService, Service, or both. Presumably it would have to be Service, as even if I accidentally had that class in a jar that would be picked up by the bootup classloader the one in the OSGi bundle should always be favored.
The other class, javax.xml.ws.Service, is included in the Java runtime as well as a few other jars. I found a geronimo jaxws jar with it in the endorsed folder on the server and deleted it just in case, but this did not affect the build.
I assume that you have CXF and Axis2 installed in parallel. This will not work. The stacktrace shows that Axis2 is triggered to start your client but it conflicts with the installed CXF.
So the solution is to only install either Axis2 or CXF.
When I posted this I thought the problem came from missing dependencies on the server, but as it turned out we were actually missing dependencies in our OSGi bundle. By including a geronimo-jaxws jar, which contains javax.xml.ws.Service, this issue was resolved.
Near as I can tell the issues with Axis2 and CXF were red herrings. There are still CXF dependencies within the bundle, and the server is still using Axis2 to call our classes. 'Preciate the help, nonetheless!
Just curious whether it is possible to run JSF 2.3 on IBM Domino?
I have tried to deploy (JSF versions 2.0, 2.1, 2.2, 2.3) via the UpdateSite Plugin install following Sven's post HowTo: Vaadin on Domino. But was not really successful as got the following exceptions (listing from v2.3, but other versions are similar):
Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?
Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory. Attempting to find backup.
Uncaught init() exception thrown by servlet {0}: {2}
CWPWC0005E: Error occurred while initializing servlet wrapper. javax.servlet.ServletException: Uncaught initialization exception thrown by servlet Thread[Thread-6,5,main]
CWPWC0005E: Error occurred while initializing servlet wrapper. javax.servlet.ServletException: Uncaught initialization exception thrown by servlet
Any suggestions what to adjust? I do understand that Servlet version could not match JSF spec, but is it feasible at all?
Thanks!
The short answer: don't bother
The long answer:
Domino modified quite some number of OSGi elements to run. The Domino JSF has been extended to include SSJS. So you fight with a lot of moving parts.
What you want to do:
put an nginx in front of your Domino on 80/443
run Domino on a different port only accepting 127.0.0.1 connections
run your Primefaces Websphere liberty Glasfish app on yet another port
have nginx redirects point to old/new server based on url
Users will see one server, https can be handled by nginx, you can have http2, offload static resources.
While you are on it: give vert.x a shot. Way more fun than JEE
Good Morning all,
I have problem while deploying my web app in IBM WAS.
I have spring ws and during the deployment, I get the below error,
Caused by: javax.xml.soap.SOAPException: Unable to create message factory for SOAP: Unable to create SAAJ meta-factorycom.ibm.ws.webservices.engine.soap.SAAJMetaFactoryImpl incompatible with javax.xml.soap.SAAJMetaFactory
at javax.xml.soap.MessageFactory.newInstance(Unknown Source)
at org.springframework.ws.soap.saaj.SaajSoapMessageFactory.afterPropertiesSet(SaajSoapMessageFactory.java:145)
I have packaged the saaj-api 1.3 and saaj impl 1.3 jars in my application and i can see them in the lib folder.
I have set the class loading properties in the WAS to parent last.
Any clue or Where am I going wrong?
I'm using WAS version 7.0.0.11
I added this entry to the MANIFEST file to solve this issue,
DisableIBMJAXWSEngine: true
Hope this helps some one.