> What you are seeing is an example of that and welcome your feedback - and > from what you're saying it sounds like you would like that standardised.
Yes, I haven't played much with Aries but that's my impression it's nice to standardize it. If something called "extension" is used in let's say 60% of use cases than for me it's not an extension any more. It's just wording but what I mean here is that a good spec should cover 70% of use cases fully. Would you agree? Best regards, Lukasz -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jeremy Hughes Sent: Tuesday, May 18, 2010 12:50 PM To: [email protected] Subject: Re: questions to Overview.ppt On 18 May 2010 08:22, Lichota, Lukasz <[email protected]> wrote: > 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 ;-) For now that is correct - the sample is bound to a non-standard namespace. In Aries we didn't want to limit ourselves to implementing finished specifications: "The project will develop extensions that go beyond the OSGi EEG specifications to provide a more complete integration of OSGi modularity with Java enterprise technologies ..." [1] We are actively working on new, not-yet-standardised technology which could potentially be standardised. What you are seeing is an example of that and welcome your feedback - and from what you're saying it sounds like you would like that standardised. [1] http://wiki.apache.org/incubator/AriesProposal > > 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%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 > > > >
