Things are clear now.
I'll try to find in which version the "need to update file twice" problem
has been fixed and check if available in karaf 4.0.X
Thank you all for you answers.
Regards,
Christian
On Wed, Jan 11, 2017 at 8:02 PM, David Jencks <david.a.jen...@gmail.com>
wrote:
> 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
>
>
