The problem is with the default environment naming context used by EJBs
looking up other EJBs deployed in the same instance of Orion, not with
Application clients looking up EJBs remotely. This default environment
naming context is obtained by using the default (parameterless) constructor
for javax.naming.InitialContext.
The problem is limited to such contexts instantiated by an EJB - web module
servlets within the same EAR have no problem finding our Session beans
properly - (new
InitialContext()).lookup("java:comp/env/ejb/ProducerServicesEJB") works just
fine in this case. Only when a Session EJB implementation attempts to find
other (Entity) EJBs does the NamingException get thrown.
I might be worth noting that the ATM sample that comes with Orion does the
lookups within the default environment naming context correctly - and in an
identical fashion to the way our app does it. The ATM sample app executes
fine within the same Orion install as our troubled app. This suggests
something unusual about our app is causing Orion not to bind things properly
in its JNDI implementation, but I remain completely stumped as to what this
cause might be.
P. Pontbriand
Canlink Interactive Technologies Inc.
----- Original Message -----
From: "shlomo" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Thursday, December 14, 2000 12:54 PM
Subject: RE: Inconsistent EJB JNDI Locations
> Hi ,
> Instead of using jndi.properties try using a Hash table with your full IP
:
> public static Context setJNDIEnv(String IP,String rmiType ,String user
> ,String pass,String j2eeName) throws javax.naming.NamingException
> {
> Hashtable env=new Hashtable();
>
>
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.evermind.server.rmi.RMIInitialC
> ontextFactory");
> env.put(Context.PROVIDER_URL, rmiType+"://"+ IP + "/"+ j2eeName);
> env.put(Context.SECURITY_PRINCIPAL, user);
> env.put(Context.SECURITY_CREDENTIALS,pass);
> return(new InitialContext(env) ) ;
> }
> :)
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Pontbriand
> Sent: Thursday, December 14, 2000 5:58 PM
> To: Orion-Interest
> Subject: Re: Inconsistent EJB JNDI Locations
>
>
> We haven't been using any jndi.properties file. We've always gotten our
> contexts from simply invoking the default constructor for
> javax.naming.InitialContext.
>
> Obviously some change in our code or DDs has caused Orion to change its
> behaviour, but we have no idea what, and cannot waste any more time trying
> to determine what.
>
> Unless anyone has a better idea, I guess we'll have to catch the
> NamingException thrown with
jndiContext.lookup("java:comp/env/ejb/whatever")
> and retry with jndiContext.lookup("whatever") everywhere we need a home
> interface - and live without a working <env-entry> implementation - while
> investigating other J2EE server offerings.
>
> P.Pontbriand
> Canlink Interactive Technologies Inc.
>
> ----- Original Message -----
> From: "Tim Endres" <[EMAIL PROTECTED]>
> To: "Orion-Interest" <[EMAIL PROTECTED]>
> Sent: Wednesday, December 13, 2000 9:50 PM
> Subject: Re: Inconsistent EJB JNDI Locations
>
>
> > Is it possible that your jndi.properties file has changed? From this
> posting,
> > and the other posting regarding <env-entry>'s, it sounds like your
getting
> an
> > InitialContext that is not correct. Could this happen if the factory
> specified
> > in jndi.properties changed?
> >
> > tim.
> >
> > > For quite some time, our Stateless Session EJBs have been finding the
> home
> > > interfaces for our Entity EJBs using "java:comp/env/ejb/whatever" in
the
> > > context lookup() invocation. Suddenly and for no apparent reason, we
now
> get
> > > a "javax.naming.NameNotFoundException" exception when doing so. The
> home
> > > interfaces are now to be found only if we specify "whatever" in the
> lookup()
> > > invocation, without the "java:comp/env" prefix. I've been rooting
around
> for
> > > an extremely long time now trying to ascertain exactly what it is that
> we
> > > might have done to cause this to happen without any luck. Our code has
> not
> > > changed in this regard, nor has the version of Orion we've been using
> > > (1.4.4).
> > >
> > > Any ideas as to what has happened?
> > >
> > > P.Pontbriand
> > > Canlink Interactive Technologies Inc.
> > >
> > >
> >
> >
> >
>
>
>
>
