Use of Reflection in Bean

[Rajeev Gupta]

As per specification:
The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language. The enterprise bean must not attempt to use the Reflection API to access
information that the security rules of the Java programming language make unavailable.
----------------------------------------------------------------------------This means we are not allowed to use reflection API in a bean. Right?

[Philippe Maquet]

Hi Rajeev,
Yes, you're right. All that just means "Don't use the reflection API in a bean".
Now these two excerpts :
"that are not otherwise accessible to the enterprise bean because of the security rules of the Java language."
and
"to access information that the security rules of the Java programming language make unavailable."
let me think that the reflection API *could* be used to access public fields and methods (because the security rules of the Java language make them accessible). But I am not sure about it. Could anyone confirm ?
Anyway, for the exam, I just remembered "No Reflection API".
Regards,
Phil.

[Rajeev Gupta]

Hi Philippe
To a great extent you are right but in HF it is mentioned that getEJBMetaData method is not there in the EJBLocalHome interface because a bean can always take this information via Reflection API. This is the point which confused me. I hope some one can give clear picture of this.
Regards
Raj

[Weerawit Maneepongsawat]

I not sure but i think the MetaData Interface for the remote point of view to do but the local point of view can do reflect ...

i'm really not sure...

[David Harrigan]

Hi,
I've wrote this very very simple example that works with the RI of J2EE 1.3.1. As you can see, it appears to work.
First, the bean itself.

  
package info.harrigan;
import javax.ejb.*;
import java.rmi.RemoteException;
import java.util.ArrayList;
import java.lang.reflect.*;
public class TestBean implements SessionBean
{
    SessionContext myCtx;
    public TestBean()
    {
    }
    public void ejbCreate()
    {
    }
    public void ejbActivate()
    {
    }
    public void ejbPassivate()
    {
    }
    public void ejbRemove()
    {
    }
    public void setSessionContext(SessionContext ctx)
    {
        myCtx = ctx;
    }
    public ArrayList doReflectionOnDummy() throws ClassNotFoundException
    {
        ArrayList a = new ArrayList();
        Class c = Class.forName("info.harrigan.Dummy");
        Method m[] = c.getDeclaredMethods();
        for(int i = 0 ; i < m.length; i++)
        {
            a.add(m[i].toString());
        }
        return a;
    }
}

Secondly, the remote home and component interfaces

  
package info.harrigan;
import javax.ejb.*;
import java.rmi.RemoteException;
public interface TestHome extends EJBHome
{
    public Test create() throws CreateException, RemoteException;
}
package info.harrigan;
import javax.ejb.*;
import java.rmi.RemoteException;
import java.util.ArrayList;
public interface Test extends EJBObject
{
    public ArrayList doReflectionOnDummy() throws RemoteException, ClassNotFoundException;
}

Thirdly, the dummy class used to do some reflection on:

package info.harrigan;
public class Dummy
{
    public String doSomethingUseful(String aVariable)
    {
        return "A Useful bit of information";
    }
}

Finally, the client class:

import javax.naming.Context;
import javax.naming.InitialContext;
import java.rmi.RemoteException;
import javax.rmi.PortableRemoteObject;
import java.util.ArrayList;
import java.util.Iterator;
import info.harrigan.TestHome;
import info.harrigan.Test;
public class TestClient
{
    public static void main(String[] args)
    {
        new TestClient().doIt();
    }
    public void doIt()
    {
        try
        {
            Context ctx = new InitialContext();
            Object o = ctx.lookup("ejbreflection");
            TestHome home = (TestHome)PortableRemoteObject.narrow(o, TestHome.class);
            Test test = home.create();
            ArrayList a = test.doReflectionOnDummy();
            Iterator i = a.iterator();
            while(i.hasNext())
            {
                System.out.println("Method Name = " + (String)i.next());
            }
        }
        catch(ClassNotFoundException cnfe)
        {
            cnfe.printStackTrace();
        }
        catch(RemoteException re)
        {
            re.printStackTrace();
        }
        catch(Exception e)
        {
            e.printStackTrace();
        }
    }
}

I leave it to an exercise for the reader to adapt it for their own system and deploy.
Here are the results of running the client:

java -classpath "ejbreflectionClient.jar:$CLASSPATH" TestClient
Method Name = public java.lang.String info.harrigan.Dummy.doSomethingUseful(java.lang.String)

