Okay so let's create a simple EJB bean that just says "hello", after that we want to secure the bean using a JDBC Realm.
Let's start with your basic EJB.
and the interface,
See that wasn't that hard. Now let's write up the sun-ejb-jar.xml file so that we can let Glassfish know what to do with the EJB once we deploy it. Think of the xml descriptors as instructions for Glassfish on how it should expose your EJB, use your EJB, what resources are needed, and so forth. Some tags from the xml descriptors have been converted into annotations for your Java code, like @Stateless and @Remote.
One of the things that I usually put into the xml descriptor is the JNDI name. I'm just so use to doing it that way, but you are free to use the @Stateless annotation to give the JNDI. So let's look at my sun-ejb-jar.xml file, also note the sun that is in front of ejb-jar.xml. The ejb-jar.xml file is the standard xml descriptor and would be a good place for the JNDI but we need the sun specific one because we will need to secure our EJB later. We'll forgo the standard ejb-jar for the sun specific one.
As you can see I've given my EJB a global JNDI name of ejb/Helloness/HelloThere.
Now deploy to Glassfish.
Congrats you've written your first EJB, or maybe your second or so. However, the JAR is running all by itself on your Glassfish server. The crappy part about that is that you won't be able to use injection now. The reason is that for injection to work the JAR and the client must be running together. You can bundle them together in a Java Enterprise Application. Of course, if you deploy the JAR with a client in an EE Application, you now have two copies of your JAR on the server.
To avoid all of that, you can just use a context lookup for the JNDI name. However, the caveat of that is, your application client won't know anything about the JAR, ergo, it won't know the signature of the method, return type, etc... If you're in Netbeans, you'll get a real eye opener if you try to include the JAR file in your project. It seems like it knows nothing about the JAR you included. Mainly you'll get something like an ejb ref error or something of the sort.
The reason? The client application is running on it's own just like the JAR is. The two aren't talking to each other, except for the JNDI lookup. So basically you lookup a POJO but then you basically cast it to an unknown type. You need to let that type be known to your client, to do such a thing, simply copy and paste your interface file into your client project.
So let's write our client program, as you know we have our HelloRemote.java file copy and pasted into our project, so I'll just cover the main file.
And there you go. A full client to use our EJB bean. Deploy that to your Glassfish server and then use Java Web Start to start up your application. Presto! You have your client getting the implementation from your remote EJB.
I'll be back later, maybe tomorrow, maybe after the holidays, to show how to secure the EJB using a JDBC realm. Of course if you want to see how to implement the JDBC Realm in Glassfish take a look at this post.
Cheers!
Let's start with your basic EJB.
//File: HelloBean.java
package com.blogger.ramen;
import javax.ejb.Stateless;
@Stateless(name="HelloBean")
public class HelloBean implements HelloRemote {
public String sayHello() {
return "Hello from EJB!";
}
}
and the interface,
//File: HelloRemote.java
package com.blogger.ramen;
import javax.ejb.Remote;
@Remote
public interface HelloRemote {
String sayHello();
}
See that wasn't that hard. Now let's write up the sun-ejb-jar.xml file so that we can let Glassfish know what to do with the EJB once we deploy it. Think of the xml descriptors as instructions for Glassfish on how it should expose your EJB, use your EJB, what resources are needed, and so forth. Some tags from the xml descriptors have been converted into annotations for your Java code, like @Stateless and @Remote.
One of the things that I usually put into the xml descriptor is the JNDI name. I'm just so use to doing it that way, but you are free to use the @Stateless annotation to give the JNDI. So let's look at my sun-ejb-jar.xml file, also note the sun that is in front of ejb-jar.xml. The ejb-jar.xml file is the standard xml descriptor and would be a good place for the JNDI but we need the sun specific one because we will need to secure our EJB later. We'll forgo the standard ejb-jar for the sun specific one.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 EJB 3.0//EN" "http://www.sun.com/software/appserver/dtds/sun-ejb-jar_3_0-0.dtd">
<sun-ejb-jar>
<enterprise-beans>
<ejb>
<ejb-name>HelloBean</ejb-name>
<jndi-name>ejb/Helloness/HelloThere</jndi-name>
</ejb>
</enterprise-beans>
</sun-ejb-jar>
As you can see I've given my EJB a global JNDI name of ejb/Helloness/HelloThere.
Now deploy to Glassfish.
Congrats you've written your first EJB, or maybe your second or so. However, the JAR is running all by itself on your Glassfish server. The crappy part about that is that you won't be able to use injection now. The reason is that for injection to work the JAR and the client must be running together. You can bundle them together in a Java Enterprise Application. Of course, if you deploy the JAR with a client in an EE Application, you now have two copies of your JAR on the server.
To avoid all of that, you can just use a context lookup for the JNDI name. However, the caveat of that is, your application client won't know anything about the JAR, ergo, it won't know the signature of the method, return type, etc... If you're in Netbeans, you'll get a real eye opener if you try to include the JAR file in your project. It seems like it knows nothing about the JAR you included. Mainly you'll get something like an ejb ref error or something of the sort.
The reason? The client application is running on it's own just like the JAR is. The two aren't talking to each other, except for the JNDI lookup. So basically you lookup a POJO but then you basically cast it to an unknown type. You need to let that type be known to your client, to do such a thing, simply copy and paste your interface file into your client project.
So let's write our client program, as you know we have our HelloRemote.java file copy and pasted into our project, so I'll just cover the main file.
//File: Main.java
package com.blogger.client;
import javax.naming.InitialContext;
import com.blogger.ramen.HelloRemote;
public class Main {
public static void main(String [] args) {
InitialContext ctx;
try {
ctx = new InitialContext();
HelloRemote hr = (HelloRemote) ctx.lookup("ejb/Helloness/HelloThere");
javax.swing.JOptionPane.showMessageDialog(hr.seyHello());
} catch (Exception ex) {
javax.swing.JOptionPane.showMessageDialog("Massive failure!");
}
}
}
And there you go. A full client to use our EJB bean. Deploy that to your Glassfish server and then use Java Web Start to start up your application. Presto! You have your client getting the implementation from your remote EJB.
I'll be back later, maybe tomorrow, maybe after the holidays, to show how to secure the EJB using a JDBC realm. Of course if you want to see how to implement the JDBC Realm in Glassfish take a look at this post.
Cheers!
