[john]

I’m using Eclipse Build id: 6.0.1-GA-200710 (“all in one”) with Glassfish 2.x and Derby started properly on a Vista platform (installation details at bottom).
My simple app tries to do…

String LocalJNDIName =  CalcLocal.class.getSimpleName() + "/local";
  CalcLocal bean = ( CalcLocal) ctx.lookup( LocalJNDIName); 

the lookup throws this exception. (The name passed to lookup is CalcLocal/local ).

javax.naming.NameNotFoundException
    at com.sun.enterprise.naming.TransientContext.resolveContext(TransientContext.java:255)
    at com.sun.enterprise.naming.TransientContext.lookup(TransientContext.java:178)

The tutorial said that the appserv-rt.jar would allow this to work “automatically and retrieve our bean with almost no effort”. But it’s not working for me. Anyway, I need to know how to make it work in general, not just the example module (which I renamed Calc here).
Everything ( ICalc.class_deploy, etc. look fine) appears deployed properly to my jar under my glassfish/demains/kickstyle.net/autodeploy/.autodeploystatus/ejb3/myeclipseide/com

I don’t see any jndi.properties files, no app*.xml, and no config files that might be needed for JNDI to find the deployed class.
* What are the necessary JNDI config files, and properties for this? Documentation?
Maybe we must deploy differently? how?

Thanks in advance!

installation details…
*** Date: Sunday, May 11, 2008 11:53:38 PM ET

*** Platform Details:

*** System properties:
awt.toolkit=sun.awt.windows.WToolkit
birt.viewer.working.path=C:\eclipse6\workspace\.metadata\.plugins\org.eclipse.birt.report.viewer
eclipse.buildId=M20070921-1145
eclipse.commands=-os
win32
-ws
win32
-arch
x86
-showsplash
-launcher
C:\eclipse6\MyEclipse6.0\eclipse\eclipse.exe
-name
Eclipse
–launcher.library
C:\eclipse6\MyEclipse6.0\eclipse\plugins\org.eclipse.equinox.launcher.win32.win32.x86_1.0.1.R33x_v20070828\eclipse_1020.dll
-startup
C:\eclipse6\MyEclipse6.0\eclipse\plugins\org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar
-exitdata
1fa8_54
-vm
C:\eclipse6\MyEclipse6.0\jre\bin\javaw.exe
eclipse.ee.install.verify=false
eclipse.product=com.genuitec.myeclipse.product.ide
eclipse.startTime=1210550844479
eclipse.vm=C:\eclipse6\MyEclipse6.0\jre\bin\javaw.exe
eclipse.vmargs=-Xms128m
-Xmx512m
-Duser.language=en
-XX:PermSize=128M
-XX:MaxPermSize=256M
-jar
C:\eclipse6\MyEclipse6.0\eclipse\plugins\org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar
eof=eof
file.encoding=Cp1252
file.encoding.pkg=sun.io
file.separator=\
java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment
java.awt.printerjob=sun.awt.windows.WPrinterJob
java.class.path=C:\eclipse6\MyEclipse6.0\eclipse\plugins\org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar
java.class.version=49.0
java.endorsed.dirs=C:\eclipse6\MyEclipse6.0\jre\lib\endorsed
java.ext.dirs=C:\eclipse6\MyEclipse6.0\jre\lib\ext
java.home=C:\eclipse6\MyEclipse6.0\jre
java.io.tmpdir=C:\Users\John\AppData\Local\Temp\
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
java.runtime.version=1.5.0_11-b03

<SNIP, please use MyEclipse > Installation Details > IInstallation Summary in the future>

[Loyal Water]

Can you point me to the tutorial that your referring to over here.

[john]

Thanks. It’s the MyEclipse EJB 3.0 Tutorial . to navigate to it do this:
MyEclipse: Help> Search. enter “EJB3” click Search. Click the MyEclipse EJB3.x Tutorial link.(It’s the first one, for me.)

[Loyal Water]

The tutorial said that the appserv-rt.jar would allow this to work “automatically and retrieve our bean with almost no effort”. But it’s not working for me.

Did you add this jar to your build path and try running the app? What errors do you have in your problem window ?

[john]

Yes. I already added appserv-rt.jar to my build path before I got the error. You can know this since the error message I showed you comes
after the point in the process where the code would have thrown an exception due to the a missing appserv-rt.jar.

Here is the exception message you requested, the same as I showed you in my original posting (above) but here is the whole stack.

