I've checked under felix and knopflerfish profiles already - everything's alright there. I'll get to the docs as soon as possible. Should I already file a bug so we can continue our discussion there?
2013/6/7 Glyn Normington <[email protected]> > 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-strategy > reference/compendium/compendium.xml > 195: 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 the > > Would 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 <[email protected]> wrote: > > Hi Glyn > > I'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 <[email protected]> > >> 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 <[email protected]> >> >>> Windows? >>> >>> Regards, >>> Glyn >>> >>> >>> <pivotal-logo-email-signature.png> >>> >>> On 6 Jun 2013, at 14:21, Alexander Shutyaev <[email protected]> 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")? >>> >>> >>> 2013/6/6 Glyn Normington <[email protected]> >>> >>>> 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 <[email protected]> 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 <[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 >>>>> >>>>> >>>>> <pivotal-logo-email-signature.png> >>>>> >>>>> 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 >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >>> >>> <TEST-org.eclipse.gemini.blueprint.blueprint.config.NestedElementsTest.xml> >>> <TEST-org.eclipse.gemini.blueprint.DictionaryEditorTest.xml> >>> _______________________________________________ >>> >>> 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 >>> >>> >> > _______________________________________________ > 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
