Simplest possible stateless bean

[renen]

Having worked happily with EJB2 code for a couple of years, I attempted to get an EJB3 stateless session bean to work.

I failed.

My EJB code:

@Stateless
public class T2Bean {

 public void doIt(int i) {
 System.out.println("in do it!: " + i);
 }

}

In a JSP page, I attempt to access the bean as follows:

 InitialContext ctx = new InitialContext();
 T2Bean t = (T2Bean)ctx.lookup(T2Bean.class.getName());
 t.doIt(4);

The ejb is packaged in a JAR and deployed. The JSP is contained in a WAR. And both are deployed within a single EAR.

I get an error: javax.naming.NameNotFoundException: za.co.oneTwoOne.T2Bean not bound

What am I doing wrong?

My understanding is that EJB3 should simplify things, eliminate the need to declare interfaces, and herald the new world order of love and happiness. Clearly things are not so simple! ;-) Or (hopefully), I'm missing something obvious.

If somebody can point me in the right direction, I will happily add the solution to the wiki for the benefit of future generations!

Renen.

[jaikiran]

Looks like my earlier post got screwed up. Here's another try.

My understanding is that EJB3 should simplify things, eliminate the need to declare interfaces

You still have to declare the remote and/or local business interfaces. These interfaces will have your application specific business methods. Have a look at
http://trailblazer.demo.jboss.com/EJB3Trail/
which provides examples of EJB3 and other stuff. Specifically for a Simple Stateless Bean have a look at
http://trailblazer.demo.jboss.com/EJB3Trail/serviceobjects/slsb/index.html

As far as the NameNotFoundException is concerned, you are using the incorrect JNDI name for looking up the bean. Once you have read through the above mentioned links and successfully deployed the bean, the client can lookup the bean using the JNDI name syntax mentioned in the Session Bean Client section in the second link above.

[renen]

Hi Jaikiran,

Thanks for the quick reply.

I must say, this is a bit frustrating. I don't understand why I need to generate an interface class. It doesn't seem to add any value to what I am doing, and the interface and the actual bean will always correspond 100%. Silly. I presume that there is an xdoclet type solution that will generate it for me. But I must say, I had hoped to be moving away from that overhead.

But Ok. I'm over that.

Then, including the ear name in the default JNDI name doesn't make sense. What happens if you need to use the classes in multiple ears?

But Ok. There is a way forward here to.

That tutorial (which is nice and clear - thanks) suggests that I use the @LocalBinding annotation. But that requires a JBoss include and makes me think that this is a JBoss specific thing.

However, I have no idea in which package I can find org.jboss.annotation.ejb.LocalBinding. I would be obliged if you could let me know. Perhaps somebody could add that nugget to the tutorial as well.

Interestingly, there are a couple of posts that suggest that you can do the T2Bean.class.getName()) thing. For example: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=66845 (see the last post). To my mind, this is much more elegant. That said, I mostly just want a solution... ;-~

Thanks for your advice.

renen.

[wolfc]

"Renen" wrote:
I must say, this is a bit frustrating. I don't understand why I need to generate an interface class. It doesn't seem to add any value to what I am doing, and the interface and the actual bean will always correspond 100%. Silly. I presume that there is an xdoclet type solution that will generate it for me. But I must say, I had hoped to be moving away from that overhead.

How would you like to reference your bean from a client (or servlet)? Maybe there is an alternative that's missing.

"Renen" wrote:
Then, including the ear name in the default JNDI name doesn't make sense. What happens if you need to use the classes in multiple ears?

The name for the bean must be as unique as possible in JNDI, or else you wouldn't be able to deploy the same bean in another enterprise application.

For example, you could run multiple shops on the same system and thus only have one coded ShoppingCartBean. This EJB is then included into each EAR which wants shopping cart functionality.

"Renen" wrote:
...
However, I have no idea in which package I can find org.jboss.annotation.ejb.LocalBinding. I would be obliged if you could let me know. Perhaps somebody could add that nugget to the tutorial as well.

jboss-annotations-ejb3.jar

"Renen" wrote:
Interestingly, there are a couple of posts that suggest that you can do the T2Bean.class.getName()) thing. For example: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=66845 (see the last post). To my mind, this is much more elegant. That said, I mostly just want a solution... ;-~

Again a JNDI name needs to be unique. And what if you had multiple bussiness interfaces, should we 'polute' JNDI by binding them all?

[renen]

Maybe there is an alternative that's missing.

I must say, I found myself asking that. We use application servers because we always have. And, it used to be neccesary. I'm not sure it still is.

;-) But I suppose one shouldn't get too philosophical.

We have a straight forward scenerio where we host two or three web sites, running against a common database. We use EJBs to manage database access, support the creation of the web pages and the rendering of data. And, we rely on MDBs, JSPs and JSP Tags.

