I think the reason that it works with other threads is that they are
created by the original thread with the InitialContext. Thus, they
end up in the same group, which may be enough to share the context.
The Swing thread, on the other hand, is in another group. This is
pure conjecture on my part.
One thing you might try is to have your Swing task run a thread that
you created. Thus, you would setup the thread to run, pass it into
your Swing.invokeLater() call, and join it within that call (I hope
that makes sense). I have no idea if this would work, but if the
context is tied to the thread, it should. Of course, the extra
threading is not desirable...
tim.
> Tim,
>
> That kind of makes sense, but you would think that if that were the
> case, just starting a new thread within the Java client would cause the
> same problem, and yet it doesn't. It only seems to lose the context
> when going to a Swing thread. Now maybe that just means that Swing is
> doing something funky with threads that causes this side-effect; it
> wouldn't really surprise me. And unfortunately, we can't get the
> InitialContext within the Swing thread ourselves because the reference
> implementation seems to ignore the SECURITY_PRINCIPLE and
> SECURITY_CREDENTIAL settings if you try to put them into the
> InitialContext yourself.
>
> Now, on the one hand, it's not too important to have this working on the
> reference implementation because no one's going to run the RI in a
> production environment. But on the other hand, we're trying to develop
> an app-server independent application, and to do so, we'd like to ensure
> that everything works the way it's supposed to against the RI. I mean,
> that's what it's there for, right? Not to mention the fact that it's a
> little disconcerting when the RI doesn't work the way it should! :)
>
> Dale
>
> ================================
> Dale V. Georg
> Technical Manager
> Indus Consultancy Services
> [EMAIL PROTECTED]
> (201) 261-3100 x229
> ================================
>
>
>
> Tim Endres wrote:
> >
> > I believe that many, if not most, EJB client applications will use the current
> > thread to identify the context that is used for authentication. I am not sure
> > how you fix this without getting your InitialContext inside the thread that
> > is accessing the server. Personally, I really hate this aspect of Swing.
> >
> > tim.
> >
> > > We have built a J2EE application with a Swing GUI Rich Client (using the
> > > J2EE
> > > Reference Implementation application client container). When we added
> > > security
> > > to the EJBs, we found that if you call an EJB from a Swing event handler
> > > the
> > > security context is lost and the EJB container believes you to be guest.
> > > However, if you make the call from the main method, or a separate thread
> > > started from the main method, the security principal is propagated
> > > correctly.
> > >
> > > The output and code is included below. If anyone has seen anything like
> > > this
> > > before and knows why it may be happening, or better yet, what we can do
> > > to make
> > > it stop happening, your help would be greatly appreciated.
> > >
> > > Regards,
> > > Brett Beaumont
> > > Dale V. Georg
> > >
> > > ================================
> > > Dale V. Georg
> > > Technical Manager
> > > Indus Consultancy Services
> > > [EMAIL PROTECTED]
> > > (201) 261-3100 x229
> > > ================================
>
> --
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