Now, as mentioned, this works on the RI of J2EE 1.3.1 from Sun. I don't know if other containers will allow this to work. Worth a try for anyone?
Hope this helps.
-=david=-
[ January 06, 2004: Message edited by: David Harrigan ]

[Philippe Maquet]

Hi David,
Thank you so much for that test !
Now what to conclude for sure from it ? I *really* don't know.
Reading the specs, I would have guessed that Class.getFields() would have worked (because it accesses *public* fields only), but not a method like Class.getDeclaredMethods()... Would be interesting to see what happens if you try to *execute* some returned method, though, because - after all - by just displaying method names, you didn't really transgressed any security rule, right ?
Interesting test anyway, and thank you again for it. Could you try what I suggested ? (starting from your existing code, it should take 2 minutes )
Best regards,
Phil.

[David Harrigan]

Hi,
Your wish is my command:
Modified Dummy class:

  
package info.harrigan;
public class Dummy
{
    public String doSomethingUseful(String aVariable)
    {
        return aVariable;
    }
}

Modified Bean class (notice that now I'm invoking the method)

  
package info.harrigan;
import javax.ejb.*;
import java.rmi.RemoteException;
import java.util.ArrayList;
import java.lang.reflect.*;
public class TestBean implements SessionBean
{
    SessionContext myCtx;
    public TestBean()
    {
    }
    public void ejbCreate()
    {
    }
    public void ejbActivate()
    {
    }
    public void ejbPassivate()
    {
    }
    public void ejbRemove()
    {
    }
    public void setSessionContext(SessionContext ctx)
    {
        myCtx = ctx;
    }
    public ArrayList doReflectionOnDummy() throws Exception
    {
        ArrayList a = new ArrayList();
        Class c = Class.forName("info.harrigan.Dummy");
        Method m[] = c.getDeclaredMethods();
        for(int i = 0 ; i < m.length; i++)
        {
            if(m[i].getName().equals("doSomethingUseful"))
            {
                a.add(m[i].getName() + " : " + m[i].invoke(c.newInstance(), new Object[] { "Fred" }));
            }
        }
        return a;
    }
}

Returned result:

  
java -classpath "$CLASSPATH%:ejbreflectionClient.jar" TestClient
doSomethingUseful : Fred

So, it appears that you *CAN* invoke methods from within a bean within a container using Reflection (at least in the RI J2EE).
Anyone want to try this for other containers?
-=david=-

[Magnus Stattin]

My understanding of this is that the restrictions in the spec should be viewed from another perspective. This is not things that will not work for sure, usually many of these things will work in reality. The restrictions are in the spec to give the container providers certain amount of freedom for how features are implemented.
For example you may not use static read/write field according to the spec. This gives the container the ability to use more than one VM in the implementation.
Another example that is the use of IO package. It is forbidden by the spec but as far as I know all containers will allow it.
The restrictions give the container provider the possibility to disallow things if they have reason to do it in their implementation. As bean providers we should avoid these things as far as possible to keep our solutions server independent.
For the certification this distiction doesn't matter as we only have to know what is forbidden. In reality some things will work if we try it, and some rules (as IO) can be broken if we have good reasons to and know what we are doing.
Here is a discussion about this at TheServerSide
This is just my opinion and would be nice to know yours.
/Best Regards
Magnus

[Philippe Maquet]

Hi David,
Thanks a lot !

Your wish is my command:

There was no command in my mind !
Now what to conclude ? At least that the J2EE RI allows you to use reflection. Obvious .
Your "Anyone want to try this for other containers?" is very interesting, though for the exam, we *know* what we must know : no introspection through the reflection API.
Now what happened here is not really surprising IMO : the EJB specs are all about contracts; you have many "must" and "must not" things for the Container, and many "must"/"must not" things for the Bean Provider. But you have no (or at least far less) things like "must ensure that the other part respects his own contract". Meaning that if the specs tell the Bean Provider "You must not use the Reflection API", it cannot be translated in "The Container must make sure the Bean Provider does not make use of the Reflection API".
Regards,
Phil.

[Philippe Maquet]

Hi Magnus,
Sorry, I had to interrupt myself to reply another message while replying to this one . So it looks like I just repeated what you wrote above. Not so bad BTW, it just means that we agree !
Best,
Phil.