RE: Weblogic, threads, and startup errors

[Bonnie MacKellar]

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

RE: Weblogic, threads, and startup errors

[Weaver, Scott]

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

RE: Weblogic, threads, and startup errors

[Bonnie MacKellar]

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

[Edson Carlos Ericksson Richter]

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

Re: Weblogic, threads, and startup errors

[Armin Waibel]

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




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Weblogic, threads, and startup errors

[Weaver, Scott]

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

RE: Weblogic, threads, and startup errors

[Bonnie MacKellar]

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

RE: Weblogic, threads, and startup errors

[Bonnie MacKellar]

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

Re: Weblogic, threads, and startup errors

[Edson Carlos Ericksson Richter]

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

RE: Weblogic, threads, and startup errors

[Bonnie MacKellar]

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