3

I have an EJB (EJB 2x) on a remote server. I have a stubs file which I use on my client to access the EJB methods.

My client runs on another host. It used to run under exactly the same server as the EJB it calls. But now I've deployed the client to a server from a different vendor and calling the EJB methods now throws a CORBA exception.

Does having the EJB stub file guarantee a successful access to EJB methods from any server? If there can be any limitations, what they could be?

I tried to debug the exception but it occurs somewhere inside the CORBA transport which is yoko for my particular client, and I was not able to get any meaningful info.

The 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)
Alexander Kulyakhtin
  • 47,782
  • 38
  • 107
  • 158
  • It could be a problem between the various ORBs, which client and server ORBs are you using? – Johnny Willemsen Jun 09 '17 at 06:49
  • @JohnnyWillemsen My EJB2 runs on WebSphere full profile and I'm trying to call its methods from WebSphere Liberty – Alexander Kulyakhtin Jun 09 '17 at 08:26
  • Not sure what happens, without details of the CORBA exception you get and some logging output probably nobody can help you here. – Johnny Willemsen Jun 09 '17 at 08:49
  • I was just asking if that kind of problem is possible and due to what. From your comment I gather it's possible, due to differences in CORBA implementations (I think WS full profile have a different implementation from the one Liberty has). I can accept your comment as the answer unless there will be any more detailed answers (unlikely). Thank you very much for your help. – Alexander Kulyakhtin Jun 09 '17 at 09:17
  • Could be different reasons, any information about the CORBA exception you get, there is a set of exceptions, each having different meanings – Johnny Willemsen Jun 09 '17 at 09:18
  • I have this exception: org.omg.CORBA.portable.UnknownException: originalEx: org.omg.CORBA.MARSHAL: encountered null wchar in wstring. There's also the same question at the IBM forum from me: https://www.ibm.com/developerworks/community/forums/html/topic?id=b99d5674-5ed2-47bb-a615-301b0ffcbd98 – Alexander Kulyakhtin Jun 09 '17 at 09:22
  • For each product you have to generate its own stubs based on your IDL. When you have change the client side you have to regenerate the stubs for the client using your IDL. The generated stubs contain the glue code between your client code and the ORB implementation, it is vendor specific, it could change with a version update. – Johnny Willemsen Jun 09 '17 at 09:55
  • So, if the client moved to another server the existing stubs jar may/will not work? And as I do not have the sources of that EJB I can not then regenerate it myself? The guy from the IBM seems to say the jar may remain the same. – Alexander Kulyakhtin Jun 09 '17 at 10:11
  • You have to regenerate your IDL at the moment you use a different client implementation. If you just move to a different server which uses the same version of the software no need to regenerate. Reading back it sounds you are now using a different server with a different software version, that shouldn't impact a client unless there are some bugs. Probably the best is to contact IBM, it are IBM products you are using. – Johnny Willemsen Jun 09 '17 at 10:49
  • Can you share the full stacktrace here? – kolossus Jun 12 '17 at 14:05
  • @kolossus I've added the stacktrace to the question – Alexander Kulyakhtin Jun 12 '17 at 15:37
  • Could you please check the response if it answers your questions? – Hash Jul 03 '17 at 10:50

1 Answers1

1

I've recently encountered a situation similar to this at a telco company, but on Weblogic and at the moment I am not able write POC for your exact problem.

Answer to the original questions

Does having the EJB stub file guarantee a successful access to EJB methods from any server?

The EJB stub itself is not a guarantee for anything. It is basically a proxy object that implements the required interface. Its responsibility is to serialize and de-serialize objects and call the RMI server with the byte stream and try map the response for you.

If there can be any limitations, what they could be?

Problems could arise in a wide range. The latest time I encountered one was an internal implementation change in the mentioned Weblogic. During the authentication a NullPointerException was thrown. All because inside the Weblogic instance they used the password which was not set, but with the previous versions it was working well. The solution was to add an empty String parameter in the InitialContext (Context.CREDENTIALS).

Also it is important to consider the network overhead as the two servers are on different machines now etc.

In most of the cases nowadays the stubs are generated at runtime so there is no need to create those statically (for example with rmic).

Additional stacktrace

It is hard to tell what exactly your problem could be (there should be a lot more log to determine), but I suspect a similar problem as it was in our case. Include a bit more from the log ahead and try to add more properties to the context if you can try those.

Hash
  • 4,647
  • 5
  • 21
  • 39