openejb-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Problem between OpenEJB embedded threading model and Swing Threading model
Date Fri, 08 Aug 2008 00:42:15 GMT
We can certainly hack up something in this regard.

Quick question, what kind of security tracking would be good for you?   
I.e. are we talking concurrent users or one user at a time?

We've got some code in the openejb-client package that's pretty useful  
for switching to different modes of tracking the user and I was just  
thinking just the other day that it wouldn't be a bad idea to port it  
to the "server side" as well for embedded scenarios.

Also, I assume this is sort of wrapped up in the other two security  
related posts.  If not, let me now if there's something more specific  
I should be looking at there.

-David

On Aug 7, 2008, at 10:24 AM, Sami Jaber wrote:

> Hello all (once more :-)),
>
> After the deployments.ear property and the custom ObjectInputStream,  
> I have
> found another issue which is IMHO more annoying, maybe a structural  
> design
> problem that David will resolve for sure ;-).
> I have a pretty big Swing Application that relies on OpenEJB over a  
> remote
> mode (integration platform) and local mode (dev platform).
> After digging into the openejb source code (I find them really well  
> coded
> btw), it appear that over LocalInitialContextFactory, the user context
> (security, tx, ...) is hold on the ThreadLocal. Not sure but it  
> seems to be
> done in the ClientSecurity.java class thru this code :
>
> public static void login(String username, String password, boolean
> threadScoped) throws FailedLoginException {
>        Object clientIdentity = directAuthentication(username,  
> password,
> server);
>        if (threadScoped) {
>            threadClientIdentity.set(clientIdentity);
>        } else {
>            staticClientIdentity = clientIdentity;
>        }
>        identityResolver = new SimpleIdentityResolver();
>    }
>
> The problem is that with Swing Application (or any multi-threaded
> front-end), you cannot assume that the thread that initiates the new
> InitialContext() is the one that will be used to lookup. In my case  
> I have
> implemented (as every smart boy ;-)) a smart proxy pattern which  
> consist in
> keeping the context in a singleton and reusing it between calls. The  
> issue
> is that the lookup is made inside a Swing Action, the Event Thread
> Dispatcher raises a new Thread and all credential information are  
> lost.
> That's why in my previous message, I told you that I get randomly  
> "guest" as
> the getCallerPrincipal().
>
> The fix would have been to instantiate a new InitialContext for every
> lookup, but not only it kills the performance but you get also an  
> error
> message saying that you cannot assign twice the ThreadLocal.
>
> The last solution that works for me is to write that code for each  
> lookup,
> this is ugly but it does the job :
>
>  public static void setInitialContext()
>    {
>    try
>    {
>        context = new InitialContext(env);
>    }
>    catch (Exception e)
>    {
>        // if TLS exists Ignore the exception, otherwise, it will set  
> a new
> one in the current thread
>    }
>   }
>
> David ?
>
> Sami


Mime
View raw message