EJB call to varargs method failing from Java7 client - ejb-3.0

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

Related

Jersey Exception Java 1.8

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.

Ambiguity in method invocation..Jboss 6.4 throws IllegalArgumentException: argument type mismatch error

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.

Grails session-scoped Service throwing NotSerializable Exception

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.

ServiceLocatorImplBase.cs not found

When my WebAPI controller is called from a client, I run into the following errors:
ServiceLocatorImplBase.cs not found error
An exception of type 'Microsoft.Practices.ServiceLocation.ActivationException' occurred in Microsoft.Practices.ServiceLocation.dll but was not handled in user code
The WebAPI controllers use constructor injection to inject a repository dependency which should be resolved by StructureMap IoC. Interestingly, the same code runs fine on my another development machine. Here is my stack trace. Thanks for your help.
System.ArgumentNullException was unhandled by user code
HResult=-2147467261
Message=Value cannot be null.
Parameter name: httpContext
Source=System.Web
ParamName=httpContext
StackTrace:
at System.Web.HttpContextWrapper..ctor(HttpContext httpContext)
at WebApi2.DependencyResolution.StructureMapDependencyScope.get_HttpContext() in c:.........\WebApi2\DependencyResolution\StructureMapDependencyScope.cs:line 69
at WebApi2.DependencyResolution.StructureMapDependencyScope.get_CurrentNestedContainer() in c:.........\WebApi2\DependencyResolution\StructureMapDependencyScope.cs:line 55
at WebApi2.DependencyResolution.StructureMapDependencyScope.DisposeNestedContainer() in c:.........\WebApi2\DependencyResolution\StructureMapDependencyScope.cs:line 90
at WebApi2.DependencyResolution.StructureMapDependencyScope.Dispose() in c:.........\WebApi2\DependencyResolution\StructureMapDependencyScope.cs:line 85
at WebApi2.App_Start.StructuremapMvc.End() in c:.........\WebApi2\App_Start\StructuremapMvc.cs:line 44
Thanks for your reply. Both machines are running integrated mode. The error is really misleading and threw me off to a wrong track. I spent hours trying to find where this ServiceLocatorImplBase.cs resides. I happened to look into the deeply nested inner exceptions, and found that the inner most exception (5th level) complains some entities generated by POCO generator have no identity key. This is because I manually added the foreign key relationship among some entities with
public virtual RelatedEntity1 {get;set;}
public virtual RelatedEntity2 {get;set;}
without setting [key] attributes in the related entities. I am not sure if this can be fixed but the exception message should not lead people to the wrong track.
The problem you are running into is because you are attempting to resolve HttpContext at the point in time that the application is composed (typically done in the Application_Start event of Global.asax). HttpContext is part of the application's runtime state. It is null at the point in time when the application is being composed.
The reason why it seems to work in your development environment is likely because your development environment's application pool is running in classic mode. Most likely the other environments are (correctly) running in integrated mode. So, this is a design issue, not a problem with deployment as you might expect.
The solution is to use an Abstract Factory so you can defer instantiating of the HttpContextWrapper until runtime. Then you can inject the abstract factory rather than HttpContextWrapper into your services.
public interface IHttpContextFactory
{
HttpContextBase Create();
}
public class HttpContextFactory
: IHttpContextFactory
{
public HttpContextBase Create()
{
return new HttpContextWrapper(HttpContext.Current);
}
}
See this answer and this answer for a complete examples including usage.

JavaEE 6: javax.naming.NameAlreadyBoundException: Use rebind to override

I have a business interface being implemented by two EJBs.
UserManagementService
#Remote
public interface UserManagementService {
// ...
}
UserManagementServiceJpaImpl
#Stateless(name="userManagementServiceJpaImpl")
public class UserManagementServiceJpaImpl implements UserManagementService {
#EJB(beanName="userManagementDaoJpaImpl")
private UserManagementDao userManagementDao;
// ...
}
UserManagementServiceMockImpl
#Stateless(name="userManagementServiceMockImpl")
public class UserManagementServiceMockImpl implements UserManagementService {
#EJB(beanName="userManagementDaoMockImpl")
private UserManagementDao userManagementDao;
// ...
}
When I deploy the application to Glassfish 3.1 I get the following error:
java.lang.RuntimeException: Error while binding JNDI name com.transbinary.imdb.service.UserManagementService for EJB : userManagementServiceMockImpl
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1550)
at com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:202)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:167)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:290)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:101)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:249)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:145)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:577)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:463)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:395)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:380)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:213)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: javax.naming.NameAlreadyBoundException: Use rebind to override
at com.sun.enterprise.naming.impl.TransientContext.doBindOrRebind(TransientContext.java:333)
at com.sun.enterprise.naming.impl.TransientContext.bind(TransientContext.java:268)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.bind(SerialContextProviderImpl.java:98)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.bind(LocalSerialContextProviderImpl.java:99)
at com.sun.enterprise.naming.impl.SerialContext.bind(SerialContext.java:672)
at com.sun.enterprise.naming.impl.SerialContext.bind(SerialContext.java:689)
at javax.naming.InitialContext.bind(InitialContext.java:404)
at javax.naming.InitialContext.bind(InitialContext.java:404)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:208)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:189)
at com.sun.ejb.containers.BaseContainer$JndiInfo.publish(BaseContainer.java:5608)
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1535)
... 23 more
Could someone help me understand why am I getting this error and how to resolve it?
By default GlassFish Server specific default JNDI names are applied automatically for backward compatibility. So com.transbinary.imdb.service.UserManagementService is the the default JNDI name for both the implementations of UserManagementService interface. Which was why I was gettting javax.naming.NameAlreadyBoundException exception.
But because the EJB 3.1 specification defines portable EJB JNDI names, there is less need for GlassFish Server specific JNDI names.
To disable GlassFish Server specific JNDI names for an EJB module, set the value of disable-nonportable-jndi-names element to true. The default is false.
It solved the problem.
Resource: http://wikis.oracle.com/display/GlassFish/Developer+Handoff+to+QA+for+EJB-8+%28Option+to+disable+GlassFish-specific+JNDI%29
GlassFish restart. (It worked for me.)
I got this same exception.
In my case I changed my code from #Stateless(mappedName = "whatever") to instead be #Stateless(name = "whatever") and it solved my issue
Make use of rebind instead of bind and it should work
In my case, i was using JBoss5.1GA and i had two EJBs implementing a common local Business Interface...
I Follow the idea suggested by #Christo Smal, and it work for me.... Another Observation: I was deploying an ear which contains the two EJBs at two differents EJB jars; e.g:
Ear File:
* Jar File1: Containing EJB1
* Jar File2: Containing EJB2
* lib/dummy.jar: Library containing the Business Local interface

Resources