This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Use of Reflection in Bean

 
Rajeev Gupta
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 203
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Your wish is my command:
Modified Dummy class:

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

Returned result:

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
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic