I commonly read about using session beans as the place to implement business logic. What I'm wondering is should that logic be implemented directly in the beans, or implmented in other plain java classes and then have the session beans extend or wrap them. What is considered best practice?

Dont extend them, remember session beans have lot of remote functionality. use them. the general notation is writing business logic in helper classes and later using instances to work along with the session bean. If you are interested in finding best practices and patterns in ejb env. then go through the book EJB patterns available on this site in book section, thatz a best place to start with.

Regards
Chetan

I have seen people put logic in POJO's to try and make unit testing easier. At the end of the day it is easier to work with JUnit than something like Cactus that is designed for in container testing.

This approach usually breaks down when you need to reference container resources like database connections.

David

Unit testing aside - generally speaking it's a good idea to consider putting business logic in POJOs called from the Session Bean. The Session Bean (and the logic it invokes) is still benefiting from interactions with the container. You won't lose things such as remote calls and transaction support but you gain a considerable amount of flexibility in the way a method call on the session bean behaves. Look into the Session Facade pattern.

As far as using JUnit on a local environment when data access or some like backend resource is involved, you can always stub out expected behavior of the component that provides access to the resource.

>
> As far as using JUnit on a local environment when data access or some like backend resource is involved, you can always stub out expected behavior of the component that provides access to the resource.

Stubbing out is an option but an option that gets more and more complex business as the number of external interfaces your system uses increase. In the end we use cactus and unit test within the container.

This discussion does make me think of the old saying "there is no problem that can not be solved by using a layer of indirection" :-).

David

Agreed David,
  Cactus is created for that purpose. I guess I'm quick to offer stubbing out because I've built up a hard wired response to people who claim it slows them down to unit test :-).
- Kevin

When testing POJOs with JUnit, instead of using a container's DataSource connection, just grab your own JDBC connection to the DB. WOrks like a charm.

OK, so if I put the code into plain ol' java objects and use them in my session beans I come up with a different problem. Assuming I put those POJO's in a separate jar file and have multiple session bean that need to get to it, what's the best way to make that jar available to my session beans within the container?

Add an entry in the Session Beans jars manifest to the jar file the POJOs are in.

But I can't deploy that pojo.jar unless it's in a particular ejb module/jar. So is my only option for deploying that pojo.jar to put it in an ear file? How else can I even get it in the container?

Depending on the context under which you are deploying, you might want to consider a WAR. Either way using a WAR or EAR is a good idea because it gives you more control over what classloader you are using. BTW - What brand of server are you using?

I'm using WebLogic, but want to be careful I do not do anything that is server specific.

What I've tried now is putting ejb1.jar and pojo.jar into ejb1.ear. ejb1 has to access ejb2, which is already loaded in the contain from its ejb2.jar.

The first thing I tried was putting a class-path line into ejb1.jar's manifest.mf like this: Class-Path: ..\ejb2\ejb2.jar.

When I deploy ejb1.ear the weblogic deployer complains that it can find "NoClassDefFoundError" on a home class in ejb2.

I thought I was on the right track there, but I noticed that the ear file itself has a manifest.mf. I updated that one with the same class path info, but got the same result. So, now I'm wondering if I can't access classes outside an ear regardless of the class-path entry in my manifest.mf. Any ideas?

In WebLogic the class loader hierarchy is the following:
-System
  - EAR
    - WAR
where the WAR is contained inside the EAR. Visibility for the class loader goes down but not up, so a class loaded by the system class loader will not find a class loaded by a class loader assigned to a specific EAR, while a class loaded by an EAR's class loader has visibility of the entire system classpath. This is where a large value add comes into play when you deploy your enterprise all within one EAR and possibly subdivided into WARs within the EAR depending on how many applications your enterprise contains. The simple answer is to put your classes in the system classpath but that is very problematic when you want to start to deploy different versions of the same class. Do yourself a favor and keep your classes out of the system classpath.

I meant to say up but not down :-)