aries-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bartosz Kowalewski <>
Subject Re: questions to Overview.ppt
Date Mon, 17 May 2010 20:55:12 GMT
Hi Valentin,

I got an impression that Lukasz was thinking of a way to unit test the 
whole Blueprint bundle outside of an OSGi container. By saying _the 
whole bundle_ I mean classes + the blueprint definitions. I don't think 
that it is possible in Apache Aries. However, when I saw this 
presentation, this was my first impression: "Aries provides some kind of 
tooling for testing Blueprint bundles outside of an OSGi container. 
That's cool! No more 1 minute long Pax Exam tests just for checking if I 
made a typo in simple Blueprint definitions :)."
When using Spring DM extender it was a best practice to split the 
context into two files: a non-OSGi dependent one and an OSGi based one. 
It was possible to test the former one outside of an OSGi container. 
This was really helpful - some fundamental mistakes were caught early 
and simple tests were only run on pure Spring bean without OSGi 
(services, references, cm-properties, etc.). This caused running the 
whole test suite to take much less time. I don't think that it possible 
with Blueprint and if it was, probably a seperate test jar containing a 
dedicated tooling would need to be released together with each Aries 


Valentin Mahrwald wrote the following on 5/17/2010 9:51 PM:
> Hi Lukasz, 
> comments below :)
> Valentin
> On 17 May 2010, at 13:36, Lichota, Lukasz wrote:
>> I have a few questions to this 
>> presentation:
>> 1. Slide #6 - Simplifies unit test outside either Java EE or OSGi r/t.
>> How can blueprint context can be unit tested outside OSGi? Any example?
> Might have misunderstood your question, so apologies if I am trying to 
> answer a different question.
> I think here the point is that dependency injection as an 
> architecture, if correctly employed, should make code more testable by 
> fostering very loose, interface driven coupling.
> In OSGi particular terms one benefit for example would be testing 
> components that interact with the OSGi service registry. Using only 
> the OSGi APIs code like the following (abridged, not bad practice!) 
> would be non-trivial and rather annoying to unit test.
> class MyActivator {
> ...
> public void start(BundleContext ctx) {
> ServiceReference ref 
> = ctx.getServiceReference(GreetingService.class.getName());
> GreetingService service = (GreetingService) ctx.getService(ref);
> service.greet();
> }
> }
> One would have to mock up BundleContext, the getServiceReference and 
> getService method calls.
> Whereas the equivalent(ish) code with blueprint should be 
> significantly easier to unit test since all the code for actually 
> getting hold of an OSGi service is handled by the container. (Similar 
> benefits would be derived from using declarative services) In general 
> since the integration is metadata driven and not encoded in code, the 
> unit testing code does not have to handle it at all.
> class Greeter {
> private GreetingService service;
> public void setGreeter(GreetingService service) { this.service = 
> service; }
> public void start() {
> service.greet();
> }
> }
> <blueprint>
> <bean class="MyBean" init-method="start">
> <property name="greeter">
> <reference interface="GreetingService" />
> </property>
> </bean>
> </blueprint>
> Of course there are still pain points of unit testing code that is 
> injected with Bundle, BundleContext or BlueprintContainer objects. But 
> even then blueprint offers benefits in that the BundleContext does not 
> have to be carefully passed from the Activator through layers of 
> objects to wherever it is needed.
>> 2. Slide #8 For integration of blueprint with jta/jpa aries specific 
>> namespaces are used.
>> xmlns:jta="/"
>> xmlns:jpa=/""/
>> Are there plans to include it in specification? Why doesn’t the spec 
>> address integration with blueprint? (which is also covered by the spec).
> As far as I understand blueprint extension namespace were originally 
> part of the blueprint spec but were dropped fairly late in the day due 
> to technical issues. 
> I would expect that some of these extensions might be tackled in a 
> future revision of the EEG spec.
>> Best regards,
>> Lukasz

View raw message