We have recently migrated to Jboss EAP 6.4 from Jboss 4.2. In one of our EJB classes we are having over loaded methods create(AbstractBean) and create(AbstractEntity). The class AbstractEntity is extending AbstractBean class. When we try to invoke the create(AbstractBean) method in Jboss 6.4 instance we are getting the IllegalArgumentException: argument type mismatch error, but we are not getting this exception in Jboss 4.2.
When we comment out the create(AbstractEntity) method, the exception is not occurring, also when we try to invoke the method using reflection the exception is not occurring.
But we just wanted to know is there anything to be done in the server configuration to resolve this issue or as mentioned above using reflection is a correct solution.
Can anyone help us understand the Jboss6.4 behavior correctly.
We were having two methods in a class which having different arugment type but argument type of one method extends argument type of other so JBoss ended up with ambiguity error. we have removed the method with derived class as argument and kept the super class one. That resolved the issue for us.
Related
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.
we updated our solution to ValueInjecter v3.0 and now we have big problems because in this version an exception is raised if a property has no setter. This is different to Version 2.3.3.
We have a lot of classes where the missing setter is possible, so what can we do beside scanning the whole source code and check every usage of InjectFrom???
Is there any global Setting who avoids the exception when there is no setter?
Greeting
Martin
no, there isn't any global setting for that, but this has been recently fixed,
you can update to the latest version now, and it should work
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
When starting WebSphere, I get this exception:
Could not instantiate bean class [org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter]:
Constructor threw exception; nested exception is java.lang.ClassCastException:
com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl incompatible with
javax.xml.transform.TransformerFactory
Caused by: java.lang.ClassCastException: com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl
incompatible with javax.xml.transform.TransformerFactory
at javax.xml.transform.TransformerFactory.newInstance(Unknown Source)
at org.springframework.http.converter.xml.AbstractXmlHttpMessageConverter.<init>(AbstractXmlHttpMessageConverter.java:47)
at org.springframework.http.converter.xml.SourceHttpMessageConverter.<init>(SourceHttpMessageConverter.java:45)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.<init>(AnnotationMethodHandlerAdapter.java:197)
This doesn't seem have any impact on any beans in my applicationContext.xml but it's still odd. For me, this looks as if IBM classes are leaking into my application.
How can I fix this? I already set the option "Access to internal server classes" to "Restrict".
It was indeed a class-loading issue, however this cannot be solved by changing class-loader settings.
The problem was that the xml-apis and javax.xml jars were being imported over some maven dependencies.
Since we already set the class loader policies for the application to PARENT_LAST, the javax.xml.transform.TransformerFactory was being loaded from the WebApp-Class loader from our jar files.
However its implementation 'com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl' was coming from the server class loader, this one was linked to the javax.xml.transform.TransformerFactory provided by the JDK/JRE.
Since the classes were loaded from different sources a ClassCastException was thrown.
Removing all dependencies to xml-apis / xerces / javax.xml jars solved the problem.
Since these APIs are now part of the JDK they no longer need to be imported.
... and if you wonder why I know so much about this issue: I work together with Aaron. ;)
I can't speak for Restrict as I have no personal experience with it,But I think the problem is more to do with IBM Class Loader. The class you are referring to is part of IBM Java implementation of TransformerFactory, I think you can try one of the following to solve this issue on hand
Either change the server class loader policy to PARENT_LAST (This way class loader will find the class from application's local class path, before going to up the chain all the way to java run time)
The other option would be look at the jaxp.properties file, I think it is located in (was_root\java\jre\lib), I only read about this option never actually used it
Why do you say IBM classes are leaking into your application?
The TransformerFactory is asked to create a newInstance. It follows a sequence of steps to determine which TransformerFactory to use. If none of the config is specified, it simply chooses to use the default factory.
Here is the javadoc for TransformerFactory:
http://download.oracle.com/javase/1.5.0/docs/api/javax/xml/transform/TransformerFactory.html#newInstance()
What is the OS ? Is that AIX?
http://www.ibm.com/developerworks/java/jdk/aix/j664/sdkguide.aix64.html
Looking at this doc (link above) for AIX it tells me that this is the default Impl:
javax.xml.transform.TransformerFactory
Selects the XSLT processor. Possible values are:
com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl
Use the XL TXE-J compiler. This value is the default.
Post back additional information so that we can try and troubleshoot this.
HTH
Manglu
I'm using Workshop for Weblogic and I'm testing an XQuery Transformation.
Both MFL and XSD are valid. But the XQuery doesn't seem to work... it gives me this error:
Error occurred while executing XQuery: loader constraint violation: when resolving method "javax.xml.stream.XMLInputFactory.createXMLStreamReader(Ljava/io/Reader;)Ljavax/xml/stream/XMLStreamReader;" the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current class, weblogic/xml/query/parsers/StAXCursorAdaptor, and the class loader (instance of ) for resolved class, javax/xml/stream/XMLInputFactory, have different Class objects for the type javax/xml/stream/XMLStreamReader used in the signature
Have you ever seen this before? How can I solve this please?
You need to reinstall workshop with default JRockit, or what is much faster just edit workshop.ini and change -vm parameter value from Sun/Oracle JDK to JRockit SDK which can be found in weblogic directory.