Sharing data across multiple EJBs using Context

Question

With Glassfish realms and Context I can use UserPrincipal.getName()and isUserInRole methods to retrieve information about the logged in user.

However, I need to share more data across the EJBs, e.g. information about the user I can get through database or LDAP (such as name, domain, etc...).

I'm not asking about how to retrieve this information, but I've been spending hours to find a good way to pass it across all the EJBs called in the Session/Request. I've read about EJBContext.getContextData(), but it seems that this property isn't propagated, and I can't use the stored values outside of the EJB that stored them. I've also read about implementing my own UserPrincipal, but I don't have a clue about how to do it for Glassfish, and keep using the glassfish default realm configurations.

I don't want to modify my EJBs signature to pass the information, but I can't think of another way of doing it properly.

Do you have any ideas?

Answer 1

Since you're using Glassfish you can use JASPIC which is the Java EE standard for passing credential data across layers. Writing the JASPIC adapter itself isn't too hard, it is generally a simple layer unless you're implementing OpenID Connect Authentication like I did as you generally will only be using what is provided by JAVA EE7 API and no other support libraries.

Answer 2

At first glance, and without looking at your code, maybe you can use interceptors, your requirements sounds like AOP (you can inject resources in the interceptors like the SessionContext). So, you catch the method and do some magic before and after executed the method.

If that is not enough, other idea that comes to my mind is using CDI producers, you create a method that produces an Object with the info that you need and at some point you can inject it as a dependency in your EJB's:

e.g : http://java.dzone.com/articles/cdi-di-p1

Answer 3

This isn't really possible. If you're only using local calls, you could use a ThreadLocal, but be sure to remove it when the call completes to avoid leaking memory on pooled threads. If you're using remote, I'm not aware of any solution other solution than modifying the method signature.