Hi Glyn 1. I've looked at their latest release source code. It seems that they propagate all properties (both private and public) and there is no way to turn it off. I'll write a test to confirm this. So I guess the answer is 'partially yes but rather no' :)
2. The problem is I can't get all the tests pass on the original project :) I've tried to do something about it but then I gave up. While I developed I ran only PropertyPlaceholderTest and my PropertyPropagationTest (they are very much alike in the setup procedures). They both pass. However, I understand that rules are rules so I should ensure that tests pass. I'll try once again to get the original project's tests to pass. And if I succeed I'll run them with my patch applied. However if I don't succeed I may require your help to get the original tests to pass. 3. No new dependencies except from Apache Felix Configuration Admin version upgrade from 1.2.4 to 1.2.8. 4. I'll start working with the docs. 5. As for raising a bug - should I do it already? A new one or is there an existing one? 2013/6/6 Glyn Normington <[email protected]> > Hi Alexander > > Thanks for raising this contribution. Some questions: > > 1. Does Apache Aries Blueprint support this function? > > 2. Does the build pass, including all tests, with your patch applied? > > 3. What new build or runtime dependencies does this patch require, if any, > in addition to upgrading Felix config admin? > > I welcome comments from the other Gemini Blueprint committers, but the > next step should be to raise a bug and attach the code. We'll need to do IP > due diligence and obtain a documentation patch before we can commit the > code. One of us can easily review your English, which looks good so far! > > Regards, > Glyn > > > > On 6 Jun 2013, at 09:39, Alexander Shutyaev <[email protected]> wrote: > > Hi all! > > Recently I've developed an enhancement for Gemini Blueprint and I want to > contribute it. The description is below, the patch is attached (must be > applied to project's root dir). Any suggestions are welcome! If this > contribution is accepted (which I very much hope will happen :) I'm ready > to make changes to the documentation (although English is not my native so > maybe a final revision from a native speaker would be nice :) > > Property propagation > > This contribution is inspired by the Section 104.4.4 "Property > Propagation" of the OSGi Configuration Admin specification. First, let me > quote it. > > ===== > A configuration target should copy the public configuration properties > (properties whose name does not start with a ’.’ or \u002E) of the > Dictionary object argument in updated(Dictionary) into the service > properties on any resulting service registration. > > This propagation allows the development of applications that leverage the > Framework service registry more extensively, so compliance with this > mechanism is advised. > > A configuration target may ignore any configuration properties it does not > recognize, or it may change the values of the configuration properties > before these properties are registered as service properties. Configuration > properties in the Framework service registry are not strictly related to > the configuration information. > > Bundles that follow this recommendation to propagate public configuration > properties can participate in horizontal applications. For example, an > application that maintains physical location information in the Framework > service registry could find out where a particular device is located in > the house or car. This service could use a property dedicated to the > physical location and provide functions that leverage this property, such > as a graphic user interface that displays these locations. > > Bundles performing service registrations on behalf of other bundles (e.g. > OSGi Declarative Services) should propagate all public configuration > properties and not propagate private configuration properties. > ===== > > At present Eclipse Gemini Blueprint does not provide such functionality. > The goal of this contribution is to add support of it. > > Now, to the implementation details. *managed-service-factory* element now > has a new property - *propagate-properties* (boolean, default=false). If > it's set to true then the following changes apply: > > - during the initial instance creation all public properties (those whose > name does not start with '.') are propagated as service properties of the > resulting service registration. > > - during the initial injection both public and private properties are > injected into the instance bean; the private properties get their first dot > removed before injection; in case there is a name conflict between private > and public property during injection, private property takes precedence > > - if *autowire-on-update* is set to true then the subsequent injections > are done in the same manner and service properties are also updated. > > More specific implementation details can be seen in the code itself. There > is also a new integration test - PropertyPropagationTest that covers the > described functionality. > > P.S. Apache Felix Configuration Admin implementation used in tests had to > be updated from v1.2.4 to v1.2.8 because v1.2.4 for some reason prohibits > configuration properties that start with dot. > > Best regards, > Alexander > <property-propagation.patch> > _______________________________________________ > gemini-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/gemini-dev > > > > _______________________________________________ > gemini-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/gemini-dev > >
<<pivotal-logo-email-signature.png>>
_______________________________________________ gemini-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/gemini-dev
