Based on your configuration, the glassfish app server is on the same machine as the tomcat. If not, then please change it to the actual IP.
Given that all jars are present, then if the configuration of the host and port are incorrect then you would only get NamingException. Other exceptions would point to configuration and environment problems.
Uy Jerwin Louise Vergara
Junior Developer / Research and Development at Incuventure Partners Corporation
Joined: Apr 01, 2007
I am running my Glassfish and Tomcat in the same machine without any conflicts, host or ports. I’ve also tested it in a peer-2-peer environment without any issues, aside from the accessing the Remote EJB using Tomcat.
I’ve tested it via stand-alone client and it works, in a network environment, as well in the same machine (localhost/127.0.0.1), please see below:
With regards to the results of the test, it seems that I am missing something in the configurations for Tomcat 5.
As in my original post I’d included/copied the required jar files in %CATALINA_HOME%\shared\lib folder in my Tomcat.
I’ve checked the MANIFEST.MF of appserv-rt.jar, in which referring to the ff. jar below:
I included the “interface class” in my war file (web app) in Tomcat and it works.
Yes, you need the interface to the EJB in order to connect to it and call it's business methods. This is how EJBs work. This is true whether the client is local or remote, and is common with all Java Application servers.
Keep in mind that there is a lot of EJB code that is generated by the application server, not you the programmer. So, the interface API on a remote client is not the same as the code that is in the application server.
This seems not portable in a sense that the “remote interface class” should be equal to each other when doing this set-up.
This sentence is confusing. "What" should be equal to each other when doing "what" set-up? Please explain.
The remote objects that enable client code to connect to the EJB are not required on the server. An EJB is never a client of itself. This does not make any sense.
Joined: Feb 01, 2005
Hmm...is there some confusion here?
All you should need from the EJB code is the business interfaces for the client to make the call through. Although simply copying over the interface classes to the WAR is fine unless it is within the same EAR as the EJB JAR (because the class would be loaded twice in the same class loader hierarchy, which is wrong), the best practice in this case would be to separate the interfaces out into a separate EJB client JAR (http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.jst.ejb.doc.user/topics/ceclientjars.html) and have both the WAR and EJB JAR reference the common JAR with the interfaces. Most IDEs support this, Eclipse certainly does...
What is the portability issue that you see? There is nothing all that different here than using any ordinary Java interface to any old API? What do you think the expected behavior should be?
Joined: Apr 01, 2007
My apologies for the confusion, please let me clear the set-up I am illustrating.
IP Address = 192.168.1.1 App Server = Glassfish (latest version) Deployed EJB (ver. 3.0):
IP Address = 192.168.1.2 Web Server = apache-tomcat-5.5.27 Deployed WAR file:
In which this "interface" was deployed in Glassfish & Tomcat.
The Servlet in the Web App deployed in Tomcat.
Basically, as illustrated above, if the SimpleBean interface changes you need to apply those changes in machine 1 & 2.
We need to copy over the modified (if there are) SimpleBean.class in Glassfish (machine 1) and in Tomcat (machine 2).
So the client (particularly in web application) need the copy of the EJB in order to connect to a Remote Machine with the same EJB.
Now, is this a binding contract in accessing Remote EJB? Is it written in the specs?
Thanks very much, really appreciate your time and effort. If there are still some confusions, please let me know.
I'd contacted the author of the blog from my first post, and he re-read his blog and he said that he failed to mention that the EJB needs to be included in Tomcat.
Joined: Feb 01, 2005
OK. As I mentioned, the best practice in your case would be to extract just the EJB remote interface to a separate JAR. The EJB spec calls this the EJB client JAR (as described in the link above). This jar would just contain some simple POJOs (for example DTOs passed as EJB parameters) and POJIs (for example, the business interfaces), no container generated stuff.
This common interface then needs to be referenced both by the client on Tomcat and the EJB JAR containing the EJB implementation. This way, there is no copying of source code. You simply have your build system generate the JAR ans place it as a dependency for both the client and the EJB jar. For example, Eclipse will help you with this, as will ANT, Maven, etc.
This make more sense? Or do you see a possibility of doing this better with existing Java semantics. modularization and class-loading?