On Aug 28, 2007, at 2:55 PM, deniskulik wrote:
Hi David,
Here is a couple of thoughts on your previous message.
David Blevins wrote:
I've put together a doc with the options: http://cwiki.apache.org/
OPENEJB/application-discovery-via-the-classpath.html
I looked at the article, which is very useful, however I failed to
kick off
the container using any approach other then using openejb.xml. Here
is what
I did to use the container with maven:
1. Option with using an empty ejb-jar.xml.
I placed an empty ejb-jar.xml in the src/test/resources/META-INF
directory,
then ran the mvn clean package command. This approach didnt work (I
got
MalformedURLException).
This wouldn't work unless your ejbs were in src/test/java (i.e. both
go to target/test-classes/ eventually).
Then I placed an empty ejb-jar.xml in the src/main/resources/META-INF
directory, then ran the mvn clean package command. This approach
didnt work
either(I got MalformedURLException).
But this way should totally work. That's the way we do it here:
http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/
expanded-env-entries/
Can you post the full log output and stack trace?
2. Option with using classpath.include parameter.
I have tried all 4 patterns mentioned in that section and all of them
failed. In some cases it was MalformedURLException again, in other
cases the
container didnt seem to pick up annotated ejbs from the classpath
and I got
NameNotFoundException.
I must be missing something, cant think of anything though.
Only thing I can think of is some windows issue. I.e. maybe we're
doing something silly with paths. The log output and stack trace
should provide some insight.
David Blevins wrote:
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?
I guess this option is quite handy, especially when you need to
provide some
configuration other than default and you dont want to mess with the
code. As
I noticed the conf directory contains a banch of other config
files, so I
would think its a good idea to keep them all in one place. It looks
like you
can move the conf directory around the classpath quite easily, you
only have
to provide the openejb.configuration parameter with the value
relative to
the classpath which points to the conf directory.
You raise some good points and you really have me liking the conf/
approach more and more. I'm not totally sure we support it in the
classpath, i.e. packed in jar. If we don't, we definitely should.
The way you can move the conf directory around the classpath is
touched on
above, more specifically you would need to set the correct
parameter values
that must be relative to the classpath. For example, if the
location of the
conf directory is target/classes/conf then we have to add this line to
initialise the initial context:
properties.setProperty("openejb.configuration",
"./target/classes/conf/openejb.xml");
Right. Seems if we cleaned this one part up somehow, the whole thing
would go from nice to great. Having to specify that relative path
and deal with restrictions on where you can run the test is a real
downer.
If we could support something like this, life would be so much easier:
properties.setProperty("openejb.configuration", "classpath://conf/
openejb.xml");
Thoughts?
David Blevins wrote:
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?
I guess it depends on the audience. Its seems to be a tradition now to
demonstrate new apps using some simple Hello World example. But for
the sake
of more advanced users I would say tests alone would do the trick.
Right, I was thinking the bean could say Hello World to the test case
and the test case could print it out if it wanted. Just to show the
round trip.
David Blevins wrote:
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.
I wonder what will happen then with the rest of the config files?
Do you
suggest moving all of them in the resources directory as well?
Yea, maybe not the best of ideas. If we can get the above stuff in
place, we probably don't need to do this part.
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).
So if I have two containers for stateful session beans (with short
and long
session timeout) how would the container decide which one to use?
By default you get the first container in your openejb.xml that
matches the bean type, but you can explicitly set the container for
any bean via an openejb-jar.xml like the following:
<openejb-jar>
<ejb-deployment ejb-name="TestBean" container-id="No Timeout
Stateful Container">
<ejb-deployment ejb-name="AnotherBean" ...
</openejb-jar>
And note that you don't have to have an ejb-jar.xml to do that and
you don't have to list all of your beans if you do elect to have an
openejb-jar.xml.
-David
