Hi Valentin,
Thanks for answers, for #2 it's a pity that it was dropped. I think if community is to really benefit from having a spec then all things typically used should be there. And since this "extension" happens to appear in basic example in "overview" presentation it simply means it's something commonly used. The conclusion is that even 'hello world' example would be bound to implementation ;-) The same touches cm and ext namespaces for blueprint. Best regards, Lukasz ________________________________ From: Valentin Mahrwald [mailto:[email protected]] Sent: Monday, May 17, 2010 9:51 PM To: [email protected] Subject: Re: questions to Overview.ppt 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%2 0-%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
