4:01 a.m.
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...
6:48 a.m.
Reposted from OPS4J lits:
Regarding Pax Exam and Husky these two frameworks are almost the same. And
both are working with an remote framework. Remote meaning that the Client
Runner and Osgi Framework are running in separate processes. Now, of course
that we do not share the same names like Conecor, invoker, bridge but
architecture wise is the same. With one diff: we consider that all the tests
have to run the osgi container and so we do not have the Bridge part in
every test method. In rest, all the things like extender based on manifest
headers, injection of bundle context, ...
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.
After all, I do not really care if there are other test frameworks over
there beside the split effort. As it looks like we think alike 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.
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 without the need to
implement the container explained above, could be used n Eclipse via Pax
Runner plugin, ... WDYT?
On Thu, Oct 15, 2009 at 12:01 PM, thomas.diesler(a)jboss.com <
do-not-reply(a)jboss.com> wrote:
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...
_______________________________________________
jboss-osgi-users mailing list
jboss-osgi-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-osgi-users
--
Alin Dreghiciu
Software Developer
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
7:07 a.m.
On Mon, Oct 19, 2009 at 5:18 PM, Alin Dreghiciu <adreghiciu(a)gmail.com>wrote:
Reposted from OPS4J lits:
After all, I do not really care if there are other test frameworks over
there beside the split effort. As it looks like we think alike 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.
+1, this way two communities could benefit from each other's effort. For
us in the OPS4J community, we will be happy to have you guys from JBoss
joining us, and JBoss could benefit by leveraging on the "simplicity fame"
that the OPS4J community has gained in the OSGi space.
Already commercial products are using OPS4J products - Apache ServiceMix4 /
Apache Felix Karaf that is commercially known as Fuse ESB is using Pax
projects successfully.
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 without the need to
implement the container explained above, could be used n Eclipse via Pax
Runner plugin, ... WDYT?
This will be a good starting point to users who are looking at bridging
traditional web applications and OSGi applications.
On Thu, Oct 15, 2009 at 12:01 PM, thomas.diesler(a)jboss.com <
do-not-reply(a)jboss.com> wrote:
> 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...
> _______________________________________________
> jboss-osgi-users mailing list
> jboss-osgi-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-osgi-users
>
--
Alin Dreghiciu
Software Developer
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
_______________________________________________
jboss-osgi-users mailing list
jboss-osgi-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-osgi-users
--
Thanks and Regards,
/Thomas Joseph
LinkedIn: http://www.linkedin.com/in/ethomasjoseph
Twitter: http://twitter.com/ethomasjoseph
Blog: http://openthoughtworks.blogspot.com
------------------------------------------------------------
Promote Open Source - Promote Liberty of Ideas and Software.
------------------------------------------------------------
4:09 a.m.
New subject: [JBoss OSGi Users] - JBossOSGi vs. Pax-Runner/Pax-Exam
Hi Alin,
I answered here
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261201#...
cheers
-thomas
On 10/19/2009 01:48 PM, Alin Dreghiciu wrote:
Regarding Pax Exam and Husky these two frameworks are almost the
same.
And both are working with an remote framework. Remote meaning that the
Client Runner and Osgi Framework are running in separate processes.
Now, of course that we do not share the same names like Conecor,
invoker, bridge but architecture wise is the same. With one diff: we
consider that all the tests have to run the osgi container and so we
do not have the Bridge part in every test method. In rest, all the
things like extender based on manifest headers, injection of bundle
context, ...
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.
After all, I do not really care if there are other test frameworks
over there beside the split effort. As it looks like we think alike
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.
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
without the need to implement the container explained above, could be
used n Eclipse via Pax Runner plugin, ... WDYT?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
6024
days inactive
6029
days old
jboss-osgi-users@lists.jboss.org
3 comments
4 participants
participants (4)
-
Alin Dreghiciu -
Thomas Diesler -
Thomas Joseph -
thomas.diesler＠jboss.com