On Fri, 5 Apr 2002 [EMAIL PROTECTED] wrote:
>
> [snip]
> You can still choose to ignore it - or to use a different mechanism.
> Including JNDI - Craig may explain us if web.xml would allow
> us to define 'custom' resources ( besides JDBC drivers, etc ). If it
> does, then we automatically have another valid mechansim to get a Log in
> a servlet environment - pushed by the 'deployer' via JNDI and web.xml.
> Class.forName() also works.
>
There is such a mechanism, but the details might be container specific.
For Tomcat 4, there are some standard JNDI object factories supplied by
default, plus a generic factory that can wrap any JavaBean that is
configurable from bean property setters. If you want to create your own
factory, you just implement javax.naming.spi.ObjectFactory. An example of
this is BasicDataSourceFactory in commons-dbcp. Online docs for Tomcat
are available at:
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html
As a general rule, JNDI is the preferred resource discovery mechanism in
the J2EE application programming model. For example, if you stored a Log
instance in JNDI with Tomcat, under resource name "log/VelocityLog", you
would access it like this:
InitialContext ic = new InitialContext();
Log log = (Log) ic.lookup("java:comp/env/log/VelocityLog");
Conceptually, this is not a lot different from using a static factory
method, so the IoC advocates are still not going to like it :-). One
thing that makes it less painful is that the contents of the initial
context are dependent on the calling environment -- for example, each
webapp has their own InitialContext, populated only with the resources
defined in that app's web.xml file.
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
