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?
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.
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
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.
Secondly, the remote home and component interfaces
Thirdly, the dummy class used to do some reflection on:
Finally, the client class:
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:
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 ]
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.
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
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.
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.
Please do not shoot the fish in this barrel. But you can shoot at this tiny ad: