openejb-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sami Jaber" <sami.ja...@gmail.com>
Subject Problem between OpenEJB embedded threading model and Swing Threading model
Date Thu, 07 Aug 2008 17:24:55 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message