OpenEJB integration in Cactus (was FW: [hausmates] Two new projects: xjb and proxytoys)

[Vincent Massol <vm...@pivolis.com>]

Hi guys,

I think it would be interested for us to offer an OpenEJBTestSetup in
the same way that we have a JettyTestSetup (http://tinyurl.com/29omo).

That would also mean creating a sample project in
jakarta-cactus/samples/openejb to automatically test it functionally.

+ some lightweight documentation (same as
http://jakarta.apache.org/cactus/integration/integration_jetty.html).

Any taker? :-) 

(I'm a bit busy right now but I'm writing this email as a reminder for
later).

Thanks
-Vincent

> -----Original Message-----
> From: hausmates-admin@lists.codehaus.org [mailto:hausmates-
> admin@lists.codehaus.org] On Behalf Of David Blevins
> Sent: 09 April 2004 11:58
> To: hausmates@lists.codehaus.org
> Subject: Re: [hausmates] Two new projects: xjb and proxytoys
> 
> On Fri, Apr 09, 2004 at 08:03:41AM +0100, Joe Walnes wrote:
> > Having seen both of these in actions I'm really impressed.
> >
> > XJB is the cleanest and simplest solution I've seen so far for
testing
> > EJBs and the only one that fits with the rapid development cycle of
TDD.
> >
> > public void testMyThing() {
> >  new EjbJarConfigurator().read(new FileReader("ejb-jar.xml")); //
> > configure XJB from deployment descriptor
> >  MyThingHome home = (MyThingHome)new InitialContext().lookup(); //
> > lookup home of EJB under test
> >  MyThing myThing = home.create(); // create it
> >  assertEquals("hello joe", myThing.sayHelloTo("joe"));
> > }
> 
> Just a note on this whole thread, there is some project out there that
> prides itself on being fast, lightweight, and embeddable :-)
> 
> OpenEJB comes with a mock TransactionManager and SecurityService and
> runs with InstantDB (defunct but usable) or HSQLDB.  You can run it in
> any test suite, client app, ant build, whatever.  James even got it
> running in Groovy.
> 
> 
> Just download and unpack 0.9.2, then copy the openejb_loader-0.9.2.jar
> into your project's classpath.  Setup is done.
> 
> Then just use ejb's in your test code like you would anywhere else.
> 
> ----------
> protected void setUp() throws Exception{
>     Properties props = new Properties();
>     props.put(Context.INITIAL_CONTEXT_FACTORY,
>         "org.openejb.client.LocalInitialContextFactory");
>     props.put("openejb.home", "C:\openejb-0.9.2");
>     ctx = new InitialContext(properties);
> }
> 
> public void testMyThing() {
>    //  lookup home of EJB under test
>    MyThingHome home = (MyThingHome)ctx.lookup("MyThingEJB");
>    // Create it
>    MyThing myThing = home.create();
>    assertEquals("hello joe", myThing.sayHelloTo("joe"));
> }
> ----------
> 
> That's all there is to it.  The EJB container alone (no fancy server
> stuff) is automatically embedded right into the test suite and you are
> able to do anything you want with it.  No starting/stopping required.
> If you want to run the same test code against a remote server, just
> replace LocalInitialContextFactory with RemoteInitialContextFactory.
> 
> We always test twice, once with everything embedded (aka local) and
> again with client and and beans in separate VMs (aka remote).  It's
> very very frequent to find things work great when it's all embedded
> but blow up as soon as things are actually serialized over a network.
> 
> Here is a test example that shows just about every type of method
> invocation possible:
> 
> http://cvs.sourceforge.net/viewcvs.py/openejb/openejb/src/tests-
> ejb/org/openejb/test/stateless/StatelessRmiIiopTests.java
> 
> (Bob, would have used http://cvs.openejb.codehaus.org, but it's not
> working :)
> 
> Ignore the numbers on the test methods; it's no longer required now
that
> junit runs things in top-down order.
> 
> Here are some docs:
>   http://www.openejb.org/embedded.html
>   http://www.openejb.org/remote-server.html
> 
> 
> IMHO, I'd love to have more people excited about easy EJB testing on
the
> OpenEJB project.  Having mock implementation of everything important
would
> be a unit testing dream.  Being able to pick which parts are real and
> which ones are fake would be unit testing nirvana.
> 
> The goal of OpenEJB is to give people EJB without the "heavy."
> Something they can use for even the smallest app.  It lives for neat
> things like this.
> 
> -David Blevins
> 
> 
> 
> 
> 
> 
> 
> 
> >
> > * The EJBs do not need to be modified in any way.
> > * This does not require any external container to run.
> > * XJB simulates the container, including EJB generation, lifecycle,
> > container managed transactions, datasources, JNDI, etc.
> > * It runs very quickly with little overhead.
> > * No extra classes need to be written.
> > * XJB has very minimal and clean code.
> >
> > -joe
> >
> >
> > Dan North wrote:
> >
> > >Hi all.
> > >
> > >I have a couple of projects I'd like to propose for hosting in the
> > >codehaus. Aslak suggested I mail the list to see what you all
think.
> > >
> > >The first is XJB, which is a test harness for EJBs. It creates a
JNDI
> > >context - new InitialContext().lookup("some/resource") - and homes
and
> > >remotes for session beans. It parses (multiple) ejb-jar.xml's and
> > >"deploys" into a unit testing context, so you can test legacy EJBs
> > >with a single line of setup:
> > >
> > >    new EjbJarConfigurator().read(someReader); // you could suck
the
> > >ejb-jar.xml out of a jar on the classpath
> > >
> > >It also manages DataSources and Connections, so is appropriate for
> > >integration testing, and (nearly) handles CMT.
> > >
> > >Out of that, I abstracted a couple of goodies (with Aslak's help)
> > >based on dynamic proxies, into a mini-project called proxytoys. One
in
> > >particular creates Null Objects, named after Josh Bloch's
description
> > >in Effective Java. Usage is:
> > >
> > >    Foo foo = (Foo)Null.object(Foo.class); // where Foo is an
interface
> > >
> > >A null object returns null objects for any method call. So methods
> > >that return a Collection class return the appropriate
> > >Collections.EMPTY_SET/LIST/MAP, array methods return a zero-length
> > >array, primitives return the default primitive value (false, zero,
> > >etc). Aslak has provided cglib integration for concrete classes as
> > >well. The working name for the null object part of proxytoys is
> > >"nothing". Aslak's cglib integration is called "nothing else".
Hence:
> > >- nothing works like a proxy
> > >- nothing else works like cglib
> > >(ba-dum tchah!)
> > >
> > >Of course, everything is completely test-driven and will have a
> > >business-friendly license (think: pico license with pico crossed
out
> > >and xjb written above it in crayon).
> > >
> > >So, let me know what you think.
> > >
> > >One more thing - I've been using subversion, and it rules. I'd like
to
> > >load a subversion dump into the codehaus svn repository rather than
go
> > >back to cvs, and then take it from there.
> > >
> > >One more thing (ok, so I lied) - Scott Crawford of the EJB 3.0
working
> > >group is very interested in XJB, and wants to see it open-sourced
with
> > >a web site that he can direct the rest of the working group
towards.
> > >So I'd really appreciate any help I can get in setting up a simple
> > >static site at codehaus to describe XJB and its usage patterns.
> > >
> > >Cheers,
> > >Dan (North - ThoughtWorks geek/coach for those who don't know me)
> > >
> >
> > _______________________________________________
> > hausmates mailing list
> > hausmates@lists.codehaus.org
> > http://lists.codehaus.org/mailman/listinfo/hausmates
> _______________________________________________
> hausmates mailing list
> hausmates@lists.codehaus.org
> http://lists.codehaus.org/mailman/listinfo/hausmates


---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org