[jboss-user] [JBoss OSGi Users] - Re: JBossOSGi vs. Pax-Runner/Pax-Exam

[thomas.diesler@jboss.com]

anonymous wrote : 
  | And both are working with an remote framework. Remote meaning that the Client Runner and Osgi Framework are running in separate processes.
  | 

Husky supports OSGi testing in a remote container. i.e. You can have a jboss instance running somewhere on the network and test osgi bundle functionality in that remote osgi environment.

For details on the various runtime model see: http://jbossosgi.blogspot.com/2009/06/jboss-osgi-runtime-as-integration.html

anonymous wrote : 
  | we consider that all the tests have to run the osgi container
  | 

This is ok for isolated functional tests, but not for integration tests, where osgi bundles need to interact with container provided services.

anonymous wrote : 
  | I would even say that Pax Exam adds more to the table because you can configure the osgi framework use for tests for things like system properties, boot delegation packages, system packages, provisioned bundles, ... IT may be that Husky supports that too but was not obvious from the blog post.
  | 

Husky does not assume that a framework needs to be configured/started in any way. It is the responsibility of the TestCase or test environment to provide the Framework. A Husky Test gets the system BundleContext injected.

The Service Provider Interface (SPI) takes care of the abstraction of the Framework. This includes configuration and also its embedded/remote nature

http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapDeveloperGuide.html#SecSPI

http://jbmuc.dyndns.org/jboss-osgi-1.0.0.Beta4/apidocs/org/jboss/osgi/spi/testing/package-summary.html

I agree that this is not clear enough from the blog post and probably also not covered sufficiently in the user guide.

We can fix that documentation aspect in Beta5:  
https://jira.jboss.org/jira/browse/JBOSGI-185

anonymous wrote : 
  | why don't you join us? Pax Exam provides an extension point where you can plug in another test container , beside pax runner based one. Implement that based on JBoss and just have it in the classpath and your pax exam tests will be running in JBoss. 
  | 

Currently, I can parametrize the jboss osgi testrun like this


  | mvn -Dtarget.container=jboss520 -Dframework=felix test
  | 

For details please see

http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapProvidedExamples.html#SecBuildAndRunExamples

This is part of the key requirements I have on the testing framework used by JBoss OSGi. 

Additionally, as we move forward towards integration with existing jboss services. It will become necessary that we can deploy/test various other components. The test framework will have to support the (remote) deployment/access of EJB3, WebBeans, MBeans, ESB endpoints, etc.

This might not all be on the PAX-Exam roadmap. Neither is it clear that it even should be. 

anonymous wrote : 
  | Actually the collaboration could be batter as we can work on adding support for JBoss in Pax Runner. This will mean that jboss can be easy started and used by pax runner users, directly used in Pax Exam
  | anonymous wrote : 
  |   | 
  |   | This has a dependency on the JBoss Embedded project. It is not as easy as you might think to bootstrap JBoss as part of a unit test and it can certainly not be done as part of every TestCase setup. In this respect, what applies to an OSGi Framework does not necessarily also apply to a whole Application Server.
  |   | 
  |   | Again, strategically it is important that whatever test framework JBoss OSGi uses - it must support integration aspects with a (remote) instance of the JBoss Application Server.
  |   | 
  |   | It is mandatory that we actually test what JBoss OSGi users do (i.e. they deploy OSGi bundles in JBoss).
  |   | 
  |   | What appears like a big overlap between Husky and PAX-Exam now, might turn out to be not so critical if you consider the scope of test functionality that JBoss OSGi actually has. i.e. we test much more than OSGi bundle functionality in a Framework that runs in a different process.
  |   | 
  |   | Nevertheless, I am also open towards cooperation and it would be good if JBoss OSGi could simply "use" a test framework, without being its primary maintainer.
  |   | 
  |   | Thanks for your feedback

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261201#4261201

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261201