I am using Eclipse Luna (versions 4.4.2) and Glassfish 4 to build a REST web-app using JAX-RS.
All POST and PUT operations, which were previously working fine, are now throwing this error on the webserver:
Warning: StandardWrapperValve[Jersey Web Application]: Servlet.service() for servlet Jersey Web Application threw exception
java.lang.ClassNotFoundException: javax.xml.parsers.ParserConfigurationException not found by org.eclipse.persistence.moxy
I have found out (in the comments here: https://java.net/jira/browse/JERSEY-2888) that it has been fixed in EclipseLink 2.6.1 and Jersey 2.19.
I have updated to Jersey 2.22.1.
Eclipselink 2.6.1 has been released on Oct 15th 2015, as you can see here: http://www.eclipse.org/eclipselink/releases/
However, as you can see here, it doesn't seem to have been incorporated into eclipse for "help -> update software": http://download.eclipse.org/rt/eclipselink/updates/
Does anybody know how to get 2.6.1 working with Eclipse? At the moment, it is preventing me from completing my application, and this problem I've had for 4 weeks.
Or is there another way to fix it?
All help much appreciated...
File a bug report at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EclipseLink indicating that it's neither in the main repository nor downloadable as a P2 repository on its own.
Related
We've been getting errors occasionally from our test and production environments where ServiceLocatorImpl has shut down which causes it to fail to create stateless EJBs from any #Schedule methods.
javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:399)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2607)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:2024)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:90)
...
Caused by: java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_9,12,566324949) has been shut down
at org.jvnet.hk2.internal.ServiceLocatorImpl.checkState(ServiceLocatorImpl.java:2384)
at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLocatorImpl.java:997)
at org.glassfish.jersey.inject.hk2.AbstractHk2InjectionManager.inject(AbstractHk2InjectionManager.java:207)
at org.glassfish.jersey.inject.hk2.ImmediateHk2InjectionManager.inject(ImmediateHk2InjectionManager.java:30)
at org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider$InjectionManagerInjectedCdiTarget.inject(CdiComponentProvider.java:668)
at org.glassfish.weld.services.JCDIServiceImpl$JCDIInjectionContextImpl.inject(JCDIServiceImpl.java:581)
at org.glassfish.weld.services.JCDIServiceImpl.injectEJBInstance(JCDIServiceImpl.java:328)
at com.sun.ejb.containers.BaseContainer.injectEjbInstance(BaseContainer.java:1818)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:437)
... 88 more
Most of the application continues to work fine and and users can continue using it but background processes that are run from #Schedule all fail until we restart Payara.
We originally ran into this in our test environment after it had been running for multiple days under a fairly high load while we were on Payara 5.2021.4 (uses Jersey 2.30). We found servicelocator impl shutdown issue in jersey 2.22 talking about this issue and it seemed to indicate that Jersey 2.26 fixed the issue.
Since we were already on a later version we dug into the release notes and found that in hk2 2.6.1 there was a fix "Fix for child service locator shutdown" (https://github.com/eclipse-ee4j/glassfish-hk2/blob/master/CHANGELOG) and that Jersey 2.29.1 had updated the hk2 version from 5.1.0 to 6.2.1 (https://github.com/eclipse-ee4j/jersey/pull/4234) and that we had been listing Jersey 2.29 as a dependency. So we updated our versions to Payara 5.2021.8, Jersey 2.34 (hk2 2.6.1) and made our environment restart payara every night. After that we didn't seen the error for a while but since then we've still gotten it a couple times in production.
We haven't been able to reproduce the issue on demand or pin down any other errors that could be causing it. Has anyone else run into this issue on the current Payara and come up with a way to fix it, work around it or mitigate it short of restarting payara whenever it happens?
We use fabric8-maven-plugin to manage the full lifecycle of all of our kubernetes services. We are having a problem upgrading statefulsets (similar to this post but we dont use the kubernetes-client). The version of the maven plugin is 4.3.1. We have no issues with daemonsets but I just cant find a way to update statefulsets. We get the same error as the afore mentioned post.
Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden..
I have tried to set the updateStrategy to rolling but that doesn't seem to do anything.
Thanks Paul
I'm having this exception when I try to consume a WebService from my application. I've been googling this error but all I see is about OutOfMemoryErrror.
I have Wildfly 8.1.0.Final and jaxws-api version 2.2.9 as dependency in my pom.xml. I'm using axis 1.4 for another legacy module of my application too. I've read in another stackoverflow post that I can't use both (Axis and CXF) in the same project (or .war finally) but I can't find any other reference about this fact.
I tried disabling webservices extensions in my standalone.xml with no success at all. Also adding jbossws-cxf-client 5.0.0.Final in my pom.xml with the same result.
Tomorrow I'll try to generate an Axis 1.4 client and see if this solves my problem.
Thanks in advance for any comment.
21:06:54,634 ERROR [....controller.BaseController] (default task-17) Manejando una excepción no tratada: javax.xml.ws.soap.SOAPFaultException: unable to create new native thread
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
at com.sun.proxy.$Proxy100.evaluateTransaction(Unknown Source)
at ...services.RiskServicesImpl.consultarRiesgoTx(RiskServicesImpl.java:191) [classes:]
Finally we realized that this SOAPFaultException was not thrown from my Wildfly but from the server we wanted to connect to, wich ran out of memory. Using another tool to query de web service was enough to see this.
Tim Biegeleisen: thanks for reading this desperate post :)
I'm using spring social in my project. I already completed integration with facebook and twitter, but had trouble with linkedin.
if I try create connection:
Connection <LinkedIn> connection = connectionFactory.createConnection(accessToken);
then I have this exception:
java.lang.NoSuchMethodError:
org.codehaus.jackson.map.SerializationConfig.withSerializationInclusion(Lorg/codehaus/jackson/map/annotate/JsonSerialize$Inclusion;)Lorg/codehaus/jackson/map/SerializationConfig;
I already tried use different versions of spring-social-linkedin and different version of jackson lib (v 1.9.2 and above) but unsuccessful.
Can anyone tell me how resolve this trouble?
The method is available since v1.9 of the API.
The only reason this can happen is that you are compiling against the right libraries at compile time, but at runtime this method is unavailable. There is a stale version (< 1.9) of the library on your classpath somewhere.
withSerializationInclusion
public SerializationConfig withSerializationInclusion(JsonSerialize.Inclusion incl)
Since:
1.9
Hi I am currently using the JodaTime library in my NetBeans restful web services on GlassFish Server using Jackson libraries.
I get a java.lang.NoClassDefFoundError for org/joda/time/ReadablePartial when I try to create an instance of a class that uses the JodaTime library in one of the Resource files.
E.g:
In the studentResource file:
Controller c = new Controller();
Where the Controller class imports and uses JodaTime libraries
I have checked that the libraries I needed are in the project.
In fact, if I run a separate project outside of the restful web services, everything runs smoothly. Is there an additional classpath issue that I have to address?
In case someone stumbles upon the same problem using Spring:
This problem comes up if you are trying to map JSON to a Java object using Jackson either via #RequestBody annotation on controller parameter or manually deserializing using an ObjectMapper().readValue(json, Class.class). Everything works fine on local machine but when deploying application to GlassFish deserialization fails.
Keeg's workaround to copy Joda-Time.jar to glassfish/modules and restarting fixes the issue.
There seems to be a bug open on Jira about this issue:
https://java.net/jira/browse/GLASSFISH-20808
Just in case someone else stumbles upon this problem, we had a similar issue with the combination of Glassfish 3.1.1, Jersey and use of Joda time. Stacktraces like this:
Caused by: java.lang.ClassNotFoundException: org.joda.time.ReadableInstant not found by jackson-mapper-asl [128]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)
etc.
The workaround I just found was dumping a copy of our joda-time jar into glassfish/modules. Not exactly pretty, but...
Ok I found the solution. Apparently all I needed to do was to move the jar file up in the list of libraries/jar files. I do that in the library tab in the project's properties. More specifically, the jar file has to be moved above the REST libraries.