I think Eclipse Virgo would benefit from support in Pax Exam as our in-container test framework is relatively poorly documented and certainly Virgo specific. Prior to v3.5, Virgo had its own special launcher, but now that 3.5 milestone 1 is shipped, it is launched via the standard Equinox launcher so I would imagine it would be relatively easy to cobble together Pax Exam/Pax Runner support for Virgo 3.5 by starting from what is already available for Equinox.
Unfortunately, I don't have many cycles to commit to this personally, but if anyone reading this list is interested in lending a hand, I'd be happy to hear from them. ;-) (Apologies if this is slightly off-topic as Virgo is a "straight" OSGi server in the sense that all Java applications are deployed as bundles or groups of bundles. WAR files are converted to Web Application Bundles before they are installed. So Virgo support is probably achievable without Harald's branch. I wanted to chime in at this point though as it would be excellent to end up with an in-container test framework that spanned all the major OSGi and perhaps also JEE servers.) Regards, Glyn On Wednesday, 4 January 2012 at 18:09, Toni Menzel wrote: > 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 > (mailto: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 (mailto: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/ > > > [2] > > > http://www.java.net/forum/topic/glassfish/glassfish/using-glassfish-pax-exam > > > > > > Best regards, > > > Harald > > > > > > _______________________________________________ > > > general mailing list > > > general@lists.ops4j.org (mailto:general@lists.ops4j.org) > > > http://lists.ops4j.org/mailman/listinfo/general > > > > > > _______________________________________________ > > general mailing list > > general@lists.ops4j.org (mailto:general@lists.ops4j.org) > > http://lists.ops4j.org/mailman/listinfo/general > > > > > > -- > Toni Menzel Source (http://tonimenzel.com) > > _______________________________________________ > general mailing list > general@lists.ops4j.org (mailto:general@lists.ops4j.org) > http://lists.ops4j.org/mailman/listinfo/general > >
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
