Hi Armin, > Hi Michael, > > > 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. > > you are right, but this doesn't mean it is best practice ;-) > When I started writing the ejb-examples my first priority was to make it > work in some way.
Understood. > I would appreciate any help to rewrite the jboss deployment, > ejb-examples section - Michael, Andy? ;-) If I succeed in getting this to work in a portable modular way, I would be happy to rewrite that section. > > 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. > > yes, some time ago Matthew started to write a JCA implemention and I do > locally too. But it isn't as simple as it seems (but it's on the roadmap > for 1.1 without guarantee). I will look into this. Perhaps, it's not so complex. On the JCA, could you or Matthew give me what you have so far? So I don't have to start from scratch. Cheers, Michael > regards, > Armin > > Michael Mogley wrote: > > > 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]
