You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Chris Francis <ch...@static2358.com> on 2000/09/21 15:59:08 UTC

EJB problems

I realize this isn't directly to do with this list but someone might know
and I am using SOAP!! 

I have a bunch of EJB's published to an Oracle 8i application server. When
running the program as an application all is well:
i.e; the lookup returns an instance of the home interface, I create the EJB
reference from there and start calling methods. 
Good.
However this is supposed to run in a servlet; I'm creating the bean instance
as the result of a SOAP call. This is when I get
the following exception...

javax.naming.NoInitialContextException: Need to specify class name in
environment or system property, or as an
 applet parameter, or in an application resource file:
java.naming.factory.initial
        at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:649)
        at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:242)
        at
javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:279)
        at javax.naming.InitialContext.lookup(InitialContext.java:349)
        at mypackage.services.Service.lookup(Service.java:111)

All the packages that I have in my application environment
(JBuilder/JDeveloper) are entered on the Servlet runner (JRun) classpath, 
I'm thinking this is actually too much and the servlet runner doesn't need
to know about it all. But what!?! There is tons of 
crap on the classpath. I'll give more details if anyone needs them.

Thanks,

Chris.



Re: EJB problems

Posted by Rich Johns <rj...@vignette.com>.
where is your jndi.properties file? If the VM that your service is
running in is not the same as the AppServer's then it's likely that
the properties are not yet set. Thus, a call to 'new InitialContext()'
is going to look for a jndi.properties file on the classpath.

So, what servlet engine are you using? Is it the app server's
or something like tomcat. Again, if it is the app server's then
it's possible that servlet engine and app server are in the same vm.

If the servlet engine is in a different vm, then it will need to have
the jndi properties of your app server.

I hope I haven't totally misunderstood your problem or told
you something you already know.

hope this helps.

Chris Francis wrote:

> I realize this isn't directly to do with this list but someone might know
> and I am using SOAP!!
>
> I have a bunch of EJB's published to an Oracle 8i application server. When
> running the program as an application all is well:
> i.e; the lookup returns an instance of the home interface, I create the EJB
> reference from there and start calling methods.
> Good.
> However this is supposed to run in a servlet; I'm creating the bean instance
> as the result of a SOAP call. This is when I get
> the following exception...
>
> javax.naming.NoInitialContextException: Need to specify class name in
> environment or system property, or as an
>  applet parameter, or in an application resource file:
> java.naming.factory.initial
>         at
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:649)
>         at
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:242)
>         at
> javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:279)
>         at javax.naming.InitialContext.lookup(InitialContext.java:349)
>         at mypackage.services.Service.lookup(Service.java:111)
>
> All the packages that I have in my application environment
> (JBuilder/JDeveloper) are entered on the Servlet runner (JRun) classpath,
> I'm thinking this is actually too much and the servlet runner doesn't need
> to know about it all. But what!?! There is tons of
> crap on the classpath. I'll give more details if anyone needs them.
>
> Thanks,
>
> Chris.


Re: EJB problems

Posted by Rich Johns <rj...@vignette.com>.
where is your jndi.properties file? If the VM that your service is
running in is not the same as the AppServer's then it's likely that
the properties are not yet set. Thus, a call to 'new InitialContext()'
is going to look for a jndi.properties file on the classpath.

So, what servlet engine are you using? Is it the app server's
or something like tomcat. Again, if it is the app server's then
it's possible that servlet engine and app server are in the same vm.

If the servlet engine is in a different vm, then it will need to have
the jndi properties of your app server.

I hope I haven't totally misunderstood your problem or told
you something you already know.

hope this helps.

Chris Francis wrote:

> I realize this isn't directly to do with this list but someone might know
> and I am using SOAP!!
>
> I have a bunch of EJB's published to an Oracle 8i application server. When
> running the program as an application all is well:
> i.e; the lookup returns an instance of the home interface, I create the EJB
> reference from there and start calling methods.
> Good.
> However this is supposed to run in a servlet; I'm creating the bean instance
> as the result of a SOAP call. This is when I get
> the following exception...
>
> javax.naming.NoInitialContextException: Need to specify class name in
> environment or system property, or as an
>  applet parameter, or in an application resource file:
> java.naming.factory.initial
>         at
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:649)
>         at
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:242)
>         at
> javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:279)
>         at javax.naming.InitialContext.lookup(InitialContext.java:349)
>         at mypackage.services.Service.lookup(Service.java:111)
>
> All the packages that I have in my application environment
> (JBuilder/JDeveloper) are entered on the Servlet runner (JRun) classpath,
> I'm thinking this is actually too much and the servlet runner doesn't need
> to know about it all. But what!?! There is tons of
> crap on the classpath. I'll give more details if anyone needs them.
>
> Thanks,
>
> Chris.