Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Cannot link to session EJB on Windows

 
Andy Evans
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all.
Am having a strange experience trying to connect to a remote session bean.
When the connection code is compiled up and run as a standalone java app then everything works fine. As soon as I wrap this code into an action class in a struts web application it fails.
It seems to be some kind of configuration issue but after scouring the web all morning I'm totally stumped.
Whats more... if the web application is deployed on a tomcat server on a Linux box then it works. As soon as the identical application is deployed to a tomcat server on Windows, it doesn't.
If I step through the code in Netbeans then the whole thing seems to hang on the following line (no exception is thrown):
Object ref = jndiContext.lookup("eppix/Integration");
According to the tomcat logs, the error is:
java.lang.NoClassDefFoundError: javax/ejb/EJBHome
Initially I assumed that it could not find my j2ee.jar.... but now I'm guessing this is a spurious error and the cause is something else.
One final thing to note... all the JAR files required to run as a standalone are now sitting in the WEB-INF/lib directory in the web application.... so why can't it find what it needs??
Has anyone got a clue as to what is going on before I put my foot through my machine??
Thanks in advance....
(e)
 
Simon Brown
sharp shooter, and author
Ranch Hand
Posts: 1913
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Andy Evans:
One final thing to note... all the JAR files required to run as a standalone are now sitting in the WEB-INF/lib directory in the web application.... so why can't it find what it needs??

Does this include the javax.ejb.* classes?
Simon
 
Andy Evans
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Simon Brown:

Does this include the javax.ejb.* classes?

Yup... totally....
(e)
 
Simon Brown
sharp shooter, and author
Ranch Hand
Posts: 1913
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
... and you've got the jndi.properties file in the classpath (or you're specifically pointing at an appserver)?
 
Andy Evans
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah... we're hardcoding it in the class right now... we'll move to a jndi.properties once we've got beyond the demo stage of this new app....
 
Simon Brown
sharp shooter, and author
Ranch Hand
Posts: 1913
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And the JAR containing any appserver specific JNDI,etc classes also in your WEB-INF/lib directory?
Which version of Tomcat are you using?
 
Andy Evans
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah... again, totally... just to re-cap.... it worked as a standalone client.... I cut and paste the majority of the main function into the perform function of my ActionClass.... I added every referenced JAR file into the lib directory of the web application.... what worked as standalone now doesn't work as a web app... but it DOES work on Linux... !??!
We're using Tomcat 4.0.3, java 1.4.0 & struts 1.0.2....
Cheers.
(e)
 
Andy Evans
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
More info....
I just tried installing and running a jboss server on my local machine. Exactly the same error happens - so it's not a network issue or anything like that.
Then I tried to lookup the demo session bean that I had already created and tested from the jboss documentation - rather than our test bean. Again, exactly the same error... the whole app just seems to hang on the lookup line.
Arrrrrrrggggggh!
(e)
 
Andy Evans
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anyone ???
 
Ruilin Yang
Ranch Hand
Posts: 150
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You may need to look your deployment descriptor xml file very carefully, e.g. name matching ? etc.
[ July 23, 2002: Message edited by: Ruilin Yang ]
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18277
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
EJBs don't completely connect with J2EE apps via the WEB-INF/lib directory. Yes, you can use copy of the exported classes/interfaces there for the benefit of the app code, but typically in a J2EE appserver, the actual running copy of the EJB is outside the webapp. That's why there's both WAR files and EAR files.
Regrettably, there's no real standard here, so you have to RTFM on how to deploy for your particular brand of appserver. In the JOnAS/Tomcat system I'm using, I simply softlink the EJB jars from the JOnAS deployed-ejb directory to the user library in Tomcat:
ln -s /usr/local/JONAS/ejbjars/myejb.jar /var/tomcat3/lib/apps/myejb.jar
Not necessarily the cleanest solution, but one that works until ObjectWeb comes up with something that eats EARs.
JBoss is better integrated with Tomcat for EJBs, but you'll have to read the docs for yourself - Its been so long, I've forgotten how it works.
... And yes, the "ln" command is for Linux, not Windows. You need at least Windows 2000 to be able to do something equivalent. Otherwise, just make 2 copies of the jar - 1 for the EJB server and one for Tomcat - unless JBoss does something nice for you.
[ July 23, 2002: Message edited by: Tim Holloway ]
 
Andy Evans
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lo all.
Well, thanks for trying... however, I've now found the solution.
It was as simple as we'd included the j2ee.jar instead of the jboss-j2ee.jar... this made all the difference.
It must have worked on the Linux box because it could somehow locate the JAR.... where as Windows was being far more tempremental.
(e)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic