Hi Chris
I am afraid I cannot answer most of your questions (!) but I am writing in
because a couple of my earlier postings did not make it through to this mail
list, and it looks like my original question remained unanswered.
The question was answered, and here it is again, for the record.
Basically, my initial concern on this thread was with the 'resource-ref'
element in the deployment descriptor.
As a reminder, this is what the resource-ref element looks like in the
deployment descriptor:
<resource-ref>
<description>My DB DataSource</description>
<res-ref-name>jdbc/postgres</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
My understanding is that Tomcat creates a 'data-source' object and somewhere
along the line wraps it up as a 'javax.sql.DataSource' object, so that when
I get an 'Object' reference to the data-source object I can safely cast it
to 'javax.sql.DataSource', like this:
return ( DataSource )new InitialContext().
lookup( "java:comp/env/jdbc/postgres" );
The suggestion is that another servlet container (Weblogic, etc.) would hand
over some *other* type of data-source object, unless I explicitly inform the
container that I need a 'javax.sql.DataSource' type by including the
'resource-ref' element in my deployment descriptor.
IOW, the 'resource-ref' element in the deployment descriptor is an insurance
policy - it is not, strictly speaking, needed with Tomcat version 5, but
that might not be true with future versions of Tomcat, and likely not to be
true with other servlet containers.
So the 'resource-ref' element is recommended for portability.
I hope that helps!
For the record, my thanks to Yoav Shapira for putting me straight on this.
Kind regards
Harry Mantheakis
London, UK
> All,
>
> I was just about to ask a question like this thread's today... glad I
> read the archives. ;)
>
> I have an intersting observation in Tomcat 4.1.29. I found that my
> resource-ref was misnamed in web.xml, so I decided to check it out. A
> long time ago, I wrote a quick-and-dirty JNDI browser to help me figure
> out these things.
>
> Using my JNDI browser, and looking at the path "java:/comp/env/jdbc" I
> find the following entries:
>
> * DSMstandard, class = org.apache.naming.ResourceLinkRef
> * diagnosis, class = org.apache.commons.dbcp.BasicDataSource
>
> (I have two DataSources configured -- I have to deal w/two DBs, so
> they're both there).
>
> It's odd that one of them shows up as a ResourceLinkRef and the other as
> a BasicDataSource. (I have no resource-ref elements in my web.xml, for
> testing). They were defined the same way in server.xml:
>
> <GlobalNamingResources>
> <Resource name="jdbc/diagnosis"
> auth="Container"
> type="javax.sql.DataSource"/>
> <Resource name="jdbc/DSMstandard"
> auth="Container"
> type="javax.sql.DataSource"/>
>
> (I'll spare you the details of the ResourceParams, but they are
> identical except for the name used).
> </GlobalNamingResources>
>
> N.B.: I have my <Resource> declaration in <GlobalNamingResources>
> because I need to use it for my Realm. Apparently, Resources defined
> within a Context that will use it as a Realm don't work well -- at least
> this was my experience. I found that putting the resource in the global
> resources and then using a ResourceLink did the trick.
>
> Then, later, within the <Context> that will be using these, I had to add
> these:
>
> <ResourceLink name="jdbc/diagnosis"
> global="jdbc/diagnosis"
> type="javax.sql.DataSource" />
>
> <ResourceLink name="jdbc/DSMstandard"
> global="jdbc/DSMstandard"
> type="javax.sql.DataSource" />
>
> Why wouldn't I get both BasicDataSource objects, or both ResourceLinkRef
> objects?
>
> I thought it may have to do with the fact that I have the same name for
> the global reference and the local reference, so I changed the global
> references to "jdbc/[dbname]-global" and re-started. I got the exact
> same stuff in that JNDI context.
>
> Can anyone explain what's going on?
>
> Logically, I would expect the following:
>
> 1. <Resource> elements in the <GlobalNamingResources> would show up for
> all Contexts. If this is true, then why do I need <ResourceLink> in my
> context?
>
> 2. <ResourceLink> elements in a <Context> "grant" access to a
> globally-defined resource to that particular Context. Makes sense --
> maybe you have a global resource for convenience, but it's a security
> issue to grant that resource to *any* webapp running on the server. So,
> if this is true, why don't I get two objects of type ResourceLinkRef in
> my context's JNDI namespace? Instead, I get one DataSource and one
> ResourceLinkRef.
>
> 3. <resource-ref> elements in web.xml should map the local name of a
> resource (the one you use from your webapp in JNDI lookups) to the
> resource mentioned in the Context's <ResourceLink> element.
>
> So, if all that's true, then here's what happens:
>
> <Resource> defines the canonical name for the resource. <ResourceLink>
> grants the resource to a particular webapp, possibly re-naming it in the
> process. (This should produce a ResourceLinkRef object in the JNDI
> namespace as seen by the webapp). <resource-ref> adds a 'local'
> reference name to a resource provided by the container. This should add
> another ResourceLinkRef (or something similar) to the JNDI namespace as
> seen by the webapp.
>
> Can someone comment on my logic, and show me where I'm making incorrect
> assumptions or missing some crucial detail?
>
> Thanks so much for helping me beat a dead horse. I really want to know
> what's going on. I'm *not* in a position where something's not working,
> so examples for getting things working aren't a ton of help (they pop up
> on the list often, and are in both Tomcat 4.x and 5.x JNDI HOWTOs).
>
> Thanks,
> -chris
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
