Thinking a bit more, as long as you are only using DS components then you won’t
have a problem with recent felix DS’s as DS no longer ever sets the bundle
location, so all bundles will have access to it. If you also had a
ManagedService[Factory] using the configuration then you’d need to set the
bundle location to e.g. “?” as MS/MSF do set any missing bundle locations. On
the other hand I am not sure how many other configuration-consuming extenders
deal appropriately with these multi-locations.
I think the “need to update file twice” problem was reported and fixed recently
in config admin. I’m not sure if it’s released yet.
david jencks
> On Jan 11, 2017, at 1:31 AM, Christian Wolf <christian.wol...@gmail.com>
> wrote:
>
> Hi,
>
> As Carsten suggested in a previous email, I moved to scr 2.0.6. It is
> working fine. I don't have any problem regarding being notified of
> configurationPid changes for component defined in separated bundles (and
> sharing the same pid file).
>
> The problem I was talking about in my latest email was regarding the pid
> file first update and karaf 4.0.8 (for shared pid or pid not shared by any
> other bundle)
>
> When restarting karaf and updating the foo.bar.cfg pid file, the @Modified
> annotated method is invoked only after the second update/save of the file.
>
> I also noticed that if I set karaf.clean.cache = true (in
> karaf/etc/system.properties)
> the problem does not occur and the component @Modified method is invoked
> after every change of the file.
>
> As default, this property is set as follow:
> #
> # Deletes the karaf.data/cache directory at every start
> #
> karaf.clean.cache = false
>
>
> As I mentioned already, this problem does not occur with karaf 4.0.5.
>
> - Any thought about this?
> - Maybe I should now move this discussion to the karaf users mailing list?
>
> Thanks
> Christian
>
>
>
>
>
>
>
> On Tue, Jan 10, 2017 at 2:00 AM, David Jencks <david.a.jen...@gmail.com>
> wrote:
>
>> There is no bug in DS here. In order to use a configuration with more
>> than one bundle, you need to arrange that the configuration location be a
>> multi-location. normally you’d want “?” so any bundle can receive the
>> configuration. AFAIK fileinstall doesn’t support setting the location, so
>> the first bundle to start wins and no other bundle uses the configuration.
>>
>> david jencks
>>
>>> On Jan 9, 2017, at 8:17 AM, Christian Wolf <christian.wol...@gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I did more tests and I noticed the following behavior with karaf 4.0.8
>> and
>>> scr 2.0.6 (which does not occur with karaf 4.0.5 and scr 2.0.2).
>>>
>>> Having a simple pid defined as:
>>>
>>> @ObjectClassDefinition(pid = "foo.bar")
>>> public @interface MyConfig {
>>> String username() default "myuser";
>>> String url() default "http://localhost:8080";;
>>> }
>>>
>>> And a simple @Component bind to it:
>>>
>>> @Component(configurationPid = "foo.bar")
>>> @Designate(ocd = MyConfig.class)
>>> public class CompA implements MyInterfaceA {
>>>
>>> @Activate
>>> public void activate(MyConfig myConfig) {
>>> ...
>>> }
>>>
>>> @Modified
>>> public synchronized void modify(MyConfig myConfig) {
>>> ...
>>> }
>>> }
>>>
>>> When starting karaf 4.0.8, the @Activate method of my component in
>> invoked
>>> Then, I update the foo.bar.cfg pid file to change a property.
>>> From time to time and only for the first pid manual update:
>>> - the first update is detected by fileinstall, however, the @Modified
>>> related method of the @Component(configurationPid = "foo.bar") is not
>>> invoked.
>>> - using the config:property-list shows the right updated value.
>>> - updating and saving the file a second time triggers the @Modified
>>> annotated method of that component.
>>>
>>> This happens only from time to time when restarting karaf.
>>>
>>> I cannot reproduce this issue with karaf 4.0.5
>>>
>>> Question:
>>> - Did someone already noticed this?
>>> - Is it a regression?
>>>
>>> Thanks
>>> Kind Regards,
>>> Christian
>>>
>>>
>>> On Mon, Jan 9, 2017 at 1:06 PM, Christian Wolf <
>> christian.wol...@gmail.com>
>>> wrote:
>>>
>>>> Hi Carsten,
>>>>
>>>> Thanks for your quick answer.
>>>>
>>>> I've just tested with latest karaf 4.0.8 which ships with scr 2.0.6
>>>> => It is working now without changing any piece of code.
>>>> It seems that a fix has been provided between 2.0.2 and 2.0.6.
>>>>
>>>> Thanks for you advice
>>>>
>>>> Kind Regards,
>>>> Christian
>>>>
>>>> On Mon, Jan 9, 2017 at 10:38 AM, Carsten Ziegeler <cziege...@apache.org
>>>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think this should be possible the way you do it, so that's a "yes" to
>>>>> the first two of your questions at the end :)
>>>>>
>>>>> Before we start to look for a bug in the implementation, could you
>>>>> please check the scr 2.0.6 release and see whether it's already fixed
>>>>> there?
>>>>> If not, please open a jira ticket.
>>>>>
>>>>> Regards
>>>>> Carsten
>>>>>
>>>>> Christian Wolf wrote
>>>>>> Hi,
>>>>>>
>>>>>> I am using DS @Component and trying to get notified through @Modified
>>>>> when
>>>>>> a shared pid file is updated (using felix scr 2.0.2 in karaf 4.0.5)
>>>>>>
>>>>>> I defined a configuration interface such as:
>>>>>>
>>>>>> @ObjectClassDefinition(pid = "foo.bar")
>>>>>> public @interface MyConfig {
>>>>>> String username() default "myuser";
>>>>>> String url() default "http://localhost:8080";;
>>>>>> }
>>>>>>
>>>>>> Then, I have 3 differents classes with @Component annotation. All of
>>>>> them
>>>>>> are mapped to this pid "foo.bar".
>>>>>> Please note that each component is defined in separated bundles.
>>>>>>
>>>>>> @Component(configurationPid = "foo.bar", immediate = true)
>>>>>> @Designate(ocd = MyConfig.class)
>>>>>> public class CompA implements MyInterfaceA {
>>>>>>
>>>>>> @Activate
>>>>>> public void activate(MyConfig myConfig) {
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> @Modified
>>>>>> public synchronized void modify(MyConfig myConfig) {
>>>>>> ...
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> @Component(configurationPid = "foo.bar")
>>>>>> @Designate(ocd = MyConfig.class)
>>>>>> public class CompB implements MyInterfaceB {
>>>>>>
>>>>>> @Activate
>>>>>> public void activate(MyConfig myConfig) {
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> @Modified
>>>>>> public synchronized void modify(MyConfig myConfig) {
>>>>>> ...
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> @Component(configurationPid = "foo.bar")
>>>>>> @Designate(ocd = MyConfig.class)
>>>>>> public class CompC implements MyInterfaceC {
>>>>>>
>>>>>> @Activate
>>>>>> public void activate(MyConfig myConfig) {
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> @Modified
>>>>>> public synchronized void modify(MyConfig myConfig) {
>>>>>> ...
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> All these 3 components are activated.
>>>>>> When the corresponding pid file foo.bar.cfg is updated, the
>>>>>> modify(MyConfig) method surrounded with the @Modified annotations is
>>>>>> invoked only for one of them.
>>>>>> Moreover, the component that get updated randomly change when
>> restarting
>>>>>> the application.
>>>>>>
>>>>>> Question:
>>>>>> - Can @Component(s) of separate bundles be notified through @Modified
>>>>>> annotated methods when a shared pid file is updated?
>>>>>> - Is it possible to achieve this using annotation configuration
>> classes
>>>>> as
>>>>>> I did here with MyConfig class (with DS 1.3)?
>>>>>> - If not possible, is there any alternative solution to achieve this?
>>>>>>
>>>>>> Thanks for your help.
>>>>>> Kind Regards,
>>>>>> Christian
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Carsten Ziegeler
>>>>> Adobe Research Switzerland
>>>>> cziege...@apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>
>>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
