...
The Time Bean Example
This is an example of a JSP-page calling a Session Bean. The result looks like this:
...
OK, what I want is an EJB that can tell the time, this is what the code for the bean looks like:
...
I have put my EJB in a package that I call mytimepak. The first 6 methods are implementations of the javax.ejb.SessionBean interface. I don't realy know what good they are, but the ejbCreate method is like a constructor, in this case an empty constructor. To enable clients to call the EJB one must provide so called home and remote interfaces. The first one, home interface, is used to locate the EJB, the other, the remote interface is used to invoke methods on the EJB. The remote interface is just like a normal interface used for RMI. As this EJB will only be used from a JSP-page that is run in the same server (same JVM) I use another type of interfaces that don't make use of the network. Thay are called LocalHome and Local interface instead, but they are just the same.
This is the code for the local home interface (coresponding to the home interface):
...
...
As you can see, the LocalHome interface is like a constructor returning MyTimeLocal.
This is the code for the Local interface (coresponding to the remote interface)
...
...
This is just a plain interface for the methods (I refuse to call them business methods) of the EJB, in this case the getTime() method.
This code is not hard to understand, the tricky part is the deployment descriptors. You need 2 of them, ejb-jar.xml and openejb-jar.xml. This is what they look like:
ejb-jar.xml:
...
...
First you have some stuff that I don't know what good they are, for example the display-name tag. You can write what ever there I guess. It seams totaly unnessesary to me, but I have not tested what happens if I take it away. What does matter is the tags ejb-name, local-home, local, ejb-class, session-type. I think that the ejb-name is part of what clients use to locate the bean (see the next xml-file). The local-home, local and ejb-class tags points out the classes. Session type tells if it is a statefull or stateless session bean. Transaction type doen't make sence I think, there is no transactions in a session bean, is there? I have tryed to read more about this deployment descriptors here: http://cwiki.apache.org/GMOxDOC11/deployment-plans.html But I have not bean able to figure it out. On the other hand, I don't think ejb-jar.xml files are needed in the next generation EJB 3.0 so perhaps one should not spend to much time trying to understand it.
Here comes the openejb-jar.xml file:
...
...
Again, I don't understand much of the first part, but the ejb-ref part is important. ref-name=ejb/MyTimeBean is what clients use to lookup the EJB. ejb-link=MyTimeBean is the same as ejb-name=MyTimeBean in ejb-jar.xml. The ejb-link and the ejb-name must be the same.
(Why this information has bean split up in 2 files is a mystery to me. I guess that it has something to do with what is generic for the application (ejb-jar.xml) and other stuff that is spesific to the application server. If you were to deploy this application on another application server than geronimo you would only have to change the openejb-jar file. That sounds good. On the other hand, now you have the extra complexity of knowing what goes where and that sure aint easier than having to rewrite one sigle deployment descriptor if you would face the rare situation of deploying your code on another type of server. But this is ofcourse my personal oppinion based on limited understanding of EJB.)
...
This is my JSP-page, I comment the code directly in the code:
...
Note that this JSP-page also have to include mytimepak.MyTimeLocalHome and mytimepak.MyTimeLocal. I have done that in the first line import="mytimepak.*. This two class files must be in the WEB-INF/classes directory, and not only that, in the WEB-INF/classes/mytimepak directory. I'll get back to that later.
If the JSP is simple, again the deployment descriptors are hard (or at least that is what I think). This is what they look like:
geronimo-web.xml:
...
...
Only inportant here (as far as I understand) is the context-root that becomes the URI.
web.xml
...
xml
...
welcome-file is what file the server will show if no file name is in the URI. ejb-local-ref is important. Here you must get the data right in all the tags (or so I think). Note how ejb/MyTimeBean corresponds to ref-name int openejb-jar. ejb-link seams to be unessesary, but we can't deply it without the local-home and local tags pointing out the classes for the interfaces.
There are 2 more deployment descriptors, the ones for the application as a whole. This is what they look like:
application.xml
...
xml
...
This file tell which two modules, the ejb and the web, that the ear file consists of.
geronimo-application.xml:
...
...
This file is pretty empty. The only thing of importance is the artifactId, it shows if you look a the lists of modules at http://localhost:8080/console/portal/apps/apps_ear like this: default/MyPhonebook_ArtifactId/1.0/car
(Anybody knows what "car" stands for?)
Allright, this is how I have organised my files :
...
First we must compile the EJB.
Then copy the interface classes to the WEB-INF\classes\mytimepak directory
Last task is to pack the EJB-jar file the WEB-war file and finaly the EAR-file.
To compile the EJB we must have geronimo-ejb_2.1_spec-1.0.1.jar in the classpath. I have installed geronimo in C:\geronimo\geronimo-1.1 and This is a bat-script that does this. Modern programmers use ant ofcourse, but for clarity, this is exactly what is needed to get the ear. So beginning in the app-home directory (in my case cd c:\java\j2ee\mytime)
...
...
As you can see here I start with declaring a variable CLPATH just not to get to long lines. Then cd to the ejb-directory and compile the EJB. Then copy the interface flasses to the web application. Then I use jar to first create an jar file for the EJB, then a war-file for the web, and finaly put this to jars (or mor corectly the jar and the war) in an ear file. Note how the META-INF/WEB-INF is directly in the jar-file root directory for all the jars.
Finaly the ear must be deployed. I use the geronimo deploy tool like this:
...