Thanks for you quick response. It has though brought about more questions. For
example, if I had the following code

Hashtable env=new Hashtable();
env.put("java.naming.factory.initial","com.sun.jndi.ldap.LdapCtxFactory");
env.put("java.naming.factory.object","crmg.tailgun.jndi.UserFactory:crmg.sysadmin.jndi.AppFactory");

env.put("java.naming.factory.state","crmg.tailgun.jndi.UserFactory:crmg.sysadmin.jndi.AppFactory");

etc...

DirContext root=new InitialDirContext(env);

According to the JNDI spec the object and state factories from this environment
should be added to the application resource properties and the system properties
 for this context. It should have no effect on any other contexts from any other
 applications.
By not following this convention, it forces me to do things in a Tomcat specific
 way.What are the issues that prevent Tomcat from following this convention?
Also, I took a look at org.apache.naming packages but I am unsure which classes
are affecting this?

Arthur





[EMAIL PROTECTED] on 01/30/2001 04:36:33 PM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:   (bcc: Arthur T Smyles)
Subject:  Re: Custom ObjectFactory w\ Tomcat 4.0beta1




> I developed an JNDI ObjectFactory that is used to read User Objects from
LDAP.
> When I run a test program and perform a lookup it works fine. But when I
use it
> within Tomcat 4.0 it ignores the java.naming.factory.object and
> java.naming.factory.state attributes that I am setting when creating the
> InitialContext. Does anyone have any ideas why these attributes are
getting
> ignored? Any help would be appreciated.

First of all, the object factories are not pluggable in b1 without modifying
some code in the naming.factory package (although the modifications are
quite simple). That has been added since then, and b2 will have pluggable
factories. However, it will not use the standard mechanism for a variety of
reasons (static mechanism - that's bad if like here you're supposed to have
isolated independant contexts -, not flexible enough, classloading issues,
...).

Instead, the reference is always processed through a set of proxy object
factories. In b2, you can use the "factory" parameter to specify a custom
store. This is done in server.xml like this :

          <ResourceParams name="jdbc/MyDataSource">

<parameter><name>factory</name><value>classname.of.the.object.factory</value
></parameter>
            <!-- Then add whatever other parameters your factory will
need -->
            <parameter><name>user</name><value>sa</value></parameter>
            <parameter><name>password</name><value></value></parameter>
            <parameter><name>driverClassName</name>
              <value>org.hsql.jdbcDriver</value></parameter>
            <parameter><name>driverName</name>
              <value>jdbc:HypersonicSQL:database</value></parameter>
          </ResourceParams>

Remy


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]








This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co. Incorporated, its
subsidiaries and affiliates.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to