I don't know enough about JDO to know what the functionality you need really is, but I would envision that you'd want to store a generic "factory for creating JDO instances of arbitrary types" in the JNDI directory context, instead of creating a different JNDI resource factory for each type of JDO object that you might want (which is essentially how EJB references work in a J2EE app server).
Craig On Sat, 27 Jul 2002, Michael Delamere wrote: > Date: Sat, 27 Jul 2002 20:45:10 +0200 > From: Michael Delamere <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: JNDI thoughts... > > > Hi, > > I�m starting to think about the benifits of using JNDI in tomcat. One of > the benifits of using JNDI is to hide the objects location. This comes in > very useful when implementing ejbs in a seperate (or more) application > server(s). Maybe there is a misunderstanding on my side but I don�t see > these benifits when deploying my objects using tomcat. (No, EJBs is not an > option :-) ) > > I want to implement a service layer for making calls to my persistence layer > which is going to consist of JDOs. Ideally I would call the service layer > via JNDI. Rather like the session facade. The problem I�m having is that I > don�t see the benifits of using JNDI if I have to write every class which I > want to call into my object Factory. > > Am I not understanding JNDI correctly. Am I missing other major benifits > other than location transparency. > > This may seem clear to most of you but I would appreciate some clearing up > on this so that I can decide wether I�m going the right route. I.e. wether > it�s worth buildng up on JNDI for the purpose mentioned above. > > Thanks in advance, > > Regards Michael > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
