On Sat, 27 Jul 2002, Michael Delamere wrote:
> Date: Sat, 27 Jul 2002 21:36:08 +0200
> From: Michael Delamere <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: JNDI thoughts...
>
> Iīm not exactly sure what you mean by "arbitrary types". Do you know of a
> good tutorial explaining this concept? I donīt want to waste your time but
> could you just add a little bit more detail to the idea of using "arbitrary
> types".
>
> I really appreciate your help on this, thank you very much.
>
Let's take an arbitrary example by defining a mythical API, somewhat like
JavaMail, that lets you create objects like Folder, Message, and
Attachment. You want to use these APIs to write the user interface of a
webmail application. Furthermore, you want your application to work on
top of different imlementations of messages stores that might exist on
various mail servers. So, we'll follow the classic object oriented design
and and abstract the details of what it means to be a "folder" into a Java
interface, and use that in the webmail program. As long as someone writes
an implementation of these interfaces for mailserver "foo" (which stores
messages as individual files in folder directories, and mailserver "bar"
(which stores messages in an RDBMS), and mailserver "baz" (which uses JDO
for persistence), your webmail app can run against any of them with no
changes.
Being diligent students of good programming practices :-), we'll use the
factory design pattern to provide our webmail client a way to create new
business object instances. You could create a factory API for each kind
of object you need (FolderFactory, MessageFactory, AttachmentFactory) and
create a JNDI resource for each of them, but this turns out to be harder
for users to configure, because they need to pick the implementation of
each factory from the set of factories for the mailserver you are going to
talk to.
Something easier to use would be to go for the Abstract Factory design
pattern instead, and put all the factory create methods in a single
interface -- something like:
public interface MailStoreFactory {
public Folder createFolder();
public Message createMessage();
public Attachment createAttachment();
}
and build a single JNDI resource factory (implementing
javax.naming.spi.ObjectFactory) that creates a MailStoreFactory instance
for your application to use. Now, in your web.xml file, you declare a
resource reference to a MailStoreFactory, and configure your app server
appopriately to create the right one for which mailserver you're going to
talk to. That's done external to the WAR itself, so you don't have to
change it at all.
All I was suggesting is that it's easier to create and configure one JNDI
resource for the entire related set of resources, rather than the three
(in this case).
One pretty straightforward example of a JNDI resource factory, very
relevant to Tomcat users, is the one that Tomcat itself uses for
javax.sql.DataSource resources. For Tomcat 4.1.x, this comes from the
commons-dbcp package -- you can get a nightly build and the corresponding
soruces from:
http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-dbcp
The JNDI object factory class is BasicDataSourceFactory, which is what you
would configure with the <factory> parameter in <ResourceParams> -- except
that Tomcat knows this is the default resource factory classname.
The first time that your application asks for this resource, the factory
creates an instance of BasicDataSource and returns it. From then on, the
same BasicDataSource instance is returned every time (i.e. all uses of the
data source share the same connection pool).
Craig
> Regards,
>
> Michael
>
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: Saturday, July 27, 2002 9:05 PM
> Subject: Re: JNDI thoughts...
>
>
> > 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]>
> >
>
>
> --
> 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]>