javax.naming.NameNotFoundException
    at com.sun.enterprise.naming.TransientContext.resolveContext(TransientContext.java:255)
    at com.sun.enterprise.naming.TransientContext.lookup(TransientContext.java:178)
    at com.sun.enterprise.naming.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:61)
    at com.sun.enterprise.naming.RemoteSerialContextProviderImpl.lookup(RemoteSerialContextProviderImpl.java:116)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:121)
    at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:650)
    at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:193)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1705)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1565)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:947)
    at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:178)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:717)
    at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:473)
    at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1270)
    at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:479)

It seems to me that the problem could be that there is nothing to tell JNDI to look in the Derby data source for the location of the bean, and nothing puts that information into Derby. These steps seem to be expected to happen by magic according to the tutorial.

Can you identify how Derby is identified to JNDI and how the location of the bean is put into Derby? Have you gotten the tutorial to work as described?

[Riyad Kalla]

John,
A few things that I hope clear it up:

1. Derby doesn’t play into that example at all, we aren’t doing any DB access. I think you might have confused the JNDI/Derby process, no bean gets put into Derby, but into the JNDI context.

2. There is a default JNDI properties file on appserv-rt.jar, that is why it works “like magic”.

3. As shown in the tutorial, Glassfish by default binds classes to their FQN. I believe the format you are using <NAME>\local is the JBoss style. Each app server binds beans in it’s own way.

4. The greatest tip anyone can ever show you when working with JNDI (saved me from going bald) is the JNDI Browser in Glassfish, here’s a tip on how to use it: https://www.genuitec.com/forums/topic/glassfish-how-do-i-browse-the-jndi-tree/

I think the problem comes from a little bit of confusion and then just using the wrong binding lookup (which you can clarify with the browser), once you get that squared away it should be smooth sailing into EJB3 land.

[john]

Riyad,
I appreciate your help.

I made all possible corrections and inspection as you advised, but I get the same result.

To each of your points…

1. I didn’t think derby was the JNDI base or doing Entity persistence JNDI must have some mapping however. If it uses IIOP, it seems that IIOP requires Derby to be running.

2. The jndi.properties file contains the following code (aside from comments), and this seems inadequate to make jndi find my MyBean EJB. Note that this tells JNDI to use RMI-IIOP, and so JNDI will require a database, such as Derby to be running.

java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
java.naming.factory.url.pkgs=com.sun.enterprise.naming
# Required to add a javax.naming.spi.StateFactory for CosNaming that
# supports dynamic RMI-IIOP.
java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl 

3. I tried the exact FQN again (just as I did before I submitted my request for support) – I was just trying each of the suggestions in Q/A postings.
I have… .lookup( “com.myeclipseide.ejb3.MyBeanLocal”)
I get the same name not found exception.

4. Thanks! however, my “Jndi tree Browsing” only displays…

Name:  ejb/mgmt/MEJB
Class: javax.naming.Reference

      [] Usertransaction
    v [] ejb
      v  [] mgmt
            [ ]  MEJB  

Is this right? how is this is supposed to allow my lookup( com.myeclipseide.ejb3.MyBeanLocal) to find the MyBean classes ?
By the way, I have also reinstalled the app server (just-in-case).
got the same results.

Do you have any more suggestions?

[john]

Riyad,

I have also tried using the mapping annotation suggested in the tutorial.

 @Stateless( name="MyBean", mappedName="ejb/MyBean") 
    public class MyBean implements MyBeanLocal {  

and in my bean Test…

     MyBeanLocal bean = ( MyBeanLocal) ctx .lookup( "ejb/MyBean" );  

this results in the same name not found exception.

But, when I run the test while I have the Derby database stopped, the .lookup results in IIOP giving the following io connect exception
Could this be a clue about what’s wrong? What do you think?

 May 13, 2008 4:52:06 PM com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl <init>
WARNING: "IOP00410201: (COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: localhost; port: 3700"
org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 201  completed: No
    at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2348)
    at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2369)
    at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:212)
    at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:225)
    at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:104)
    at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:159)
    at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:156)
    at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:296)
    at org.omg.CORBA.portable.ObjectImpl._is_a(Unknown Source)
    at org.omg.CosNaming.NamingContextHelper.narrow(Unknown Source)
    at com.sun.enterprise.naming.SerialContext.narrowProvider(SerialContext.java:110)
    at com.sun.enterprise.naming.SerialContext.getProvider(SerialContext.java:164)
    at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:309)
    at javax.naming.InitialContext.lookup(Unknown Source)
    at com.MyBeanTest.main(MyBeanTest.java:43)


Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection refused: connect    at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:356)
    at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:195)
    ... 12 more
Caused by: java.net.ConnectException: Connection refused: connect
    at sun.nio.ch.Net.connect(Native Method)
    at sun.nio.ch.SocketChannelImpl.connect(Unknown Source)
    at java.nio.channels.SocketChannel.open(Unknown Source)
    at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:340)
    ... 13 more 

