aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Obtaining container information Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Obtaining container information" Watch "Obtaining container information" New topic
Author

Obtaining container information

JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Hi all,
Imagine I am a Java Class (POJO) used as a Helper in a J2EE application
(deployed onto a J2EE App Server)
Imagine this POJO class is sometimes used by an EJB, and sometime by a jsp.
Is it possible, from this POJO, to obtain information about the caller, that is to say, to discover at runtime whether the caller is a jsp/servlet or an EJB
I hope my question is clear...
TIA,


/ JeanLouis<br /><i>"software development has been, is, and will remain fundamentally hard" (Grady Booch)</i><br /> <br />Take a look at <a href="http://www.epfwiki.net/wikis/openup/" target="_blank" rel="nofollow">Agile OpenUP</a> in the Eclipse community
Michael D. Brown
Greenhorn

Joined: Nov 22, 2003
Posts: 29
Is it possible? Yes. Is it necessary, that is for you to determine. Why precisely do you want to know the kind of object calling your object? The solution could be as simple as requiring the caller to pass a reference to itself to the function and determining what kind of object it is from reflection.
A more complicated solution would be a stack trace.
But I am still curious to learn why you want this information. Maybe it's not necessary at all.
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Originally posted by Michael D. Brown:
Is it possible? Yes. Is it necessary, that is for you to determine. Why precisely do you want to know the kind of object calling your object? The solution could be as simple as requiring the caller to pass a reference to itself to the function and determining what kind of object it is from reflection.
A more complicated solution would be a stack trace.
But I am still curious to learn why you want this information. Maybe it's not necessary at all.

Thanks for this answer Mickael.
The first solution you mentioned (the caller pass a reference to itself) is not a solution for me. I don't want to change all my POJO' method signatures to add the caller.

A more complicated solution would be a stack trace.
Could you elaborate about this one.
And last, but not least... is it necessary to do that. Good question
I have no specific need. actually, it is just a technical question
Billybob Marshall
Ranch Hand

Joined: Jan 27, 2004
Posts: 202
Your footnote quoting Murphy's law sums it up. There's also another quote I see often which fits (which I may misquote a little):
For every problem with a simple solution there is also another solution which is complex, and wrong.
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Originally posted by Billybob Marshall:
Your footnote quoting Murphy's law sums it up. There's also another quote I see often which fits (which I may misquote a little):
For every problem with a simple solution there is also another solution which is complex, and wrong.

Ok Billibob. I agree there is a simple solution (obtaining the information through an argument). But I would like to know if there is another solution using the containers.
Then please, let me choose which is the good one and which one is the bad one according to what I have to do.
Just a little sample to explain the sense of my question
If I want to obtain the user logged in my EJB Container context, I have two solutions.
1 - Add the user credentieals to each method signature (yaaark !)
2 - context.getCallerPrincipal() (thus using the container)
Which one is the best solution according to you ??

With my servlet/EJB question, it is the same. If the container offers a possibility I am not aware of, I would be glad to learn and (maybe) use it .
If not, it is not that bad, I'm sure I'll survive.
Billybob Marshall
Ranch Hand

Joined: Jan 27, 2004
Posts: 202
Originally posted by Jean-Louis Marechaux:

Ok Billibob. I agree there is a simple solution (obtaining the information through an argument).

Where did I imply that was the solution?
Actually, what I meant to imply was that there really should be no reason for you to need to know what the calling class is. Get rid of this "requirement" (time for a re-design).
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Originally posted by Billybob Marshall:

Where did I imply that was the solution?
Actually, what I meant to imply was that there really should be no reason for you to need to know what the calling class is. Get rid of this "requirement" (time for a re-design).

Where did I imply that was a need for me
Please, don't get me wrong . This is just a technical question
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
A more complicated solution would be a stack trace.
Could you elaborate about this one.

I believe the idea was to purposefully create and throw an exception only to print out the stack trace into a String and then parse it to figure out the name of the class/method responsible for the call. Someone blogged about this just a couple of weeks ago, I think.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Originally posted by Lasse Koskela:

I believe the idea was to purposefully create and throw an exception only to print out the stack trace into a String and then parse it to figure out the name of the class/method responsible for the call. Someone blogged about this just a couple of weeks ago, I think.


Thanks Lasse. I see what you mean.
Well, I'm not sure it's a good idea.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Bloglines was down so I decided to play around with my brand new IDEA and put out my own implementation:

and the accompanying test code:
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Ok. Now I found the blog(s) I referred to.
First Cameron and then Cedric. Of course Cameron's implementation is a lot more feature rich, parsing .java source files and all...
Michael D. Brown
Greenhorn

Joined: Nov 22, 2003
Posts: 29
Actually,
I was just tossing out ideas for getting the calling object. I would prefer to know the reason for needing to know what the calling object is. If you wanted to just learn how to do it so you could if you needed to, those are two ways to do it.

Michael
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Originally posted by Lasse Koskela:
Ok. Now I found the blog(s) I referred to.
First Cameron and then Cedric. Of course Cameron's implementation is a lot more feature rich, parsing .java source files and all...


Thanks Lasse, your help was really useful, as usual.
We should organize Golden Globe Awards for the best bartender


PS : Did Cameron or Cedric explain why they tried to do that ??
[ February 23, 2004: Message edited by: Jean-Louis Marechaux ]
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Originally posted by Michael D. Brown:
Actually,
I was just tossing out ideas for getting the calling object. I would prefer to know the reason for needing to know what the calling object is. If you wanted to just learn how to do it so you could if you needed to, those are two ways to do it.
Michael


Yes Michael, I understand your point of view, bu thats was only a technical question. There is no specific need behind this.
Sorry if my post was not clear enough.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Obtaining container information