On 29.04.2009, at 09:08, Toni Menzel wrote:
The "separate VM" is a followup of our default Pax Runner based
TestContainer implementation.
As such, there can be (many) different TestContainer implementations.
Its just a matter of convinience you lose when not using the pax
runner
richness.
If there is demand for a "native" felix testcontainer, we could do
so in
quite a short amount of time.
Yes, there is a demand :-).
As you know, I did some test with pax-exam. I find it pretty cool, but
my main issue is that it dramatically slow...
For example, running 2000 test case with junit4osgi (same VM isolated
classloader) takes around 5 minutes
20 tests with pax:exam and the pax-runner container takes around 3
minutes.
I agree that sometimes having a separated VM is great to avoid side-
effects... But providing an alternative would be great:
-(sometimes we're looking about side effects), but of course I have
ideas about that that we can discuss (playing with test suite, were
each test suite run it's own OSGi container...).
Clement
Toni
On Wed, Apr 29, 2009 at 9:01 AM, Guillaume Nodet <gno...@gmail.com>
wrote:
Cool. Just one question though. How difficult would it be to run
the
tests in the same JVM in an isolated classloader ? It would make
debugging way easier than having to hack the test to add the
necessary
jvm option for remote debugging.
2009/4/29 Alin Dreghiciu <adreghi...@gmail.com>:
About tests, afaik iPojo will move also towards Pax Exam. We are
discussing
with Clement about doing the necessary changes in Pax Exam to
support all
features required by iPojo tests which were available in junit4osgi.
On Tue, Apr 28, 2009 at 4:45 PM, Guillaume Nodet <gno...@gmail.com>
wrote:
The past days, I've been working on the blueprint implementation
inside Geronimo [1].
The spec is still being written so the implementation is not really
stable and is still missing a lot of features.
However, it's already somewhat usable and as I've hacked Karaf to
start using blueprint instead of spring-dm in a branch [2].
Tests do not even compile, but I've been able to start the
console, so
I thought I would talk about it a bit.
This raises the question whether we want to switch to blueprint
instead of spring-dm.
I think we should, and even have to, given that Spring-DM will
switch
to support Blueprint at some point in the future too. Also the
blueprint spec is way better than spring-dm wrt to namespace
handlers
(that are considered dependencies, so we would not have problems
with
namespace handlers not being available when a bundle is started)
and
classloading (i think classes loaded for namespace handlers will be
loaded from the namespace handler bundle, thus freeing the bundle
to
import all the namespace handlers packages), though those areas
are in
flux.
If so, we might even want to do that before renaming the
packages, as
the patch is quite big and would be quite broken after the rename
imho
...
As for tests, we'd have to switch to something else, which could be
junit4osgi from iPojo or pax-exam for example.
Feedback welcome.
[1] https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint
[2]
https://svn.apache.org/repos/asf/felix/sandbox/gnodet/karaf-
blueprint/
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Alin Dreghiciu
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven
Development.
Looking for a job.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Toni Menzel
Independent Software Developer - Looking for new projects!
Professional Profile: http://www.osgify.com
Blog: tonitcom.blogspot.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
