Community
Participate
Working Groups
Virgo would benefit from support in Pax Exam ([1]) 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. I have flagged this enhancement as "helpwanted" because it's a relatively separate function to the main Virgo runtime and anyone could have a go at it, particularly anyone with some experience of Pax Exam. The following helpful comment appeared on the General OPS4J list: On 5 Jan 2012, at 04:19, Andreas Pieber wrote: >Hey Glyn, > >Since Virgo has a quite similar concept to Apache Karaf it might be possible to >do something similar for Virgo as I've done for Karaf. TBH I'm not sure how >different Virgo is from Karaf but maybe some sources can even be reused: > >This https://github.com/openengsb/labs-paxexam-karaf had been merged here: >https://svn.apache.org/repos/asf/karaf/trunk/tooling/exam/ > >Kind regards, >Andreas [1] http://team.ops4j.org/wiki/display/paxexam/Pax+Exam
With Pax Exam 2 now being stabilized, it appears to me that adding Virgo support is a very good idea for both sides. A little explanation on what container types are currently supported (as of 2.3). All container implementations can be used as test targets. Replacing containers is just a matter of putting one or the other on the class path Test Containers have the following lifecycle: start stage(bundles*) run(test pointer) unstage/clear stop On remote containers, start/stop can be left out of cause. Essentially its a quite simple interface, don't you think? Here's which containers exist: (1) Pax Runner Container this basically means that every container you can start with pax runner like so: pax-run.sh --platform=equinox --version=3.7.0 can be used as a test target. Pax Runner is roughly speaking a configuration file generator. Giving inputs (like list of bundles, start levels, options, JVM etc.) it generates config files and potentially launches the VM or generates launch scripts. However, this is old news. With the advent of OSGi standardizing the launch API, its fairly simple to write custom generic launchers, framework agnostic. This is used in the so called "Native Test Container" in Exam 2: (2) Native Test Container This container uses the OSGi 4.2 Launch API to launch and provision a OSGi framework in a vendor agnostic way. Other than (1) it does not spawn another JVM for the target framework, making the entire roundtrip faster but drops some options (like adding JVM options or choosing different JVMs for targets) Adding a new framework support to this container is a 0-effort: if it implements the launch api. (3) Karaf Test Container Somewhat a special thing for karaf, since its a full blown assembly on top of a felix or equinox providing default bundles, some management helpers etc. So essentially users might want to go with container (2) instead but as a convenience its just much simpler saying "run that test against Karaf Version XY". Conceptually, this container certainly can be implemented as a set of options on container (2). As far as i know, this container can take Karaf assemblies (zip) and use that. Its running in its own JVM which improves isolation but makes debugging harder for example (remote debugging required). The Karaf Test Container implementation lives inside the Karaf Projects at ASF so its not bound to Exam release cycles. For Virgo: We need to take a look at the current Virgo version to decide if Virgo should be targeted as an option for container (2) or strip out the common parts from (3) and go with that.
Another consideration is Virgo's user region support which is present in Virgo Kernel, Virgo Tomcat Server, and Virgo Jetty Server, but not present in Virgo Nano (and any future non-Kernel extensions of Nano). When a user region is present, it is necessary either to use the Virgo deployer to install/start bundles in the user region or to use some bundle context in the user region to do a regular bundle install, in which case the new bundle will be installed in the user region and can be started as normal. When no user region is present, the situation is essentially similar to vanilla Equinox. So it might be easiest to start with Virgo Nano support of Pax Exam and step up to user region support in a second phase of development.
(In reply to comment #1) > (2) Native Test Container > This container uses the OSGi 4.2 Launch API to launch and provision a OSGi > framework in a vendor agnostic way. > Other than (1) it does not spawn another JVM for the target framework, making > the entire roundtrip faster but drops some options (like adding JVM options or > choosing different JVMs for targets) > Adding a new framework support to this container is a 0-effort: if it > implements the launch api. For Virgo Nano, option 2 seems the quickest/cheapest to start with. We should only go with option 3 if 2 proves to have significant limitations. Equinox does implement the OSGi 4.2 launcher API, but note that the Virgo startup scripts (dmk.sh and dmk.bat in bin/) currently invoke org.eclipse.equinox.launcher.Main.
Oh it's probably worth pointing out that Virgo is tied to Equinox, so no need to worry about other OSGi framework implementations!
