Kevin sais:
anonymous wrote :
| Congrats on the release, I am looking forward to playing with it.
|
| Can you explain the benefits of our own integration over something like the
pax-runner/pax-exam framework? I have been using those for OSGi work and am very happy
with it, what functionality do you provide above and beyond theirs?
|
| Do you plan on supporting Knoplerfish?
|
pax-runner/pax-exam is probably not much different to jboss osgi runtime/husky as long as
you use the felix or equinox, in an embedded scenario.
The main objective of JBoss OSGi however is to bring OSGi functionality to the JBoss
Application server. That JBoss OSGi has its own standalone runtime and can be bootstrapped
embedded in you application is a by-product if you like.
With Beta4 you also get the first Alpha release of our own OSGi Framework implementation
that is based on the JBoss Microcontainer.
Q: Why would we want to write our own OSGi Framework, if there are good open source
alternatives out there?
A: Because eventually we want to bring added value to our customers that they can leverage
the OSGi technology and at the same time talk to existing services that are deployed on
JBoss. We would like to access OSGi services from EJB3, MCBeans, MBeans, WebBeans, and
vica versa. This type of cross-component model integration would not be possible if we
deployed a 3rd party framework like Felix or Equinox into JBoss.
For details on the various runtime model see:
http://jbossosgi.blogspot.com/2009/06/jboss-osgi-runtime-as-integration.html
Because JBoss integration is at the heart of everything I do, I needed to find a way to
write a plain JUnit4 test case and run that against multiple OSGi Frameworks in embedded
mode as well as integrated in JBoss.
So what I actually do in Hudson is:
#1 build the installer
#2 auto execute the installer with a choice of container/framework
#3 run the test suite against that installation using a given jdk
I that way I can be sure that every functionality I ship and advertise actually runs in
JBoss. Pax-Exam does not support the notion of remote OSGi Framework AFAIK.
If you'd like to read more on Husky, have a look at
http://jbossosgi.blogspot.com/2009/10/osgi-unit-testing.html
Here is the set of requirements that I had
# The solution MUST support plain JUnit4 POJO test cases
# There SHOULD be no requirement to extend a specific test base class
# There MUST be no requirement on a specific test runner
# There SHOULD be a minimum test framework leakage into the test case
# The test framework MUST support embedded and remote OSGi Runtimes with no change
required to the test
# The same test case MUST be executable from outside as well as from within the OSGi
Framework
# There SHOULD be a pluggable communication layer from the test runner to the OSGi
Framework
# The test framework MUST NOT depend on OSGi Framework specific features
# There MUST be no automated creation of test bundles required by the test framework
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260471#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...