Thank you _VERY_ much for taking time in explaining it to me in more detail.
I�ve actually managed to get a very basic factory working and I think now
with your input I should be able to manage the rest!
Thank you very much,
regards,
Michael
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Sunday, July 28, 2002 12:30 AM
Subject: Re: JNDI thoughts...
>
>
> 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]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