[Riyad Kalla]

John,
Ok now I’m really curious.

If you jump back to the EJB TUtorial and go to the Resources section and grab the example project that was created for the tutorial (http://www.myeclipseide.com/documentation/quickstarts/ejb3/#Resources) does *it* work when deployed? I wonder what is going on.

[john]

Riyad,

I have copied the Tutorial’s sample into my workspace with no changes; all files are exactly from the Tutorial resources.
It has the same problem: MyBeanRemote not found. The latest trace is at bottom of this message.

I see 4 suspicious things that might be causing the problem. Please help.

1. The port number of Derby might be wrong.

When I stop Derby before running the MyBeanClient, the trace says IIOP can’t connect on port 3700. (see previous posting in this discussion thread.)
However, I remember that when I set up derby, the setup procedure provided default port was port 1527. Is one of these wrong? How can I change Derby’s port number?

2. The deployment by MyEclipse might be wrong.

asadmin shows the deployed beans in its Web Applications node,
instead of its EJB Modules node. Is this right? (I deploy thru MyEclipse, of course.) This seems wrong because the MyBean modules of the Sample are EJB Modules, not Web Applications.
Should MyEclipse’s deploy function be changed to put the EJB Modules properly? (By the way, I am considering deploying thru asadmin, but it doesn’t accept the jar file as-is.)

My asadmin tool displays this in its Deployed Web Applications screen:

Application Name                                     Enabled  Context        

SampleEjbProject.jar_com_myeclipseide_ejb3_IMyBean      true  IMyBean   

SampleEjbProject.jar_com_myeclipseide_ejb3_MyBean       true  MyBean   

SampleEjbProject.jar_com_myeclipseide_ejb3_MyBeanClient true  MyBeanClient   

SampleEjbProject.jar_com_myeclipseide_ejb3_MyBeanLocal  true  MyBeanLocal   

SampleEjbProject.jar_com_myeclipseide_ejb3_MyBeanRemote true  MyBeanRemote  

3. JNDI might not be receiving the mapping when MyEclipse’s deploy is done.

My admintool’s JNDI browser shows only this:

Name:  ejb/mgmt/MEJB 
Class: javax.naming.Reference 

      [] Usertransaction 
    v [] ejb 
      v  [] mgmt 
            [ ]  MEJB  

Is there a way to tell JNDI the mappings, perhaps manually? I have tried the @EJB and EJBContext appoach but I get the same results.

4. Something else might be blocking the IIOP to derby connection due to port conflict (I don’t think this is it. I’ve tried another PC).

I have everything non-essential shutdown. I also started Derby upon start up, and noght else complained about getting a port afterward.

Here is the trace from the sample.

javax.naming.NameNotFoundException: com.myeclipseide.ejb3.MyBeanRemote not found
    at com.sun.enterprise.naming.TransientContext.doLookup(TransientContext.java:203)
    at com.sun.enterprise.naming.TransientContext.lookup(TransientContext.java:175)
    at com.sun.enterprise.naming.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:61)
    at com.sun.enterprise.naming.RemoteSerialContextProviderImpl.lookup(RemoteSerialContextProviderImpl.java:116)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:121)
    at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:650)
    at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:193)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1705)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1565)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:947)
    at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:178)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:717)
    at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:473)
    at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1270)
    at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:479)

Thank you; I look forward again to your help.

[Riyad Kalla]

John, I’ve cleared time on my schedule to walk through all this stuff this afternoon. Bear with me as I get caught up and I’ll give this the attention it deserves.

Thank you for being so detailed wth your reports. My first order of business with be clean installs of MyEclipse and the latest Glassfish 2 release to confirm that the problem doesn’t lie there (if you want to try the same).

[Riyad Kalla]

John,
I finally got a chance to sit down and run through that tutorial. The end result, is that I think you are fighting some sort of Glassfish install problem or configuration problem on your end, because with clean installs of everything, the project worked without a hitch. Here’s what I did:

1. Downloaded glassfish 2ur2 from the Glassfish website
2. Ran the installer which unzips it
3. Ran ant -f setup.xml which causes Glassfish to uncompress the rest of it’s resources and generate a domain
4. Setup the connector in MyEclipse by setting the Home dir and set it up to launch with JDK 1.6.0_04
5. Imported the EJB 3 project from the tutorial, opened the deployment tool and deployed it exploded to Glassfish.
5.1 Fixed the appserv-rt.jar reference by pointing over to that exact JAR from my new Glassfish install, in the /lib dir.
6. Spun up Glassfish, let it finish starting.
7. Right-click and Ran As > Java Application “MyBeanClient”
8. It ran, and in the server console the EJB3 bean printed out “Hello World”

