Ok, that is fine. The patch that I sent a few hours ago, assumes that you
define the provider url in jndi.properties, but it should be fairly simply
to modify the jnp server to stuff the local url into the context. I will
check that out tomorrow. In the mean time (before clustering is
available and the jnp server is patched) it should suffice to define the
provider url in jndi.properties no?
--jason
On Fri, 8 Dec 2000, Rickard �berg wrote:
> Hi!
>
> Jason Dillon wrote:
> > > The best solution would probably be to modify JNP to include provider
> > > URL in environment.
> > >
> > > Note that if you use JNP from within the JBoss JVM the provider URL
> > > *should* be null. It is only set if you use it from client JVM's.
> > >
> >
> > Given my current local modifications, if you specify the provider url in
> > jndi.properties it works just fine. My impl assumes that when I get an
> > InitialContext (with no enviroment) that it will contain enough information
> > to recreate the context.
> >
> > Is there any reason why a 'new InitialContext()' shouldn't contain
> > Context.PROVIDER_URL in its enviroment?
>
> PROVIDER_URL is only used by clients. On the server it is not needed. If
> the IC sess null as provider it is interpreted as "use the in-VM JNP
> provider". The reason is that the alternative ("localhost") is going to
> break things when we do clustering, since all JNDI providers will be on
> "localhost". And one of the design goals of the clustering is to allow
> multiple JBoss JVM's on one host. This is the primary reason for having
> null as PROVIDER_URL on the server.
>
> /Rickard
>
>
