Weblogic 10.3- NPE from RemoteBusinessIntfProxy.getTargetMethod

Question

I am migrating an application from oc4j to WLS 10.3. The application defines EJB3. From a j2se client, I do the following:
Hashtable env = new Hashtable();
env.put( Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory" );
env.put( Context.SECURITY_PRINCIPAL, "weblogic" );
env.put( Context.SECURITY_CREDENTIALS, "weblogic" );
env.put(Context.PROVIDER_URL, "t3://localhost:7001");
Context initial = new InitialContext(env);
MyEJBRemote remote = (MyEJBRemote) initial.lookup("simple/myejbRemote");
remote.open();
However, I got the following NPE exception in runtime:
java.lang.NullPointerException
at weblogic.ejb.container.internal.RemoteBusinessIntfProxy.getTargetMethod(RemoteBusinessIntfProxy.java:162)
at weblogic.ejb.container.internal.RemoteBusinessIntfProxy.invoke(RemoteBusinessIntfProxy.java:53)
at $Proxy0.open(Unknown Source)
at demo.client.j2se.JobRequestSubmitorClient.queryRequestSummary(JobRequestSubmitorClient.java:245)
What might be the cause? How can I turn on trace in client/server side to get more information. Any help are appreciated. Thanks.

Answer 1

Here are some notes from a related CR, CR305208, that given insight to a work-around. Also consider looking at the known/resolved issues in 10.0, which discuss this as well:
[http://edocs.bea.com/wls/docs100/issues/known_resolved.html#wp1169024]
DIAGNOSIS:
EJB using type variables on class level is not supported.
RESOLUTION:
Problem was solved with a code fix to support generic types, especially type
variables on class level.
CHANGED BEHAVIOR:
As a result of this change, generic types can be used for bean class and
business/component interface of EJB. For example, the following EJB can be
deployed and invoked successfully:
public interface RootI<T> {
public T getObject();
public void updateObject(T object);
Business interface:
@Remote
public interface StatelessI extends RootI<String> {
Bean class:
@Stateless
public class StatelessSample implements StatelessI {
public String getObject() {
return null;
public void updateObject(String object) {
RECOMMENDED STYLE
Please note, under current mechanism of EJB code generation, the recommended
style to use generic types, is to define super class/interface with type
variables and make bean class or business/component interface parameterize it
like the example above. The type variables declared directly on class level
of bean class or business interface/componnent interface will be erased,
which can be deployed successfully only when bean class parameterizes
business interface with the upper bounds of the type parameter and no other
generic information involved. As a good design, we suggest not to declare
type variable on class level of bean class or business/component interface
directly. For example, the following EJB is not legal for Weblogic generic
support:
Business interface:
@Remote
public interface StatelessI<T> {
Bean class:
@Stateless
public class StatelessSample implements StatelessI<String> {
public String getObject() {
return null;
public void updateObject(String object) {
Because the type variable "T" on StatelessI has no upper bound explicitly
declared, the upper bound is Object. So the bean class StatelessSample must
parameterize StatelessI with Object like following:
public class StatelessSample implements StatelessI<Object> {
public Object getObject() {
return null;
public void updateObject(Object object) {
KNOWN ISSUE:
And, there will be problem when meeting all following conditions:
1. The business interface doesn't extend java.rmi.Remote.
2. The invocation of method is via remote proxy through RMI remote
call, and no generated stub on client side. The local invocation within one
JVM will succeed.
3. The remote call is via t3 protocol, not iiop protocol.
4. The method in business interface has generic information. I.e.
method has type parameters or generic type like List<String> as parameter
type, etc.
WORKAROUND FOR KNOWN ISSUE
It will be ok when meeting any of the following conditions:
1. The business interface extends java.rmi.Remote.
2. Put the generated stub on client side when the invocation of method is via
remote proxy through RMI remote call. The local invocation within one
JVM will succeed as well.
3. The remote call is via iiop protocol, not t3 protocol.
4. The method in business interface has no generic information. It will be ok
if the method only has generic info declared on class level of business
interface, and the type variable is parameterized with raw
type. For example:
Interface RootI < T > {
public void hello (T t ) ;
public &lt; S extends Comparable &gt; S testComp ( T t , S s ) ;
//Business interface
Interface StatelessI extends RootI < String > {
Though business interface doesn't extend Remote, whatever through remote call
or local call, the invocation on StatelessI.hello(String) will be ok. But
remote invocation on StatelessI.testComp() will fail when no generated stub
on client side.
Release note text:
The general issue is covered in Dante EJB docs at
http://edocs.bea.com/wls/docs100/ejb30/implementing.html#wp1205541
Known and resolved issues: EJBs
http://edocs.bea.com/wls/docs100/issues/known_resolved.html#wp1131925
EJBs with generic information fail when all of the following conditions are
met:
The business interface doesn't extend java.rmi.Remote.
The invocation of method is via remote proxy through RMI remote call, and
there is no generated stub on client side. The local invocation within one
JVM will succeed.
The remote call is via t3 protocol, not iiop protocol.
The method in the business interface has generic information; that is, type
parameters or a generic type like List<String> as a parameter type.
Workaround or Solution:
Make sure you fulfill any of the following conditions:
Write your business interface to extend java.rmi.Remote.
Put the generated stub on the client side when the invocation of method is
via remote proxy through a RMI remote call. The local invocation within one
JVM will succeed as well.
Make the remote call via the iiop protocol, not the t3 protocol.
Either do not use generic information in the business interface method, or
use only generic information declared on the class level of the business
interface with the type variable parameterized with raw type. For example:
Interface RootI&lt;T&gt; {
public void hello(T t);
public &lt;S extends Comparable&gt; S testComp(T t, S s);
//Business interface
Interface StatelessI extends RootI&lt;String&gt;{
Though the business interface doesn't extend Remote, whether through remote
call or local call, the invocation on StatelessI.hello(String) will work. But
remote invocation on StatelessI.testComp() will fail when there is no
generated stub on the client side.