Questions on Java Reflection in EJB

Hi,
Recently, I use reflection technology on EJB to get/set properties of a bean.
We need it because we need to encapsulate data in a map to transfer data between
presentation layer and business back end(i.e. the so-called value data object).
A bean is packed into a map as following:
The property name of a bean becomes the key in the map, and its value becomes the
corresponding value in the map.
So we have to do two things:
1)Given a bean, convert it to a map;
2)Given a data map, assign the value to a bean

It would be nice if we can implement the two requirements in a base class. So I use
reflection. And succeed to achieve the goal.
But there are two problems occured and I can't understand why.
1)If I use Class.forName() to load the entity bean implementation class(BMP or CMP abstract
schema) I got a ClassNotFoundException. A workaround is to jar the BMP or CMP bean class
and place it on the classpath.
So, I want to know why there is such restriction.
2)For the classes java.lang.reflect.Method, java.lang.reflect.InvocationTargetException
I reference to in bean class, the IDE(I use IntelliJ Idea) give me a
warning: "Use java.lang.reflect.Method are not allowed in EJB". Are the methods really
dangerous in EJB environment?

Can anyone explain me these pluzzles?
Thank you in advance!

BTW, I develop under weblogic 7.0. Now, my program functions well, I just can't understand
the above phenomena.

Regards,
Justine

3 comments
Comment actions Permalink

Hi,

"justine" wrote ...

1)If I use Class.forName() to load the entity bean implementation

class(BMP or CMP abstract

schema) I got a ClassNotFoundException. A workaround is to jar the BMP

or CMP bean class

and place it on the classpath.
So, I want to know why there is such restriction.


But why to you try to load the entity bean implementation class?
Normally it is shielded from the developer with container-created
implementation of corresponding interfaces, that delegate responsibilities
to the implementation class behind the curtain.
If you need to know properties set at runtime, you could use reflection
against the interface "class" (I think it is the best solution at such
reflection-based situation), or reflection/introspection against the
container-provided implementation (that is probably less appropriate since
you need to get an instance of auto-implemented class before).

2)For the classes java.lang.reflect.Method,

java.lang.reflect.InvocationTargetException

I reference to in bean class, the IDE(I use IntelliJ Idea) give me a
warning: "Use java.lang.reflect.Method are not allowed in EJB". Are

the methods really

dangerous in EJB environment?


EJB specification states:
"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."
But IMHO it is not a reason to restrict reflection usages at all.
I'd be glad to participate in resolving of this issue.

regards,
/Roman
JetBrains




0
Comment actions Permalink

Hi,Roman
Thank you very much for you explanation.
I have to load the bean class because our reflect framework supports so-called delegation: use the special key to access the properties of a field whose type is just
another entity bean local interface. Consider the example:
Employee have a department field. And Entity Department have name, code properties. Given a Employee entity we need to access its department's name, code. We call this access mode delegation.
To achieve this goal, the key used to access the a property of a given bean begins with the entity(or model) name. And we have a .properties file to describe the meta info of this entity. In short, the key should looks like
XXX_YYYY where XXX is the entity name and YYYY is the field name. In the above Employee-Department example it looks Department_name, Department_code.
To judge if delegation happens, we check the key passed in, get the entity name, figure out the fully qualified class name of the bean class by lookup the entity meta info config file. Then load the class and compare it against the current bean class:

  • Class cl = Class.forName(beanClassName);

if (!cl.isAssignableFrom(this.getClass())) {
} *++
This is why I have to load the bean class.

Regards,
justine

0
Comment actions Permalink

Use thread local classloader not sysytem classloader

0

Please sign in to leave a comment.