Glenn Barnard wrote:
> Thank you for your prompt reply, Kenneth.....Unfortunately, it seems
> more JAR files may be needed plus additional configurations and/or
> resources.....
>
>
>
> My first attempt indicated that InitialContext would require
> com.sun.logging.LogDomain, so I found it in appserv-launch.jar and
> brought it over ....
>
>
>
> The next attempt complained that the resource bundle was missing:
>
Hi Glenn,
The reason there are additional .jars needed in this case is probably
because
you're copying the appserv-rt.jar/javaee.jar rather than referring to
them from
the glassfish/lib directory. appserv-rt.jar uses the .jar
MANIFEST-CLASSPATH
mechanism to include other .jars in the same directory, so when it's copied
those are not found. The easiest thing to do is configure your tomcat
classpath to refer to the .jars directly from the appserver lib
directory. If that's
not possible you'll need to copy some other .jars referred to by
appserv-rt.jar's
MANIFEST.MF. I was able to do an ejb30 remote reference lookup from
a servlet running in tomcat with the following .jars in
$TOMCAT_HOME/shared/lib :
$ ls
appserv-deployment-client.jar appserv-ext.jar appserv-rt.jar javaee.jar
--ken
>
>
> Caused by: _java.util.MissingResourceException_: Can't find
> com.sun.logging.enterprise.system.util.LogStrings bundle
>
>
>
>
>
>
>
> -----Original Message-----
> *From:* Kenneth.Saks_at_Sun.COM [mailto:Kenneth.Saks_at_Sun.COM]
> *Sent:* Monday, August 14, 2006 4:35 PM
> *To:* ejb_at_glassfish.dev.java.net; Glenn Barnard
> *Subject:* Re: Access to EJB's from Tomcat
>
>
>
> Glenn Barnard wrote:
>
> Following the guidelines for accessing an EJB 3.0 module from a
> standalone java application, I attempted to do the same from a Tomcat
> servlet. I got the following error:
>
>
>
> _javax.naming.NameNotFoundException_: Name <<CLASSNAME>> is not bound in this Context
>
>
>
>
>
> I have the requisite jar files (javaee.jar and appserv-rt.jar) in my
> application's lib directory. The statements I'm using are:
>
>>
>>
>> *try*
>>
>> {
>>
>> InitialContext ic = *new* InitialContext();
>>
>> << classRemote >> c = (<<classRemote>>)ic.lookup(<<classRemote>>.*class*.getName());
>>
>> }
>>
>> *catch* (NamingException e)
>>
>> {
>>
>> e.printStackTrace();
>>
>> }
>>
>>
>>
>>
>>
>> I'm assuming that the InitialContext requires parameters to cause it
>> to look outside Tomcat to find Glassfish, but I have not been able to
>> figure out what those parameters are.
>>
> Hi Glenn,
>
> Right, in a pure stand-alone client, the default JNDI naming provider
> for glassfish is
> bootstrapped from a jndi.properties file within our appserv-rt.jar.
> We do that so the
> application can just use the simpler no-arg InitialContext()
> constructor. However,
> many java web servers override the default naming provider for the JVM
> to be something
> different. In that case, you'll need to explicitly create an
> InitialContext(Hashtable)
> with a properties object containing the following properties :
>
> java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
> java.naming.factory.url.pkgs=com.sun.enterprise.naming
> java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl
>
> In addition, add a host property if tomcat is running on a different
> machine than
> the glassfish server and add a port property if you're using something
> other than
> the default orb/naming port (3700) in glassfish :
>
> org.omg.CORBA.ORBInitialHost=localhost
> org.omg.CORBA.ORBInitialPort=3700
>
> Finally, we recently fixed a bug
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=920
>
> involving this use-case so you'll need to
> grab a nightly build from the TRUNK from Aug. 11 or later.
>
> http://download.java.net/javaee5/trunk/installer-nightly/
>
>
>
>
>
>
>
>
>
> A little help would be greatly appreciated!!!!!!!!!
>
>
>
>
>