On Wed, Sep 2, 2009 at 1:22 AM, Martin Gainty<mgai...@hotmail.com> wrote:
>
> the fellow who wrote it was writing code for at least 2 other projects
> it may have been a case of where he accomplished 75% of what was needed then
> some other task got moved to his front burner
I hear you, we've all been there a couple of times I think ;)
> still it is *unusual* that web.xml resource-ref is'nt read
I remember digging up some more of that unusual stuff in the Tomcat
source, like the null java:comp/UserTransaction that's inserted by
Tomcat into JNDI (might have some use, but the code wasn't clear about
this) and several of the Java EE injection annotations that were
handled in code but all different ones ended up doing exactly the same
thing.
Anyway, I have to say that the entire resource-ref element in web.xml
has been poorly understood and documented anyway. Just by itself the
element doesn't really do anything. The way I now understand this
element to work is that it's some sort of hint to the container
processing the deployment descriptor that it should go looking for a
magical (vendor specific) mapping of the resource name declared by the
resource-ref element to some global resource somewhere.
E.g.
web.xml
<resource-ref>
<res-ref-name>jdbc/myDs</res-ref-name>
Container now goes looking for a vendor specific mapping file, that
resides within the web module (.war) or is at least directly
associated with the web module, that contains a mapping of what
"jdbc/myDs" should resolve to.
So, there might be a separate file myvendor.xml containing:
<Resource-mapping res-ref-name="jdbc/myDs" maps-to-name="java:somectx/someDS" />
The effect of this line would be that java:comp/jdbc/myDs becomes a
link to java:somectx/someDS. Of course, you still have to define
java:somectx/someDS somewhere, which happens in yet another vendor
specific file, say resources.xml:
<Resource name="somectx/someDS" url="..." etc/>
To me this seems overly silly. If the myvendor.xml file is local to
the web module anyway, then the container implementation can just read
and process this directly without needing the hint in web.xml that it
should process this. In the end, all we want is an entry in JDNI. It's
interesting to note that there's an element with the same name
(resource-ref) and mostly same attributes in the EJB deployment
descriptor. Only there it does make sense, since it has this little
extra attribute that the web version lacks: mappedName. mappedName
does exactly what this intermediate mapping file in the web container
does; linking a local JDNI name to a global JNDI name.
The entire idea of declaring a dependency, which the vendor should
then magically resolve to a specific intermediate mapping file is just
vague and confusing. Maybe I misunderstood, but I think I have spent
more time in trying to understand this element than the average
programmer does, so I wonder whether this average programmer has any
idea of the exact use of this element.
As in EJB3, resource-ref should be truly optional; if you want your
code to use the global names, don't use it. If you want an extra
indirection mechanism for the JNDI names, use it. If you use it, let
the mapping of local to global names be specified directly in the
resource-ref element and don't require some awkward vendor specific
mapping file.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
