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]
> > > > >
> >
> >
