Is it possible to pass data from web tier to ejb tier not as method parameter?

[brad kevin]

Hi all,

In our enterprise application there are Service tier (EJB3.0 including business logic and database access) and Web tier (Servlet/JSP). Seperated ear and war are deployed in JBoss AS 7 in distributed machines.

Service tier contains both Stateful and Stateless EJB.

We have EJB interceptor for methods invoking. For user that logged in from the Web tier the user info is saved in HttpSession (user validation is simply processed by query his account & password in DB).

Now the performance tuning needs to know which user has called those EJB methods, the user info, date info etc. These will be extracted and logged or stored in DB for our anylize.

Now my question is:

How to distinguish the caller's info in EJB tier?

The EJB interceptor can get the EJB method's parameters and when it's called. But we don't know who has called it.

We know it's ugly to combine EJB tier with Web tier. So we won't pass HttpSession/HttpRequest to EJB layer even that may help to get what we need from the Session/Request object.

And there are so many EJB methods that we can not pass an TuningInfo object (include request info, user info etc) as parameter from web to every EJB method.

Is it possible to get the caller's info in EJB tier?
Thanks in advance.

[Ranganathan Kaliyur Mannar]

Hi Brad,
Welcome to the Ranch!

When we create the InitialContext object to do a lookup to get an EJB, we would put the credentials inside the HashMap, like:

properties.put(Context.SECURITY_PRINCIPAL, "user");
properties.put(Context.SECURITY_CREDENTIALS, "password");
Context ctx = new InitialContext (properties);
bean = ctx.lookup(...);
bean.callmethod(); 

This would propogate the credential information automatically to the calls.
You can then get the credential inside the EJB from the EJBContext object via the getCallerPrincipal().

[brad kevin]

Thanks Ranga.

Good idea. It works for the first time initiation of the Stateless Bean, which is a member variable of our Actions (Struts 1.x).

We didn't create a new Stateless Bean each time when request comes, but reuse the member variable.

So when initiate it with JNDI and pass the user info in HttpSession, the Stateless Bean can get the user id from context.

But the next time when another user access the action and invoke the same method of the same bean in the action, the user info is different at that time.

And now invoking the context's method we'll still get the first user's id/name. So maybe we need create a new Stateless Bean for each request?

Then we need to modify many place for this change and maybe it will be slower than using it as a member variable.

[Ranganathan Kaliyur Mannar]

hmm...

There is a getUserPrincipal() method in HttpServletRequest too. I think this works with the login-config tag (where you have a login form with userid's field named 'j_username' and so on).
I am not sure if this is propagated to EJB calls too. But, if you are indeed using this method for authentication, then you can try and see if the propagation happens (in this case, you would just create the InitialContext without the credential properties).

[brad kevin]

Thanks Ranga.

Seems it's complexity in J2EE5 for this:) Maybe I should look through in 6.

Thanks again:)

[Tim Holloway]

You can obtain the Principal security object from the EJBContext using the getCallerPrincipal() method. If you are using the J2EE/JEE standard container security manager, the Principal will contain the userid.

If you invented your own security manager, instead, you're out of luck.

In any event, it sounds like you want to propagate a complex environment into many EJBs, so just knowing the user ID isn't enough - you'd have to obtain the associated metrics objects. Short of either replicating a lot of code or doing a lot of subclassing, about the best you can do is inject that object into each EJB that needs it.

[brad kevin]

Tim Holloway wrote:You can obtain the Principal security object from the EJBContext using the getCallerPrincipal() method. If you are using the J2EE/JEE standard container security manager, the Principal will contain the userid.

If you invented your own security manager, instead, you're out of luck.

In any event, it sounds like you want to propagate a complex environment into many EJBs, so just knowing the user ID isn't enough - you'd have to obtain the associated metrics objects. Short of either replicating a lot of code or doing a lot of subclassing, about the best you can do is inject that object into each EJB that needs it.

Yes we don't use the security system, just by db query. So getCallerPrinciple() just get 'anoymous'.

I'm trying to find clue for the injection into EJB, if it's complicated we may let this go:)

Thanks Tim:)

[Tim Holloway]

Probably the easiest way to get stuff injected is to use the Spring Framework.

I use this extensively to interconnect persistency mechanisms using JPA, but while JPA is based on EJB3, there are some differences. Spring is supposed to be OK with EJB3, but I've never put it to the ultimate test.