-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck,
On 10/15/2009 5:28 PM, Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Subject: Re: Can a JNDI resource be in a webapp's lib folder >> >> I think this is a reasonable desire, and I'm not sure why Tomcat's >> architecture does not allow this. Honestly, using the webapp's >> ClassLoader to create JNDI resources would make a lot of sense and >> fix at least one long-standing bug/resource leak when restarting >> webapps. > > Not sure if that's feasible without spec changes. The JNDI registry > is for the entire JVM Hmm... I didn't realize that. I didn't know that the servlet spec mandated JNDI behavior "above" the webapp level. > if resources reachable through it were under control of a webapp > classloader, they would be visible to but not usable by other > webapps. Definitely. > There may be ways to construct local (per-webapp) JNDI domains, but I > don't think there's anything like that in the spec. I find these notes in the servlet spec (2.5 S 14.2.2): " The developer uses [the resource-ref, resource-env-ref, service-ref, ejb-entry, ejb-ref, and ejb-local-ref] elements to describe certain objects that the Web application requires to be registered in the JNDI namespace in the Web container at runtime. " This implies to me that the JNDI resources are in "the container" and not just available to the webapp itself. :( "The JNDI namespace" is referred to as just the "/the/ JNDI namespace" (emphasis mine), so perhaps you are right that there is one global namespace, but that webapps are allowed to see only parts of it (for security, etc. reasons). Is this made more explicit anywhere else? Thanks, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrYjakACgkQ9CaO5/Lv0PDiBQCePr6THyKQzxAc4rvS/BkvL2Vg cuYAnjA/DvVNd0Hnz8zDIOdiJlZmgmR9 =hZfC -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
