Kyle,
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 and
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
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
lev.com> cc:
Subject: [EMAIL PROTECTED]:
DataSourceRealm and Context defined JNDI Resource]
08/01/2004 20:52
Please respond to
"Tomcat
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 <[EMAIL PROTECTED]> -----
Remy: I'm looking at two bugs (one of which I opened):
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16316
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24545
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
resource.
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
developers.
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.
Thanks.
----- End forwarded message -----
--
[EMAIL PROTECTED]
Some people have a way with words, while others... erm... thingy.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
