| Re: [gemini-dev] Property propagation (a contribution) |
Great news that the tests are passing now. If you want to be really thorough, you should check they pass with the Felix and Knopflerfish profiles too, if you haven't already.
As for the docs, I think they really are outdated if the following is any indication:$ pwd/Users/gnormington/dev/eclipse/org.eclipse.gemini.blueprint/docs/src/docbkx[localhost:docbkx master]$ ack update-strategyreference/compendium/compendium.xml195: one can configure <literal>managed-properties</literal> element to receive configuration updates through the <literal>update-strategy</literal>231: <osgix:managed-properties persistent-id="labX" update-strategy="container-managed"/>236: <osgix:managed-properties persistent-id="labY" update-strategy="bean-managed" update-method="updateCallback"/>252: <entry><literal>update-strategy</literal></entry>381: <entry>update-strategy</entry>418: update-strategy="bean-managed"469: Finally, due to the specified <literal>update-strategy</literal>, any updates executed to each CM configuration will cause theWould you be able to provide a correction to the docs as a separate patch which you could then base the patch for the new docs upon?Regards,
Glyn
On 7 Jun 2013, at 07:27, Alexander Shutyaev <shutyaev@xxxxxxxxx> wrote:Hi GlynI've started looking into the documentation sources and found them a little bit outdated. It seems that the managed-service-factory is described as it was in schema spring-osgi-compendium-1.2.xsd while even in the latest release (1.0.2) the latest version is spring-osgi-compendium-2.0.xsd or gemini-blueprint-compendium-1.0.xsd. One of the differences is that update-strategy attribute in managed-service-factory which is mentioned in the documentation was replaced by autowire-on-update attribute in the latest schema. Moreover, I've checked that the online documentation and the documentation which ships with 1.0.2 release has the same outdated information. As my new attribute's behavior somehow depends on autowire-on-update I need it to be present in the docs :) Could you please check whether the docs are really outdated or am I missing something?2013/6/6 Alexander Shutyaev <shutyaev@xxxxxxxxx>Nope, I'm on ubuntu. I've tried it on Windows with the same jdk version. Everything works fine. I can confirm that both before and after my changes all tests pass.
2013/6/6 Glyn Normington <gnormington@xxxxxxxxxxxxx>Windows?Regards,
Glyn
<pivotal-logo-email-signature.png>On 6 Jun 2013, at 14:21, Alexander Shutyaev <shutyaev@xxxxxxxxx> wrote:Ok, I've tried running tests on the project without my modifications. I've git-cloned it about an hour ago. Then I've run mvn clean test -Pit,equinox from the project's root folder.I'm getting about 190 test error in core module. They seem weird. Most of them are because a classpath resource that is created is null (see attached NestedElementTest.xml report). Next there are two tests that fail because System.out is null (see attached DictionaryEditorTest.xml report). There may be other types of errors but because the number of failures is so high it's hard for me to find if there are any others.The weirdness of these failures has lead me to believe I was missing something in the environment. I've tried switching the jdk (from 1.6.0_43 to 1.7.0_21) but the errors are the same. Maven version is 3.0.5.Do you have any clues? Should I maybe post a new thread so the others would see it under a more appropriate title (like "tests fail")?<TEST-org.eclipse.gemini.blueprint.blueprint.config.NestedElementsTest.xml><TEST-org.eclipse.gemini.blueprint.DictionaryEditorTest.xml>_______________________________________________2013/6/6 Glyn Normington <gnormington@xxxxxxxxxxxxx>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
<pivotal-logo-email-signature.png>On 6 Jun 2013, at 10:58, Alexander Shutyaev <shutyaev@xxxxxxxxx> wrote:Hi Glyn1. 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 <gnormington@xxxxxxxxxxxxx>
Hi AlexanderThanks 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 <shutyaev@xxxxxxxxx> wrote:<property-propagation.patch>_______________________________________________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 propagationThis 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
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev
_______________________________________________
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev
_______________________________________________
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev
_______________________________________________
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev
_______________________________________________
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev
_______________________________________________
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev
_______________________________________________
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev