just a quick idea, I don't know if it can work.
you could implement a little bean that just can get a PersistenceBorker instance.
You can then deploy the bean as global JNDI resource (quite easy in tomcat) that way you should be able to share OJB through several web-apps.
However as I said, I didn't tried it... bye danilo
Maybe not desperate, but frustrated. I do appreciate the quick reply.
I think it would be tragic for ojb not be sharable among webapps. There are times when multiple apps should be able to take advantage of the same mapping and associated caches. For instance, an admin app modifies some domain objects and all viewer apps are automatically synchronized by virtual of a shared cache.
Anyway, I think my problem might just be the defaultBroker call. I'll try it again by requesting a broker for a specific jcdalias.
Michael
----- Original Message ----- From: "Charles Anthony" <[EMAIL PROTECTED]>
To: "'OJB Users List'" <[EMAIL PROTECTED]>
Sent: Monday, December 08, 2003 11:31 PM
Subject: RE: ojb mixing up jdbc-connection-descriptors
I'm not sure; you seemed to be getting desperate, hence the quickly fired-off answer.
Actually, I'm fairly sure the answer is no - there is no way to keep OJB
as
a shared library between multiple webapps, but I'll defer to the
developers
to be categorical.
To follow up to the logical next question, I do not think it would be a trivial task to change OJB to support multiple webapps. But I could be wrong.
Cheers,
Charles.
-----Original Message----- From: Michael Mogley [mailto:[EMAIL PROTECTED] Sent: 09 December 2003 07:34 To: OJB Users List Subject: Re: ojb mixing up jdbc-connection-descriptors
You're probably right. But is there no way then to keep Ojb as a shared library?
Michael
----- Original Message ----- From: "Charles Anthony" <[EMAIL PROTECTED]>
To: "'OJB Users List'" <[EMAIL PROTECTED]>
Sent: Monday, December 08, 2003 11:23 PM
Subject: RE: ojb mixing up jdbc-connection-descriptors
I think you'll find that putting OJB in /common/lib is your problem.
Try putting the the OJB jars in the each webapps
WEB-INF/lib directory, and
see if the problem goes away. I think it will.
Cheers,
Charles.
-----Original Message----- From: Michael Mogley [mailto:[EMAIL PROTECTED] Sent: 09 December 2003 07:29 To: OJB Users List Subject: ojb mixing up jdbc-connection-descriptors
OK, I've got two Tomcat webapps. Each with it's own OJB.properties and repository xml files defining two different mappings and two different connection descriptors.
Ojb libraries are in common/lib to allow sharing among webapps.
Everything was working file until I added the second webapp.
Now, observing the logs, it seems the first webapp is getting the broker corresponding to the connection-descriptor in the second one. In both apps, I do PersistenceBroker.defaultBrokerInstance() to obtain the brokers. I tried giving each connection-descriptor a unique jcd-alias, but to no avail. Actually, that's how I discovered what the problem is.
How do I tell Ojb to reference the connection-descriptor defined for a specific webapp? This seems like a classloading issue. Perhaps, there is a place in the Ojb code without a needed Thread.getContextClassLoader() call?
Please help. I'm running out of time debugging Ojb issues.
Michael
___________________________________________________________ HPD Software Ltd. - Helping Business Finance Business Email terms and conditions: www.hpdsoftware.com/disclaimer
---------------------------------------------------------------------
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]
___________________________________________________________ HPD Software Ltd. - Helping Business Finance Business Email terms and conditions: www.hpdsoftware.com/disclaimer
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
