Hi David, Here is a couple of thoughts on your previous message.
David Blevins wrote: > > 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 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). 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). 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. 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. David Blevins wrote: > > > 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. > > 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"); 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. 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? David Blevins wrote: > >> 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). > 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? -- View this message in context: http://www.nabble.com/Setup-tutorial--tf4337589.html#a12377193 Sent from the OpenEJB User mailing list archive at Nabble.com.