So before you keep banging your head against the wall, I’d suggest backing up your Glassfish install and doing a brand new clean one with the same version I mentioned above and trying again. Otherwise I think you may run the chance of chasing red-herrings around.

Also just incase there was some sort of Derby conflict (I’m still not sure why Derby keeps coming up) I stopped Glassfish, ran MyEclipse Derby (1527 is default port btw) and then refired up Glassfish and it still worked fine. So no conflicts there.

[john]

Hello World!

Riyad you were right about a problem with my installation. I actually had started with (what I thought was) a clean jee5 and glassfish v2,
I have discovered what was wrong with it (at least some things).

I’ll share what I learned for benefit of others…
But first, I get the following exception when I start the glassfish server…

SEVERE: LDR5004: UnExpected error occured while creating ejb container
java.lang.ClassNotFoundException: com.sun.ejb.containers.TimerMigrationBean649625130_ConcreteImpl
    at com.sun.enterprise.loader.EJBClassLoader.findClassData(EJBClassLoader.java:741) . . . 

It eventually displays Success, however.

Please, Let me know if you think this is a concern. Did you get this exception too? Everything else seems clean.

Some things I learned…

1. Step three resulted in an out-of-heap exception. I had to specify larger memory like this

 java -Xms5m -Xmx150m -jar   glassfish-installer-v2ur2-b04-windows.jar 

My machine has 2Gig ram and was not running much at this time. I wonder if this is a defect in the installation procedure in the sense that it depends on something in the target OS or environment.

2. There actually was a conflict with port 4848. It was due to my previous installation of the server which I thought I had shut down and removed. However, it was still present in the Vista task manager as a stopped service. It wasn’t easy to remove it, but the conflict went away after it was removed. Lesson learned: first time around, don’t select the option to make the server a Windows Service.

3. I had a previous version of java jdk installed under \Program Files\Java\… My PATH was still pointing to this. NOTE! that the JEE installation provides a checkbox to automatically Add Bin Directory to PATH variable. I did check this (screen captured each step! ) But it was not actually updated. That mislead me into not looking carefully at the PATH. I didn’t remove the old jdk because Vista prevented removal (ultimately due to the app server not being gone.) and because that’s usually not a problem.

4. The first time around (before the present total re-install), my ant -f setup.xml gave an error about a missing jar file (caused by #2, the wrong jdk). I should have stopped and really fixed the problem right there. But I assumed this was just a defect in the setup.xml. I just found the jar file and put it where it belonged. Sometimes, that approach is your only choice with a really defective newly released setup.

5. The container was clearly not able to find the provider (before my total re-install). The context variable had this:

ctx                   InitialContext
  defaultInitCtx      SerialContext
    cosContext      null   <------- ?????
   ... 
    provider          null   <------- ?????  

Lesson learned: When we see this, “all bets are off” and there is a severe problem with the application server, even though the server comes up and works without much complaint. Immediately after the lookup(), the defaultInitCtx.provider has _SerialContextProvider_DynamicStub in this case. However, the values are null before the lookup, so this clue might not be very useful for diagnosing the installation.

Because of your advice, I removed previous jdk and server completely. It was a battle against the operating system.

6. ONE MORE Configuration Task

The app server is installed as a Windows Service with AUTO startup mode. This creates a problem: The app server tries to start up when booting up. It fails (I don’t know why) and yet it hangs on to Port 8080. So when you try to start the app server via MyEclipse, it aborts because 8080 is busy.

The cure for this is to set the Service to MANUAL (maybe disable would work as well).
Do this…
Start menu> Control Panel> Services…
scroll down to “Sun app server (instead of just “AppServer…) click it and set the mode to MANUAL.
I don’t know how to remove it from the list of Windows Services. Apparently, it didn’t occur to MS that Services sometimes need to be removed. Duh!

John

[Riyad Kalla]

Please, Let me know if you think this is a concern. Did you get this exception too? Everything else seems clean.

Weird, no I don’t get that error, but IIRC the “TimerBean” is some example or system EJB that is deployed with a clean install of Glassfish. But if there are no side effects, I guess it doesn’t do anything critical 😀

1. Step three resulted in an out-of-heap exception. I had to specify larger memory like this
Code:
java -Xms5m -Xmx150m -jar glassfish-installer-v2ur2-b04-windows.jar

My machine has 2Gig ram and was not running much at this time. I wonder if this is a defect in the installation procedure in the sense that it depends on something in the target OS or environment.

It’s on the Glassfish download page; the default VM heap (64mb) isn’t big enough to let the installer run… I guess it loads up the manifest of every file in it or something. They usually recommend using 256m. No biggie.

John I’m really glad things are working for you now, happy coding!

[Author]

Posts