I guess the final answer to your question is that when deploying a bean, you
can't give it just any name you want. In JNDI, certain characters have
special meaning, and will ALWAYS be interpreted in a special way, whether
running in a J2EE server or not. The colon is one such character. Slash is
also a special character. Each slash in a JNDI name is interpreted as a
subcontext. For instance, if you deployed your bean under the name
"mybean/MyBeanHome," the following would work:
Context ctx = new InitialContext();
ctx = (Context) ctx.lookup("mybean");
HomeInterface myhome = (HomeInterface)ctx.lookup("MyBeanHome");
Clearly, the above would not work if the slach character did not have a
special meaning. If it were just interpreted "as-is", then you could ONLY
lookup the name "mybean/MyBeanHome," and there would be no notion of
subcontexts or anything.
Same story with the colon. There is no way to get a colon interpreted
"as-is" by JNDI, no matter what. In J2EE servers (like WebLogic) where the
java: namespace works for out-of-server clients, that is because they have
implemented a special javaURLContextFactory for use by the external client,
and perhaps they have a special root context that applies to java: as well.
Point is, there is no "easy" way to implement a java: namespace. It is most
certainly NOT just a matter of interpreting it just like any other string;
JNDI does not allow this.
Kevin Lewis wrote:
> I really appreciate your replies, Charles.
>
> > Whenever a JNDI name is prefixed with a string followed by a
> > colon, as in
> > "java:," the JNDI manager then tries to find a special naming context
> > factory associated with that name. The JNDI specification
> > does NOT allow
> > for names of this type to not be "interpreted in any way."
> > It should and
> > does matter that the name looks like a JNDI URL...it IS a
> > JNDI URL!!! The
> > jBoss naming server IS a JNDI provider, and is constrained by
> > the way JNDI
> > works.
>
> Right, but this is with respect to a deployed enterprise bean or
> servlet. In those cases, names are handled by a class called
> javaURLContextFactory provided by the container (as opposed to the
> server in which the container is executing).
>
> In my case, I'm not necessarily within a web container or an ejb
> container.
>
> > Even when looking up an ejb from outside the EJB container,
> > you are still
> > using JNDI. And the J2EE spec does not require "application
> > clients" as
> > they are called, to have any access to the "java:" namespace
> > from JNDI.
>
> Right. In fact, I would say that it's meaningless to give clients
> access to a special java: namespace since those name spaces are only
> meaningful (as far as I know) from the perspective of an enterprise bean
> or servlet.
>
> However, if I'm writing an application client, and I deploy a bean with
> an external JNDI name with java:, I don't think the server-provided
> context that holds that name should interpret it any differently than
> foo/bar.
>
> > I hope this clears things up. From looking at your email
> > below, it looks as
> > if you think that external clients are NOT using JNDI to look
> > up beans, when
> > they are. And the J2EE spec dictates that the "java:"
> > namespace only needs
> > to be valid from within the server itself.
>
> No, I realize that you are always using JNDI to lookup beans. I also
> understand that the java: name space (or java:comp/env) has a special
> meaning when inside a J2EE container.
>
> However, that namespace is different for each enterprise bean or each
> web container. I'm not expecting any of those things to be available to
> application clients.
>
> However, when I deploy a bean, I thought that I could give it any name I
> liked. In this case, it was java:comp/env/ejb/<name>. In this way, I
> can call things the same no matter what code I'm writing.
>
> I'll see if I can change my clients. It may not be a big deal. I'm
> just trying to understand this more full.
>
> You've been very helpful, Charles. Thank you for your time.
>
> -Kevin
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
