Hi Sahoo,
thanks for your feedback! Yes, I'd looked at your Fighterfish test
projects before I started implementing the new Pax Exam GlassFish
Container, which made it a lot easier to get started, and of course I'm
also trying to avoid duplicate work.
No doubt I'll be back in while with questions about GlassFish internals
for polishing the implementation of pax-exam-container-glassfish - at
the moment I'm still exploring how to generalize Pax Exam's APIs without
losing 2.x compatibility.
So far, I'm rather pleased with how easy it is to use GlassFish in an
embedded OSGi framework (whereas the official Embedded GlassFish API is
non-OSGi).
The road to Pax Exam 3.0.0 will probably take a couple of months, but
I'm planning to provide a 3.0.0.M1 milestone release focused on
GlassFish as soon as possible. That should be doable within the next few
weeks, but of course I won't name a specific date ;-)
I've started creating JIRA issues with Fix Version = 3.0.0, and there's
a new road map page in the Pax Exam wiki:
http://team.ops4j.org/wiki/display/paxexam/Roadmap
As always, comments and features requests are more than welcome.
Best regards,
Harald
Am 04.01.2012 19:04, schrieb Sanjeeb Sahoo:
Hi Harald,
I like this idea as well. When I was evaluating pax-exam as an
integration test framework for FighterFish project, I had successfully
experimented the idea of a native container implementation using
GlassFish [1]. It was attempted with two goals in mind, viz:
a) to ease development of integration tests for hybrid (Java EE + OSGi)
bundles using GlassFish,
b) to not bootstrap GlassFish during every test run.
Unlike yours, the scope of my experiment was limited to GlassFish and it
was a prototype only. It was using older pax-exam SPIs and Toni did tell
me then that the interfaces were evolving, so I am not at all surprised
that it does not compile any more. As PAX-EXAM 2 stabilized, I could
achieve these goals to a reasonable extent by writing a small utility
bundle. This strategy has worked out fine so far. In fact, we do have
scenarios in our test suite where we deploy regular Java EE (non-osgi)
applications in addition to deploying OSGi bundles to test interaction
between vanilla Java EE and hybrid applications. This is straight
forward while using GlassFish because of existence of an embeddable API
that gives access to underlying administrative command execution framework.
It has been in my TODO list to resurrect the experimental test
container, make it compliant with latest exam interfaces and broaden the
scope to include support for remote (non-embedded) GlassFish. I will
closely watch the development here to avoid duplicate efforts.
Thanks,
Sahoo
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
