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
version.
Thanks,
Bartek
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: https://svn.apache.org/repos/asf/incubator/aries/slides/Apache%20Aries%20-%20Overview.ppt
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="/http://aries.apache.org/xmlns/transactions/v1.0.0/";
xmlns:jpa=/"http://aries.apache.org/xmlns/jpa/v1.0.0"/
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