We serve about 100 000 pages per day.

So, that's the broad context. More specifically, I would like to take advantage of some of the Java 1.5 constructs (specifically, varargs), and would also like to move with the times. So, I would like start porting our existing J2EE EJBs to EJB3.

POJOs have a lot of appeal in that they are simple to implement, easy to test etc etc. But, they never used to be managed in the same way that application server code was. But, I think that might have changed. Certainly, Tomcat must deal with them very effectively.

So, should we simply abandon EJBs all together? Feels a bit dramatic.

;-)

How would you like to reference your bean from a client (or servlet)?

The EJBs are accessed from JSP pages, tag libraries, MDBs and from other EJBs (all of which are stateless session beans). All these objects exist within JARs or WARs inside a single ear running on a seperate JBOSS instance.

Once implemented, the EJBs won't change very fast. Although we do add MDBs at a steady rate.

Again a JNDI name needs to be unique. And what if you had multiple bussiness interfaces, should we 'polute' JNDI by binding them all?

I'll hear that. Although, after mulling it over for bit, does it make any difference if JNDI is overpopulated? Are those performance concerns material against the singificantly increased levels of complexity?

THis topic has meandered quite far. I have learnt quite a bit and the replies have made me think. Thanks.

[renen]

Thanks - I have managed to resolve my initial problem. I can instantiate and use the EJB. Would still read very closely any replies to the other points.

[wolfc]

"Renen" wrote:

How would you like to reference your bean from a client (or servlet)?

The EJBs are accessed from JSP pages, tag libraries, MDBs and from other EJBs (all of which are stateless session beans). All these objects exist within JARs or WARs inside a single ear running on a seperate JBOSS instance.

Once implemented, the EJBs won't change very fast. Although we do add MDBs at a steady rate.

Misunderstanding. I was talking about how would you like to code your client, what API did you have in mind?

"Renen" wrote:
I'll hear that. Although, after mulling it over for bit, does it make any difference if JNDI is overpopulated? Are those performance concerns material against the singificantly increased levels of complexity?

Let's take the shopping cart again. It could be bound on java:com.acme.ShoppingCart/local. But where would it be bound if I deploy a second shopping cart?
So I would get: java:com.acme.ShoppingCart/deploy2.jar/local?
I don't see a way around putting extra artifacts in the name.

[renen]

Misunderstanding. I was talking about how would you like to code your client, what API did you have in mind?

Now I'm puzzled: could you explain what API choices I have.

If I should RTFM, don't hesitate to say so! But, I think even terse answers will steer my reading.

Thanks for the guidance.

[wolfc]

"Renen" wrote:

Misunderstanding. I was talking about how would you like to code your client, what API did you have in mind?

Now I'm puzzled: could you explain what API choices I have.

If I should RTFM, don't hesitate to say so! But, I think even terse answers will steer my reading.

Thanks for the guidance.

Hehe, currently there is no choice. You have to create an interface to go with your bean and use that interface in your client.

As I gather from your post you expected something different. So I am curious to what you did expect of the EJB 3 implementation? Maybe I misread your post and the 'Refactor'->'Extract Interface...' menu in Eclipse could cut the cake. Or maybe there is an alternative which has been overlooked.

[renen]

Hi Wolfc,

We had a holiday down here (za) so I haven't been at my computer.

I understood one of the overriding drivers of the EJB3 evolution was to simplify things, to make better use of defaults, and to reduce the barrier to entry required to get EJBs up and running.

I think I had hoped that things would have shifted such that you can start life with a POJO, and then gradually add EJB functionality. For example, by adding the stateless annotation.

For example, that interface you refer to: my EJBs are all local (as I suspect / hope 99% of the EJBs on earth are), so I only really need one interface. Right clicking and selecting extract interface isn't too tough, but now I have to evolve two chunks of code (the class and the interface) rather than one. Just makes things that much harder to get right and tougher to refactor. Development is shatteringly expensive. Anything that makes the process simpler, quicker and faster must be a step in the right direction (mind you EJB3 vs EJB2 is clearly a massive step in the right direction!).

JNDI is another great example of a sensible idea - but one that makes things much more complicated than it needs to be. I'd guess that a massive fraction of developers simply cut and paste boilerplate code and guess their way through the naming exercise... And, I'm sure it could be neatly tucked away with clever defaults that can be overridden when you need to.

For example: your multiple shopping cart example: I'm sure most people start with one, and only add a second over time. Why not create a default JNDI reference initially and allow me to mutate this as my project evolves? In fact, I'd guess that most people stumble completely on the JNDI configuration hurdle and instead simple setup two JBOSS servers (which, for better or worse), is what I did ;-(

Anyway, when all this stuff works, it works very sweetly. So, for all my winging, I'm still an advocate.

Next time I might pay a little more attention to the standard setting process. Ruby anyone?