directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: Tomcat uses JNDI to load resources, including JSP pages
Date Tue, 06 Jan 2004 14:28:04 GMT
>>>The DataSource resource I constructed doesn't come in via a 
>>>URL to the webapp and thus the servlet getResource() method 
>>>doesn't apply there. It's defined as a J2EE JNDI resource 
>>>found via the standard JNDI path "java:comp/env". Nothing 
>>>special is required to use it; all the magic is in the 
>>>factory class that I made available to Tomcat. And there's 
>>>not even a whole lot of magic there. You've seen the code, I 
>>>think. The whole thing's maybe 3-4 pages long at most.
> I'm not clued in to the entire problem space you're trying to solve, but the
> proposed DataSourceFactory certainly seems like a very reasonable way to create
> a DataSource resource from configuration data stored in an LDAP server.  If
> you're after portability, though, you've still got to deal with figuring out
> how to integrate custom JNDI ObjectFactory classes into any arbitrary app
> server, but Tomcat (at least) tries to make that task easy.

I agree that providing a resource factory that can create a DataSource 
from config data from LDAP makes a good addition to the naming component. 
  I am struggling a bit, however, on the issues of standardization / 
portability and scope for the naming service provider.  For JNDI data 
sources, both the objects created and the resource parameters are pretty 
standard, so there is (I think) big value in providing easy ways to grab 
the necessary parameters from "standard" representations (xml, LDAP, 
properties files, etc.) and make instances available via JNDI. This is 
more or less what we have the beginnings of now, with just one 
"configuration source" supported (simplified version of tomcat's 
server.xml) and tomcat's resource factories (datasource, mail session, 
ejb, "bean").

I see the responsibility of the naming service ending with the JNDI SPI, 
however.  Where it starts to get fuzzy for me is when we talk about 
integrating with app servers or changing the way that they acquire 
configuration parameters to provide to resource factories.

I need to study JSR-88, but from the notes here
it looks to me as though we (Directory, both ldap + naming) could provide 
the core persistence services (using LDAP, XML or "other") for the JSR-88 
SPI as well as JNDI services. It should be possible to do that just using 
the JNDI SPI to interact with the app server.  I guess where it gets fuzzy 
is in who loads the config data and what exactly do the resource factories 
provide. The second of these should be answered in the spec, so I guess I 
need to go read that :-)


> Craig McClanahan

View raw message