Does the EJB secure the remote EJB for any client?
I have an EJB (EJB 2x) on a remote server. I have a stub file that I use on my client to access EJB methods.
My client is running on a different host. It was running under the same server as the EJB. But now I deployed a client to a server from a different vendor and calling EJB methods now throws a CORBA exception.
Does the EJB stub file successfully access EJB methods from any server? If there can be any restrictions, what can they be?
I tried to debug the exception, but it is happening somewhere inside the CORBA transport, which is yoko for my particular client, and I was unable to get any meaningful information.
In stacktrace I have:
org.omg.CORBA.portable.UnknownException: originalEx: org.omg.CORBA.MARSHAL: encountered null wchar in wstring: vmcid: Apache minor code: 0x15 completed: No: vmcid: 0x0 minor code: 0x0 completed: Maybe
at org.apache.yoko.rmi.impl.ValueDescriptor.readSerializable(ValueDescriptor.java:747)
at org.apache.yoko.rmi.impl.ValueDescriptor.readValue(ValueDescriptor.java:726)
at org.apache.yoko.rmi.impl.ValueDescriptor.readValue(ValueDescriptor.java:584)
at org.apache.yoko.rmi.impl.ValueHandlerImpl.readValue0(ValueHandlerImpl.java:114)
source to share
I recently ran into a situation similar to this in a telco but in Weblogic and at the moment I cannot write a POC for your specific problem.
Answer to original questions
Does the EJB stub file successfully access EJB methods from any server?
The EJB itself is not collateral. It is basically a proxy object that implements the required interface. Its responsibility is to serialize and de-serialize objects and invoke an RMI server with a stream of bytes and try to map the response for you.
If there can be any restrictions, what can they be?
Problems can arise in a wide range. The last time I ran into this was a change to the internal implementation of the mentioned Weblogic. A was dropped during authentication NullPointerException
. This is because inside the Weblogic instance they used a password that was not set, but it worked well with previous versions. The solution was to add an empty parameter String
to InitialContext
( Context.CREDENTIALS
).
It is also important to consider the network overhead since the two servers are on different machines, etc.
In most cases nowadays, stubs are generated at runtime, so there is no need to create them statically (eg with rmic
).
Additional stacktrace
It's hard to say exactly what the problem might be (there is much more log to be defined), but I suspect the problem is similar to the one in our case. Include a little more from the log forward and try adding additional properties to context if you can try them.
source to share