Re: [gemini-dev] Property propagation (a contribution)

[Glyn Normington]

Thanks. I think your highest priority should be to get the tests to pass before raising a bug. Unfortunately, I don't have much detailed knowledge of Gemini Blueprint internals. I'm acting as a caretaker project lead until such time as a project lead can be found who has the necessary time and/or existing expertise in the codebase. This means I probably won't be much help debugging failing tests. Your best best would be to do as much analysis as you can and if you are still stuck, post to this list and hope the other committers can help. I'm afraid this might cost you quite some time. I guess another strategy would be to get all the tests passing without your changes and then phase the changes in gradually so you can narrow down very quickly which part of your change is breaking a test. I'd certainly adopt that approach if I was you. Hope that helps! Regards, Glyn On 6 Jun 2013, at 10:58, Alexander Shutyaev <shuty...@gmail.com> wrote: 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 <gnorming...@gopivotal.com> 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 <pivotal-logo-email-signature.png> On 6 Jun 2013, at 09:39, Alexander Shutyaev <shuty...@gmail.com> 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 gemini-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/gemini-dev _______________________________________________ gemini-dev mailing list gemini-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/gemini-dev _______________________________________________ gemini-dev mailing list gemini-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/gemini-dev

_______________________________________________
gemini-dev mailing list
gemini-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/gemini-dev