Hi, I was out yesterday, so I just read this. This is an excellent explanation. When I encountered the problem, I very much suspected it was something like you were describing. But I was not sure, and in particular, I was not sure what the "right" fix might be.
Thanks! Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED] > -----Original Message----- > From: Weaver, Scott [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 08, 2003 10:29 AM > To: 'OJB Users List' > Subject: RE: Weblogic, threads, and startup errors > > > Hi Bonnie, > > Well classloaders, especially in servlet containers, are not > always the most predictable things. I am not sure if the > classloader of threads started from a web application is even > really covered in any length in the servlet specification. > So let's look at the javadocs of > Thread.getContextClassLoader() for an idea of how this > classloader craziness is supposed to work: > > "Returns the context ClassLoader for this Thread. The context > ClassLoader is provided by the creator of the thread for use > by code running in this thread when loading classes and > resources. If not set, the default is the ClassLoader context > of the parent Thread. The context ClassLoader of the > primordial thread is typically set to the class loader used > to load the application. > > First, if there is a security manager, and the caller's class > loader is not null and the caller's class loader is not the > same as or an ancestor of the context class loader for the > thread whose context class loader is being requested, then > the security manager's checkPermission method is called with > a RuntimePermission("getClassLoader") permission to see if > it's ok to get the context ClassLoader." > > > "If not set, the default is the ClassLoader context of the > parent Thread." > > Based on this statement on starting a new thread, you would > expect it's classloader to be the same as the parent > classloader of the thread it was started from. However, this > is obviously not the case within Weblogic. You would expect, > (hope), the a new thread started from a servlet would use the > webapp's classloader, i.e. the parent classloader that the > servlet is using. However, it is obvious that the > classloader given to new threads started within Weblogic is > not the same classloader as the one possessed by the servlet. > My guess is that new threads are using either the system of > the container or the primordial classloader rather than the > webapp's classloader. > > > So, based on the statement "The context ClassLoader is > provided by the creator of the thread for use by code running > in this thread when loading classes and resources." It is > probably a best practice to make sure you always set the > classloader of a new thread before starting. By using this > process you have guaranteed the behavior of the new thread's > classloader. > > In closing, my guess on what is currently happening is that > new threads are either using the system classloader of the > container or the primordial classloader rather than the > webapp's classloader. > > > > *===================================* > * Scott T Weaver������������������� * > * Jakarta Jetspeed Portal Project�� * > * [EMAIL PROTECTED] * > *===================================* > � > > > > -----Original Message----- > > From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] > > Sent: Monday, July 07, 2003 5:27 PM > > To: OJB Users List > > Subject: RE: Weblogic, threads, and startup errors > > > > This did the trick. Thank you! Now I just have to > > understand WHY it did the trick :-) > > > > Bonnie MacKellar > > software engineer > > Mobius Management Systems, Inc. > > [EMAIL PROTECTED] > > > > > > > -----Original Message----- > > > From: Weaver, Scott [mailto:[EMAIL PROTECTED] > > > Sent: Monday, July 07, 2003 5:23 PM > > > To: 'OJB Users List' > > > Subject: RE: Weblogic, threads, and startup errors > > > > > > > > > Actually, it should look like thisL > > > > > > ClassLoader cl = Thread.currentThread().getContextClassLoader(); > > > AccountUpdater myNewThread = new AccountUpdater(); > > > myNewThread.setContextClassLoader(cl); > > > myNewThreadStart.start(); > > > > > > *===================================* > > > * Scott T Weaver������������������� * > > > * Jakarta Jetspeed Portal Project�� * > > > * [EMAIL PROTECTED] * > > > *===================================* > > > > > > > > > > > > > -----Original Message----- > > > > From: Weaver, Scott [mailto:[EMAIL PROTECTED] > > > > Sent: Monday, July 07, 2003 5:21 PM > > > > To: 'OJB Users List' > > > > Subject: RE: Weblogic, threads, and startup errors > > > > > > > > Some simple questions: > > > > > > > > 1. Where do you have the OJB resources (OJB.properties, > > > repository.xml, > > > > etc.)? To make things easy, they should be in the default > > > package of your > > > > webapp's WEB-INF/classes directory. > > > > > > > > 2. Where is your OJB jar? For the most predictable > > > results, it should be > > > > in your webapp's WEB-INF/lib directory. I would discourage > > > loading OJB > > > > from shared or common lib locations within your container > > > as this might be > > > > a source of class loader errors. > > > > > > > > You may want to try setting the context classloader of your > > > new Thread > > > > with the context classloader of your servlet's current > > > thread and see if > > > > that helps. > > > > > > > > In your servlet try this... > > > > > > > > ClassLoader cl = Thread.currentThread().getContextClassLoader(); > > > > AccountUpdater myNewThread = new Thread(); > > > > myNewThread.setContextClassLoader(cl); > > > > myNewThreadStart.start(); > > > > > > > > *===================================* > > > > * Scott T Weaver������������������� * > > > > * Jakarta Jetspeed Portal Project�� * > > > > * [EMAIL PROTECTED] * > > > > *===================================* > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] > > > > > Sent: Monday, July 07, 2003 5:01 PM > > > > > To: OJB Users List > > > > > Subject: RE: Weblogic, threads, and startup errors > > > > > > > > > > You are right in your analysis, but in fact, the code I > > > just gave you is > > > > > newer code that > > > > > I put together to try to see if defaultPersistenceBroker > > > might be the > > > > > problem. My original code (which generated the exception) > > > looks exactly > > > > > like your code below!! > > > > > > > > > > The problem is more fundamental than this. It is > > > something to do with > > > > > the interaction of Weblogic, OJB startup code, and threading. > > > > > > > > > > Bonnie MacKellar > > > > > software engineer > > > > > Mobius Management Systems, Inc. > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Edson Carlos Ericksson Richter > > > > > > [mailto:[EMAIL PROTECTED] > > > > > > Sent: Monday, July 07, 2003 4:56 PM > > > > > > To: OJB Users List > > > > > > Subject: Re: Weblogic, threads, and startup errors > > > > > > > > > > > > > > > > > > I'm being analizing your code... Well, I get my broker using > > > > > > > > > > > > PersistenceBrokerFactory.defaultPersistenceBroker() > > > > > > > > > > > > Have you tried to work with defaultPersistenceBroker()? I > > > > > > know that in some > > > > > > release (I don't know what) things was changed in > the way OJB > > > > > > is getting the > > > > > > .xml based on this config... Then you can evolute to a > > > > > > createPersistenceBroker after this is working... > > > > > > > > > > > > Another point: you are declaring a object scoped broker in > > > > > > > > > > > > public class AccountUpdater extends Thread > > > > > > { > > > > > > private PersistenceBroker broker = null; > > > > > > > > > > > > but in the run method, you are not filling in > because you are > > > > > > declaring a > > > > > > new try scoped broker: > > > > > > > > > > > > PersistenceBroker broker = > > > > > > > > > PersistenceBrokerFactory.createPersistenceBroker(new > > > > > > PBKey("ActiveBill")); > > > > > > > > > > > > > > > > > > You can test making in the following way: > > > > > > > > > > > > public class AccountUpdater extends Thread > > > > > > { > > > > > > // private PersistenceBroker broker = null; // This line > > > > > > is being removed > > > > > > in favor of a parameter for retrieveAccountByNumber... > > > > > > > > > > > > public void run() > > > > > > { > > > > > > try > > > > > > { > > > > > > PersistenceBroker broker = > > > > > > > > > PersistenceBrokerFactory.defaultPersistenceBroker(); > > > > > > broker.beginTransaction(); > > > > > > AccountInterface acc = > > > > > > retrieveAccountByNumber(broker, "1234"); > > > > > > broker.commitTransaction(); > > > > > > } > > > > > > catch (Exception e) > > > > > > { > > > > > > broker.abortTransaction(); > > > > > > System.out.print(e.getMessage()); > > > > > > e.printStackTrace(); > > > > > > } > > > > > > finally { > > > > > > broker.close(); > > > > > > } > > > > > > } > > > > > > > > > > > > > > > > > > Don't forget to change the retrive... to use the > > > parameter you are > > > > > > sending... > > > > > > Another point that could you check is use rc3 or > download cvs > > > > > > HEAD to build > > > > > > a "near rc4" bin. They are far stable than previous > versions... > > > > > > > > > > > > My2c, > > > > > > > > > > > > Edson Richter > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Bonnie MacKellar" <[EMAIL PROTECTED]> > > > > > > To: "OJB Users List" <[EMAIL PROTECTED]> > > > > > > Sent: Monday, July 07, 2003 5:36 PM > > > > > > Subject: RE: Weblogic, threads, and startup errors > > > > > > > > > > > > > > > > > > Well, that is precisely why I was trying this - to > > > ensure that I have > > > > > > no brokers spanning threads. > > > > > > > > > > > > My code looks like this : > > > > > > > > > > > > public class AccountUpdater extends Thread > > > > > > { > > > > > > private PersistenceBroker broker = null; > > > > > > > > > > > > > > > > > > public void run() > > > > > > { > > > > > > try > > > > > > { > > > > > > PersistenceBroker broker = > > > > > > > > > PersistenceBrokerFactory.createPersistenceBroker(new > > > > > > PBKey("ActiveBill")); > > > > > > broker.beginTransaction(); > > > > > > AccountInterface acc = > > > retrieveAccountByNumber("1234"); > > > > > > broker.commitTransaction(); > > > > > > } > > > > > > catch (Exception e) > > > > > > { > > > > > > broker.abortTransaction(); > > > > > > System.out.print(e.getMessage()); > > > > > > e.printStackTrace(); > > > > > > } > > > > > > finally { > > > > > > broker.close(); > > > > > > } > > > > > > } > > > > > > > > > > > > The exception is thrown right at the createPersistenceBroker > > > > > > step. If I run > > > > > > this so that a new thread is not spawned, there is no > > > > > > problem. But if I > > > > > > spawn a thread and then call this code, I get the exception. > > > > > > > > > > > > The NULL error that you are having appear to me a problem to > > > > > > acquire the > > > > > > broker (read "not find the asked config"). Using > > > > > > defaultPersistenceBroker > > > > > > you will be acquiring the one defined in > > > > > > > > > > > > Again, I need to do this in order to avoid long > lived brokers. > > > > > > > > > > > > Bonnie MacKellar > > > > > > software engineer > > > > > > Mobius Management Systems, Inc. > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Edson Carlos Ericksson Richter > > > > > > > [mailto:[EMAIL PROTECTED] > > > > > > > Sent: Monday, July 07, 2003 4:30 PM > > > > > > > To: OJB Users List > > > > > > > Subject: Re: Weblogic, threads, and startup errors > > > > > > > > > > > > > > > > > > > > > I don't know about you, but I had all kind of > strange errors > > > > > > > working with > > > > > > > long time broker lives... > > > > > > > > > > > > > > Now, I'm working as in mnemonic code: > > > > > > > > > > > > > > public void xyzStore( XYZObject o ) { > > > > > > > broker = getBroker(); > > > > > > > > > > > > > > try { > > > > > > > broker.store( o ); > > > > > > > } catch() { > > > > > > > }finally { > > > > > > > broker.close(); // this guarantees no mistakes... > > > > > > > } > > > > > > > > > > > > > > } > > > > > > > > > > > > > > This guarantees that the broker object isn't spawned along > > > > > > > threads... And my > > > > > > > code works fine! > > > > > > > Since the brokers are maintained in a pool, there > is not pain > > > > > > > in performance > > > > > > > (AFAIK). > > > > > > > > > > > > > > > > > > > > > Edson Richter > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Bonnie MacKellar" <[EMAIL PROTECTED]> > > > > > > > To: "OJB Users List (E-mail)" <[EMAIL PROTECTED]> > > > > > > > Sent: Monday, July 07, 2003 5:20 PM > > > > > > > Subject: Weblogic, threads, and startup errors > > > > > > > > > > > > > > > > > > > > > I posted a question on Thursday about a > mysterious error I am > > > > > > > getting when I > > > > > > > try to obtain a broker in a thread spawned within my > > > > > > > application. It was not > > > > > > > answered, perhaps because of the holiday, or > perhaps because > > > > > > > no one else is > > > > > > > doing what we are doing. > > > > > > > > > > > > > > We are running a servlet based application in > Weblogic. I am > > > > > > > using rc2 at > > > > > > > the moment. As long as I obtain the broker in the main > > > > > > > thread, there is no > > > > > > > problem. But if I spawn a new thread and try to obtain the > > > > > > > broker, I was > > > > > > > getting obvious classpath problems - OJB.properties not > > > > > > > found, and so forth. > > > > > > > > > > > > > > I explicitly placed the classpath info for the app in my > > > > > > > Weblogic startup > > > > > > > file (not good, but I will try anything right now). Doing > > > > > > > this, it does find > > > > > > > the OJB.properties file, but now I get another odd error : > > > > > > > > > > > > > > [BOOT] ERROR: The specified class > > > > > > > > "org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl" does > > > > > > > not implement > > > > > > > the interface > > > org.apache.ojb.broker.cache.ObjectCache, which is a > > > > > > > requirement for the key "ObjectCacheClass". Using > > > default class > > > > > > > org.apache.ojb.broker.cache.ObjectCacheDefaultImpl > > > > > > > java.lang.NullPointerException > > > > > > > at > dbtests.AccountUpdater.run(AccountUpdater.java:68) > > > > > > > > > > > > > > Has anybody ever encountered this error before? Obviously, > > > > > > > something goes > > > > > > > hideously wrong with the configuration of OJB once threads > > > > > > > get into the > > > > > > > picture, but what? And again, I do not have this > problem as > > > > > > > long as the code > > > > > > > to obtain the broker is situated in the main thread. > > > > > > > > > > > > > > thanks, > > > > > > > Bonnie MacKellar > > > > > > > software engineer > > > > > > > Mobius Management Systems, Inc. > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > Outgoing mail is certified Virus Free. > > > > > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > > > > > Version: 6.0.497 / Virus Database: 296 - Release > > > Date: 4/7/2003 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > Outgoing mail is certified Virus Free. > > > > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > > > > Version: 6.0.497 / Virus Database: 296 - Release > Date: 4/7/2003 > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > >
