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 >
