felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Leau <costin.l...@gmail.com>
Subject Re: Library Enabling Test Framework...?
Date Wed, 04 Jun 2008 15:01:25 GMT
Toni Menzel wrote:
> Yes, documentation is on the way.
> The project goals as well as the main obstacles for not using springDM's implementation
can be found here:
> https://scm.ops4j.org/repos/ops4j/laboratory/users/tonit/incubator/drone/README
Hi Toni,

I wasn't aware of the obstacles you mentioned in your link  - have you 
considered reporting or discussing this issues on Spring-DM mailing 
list/forum? We're keen on improving the user experience.

Since the topic was opened, I'd like to (briefly) address the issues 
mentioned in the README:

a) "it pulls in a lot of dependencies (about 8 extra bundles that are 
just infrastructure)"
A:  this is completely customizable. In fact all the jars are read from 
  a property file which can be modified (declaratively or 
programatically). Only half of the bundles (or less) are needed - the 
rest are provided as convenience for installing Spring-DM 
infrastructure. If size is an issue, the util methods used can be 
potentially implemented locally but frankly, the extra 50-100K doesn't 
seem to be worth it. For 1.1.x we played with the idea of profiles but 
we postponed this for 1.2 (see below). However, you can do this yourself 
now by selecting what bundles you want installed based on some criteria.

b) "uses base-classloader to hold and transfer data from the osgi framework"

This is actually on purpose. Remoting involves serialization which is 
quite slow. To improve performance we went from small serialization (the 
initial design) to class loading which improved performance around 20% 
on a simple code base. The numbers are not accurate since we didn't do 
extensive benchmarking but it did show improvements in the nightly 
builds. Everything takes place inside the same VM so the test results or 
all the objects and their state are returned to the IDE in pristine 
state, w/o any transformation. Remoting was not (nor is) on the roadmap 
but we can consider it (there are many things that can be said on OSGi 
and remoting).

c) "hard to extend (singletons, classloader tricks,big classes,many 

The testing framework was aimed initially for Spring-DM alone. It can be 
customized quite a lot and extended (from OSGi platforms to how bundles 
are retrieved or installed). Since we use Junit 3, we're forced to have 
certain parents and are somewhat limited in what we can do.
However, post 1.1, we plan to improve the testing framework by 
integrating it with JUnit 4 and TestNG.

As for the singletons, that's actually on purpose - you don't want to 
start a new OSGI framework for each test inside your test case. The same 
for the Spring application context. If you really want to, then just 
write another test case.
Again, the consideration here is speed.

I'd be curios to know what sort of issues you ran with regard to class 
loading as it doesn't interfere with plugability nor extension. You keep 
mentioning but I don't see why this is a problem.

These being said, I don't want to hijack this thread so please, if you 
want to follow up (I hope you do), please consider using the Spring-DM 
forum/mailing list.


> There will be an official announcement on the ops4j mailinglist along with "real" documentation
on the ops4j wiki somehwat next week. (hope every one is subscribed to it ;-) ?)
> till then,
> /Toni
> -------- Original-Nachricht --------
>> Datum: Wed, 4 Jun 2008 16:41:26 +0300
>> Von: "Alin Dreghiciu" <adreghiciu@gmail.com>
>> An: dev@felix.apache.org
>> Betreff: Re: Library Enabling Test Framework...?
>> As Guillaume pointerd out, Spring DM Testing support should be able to
>> solve your use case.
>> Toni Menzel is also working on such a testing support as part of Pax
>> Drone, which is now in hie incubator but I expect that soon to be
>> "ready" to use. There is no documentation yet about, but soon. Toni?
>> Alin Dreghiciu
>> On Wed, Jun 4, 2008 at 3:55 PM, Alex Karasulu <akarasulu@apache.org>
>> wrote:
>>> Niclas, Robert,
>>> It sounded to me as if Robert was more interested in a integration
>> testing
>>> framework rather than the build tool used to generate the manifest and
>> build
>>> the bundle.  Please excuse me if I'm wrong here tho.
>>> I just wanted to say that Directory too would like to start using OSGi
>> but
>>> the biggest impediment to date is having a good mini/micro integration
>>> testing framework to test our components in the container right after
>> the
>>> bundle is generated by Maven for that module.  We don't want to have to
>>> create a foo module then a foo-test module just to integration test
>> since
>>> this will lead to a (Maven) module explosion.  It would be nice to have
>> a
>>> JUnit-ish framework for in situ testing OSGi bundles inside target
>>> containers.
>>> Like Robert we want to take bundle foo and make sure if it's a library,
>> the
>>> classes there in function properly by running some tests that access
>> those
>>> classes within the container.  If foo bundle exposes a service we'd like
>> to
>>> get a handle on that service and start running some tests on it etc.
>>> I think such a framework would help increase uptake.
>>> Best Regards,
>>> Alex
>>> On Wed, Jun 4, 2008 at 8:37 AM, Niclas Hedhman <niclas@hedhman.org>
>> wrote:
>>>> On Saturday 31 May 2008 15:02, Robert Burrell Donkin wrote:
>>>>> over in JAMES, we'd like to OSGi enable our upcoming library releases
>>>>> so that they can be used unforked in OSGi environments. the plan is
>> to
>>>>> use the maven plugin but we don't have a lot of OSGi experience. so
>>>>> i'd like to add some integration tests to check that the libraries
>>>>> function ok when used in an OSGi environment. this seems a reasonably
>>>>> general requirement and i was wondering about a general integration
>>>>> testing micro library to test that a library was correctly enabled.
>>>> Robert,
>>>> I think the first necessary step is to incorporate the so called BND
>> tool
>>>> into
>>>> your build. If you are using Maven, then there is a plugin available
>> here
>>>> to
>>>> make it easier.
>>>> BND recursively walks through the classes and figures out what is
>> needed
>>>> and
>>>> compares that against a "recipe" that you specify. The recipe can
>> either be
>>>> explicit (in which case every import has to specified or else an error)
>> or
>>>> you use wildcards (less recommended).
>>>> The recipe also contains information about which packages should be
>>>> Exported,
>>>> ignored and kept private.
>>>> With BND it is not too hard to maintain the recipe (typically an
>> external
>>>> file), and will lower the initial need for in-container tests.
>>>> Setting it up is easy, if you know what you are doing, so I suggest
>> that
>>>> someone here volunteers (Stuart???) to help you out.
>>>> Cheers
>>>> --
>>>> Niclas Hedhman, Software Developer
>>>> I  live here; http://tinyurl.com/2qq9er
>>>> I  work here; http://tinyurl.com/2ymelc
>>>> I relax here; http://tinyurl.com/2cgsug
>> -- 
>> 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.
>> http://malaysia.jayway.net - New Energy for Projects - Great People
>> working on Great Projects at Great Places

View raw message