Reflection API...

[James Turner]

Hi Guys,

I have read in the EJB spec that an enterprise bean must not use the reflection API, but the fact that local home interfaces do not provide a EJBMetaData interface is because a bean can use reflection to get information about the other bean.

Isn't there a clash of reasioning here...?

I think i am missing something here. Any comments are greatly appreciated.

Thanx,

James.

[Yi Zou]

I think Reflection API is for EJB Container tool developement.
As for Bean Developer, better focus on business application instead of under the hood tweaking.

[Arun Krishnamoorthy]

I found this under the sun site (blueprints):

Why is there a restriction against using the Java Reflection APIs to obtain declared member information that the Java language security rules would not allow? Doesn't Java automatically enforce those rules?

Contrary to common belief, most of the Java Reflection API can be used from EJB components. For example, loadClass() and invoke() can both be used by enterprise beans. Only certain reflection methods are forbidden.


This restriction refers to the enabling of the security permission ReflectPermission. The suppressAccessChecks permission target name, when enabled, allows a class to use reflection to inspect, access, and modify protected and private members and methods in other classes. Obviously, if EJB components are using private or protected members or methods to manage sensitive information, this facility could be used to violate security mechanisms. Therefore, the EJB specification explicitly restricts usage of suppressAccessChecks, to prevent the security hole that would result. Denial of ReflectPermission is part of the standard security policy for an EJB container.

Hope this helps...

[James Turner]

Thank you both for your help...

That helps a lot.



Cheers!

James.