Security Context is stored in a ThreadLocal map and is meaningless (non-existing) outside of constructor thread. Gene -----Original Message----- From: A mailing list for Enterprise JavaBeans development To: [EMAIL PROTECTED] Sent: 2/15/01 8:20 AM Subject: Re: Security principal lost when invoking EJB methodsfrom SwingGUI That's what we were doing already. Bascially, we have a single test class, Class1Client, whose constructor not only creates the InitialContext, but also looks up and stores the reference to the home interface of our test bean. The main() method then calls create() on the home interface to get the remote interface, makes a call on the remote interface, and the bean reports our security principle properly. The main() method next creates a new thread; the new thread calls create() on the home interface, followed by the bean method, and the bean again reports the correct principle. The main() method next creates a simple JFrame, adds a JButton to it, and calls show(). When the JButton is pressed, we again call create() on the home interface, followed by the method on the remote interface. This time, the bean reports our principle as guest. When the JFrame is dismissed, the main() method creates and makes one final call to the bean, and now our security principle is again reported correctly. I guess part of the question that I have is, if I looked up and stored the home interface for a bean using a particular security context, shouldn't that be the context which is used when I call home.create()? I suppose one thing we could try just to see what happens is to call home.create() outside of the Swing thread, store the remote interface, then start the JFrame and just call the remote interface method. Another point: someone had suggested that maybe the Swing thread was part of a different thread group, and that that was why it wasn't inheriting the security context. That also seems not to be the case. If we print out the name of the thread group, it is the same for all three of the threads that we are dealing with. Dale ================================ Dale V. Georg Technical Manager Indus Consultancy Services [EMAIL PROTECTED] (201) 261-3100 x229 ================================ Ian McCallion wrote: > > Just a wild guess, but perhaps you need to get the Initial Context before > starting up Swing in order to get it inherited by swing's threads? > > "Dale V. Georg" wrote: > > > > 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. > Ian McCallion > Alexis Systems Limited > Romsey, UK > ======================================================================== === 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". ======================================================================== === 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". =========================================================================== 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".
