Hey
Scott Seligman wrote:
> Rickard writes:
> There is no way for different component engines (e.g. servlet engine and
> EJB container) living in the same VM to implement the same JNDI
> namespace. When using URLContextFactories for lookup of "java:" URL's
> the JNDI NamingManager chooses one from a list, and always the first
> one, i.e. there is no way for multiple handlers, i.e. all component
> engines must come from same vendor.
> ...
> Pleeeease tell me I'm wrong 8-) What have I missed?
>
> One thing I suspect you have missed is that in JNDI 1.2, it is possible
> for different containers within a single VM to provide different
> implementations of the "java:" namespace. (This was not the case in
> JNDI 1.1.x.) This would be implemented by each container having its
> own JNDI application resource file specifying the URL context factory
> for its "java:" namespace.
Hm.. you say this will work, but I have decompiled the NamingManager and
found the following lines:
private static Object getURLObject(String string1, Object object1,
Name name, Context context, Hashtable hashtable)
throws NamingException
{
Object object2;
Object object3;
StringTokenizer stringTokenizer;
Object object4;
NamingException e3;
ObjectFactory objectFactory = null;
String string2 = new
StringBuffer(String.valueOf(string1)).append("URLContextFactory").toString();
String string3 = getPkgPrefixes(context, hashtable);
for (stringTokenizer = new StringTokenizer(string3, ":");
objectFactory == null && stringTokenizer.hasMoreTokens(); )
{
object2 = stringTokenizer.nextToken().trim();
object3 = "." + string1 + "." + string2;
if ((objectFactory =
(ObjectFactory)object_factories.get(object3)) == null)
{
try
{
objectFactory =
(ObjectFactory)helper.loadClass(object3).newInstance();
object_factories.put(object3, objectFactory);
}
catch (ClassNotFoundException e1)
{
}
catch ()
{
e3 = new NamingException(new StringBuffer("Cannot
get URL Context for ").append(string1).toString());
e3.setRootCause(object4);
throw e3;
}
catch ()
{
e3 = new NamingException(new StringBuffer("Cannot
get URL Context for ").append(string1).toString());
e3.setRootCause(object4);
throw e3;
}
catch (Exception e2)
{
}
}
}
if (objectFactory == null)
return null;
try
{
object2 = objectFactory.getObjectInstance(object1, name,
context, hashtable);
return object2; // RICKARD: No 'null' check!!! So if a
particular factory says "no, I'm not the one" (which it is allowed to do
by, according to the ObjectFactory docs, returning null.
}
catch ()
{
if (object3 instanceof NamingException)
throw (NamingException)object3;
}
object4 = new NamingException();
object4.setRootCause(object3);
throw object4;
}
-------------------
As you can see in the above commented code there is no way to have
multiple URL context factories as it will only use the (and this is odd
if anything) *last* one.
You will have to change the above to include some null checking before
it'll work.
Or what am I missing, since you say this works?
> Rickard writes:
> But never before has a JNDI context been dependent on who's calling,
> which is the case now.
>
> I can't say that I can think of a JNDI implementation that does this.
> Java's lack of the notion of a user (pre-JAAS) probably gets in the
> way somewhat. But I can give other relevant examples, such as ~ in
> the Unix C-shell. Or for a more obscure but more closely-related
> example, the names _myself, _thishost, and _myorgunit in XFN.
Uhm.. not very good examples IMHO. Aaanyway...
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
