While I understand that J2EE spec has a standard way of getting
resources,(including I imagine other JNDI Contexts), I still think that this
approach should also be allowed for the following reasons:
1. It follows the JNDI Tutorial nicely (making it easy for new users to use);
2. It is backwards-compatible with non-J2EE sevlet engines (those that follow
the 2.1 spec for example). This is important in my case since that is what I am
currently using for my production environment.
3. It doesn't break J2EE or Servlet 2.3 compliance.
4. It wouldn't hurt anything. After all, just because OTHER projects don't allow
it doesn't mean Tomcat shouldn't :)
Arthur
[EMAIL PROTECTED] on 01/30/2001 06:35:39 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: (bcc: Arthur T Smyles)
Subject: Re: Custom ObjectFactory w\ Tomcat 4.0beta1
Quoting Arthur T Smyles <[EMAIL PROTECTED]>:
> 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.A
ppFactory");
>
> 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?
Using this doesn't work right now, but perhaps it could be fixed.
I fail to see how it could be useful anyway, since whatever happens :
- the reference format is server specific (the attributes name in the reference
is not something which is portable from one server to another)
- the reference definition format (for exemple how to specify the JDBC driver,
etc) is server specific
So having the object factory definition server specific too doesn't look like
it's a big problem to me.
All the other open source JNDI implementation I've checked (Tyrex, jBoss,
OpenJMS) :
- specify the object factory when they bind the reference
- don't allow plugging external object factories
- have custom reference attribute names
So the Catalina naming package is more flexible overall (although like the
others, it's proprietary).
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]
