On 18 May 2010 13:30, Lichota, Lukasz <[email protected]> wrote: >> 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?
The Blueprint spec specifically describes 'Extensions' in section 121.3.3. So it provides a standard way of writing extensions in non-standard namespaces :-) It is up to the OSGi Alliance and members as to whether the JPA and JTA extensions we have in Aries will be pulled into the Blueprint specification, stand in their own specification or get added to the JPA or JTA spec accordingly. So I think extensions *can* remain extensions if they are used 60 or 70% of the time ... it's just another way of saying something is modular. > > 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 >> >> >> >> >
