tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Cassidy" <>
Subject Re: [ DataSourceRealm and Context defined JNDI Resource]
Date Fri, 09 Jan 2004 08:57:21 GMT


I agree with you on this.

I'd like to draw a parallel with the classloader and how it treats the classes in the common
area and classes in a webapp.

(please correct me if I'm wrong)

If I put a class (database driver etc) in the common/lib area tomcat can use it *and* my web
app can.
Direct parallel :
I can define a resource in globalresources and use tomcat can use it for the global realm
my web app can use it for its context based realm.

If I put a class in my webapps lib area My webapp can use it but tomcat cannot see it.

If I define a resource at the context level why can't my web app use it for a realm ?

I seems a little inconsistent to me. But if I'm missing the point please please tell me why

(The only thing I can think of is if you are making a global realm the code doing the lookup
will need to restrict its search to just the global resources rather than using the initial
context as well.
but ... ?? )

Kind regards

David Cassidy

                      Kyle VanderBeek                                                    
                      <kylev-jakarta@ky        To:
            >                 cc:                                    
                                               Subject:  [ DataSourceRealm
and Context defined JNDI Resource]                                  
                      08/01/2004 20:52                                                   
                      Please respond to                                                  
                      Developers List"                                                   

I'm re-forwarding this message to the list for (hopefully) discussion.
I sent this the first time as 5.0 was going final, so people where very
busy.  I get very regular personal questions about this topic as people
cull the list archives and find me.  Also, I think I've seen two more
bugs on the same issue opened and closed (INVALID/WONTFIX) recently.

People (myself included) *really* don't understand why a Context-local
JNDI Datasource isn't reasonable.

----- Forwarded message from Kyle VanderBeek <> -----

Remy: I'm looking at two bugs (one of which I opened):

And it seems to have confused several people that DataSourceRealm can't
use a JNDI Resource defined in a Context but must instead use a global

The matters that confuse are that 1) an administrator can define a
Resource at the Context level and 2) a Realm is defined at a Context
level.  It seems to follow from these observations that a Realm should
be able to use a JNDI Resource defined at the same level.  This is
possible with the small patch I submitted on bug 24545 (from my work
address).  It seems to work fine (contrary to your 2003-6-12 remark on
bug 16316).

In addition, this seems like a very useful functionality.  Several
people have brought up the security concern of placing their user
database in a global JNDI resource.  I also brought up the idea of
turnkey applications that could be deployed using a DataSourceRealm
without having to ask the client to make modifications to their
server.xml: drop the context fragment and the .war in the right place
and you're done.

I've gotten emails about this expected functionality (related to my bug)
and really don't have anything to tell people.  Remy, I'd like to
understand why you've so quickly closed these bugs WONTFIX.  I don't see
the issue.  If there is a design problem with this, I'd like to know
what it is.  I was hoping for a dialogue from you and the other

In the end, maybe this is just an enhancement request.  Regardless, it's
probably good to get this (and hopefully a series of well-formed
responses) in the archive.


----- End forwarded message -----

  Some people have a way with words, while others... erm... thingy.

To unsubscribe, e-mail:
For additional commands, e-mail:


This e-mail may contain confidential and/or privileged information. If you are not the intended
recipient (or have received this e-mail in error) please notify the sender immediately and
destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message