Cool Sahoo!! I am looking into enforcing the effort building a more general Exam3 based on Haralds Branch and your Ideas.
FYI, i just got to track the branch on the OPS4J CI: http://ci.ops4j.org/hudson/job/org.ops4j.pax.exam3/ Now don't mess it up. Almost there ;)) Toni On Wed, Jan 4, 2012 at 7:04 PM, Sanjeeb Sahoo <www.sa...@gmail.com> wrote: > 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 > > [1] > http://java.net/projects/glassfish/sources/svn/content/trunk/fighterfish/test/gfpaxtc/src/main/java/org/glassfish/fighterfish/test/gfpaxtc/GlassFishTestContainerFactory.java > > > On Tue, Dec 27, 2011 at 2:01 AM, Harald Wellmann < > hwellmann...@googlemail.com> wrote: > >> With Pax Exam 2.x, you can write tests which launch an OSGi container, >> automatically install a test probe bundle, inject container dependencies >> into the test and invoke test methods within the container. >> >> Now why should the container be limited to an OSGi framework and the >> probe be limited to a bundle? >> >> The same approach works for Java EE: the container is an (embedded) Java >> EE server, the probe is a WAR built on the fly, and the injection method is >> CDI. >> >> There is a growing number of Java EE servers which are built on OSGi >> and/or offer an OSGi subsystem for deploying bundles in addition to >> traditional WARs. >> >> Thus, an in-container testing framework should support both modes, OSGi >> and Java EE, to let you test hybrid applications. >> >> As it happens, I created the jeeunit project [1] in 2010 for testing my >> Java EE 6 projects - long before I started working with Pax Exam. >> >> The more I work with these two projects, the more I feel they are really >> two sides of the same coin. >> >> jeeunit supports GlassFish 3.1, JBoss AS 7 and Resin 4. Recently, its >> scope has broadened to cover other containers and injection methods in the >> guise of Tomcat 6 and 7 and Spring. There is no OSGi support. >> >> Pax Exam on the other hand supports practically all OSGi frameworks, but >> no Java EE or servlet containers. >> >> Now I'm proposing to merge jeeunit into Pax Exam to provide adequate >> testing capabilities for containers that support hybrid OSGi plus Java EE >> applications and to offer a unified testing approach for users who switch >> between OSGi, Java EE and Spring. >> >> Working with a pure OSGi or a pure Java EE container, the resulting Pax >> Exam 3.0 would be equivalent to either Pax Exam 2.x or jeeunit, but on a >> hybrid container, Pax Exam 3.x would let you deploy and test WARs and >> bundles at the same time. >> >> This should be doable by introducing a bunch of new options like war(), >> mavenWar() and a number of new pax-exam-container-foo modules. >> >> As a proof of concept, I've started working on a GlassFish Container, >> guided by Sahoo's usage of Pax Exam 2.1 for testing OSGi bundles and WABs >> on GlassFish [2]. >> >> I'm looking forward to your comments on this idea. >> >> [1] http://code.google.com/p/**jeeunit/<http://code.google.com/p/jeeunit/> >> [2] http://www.java.net/forum/**topic/glassfish/glassfish/** >> using-glassfish-pax-exam<http://www.java.net/forum/topic/glassfish/glassfish/using-glassfish-pax-exam> >> >> Best regards, >> Harald >> >> ______________________________**_________________ >> general mailing list >> general@lists.ops4j.org >> http://lists.ops4j.org/**mailman/listinfo/general<http://lists.ops4j.org/mailman/listinfo/general> >> > > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > > -- Toni Menzel Source <http://tonimenzel.com>
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
