tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Setup tutorial?
Date Tue, 28 Aug 2007 01:11:13 GMT
This is fantastic feedback!  Thank you.  Impressively organized for  
notes -- we could probably put this right on the website once we get  
the setup steamed out.

Likely going to include some of the answers in our documentation, so  
forgive me if they are a bit long :)  I really hope it's not too  
overwhelming.  Please ask us to simplify if it's just too much.

On Aug 27, 2007, at 11:50 AM, deniskulik wrote:

> We will start off by going through this little check list and  
> making sure we
> have everything in place before setting up the OpenEJB container.

FYI, great checklist and nice little sample app.

> Option 1 (Using OpenEJB without Maven 2)
> 1.Include OpenEJB dependences in your classpath. You can include  
> all jars
> from the OpenEJB's lib directory for simplicity.
> 2. Include conf directory in your class path. The conf directory must
> contain openejb.xml file with the following contents (this  
> essentially tells
> the container where to find ejb classes for deployment):
> <?xml version="1.0" encoding="UTF-8"?>
> <openejb>
>     <Container
>         id="Default CMP Container"
>         ctype="CMP_ENTITY">
>     </Container>
>     <Deployments dir="bin" />
> </openejb>

First thing of note is that you shouldn't need an openejb.xml file or  
conf dir.  Having one is fine, but it should be possible for the test  
case to do 100% of the driving with OpenEJB simply in your classpath  
as any other library would be.

I've put together a doc with the options: 

As noted in that doc, the empty ejb-jar.xml involves the least  
overhead in setup and in load time.  Definitely the recommended option.

I personally didn't think people would like to use an openejb.xml  
file while testing, but it's not a bad option.  If you like that  
option best we could perhaps improve it so you could put the  
openejb.xml anywhere in your classpath eliminating the need to have  
to create a conf directory for your test case.  Or perhaps an  
alternate idea would be to allow you to set the path of the conf  
directory.  Thoughts, preferences?

Also, any feedback on how you got down the conf/openejb.xml path  
would be fantastic as we could improve the "flow" by adding better  
documentation or program output in the places you looked.  A keenly  
placed README can do wonders sometimes as well just the right text in  
just the right place.

> 3. Run the test and check the output, which should read something  
> similar to
> this:
> Apache OpenEJB 3.0.0-SNAPSHOT    build: 20070823-10:19
> OpenEJB ready.
> Hello World!

You can definitely check the output of your bean code by having it  
return "Hello World!" in addition to printing it.  We've focused on  
making the OpenEJB side of the testing as invisible as possible, but  
it occurs to me that maybe people might like a way to get some sort  
of "everything is good" sign via code.  What do you think?

> Option 2 (Using OpenEJB with Maven 2)
> 1. Update the pom file of your project with the following  
> configuration:
> <dependency>
>     <groupId>org.apache.openejb</groupId>
>     <artifactId>openejb-core</artifactId>
>     <version>3.0.0-SNAPSHOT</version>
>     <scope>test</scope>
>     </dependency>
> </dependencies>
> 2. Include conf directory in your class path. The conf directory must
> contain the same openejb.xml file as mentioned in the Option 1  
> above. There
> are seem to be two ways of doing so.

Perhaps we could setup just plain "/openejb.xml" as a path we search  
in the classpath (after conf/openejb.xml of course) allowing you to  
simply add the openejb.xml to the src/main/resources directory.

> 3. Run the test and check the output. This is where things get  
> confusing
> (for me anyway). The output will first show a warning saying that
> ejb-jar.xml cannot be found and after a series of other steps we  
> will see a
> MelformedURLException message

Those two warnings need to get downgraded to info or perhaps debug.   
Thanks for pointing them out.  Just the kind of feedback we need.

> But then the output will show
> that the new configuration was eventually created (although it  
> looks like we
> have 2 containers now) and our test finally passed with the Hello  
> World
> message being printed out.
> I suppose I messed something up along the line but cant figure out  
> what
> exactly without having any docs at hand.
> Also, there are a number of container types mentioned in the container
> configuration tutorial, but it would be very helpful to know what  
> they mean
> and what are the implications of using one or another.

Here's the 411 on that and please tell us how/where to communicate  
this better.

OpenEJB has several containers, one for each type of bean: bmp entity  
bean, cmp entity bean, stateless session bean, stateful session bean,  
and message driven bean.  Each container has different configuration  
properties and each can be declared (aka "instantiated") in your  
openejb.xml several times, each time with different configuration.   
(perhaps you want two stateful session bean containers, one with a  
short session timeout and one with no session timeout at all say for  
deploying system services as stateful session beans).

In your openejb.xml file you declared a cmp entity container, so we  
loaded it at boot time.  Then when your bean was deployed we  
discovered you didn't have a container capable of running it (i.e. no  
stateless session bean container) so we created one automatically for  
you with the default configuration and deployed your bean into it.

We will create anything your app needs that isn't found in the  
openejb.xml file including JDBC DataSources, JMS Topics and Queues,  
etc.  We log all the things we auto-create for you so that you could  
potentially add those things to your openejb.xml if you desired.

I hope this isn't getting to advanced to quickly, but it is also  
possible to change the configuration of these containers in your test  
case to achieve different effects.  The most common by far is setting  
up the Default Stateful Container so that it has no pool and therefor  
forces your bean to be activated and passivated on each method call  
allowing you to actually *test* that the @PrePassivate (aka.  
ejbPassivate) and @PostActivate (aka ejbActivate) methods are  
implemented correctly.

You'd simply do like this:

protected void setUp() throws Exception

     Properties properties = new Properties();
     properties.setProperty("Default\ Stateful\ Container.PoolSize",  
     properties.setProperty("Default\ Stateful\  
Container.BulkPassivate", "1");

     initialContext = new InitialContext(properties);

That's it for now :)

Thank you very much, Denis.  We definitely appreciate the energy.   
You're feedback is really going to help us tune the usage path to be  
as intuitive as possible.  We want to find and eliminate any possible  
places where a user might feel lost or confused or left wondering  
what's going on.


View raw message