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: http://cwiki.apache.org/
OPENEJB/application-discovery-via-the-classpath.html
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
http://openejb.apache.org/
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
{
super.setUp();
Properties properties = new Properties();
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");
properties.setProperty("Default\ Stateful\ Container.PoolSize",
"0");
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.
-David
