Andrew, thanks for your detailed reply! Your technique seems like the
cleanest and most portable. One thing that I'm not clear on is how you
would ever be able to access the broker service from an entirely different
ear. Is that allowed by the spec? But even if you could do that, wouldn't
you then have the issue of classloaders? For example, you retrieve a
collection of A's from app1.ear using app1 broker service. You try to
obtain an element from the collection: A thisA = (A)iterator.next() But the
cast fails because the class-loader for the A in the collection is the one
for app1.ear and your definition of A comes from app2.ear's class-loader.
This might not be a problem in JBoss due to its unified class-loading
architechture, but can this be counted on in other app servers?
This is really just an aside. I'm still using your method. But if I ever
have another ear, I think I'll simply give it its own PB service rather than
get into classloader issues.
Thanks again for your help!
Michael
----- Original Message -----
From: "Clute, Andrew" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Thursday, February 26, 2004 6:35 AM
Subject: RE: how to keep repository-user.xml mappings separate from ojb.sar?
Maybe I am missing something (wouldn't be the first time ;), but it
seems to be even easier than that.
Let me see if I can explain our situation, and see if that helps.
- We have a PersistenceService EJB (stateless) that has methods on it
like findObjectByQuery(), findCollectionByQuery(), storeObject(), etc --
these methods take, usually, a Criteria as a parameter
- Inside the EJB methods, we create an instance of a PersistenceSession
-- this is just a soft wrapper class that I wrote that abstracts OJB
away from our app (if I need to plug in another O/R tool) -- but it's
methods are an almost 1-to-1 mapping to PersistenceBrokers' methods. In
the constructor of our PS, we create the instance to PB, using the usual
method of getting a PB, not worrying about OJB being a service or an
EJB:
protected PersistenceBroker getBroker()
{
if (log.isDebugEnabled())
log.debug("getBroker was called");
if (this.connectionName == null
||
this.connectionName.equalsIgnoreCase("default"))
return
PersistenceBrokerFactory.defaultPersistenceBroker();
else
{
PBKey pbKey = new PBKey(this.connectionName);
return
PersistenceBrokerFactory.createPersistenceBroker(pbKey);
}
}
- So, any persistence call, is really just redirected into the EJB's VM
space, and OJB is used as if it were just a normal library of the EJB.
The true guts of OJB are not exposed to the clients. This makes it so
any application you have deployed *inside this ear* access the DAO's via
these methods on the PersistenceService EJB.
-Now this does mean that all of the DAO's, and the mapping files are
packages inside the EAR file, so in my case, the EAR is tied to those
mappings. But, in my reality, that is fine, since I only have one
Enterprise-level domain model. I only have a need for one set of
mappings. *Any* application I have, whether it is in this EAR file, or
on another machine, can access this one service via the PS EJB (and I
can still cluster this later on if I need too).
As for the EAR configuration, it looks like this (my EAR contains all of
my EJB's and DAO's also:
--EAR file
|
--EJB-JAR file (beans.jar)
|
-- DAO's
-- EJB classes and descriptors
--war file
-- repository.xml
-- repository_user.xml
-- OJB.properties
I hope this makes sense. I am sure I have not thought this through
completely, and missed something obvious, but this configuration works
great for us right now. It accomplished my goal of having one unified
Domain model, along with only one instance of OJB running, with one
cache -- that any of our applications in the Enterprise could access.
It does have some downsides -- since the DAO's passed out by the EJB can
be serialized if it is out of the VM, using any of the higher-level
API's with OJB doesn't buy you much -- they count on having references
to the object being worked on in the client. So, I went the opposite
route, and only use the PB-API, and always throw cloned objects back out
of the EJB. This ensures for me that my OJB-cache is always pristine.
But I do have to do some extra work for saving tree's, and deleting
objects inside collections, etc.
Let me know if this helps.
-Andrew
-----Original Message-----
From: Michael Mogley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 25, 2004 5:47 PM
To: OJB Users List
Subject: Re: how to keep repository-user.xml mappings separate from
ojb.sar?
Hi Andrew,
Yeah, using a SessionBean as a facade to the underlying DAOs is exactly
how I'm envisioning it. My only question is how to get access to the
broker in the first place. Are you using JNDI to get at the broker
factory? Or just calling the static getFactory method directly?
I would like to avoid using the sar since this does not seem portable,
but on the other hand, that IS the documented way in the howto.
It almost sounds like the PersistenceBrokerFactory is really like a
Datasource and the PersistenceBroker like a Connection - which would
seem to indicate OJB should be deployed as a rar. But would I then have
to put the DAOs/xml mappings into the rar as well? Or could keep them
as a separate jar in the ear?
It would be nice to have an abstract OJB service available to all apps,
with each app telling the service about its specific descriptors on
startup.
Am I really just making this way too complicated?
Incidentally, using different versions of OJB for different ears is not
a requirement. Also, dynamically unloading the app without restarting
the server isn't important to me either (I've heard that could be a
problem).
Would you mind giving a detailed directory structure of your ear?
Appreciate your help.
Michael
----- Original Message -----
From: "Clute, Andrew" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, February 25, 2004 10:47 AM
Subject: RE: how to keep repository-user.xml mappings separate from
ojb.sar?
There really is no reason to deploy OJB as a SAR (I would love to hear
from anyone else that can tell what a good use case would be deploying
it as a SAR).
Just create a facade EJB that will create your PersistenceBroker and do
your work find/save work there. Your client app's will not access the
broker, but instead the EJB's methods. In that case, your EAR will
contain your EJB-JAR's, probably with your DAO's, and then you can
include the repository files in the root of that EAR -- works like a
charm. You know have one self-contained application, with it's own OJB
'space'.
You can even leverage the EJB examples that OJB ships with as your
pass-through EJB.
Let me know if this answers your problem, or if you have more questions.
I have a current deployment that is doing exactly this right now.
BTW, yes, this means that each EAR has it's own OJB version -- but if
you have a unified data model, you really only want one Persistence
layer across an enterprise.
-Andrew
-----Original Message-----
From: Michael Mogley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 25, 2004 12:47 PM
To: OJB Users List
Subject: Re: how to keep repository-user.xml mappings separate from
ojb.sar?
Hi Armin,
So in this case, how would I access the broker? I assume through JNDI
somehow? Would I have to setup the PersistenceBrokerFactory as a
resource adaptor? How would I do that?
Michael
----- Original Message -----
From: "Armin Waibel" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, February 25, 2004 5:21 AM
Subject: Re: how to keep repository-user.xml mappings separate from
ojb.sar?
> Hi Michael,
>
> Michael Mogley wrote:
> > Hi all,
> >
> > I'm trying to deploy an application on JBoss 3.2.3 using latest OJB.
I've followed the steps to create an ojb.sar in the deployment dir.
> >
> > I would like to keep the xml mapping definitions and DAOs local to
the
specific .ear
> I'm deploying. Is this possible? Or must I keep all the mappings for
> all applications
> in one repository-user.xml in the ojb.sar?
> >
>
> Don't use .sar file in this case (AFAIK it's JBoss specific and shared
> among the deployed application), try to include all OJB jar (with used
> libraries) + beans in each application .ear file?
> (Don't ask for details ;-))
>
> regards,
> Armin
>
> > Thanks for any help/advice.
> >
> > Michael
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
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]
