test infrastructure for OSGi

[dan.j.allen]

We would like to provide a complete infrastructure for integration testing OSGi applications. This is an interesting direction for Arquillian because it demonstrates that Arquillian is not limited to, or tied to, Java EE containers.

The goal is to provide support for writing JUnit or TestNG test cases that are executed in-container, where the container is the OSGi framework. The testing scenario for OSGi parallels that of Java EE:

• start the OSGi framework
• install and start the bundles required for the test (as defined in the @Deployment method)
• package the test case itself into a bundle, generate a manifest and install it in the OSGi framework
• execute the test case inside the OSGi framework
• shut down the OSGi framework
• pass the test results back to the originating test case instance that is running outside of the OSGi framework

The reason we want to provide this support is because  testing OSGi bundles is hard. You need to generate the OSGi bundle header from the classes in the test case. As we have control of the classpath through ShrinkWrap, generating the header should be straightforward, as should setting up the container.

There are currently two JIRA issues to track this support:

• ARQ-73: OSGi test container (Arquillian)
• SHRINKWRAP-179:  Ability to generate OSGi bundle headers

In short, we need to be able to:

• generate an OSGi bundle with ShrinkWrap
• implement the DeployableContainer SPI in Arquillian to start/stop the OSGi framework and deploy/undeploy the bundle
• implement a deployment appender to include the test case in an OSGi bundle

If you are interested in helping with this feature, we encourage you to join #jbosstesting on freenode to ask questions.

[caniszczyk]

• generate an OSGi bundle with ShrinkWrap

I'm not sure how involved this is but essentially we just need to build a JAR and add metadata to the MANIFEST.MF

• implement the DeployableContainer SPI in  Arquillian to start/stop the OSGi framework and deploy/undeploy the  bundle

I should be able to do this in a generic fashion using the new FrameworkFactory API in OSGi so it will be framework agnostic. I will start with Equinox as my test bed as that's what I'm familiar with. Any pointers to a sample implementation that I can look at?

• implement a deployment appender to include the test case  in an OSGi bundle

Is this another SPI? Can you be more specific?

[dan.j.allen]

Chris Aniszczyk wrote:

• generate an OSGi bundle with ShrinkWrap

I'm not sure how involved this is but essentially we just need to build a JAR and add metadata to the MANIFEST.MF

Yep. As Andrew Rubinger (ALR) like to put it, this is CS 101 stuff. If you could spare some time, it would be best if someone well versed in OSGi like yourself has a hand in this just so that nothing gets overlooked.

• implement the DeployableContainer SPI in  Arquillian to start/stop the OSGi framework and deploy/undeploy the bundle

I should be able to do this in a generic fashion using the new FrameworkFactory API in OSGi so it will be framework agnostic. I will start with Equinox as my test bed as that's what I'm familiar with. Any pointers to a sample implementation that I can look at?

Great!

The best example to look at is likely the embedded CDI containers (for Weld, for OpenWebBeans) since they are examples of standalone bootstrap frameworks (as opposed to application servers).

• implement a deployment appender to include the test case in an OSGi bundle

Is this another SPI? Can you be more specific?

Hmm, I'm a little fuzzy on this because OSGi is a different type of a container than what we've been dealing with so far.

Deployment appender is an implementation of this SPI:

org.jboss.arquillian.spi.AuxiliaryArchiveAppender

The purpose is to allow the Arquillian container implementation to add extra deployments into the container that are needed for the test. These fall into two catagories:

• The infrastructure for the unit testing framework (see JUnitDeploymentAppender)
• Test enrichers that are used to perform dependency injection into the test class.

I have a feeling we are going to need an OSGi version of the JUnitDeploymentAppender (or upgrade the archive it produces to an OSGi bundle). The idea is that the test runs "in-container", so you need to make the test and test framework visible to the container and then use some sort of protocol to negotiate the execution of the tests. In Java EE containers, an HTTP servlet is used. I think for OSGi we need to use a BundleActivator to kick off the test case. This is new territory for Arquillian.

Aslak can provide more details and recommendations.

[aslak]

Welcome to the team Chris!

• generate an OSGi bundle with ShrinkWrap

I'm not sure how involved this is but essentially we just need to build a JAR and add metadata to the MANIFEST.MF

In the simplest case we support this right now. You can add your classes and add your own MANIFEST.MF. But we're looking for a bit more integrated api to the MANIFEST.MF/OSGI descriptor. If you look at what I played with a while ago you might get the general idea;

http://shrinkwrap.pastebin.com/zikd1gSD It uses the BND tools in the background to generate the descriptions etc.

You know more about the content of the MANIFEST.MF and how OSGI people build/use this stuff  then me. Maybe that approach is not the ideal? My first question when i was doing it was 'where do I get the dependency versions from?'.

[aslak]

In my play attempt I did the following:

• I used Felix and added the Arquillian core packages to the System Path in it's config
• A new DeploymentPackager that merged some of the AuxiliaryArchives with the ApplicationArchive into a new OSGi bundle.
• A new OSGi TestRunner(see ServletTestRunner) service deployed as part of the Deployment
• I also had a special ContainerMethodInvoker to forward the test case method invoke to the installed TestRunner service.

We're working on API/SPI for Arquillian managed Object to support injection of other things then just EJB/Resource/CDI Beans. e.g. InitialContext, Servlet URLs etc. As a part of this and OSGi; BundleContext, Service, ServiceReference object might be candidates.

{code:java}
@ArquillianResource
private BundelContext context;
@Test
public void shouldHandle(MyOSGIService service) throws Exception() 
{
  context...
  service....
}
{code}