RE: Weblogic, threads, and startup errors
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
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.
> > >
> >
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 =
> >
Re: Weblogic, threads, and startup errors
Yes, I agree. You should try newer release...
I'm working in a muli-threaded app using swing, and no problem at all about
threads (I'm using cvs HEAD).
Edson Richter
- Original Message -
From: "Bonnie MacKellar" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Monday, July 07, 2003 6:00 PM
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
RE: Weblogic, threads, and startup errors
I absolutely think you are right. However, I am not
much of a Weblogic expert either, nor am I much
of an OJB expert :-(.
Trying to understand the interaction is very difficult.
I am really just hoping someone else has had (and
fixed) this problem. It must be pretty common, I would
think.
thanks,
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
> -Original Message-
> From: Armin Waibel [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 07, 2003 5:15 PM
> To: OJB Users List
> Subject: Re: Weblogic, threads, and startup errors
>
>
> Hi,
>
> I'm not an expert in web-environments, but this
> seems like a ClassLoader problem.
> The thread's ClassLoader try to initialize
> OJB again.
> Maybe you have to associate the new created
> thread with the 'right' ClassLoader using
> thread.setContextClassLoader(...)???
>
> Maybe I'm completely wrong ;-)
> regards,
> Armin
>
> - Original Message -
> From: "Bonnie MacKellar" <[EMAIL PROTECTED]>
> To: "OJB Users List" <[EMAIL PROTECTED]>
> Sent: Monday, July 07, 2003 10: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.
> >
> > 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
RE: Weblogic, threads, and startup errors
1) yes, they are in WEB-INF/classes
2) yes, it is in WEB-INF/lib
3) I will try this...
thanks,
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[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.
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 (Except
Re: Weblogic, threads, and startup errors
Hi,
I'm not an expert in web-environments, but this
seems like a ClassLoader problem.
The thread's ClassLoader try to initialize
OJB again.
Maybe you have to associate the new created
thread with the 'right' ClassLoader using
thread.setContextClassLoader(...)???
Maybe I'm completely wrong ;-)
regards,
Armin
- Original Message -
From: "Bonnie MacKellar" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Monday, July 07, 2003 10: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.
>
> 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 o
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.
>
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
> > Subje
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
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.
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]
>
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]
