I am calling a REST service and the provider has supplied a client. Client's specification is to use Jersey 2.18. So i have used the below jersey dependencies
Jersey-client-2.18.jar
Jersey-common-2.18.jar
Jersey-entity-filtering-2.18.jar
Jersey-guava-2.18.jar
jersey-media-json-jackson-2.18.jar
I am making calls using scheduledThreadPoolExecutor and my application is running in tc server and JDK 1.8. Sporadically i get the below exception. I tried searching this exception in google but no luck. But i see the below for almost everytime
Cannot create new registration for component type class > org.glassfish.jersey.client.authentication.HttpAuthenticationFeature
Exception
java.lang.NullPointerException at
org.glassfish.jersey.model.internal.CommonConfig.configureFeatures(CommonConfig.java:694)
at
org.glassfish.jersey.model.internal.CommonConfig.configureMetaProviders(CommonConfig.java:644)
at
org.glassfish.jersey.client.ClientConfig$State.configureMetaProviders(ClientConfig.java:365)
at
org.glassfish.jersey.client.ClientConfig$State.initRuntime(ClientConfig.java:398)
at
org.glassfish.jersey.client.ClientConfig$State.access$000(ClientConfig.java:88)
at
org.glassfish.jersey.client.ClientConfig$State$3.get(ClientConfig.java:120)
at
org.glassfish.jersey.client.ClientConfig$State$3.get(ClientConfig.java:117)
at
org.glassfish.jersey.internal.util.collection.Values$LazyValueImpl.get(Values.java:340)
at
org.glassfish.jersey.client.ClientConfig.getRuntime(ClientConfig.java:726)
at
org.glassfish.jersey.client.ClientRequest.getConfiguration(ClientRequest.java:285)
at
org.glassfish.jersey.client.JerseyInvocation.validateHttpMethodAndEntity(JerseyInvocation.java:126)
at
org.glassfish.jersey.client.JerseyInvocation.(JerseyInvocation.java:98)
at
org.glassfish.jersey.client.JerseyInvocation.(JerseyInvocation.java:91)
at
org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:411)
at
org.glassfish.jersey.client.JerseyInvocation$Builder.get(JerseyInvocation.java:307)
I resolved this issue. My implementation was wrong. The client object was defined as a class level variable and it was initialized during every method call. During parallel call. every thread concurrent call attacks the same class level object and tries to modify and hence the object was not properly initialized. Now i fixed it by injecting the class from spring so that it is not modified during every call.
Related
I am trying to move to KafkaClient 0.10.0.1 from 0.9.0.0. The code is working fine in production with 0.9.0.0. Now the same code in development platform throwing exception when a consumer is started with following exception
javax.servlet.ServletException: java.lang.NoSuchMethodError: org/apache/kafka/clients/consumer/KafkaConsumer.subscribe(Ljava/util/List;)V (loaded from file:/home/vcap/app/wlp/usr/shared/config/lib/global/kafka-clients-0.10.0.1.jar by com.ibm.ws.classloading.internal.AppClassLoader#7a0d5027) called from class com.ibm.b2b.msghub.helper.AbstractB2BConsumer (loaded from file:/home/vcap/app/wlp/usr/shared/config/lib/global/B2BBlueMixLib-1.0.jar by com.ibm.ws.classloading.internal.AppClassLoader#7a0d5027).
Madhu
The client API has slightly changed between Kafka 0.9 and 0.10.
The definition of KafkaConsumer.subscribe() has changed. The first argument is now of type Collection instead of List.
This was done to make the API more consistent as now most (all?) calls take a Collection object whereas before it was a mix of several types.
I have a Grails 3 application (3.1.1) that implements a Breadcrumb system. I based it on this plugin for an earlier version of Grails.
It runs fine locally (using Grails command line command run-app), however, when I build and run on Tomcat 7, I get the following exception:
Jul 08, 2016 5:10:34 PM org.apache.catalina.ha.session.DeltaManager requestCompleted
SEVERE: Unable to serialize delta request for sessionid [6605EAC9C04DF7E2512493CABDFB1AD2]
java.io.NotSerializableException: au.packagename.BreadCrumbService
The above named service has a scope set to session, and is specified as a proxy. I have even added the Serializable implementation, however that does not seem to help.
class BreadCrumbService implements Serializable {
static transactional = false
static scope = 'session'
static proxy = true
}
I have an Interceptor that uses the Service to write the current controller and action as a Crumb object to the session. I have added the Serializable implementation to the Crumb and BreadCrumbType Enum (used in the Controllers annotation) that gets written to the session.
Is anyone able to indicate to me why this might be happening (I understand the concept of Serializable) and how I might go about resolving it?
#Hoàng Long's comment put me the right track.
When writing the Crumb object (all of which were made Serializable) to the session, I was using a static variable in the BreadCrumbService for the session map's key.
session[BreadCrumbService.NAMESPACE].crumb = new Crumb()
When I moved this variable to the Crumb object, the issue was resolved.
Even though the Service itself hasn't being written to the session. The mere reference to a variable inside the Service in the writing to the session required the service and every member to be Serializable.
I'm hoping to save some client info (IP address, etc) to a database on session created in Spring MVC.
I created a class implementing HttpSessionListener and configured it in web.xml. However, I'm not sure where to go after that.
Would like to be able to inject a bean as well (Spring Data JPA repository).
I've seen How to get the IP address when a session is created? , however if I try to access RequestContextHolder.currentRequestAttributes() I get the following exception:
SEVERE: Session event listener threw exception
java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
You can create a bean this way with Spring java config:
#Bean
#Named ("IP")
#Scope ("session")
public String ip (HttpServletRequest request) {
return request.getRemoteAddr ();
}
If all you want to do is log stuff then you should use the HttpSessionListener, please provide your source and full stack trace. Use pastebin.com if necessary.
We have stateless session bean (EJB 3.0) that has a method which accepts varargs(variable arguments) as inputs. Method signature is as below:-
public String operation1(String arg1,List...arg4);
This EJB is deployed on Weblogic 10.3.2 running on a "Java6" JRE.
When this EJB method is invoked from a Java6 standalone client, the call is successful.
When I change the JRE from Java6 to Java7(without changing any other client code),the call fails with an unmarshal exception(Stack trace below).
javax.ejb.EJBException: Could not unmarshal method ID; nested exception is:
java.rmi.UnmarshalException: Method not found: 'operation1(Ljava.lang.String;Ljava.util.List...;)'; nested exception is: java.rmi.UnmarshalException: Method not found: 'operation1(Ljava.lang.String;Ljava.util.List...;)'
at weblogic.ejb.container.internal.RemoteBusinessIntfProxy.unwrapRemoteException(RemoteBusinessIntfProxy.java:109)
at weblogic.ejb.container.internal.RemoteBusinessIntfProxy.invoke(RemoteBusinessIntfProxy.java:91)
at com.sun.proxy.$Proxy5.operation1(Unknown Source)
at com.MyEJBStandaloneClient.testOperation1(MyEJBStandaloneClient.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
EJB Code
#Stateless(mappedName = "MyBean")
public class MyBean implements MyBeanRemote{
public String operation1(String arg1,List...arg4) {
System.out.println("Input1 is:-"+arg1);
return "newString";
}
}
Remote class
#Remote
public interface MyBeanRemote {
public String operation1(String arg1,List... arg4);
}
The non-varargs methods(if any are added), within the same EJB are invoked successfully from Java7 clients & it is only the varargs methods in the EJB that have this problem.
Note that the same call works fine even with Java7 if the method signature on the Remote interface class is changed to the following
public String operation1(String arg1,List[] arg4);
But is there any way to make it work without changing the method signature?
Are there any known issues around this?
Thanks.
The problem you described is the consequence of an old bug from WebLogic.
In fact, EJB methods using varargs are ignored when it generates its stub classes.
The deep reason is that WebLogic EJB compiler incorrectly tries to append a transient modifier to the varargs argument.
Obviously, it results in an error, and so, the method stub is not generated.
At that time BEA created a path, CR327275, for WebLogic 10.0.MP1 to correct the issue. Unfortunately, this patch was apparently NOT included in WebLogic 10.3 release...
Feedbacks on this point are not that easy to find, but the Seam community made some. Here they are:
http://in.relation.to/Bloggers/Weblogic10SeamAndEJB3#H-Option1ApplyTheTtCR327275ttPatchBut
https://docs.jboss.org/seam/2.1.2/reference/en-US/html/weblogic.html
So, to solve your issue:
either, as you guessed, you have to change the method signature
or you contact WebLogic to get and install the former patch.
Regards,
Thomas
I'm facing a JAXBException " is not known to this context" when calling a web service from within a job controlled by Quartz on Spring:
javax.xml.ws.WebServiceException: javax.xml.bind.JAXBException: com.xxxx.yyyy.zzzz.ImageMetaData is not known to this context
at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:175)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:128)
at org.apache.axis2.jaxws.marshaller.impl.alt.DocLitWrappedMinimalMethodMarshaller.demarshalResponse(DocLitWrappedMinimalMethodMarshaller.java:624)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.createResponse(JAXWSProxyHandler.java:593)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:432)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invoke(JAXWSProxyHandler.java:213)
at com.sun.proxy.$Proxy299.findAllImageMetaData(Unknown Source)
I'm having a Spring 3.2.4 Java EE application with JSF running on IBM WebSphere v8.
When calling a specific web service from the JSF part of the application (i.e. from an action or a service), everything's ok.
The exception occurs only when the call is done from within a Quartz/Spring triggered job.
Executing exacty the same job code from the action does not result in an exception.
I tried a lot of different things like using a corresponding #XmlSeeAlso annotation in the JAXB generated classes but even using the annotation in the webservice interface itself does not solve the issue.
I also updated the Spring and Quartz libraries to more recent versions but this didn't help.
Anyone any idea?
I've finally solved the issue.
After much analysis I encountered the following issue in the Spring framework:
https://jira.spring.io/i#browse/SPR-11125
When a job is triggered via Spring/Quartz on WebSphere, the wrong ContextClassLoader is set.
This may cause many different problems - among them is the JAXBException as described.
The Spring bug is still open - so as a workaround I had to overwrite the context class loader of the current thread by the correct one:
ClassLoader cl = invoiceService.getClass().getClassLoader();
Thread.currentThread().setContextClassLoader(cl);
The correct class loader can be simply retrieved by a class that has been loaded by the container. Using this class loader as the context class loader for the current thread solved my issue.