:-) > On 13 Mar 2017, at 16:21, Daghan ACAY <daghana...@hotmail.com> wrote: > > Thanks for your comments. I agree the last one was an edge case and not very > useful in practical scenarios. It was only question to understand life cycle > in a better way and not abuse it unnecessarily. > > Regards > - Daghan > > Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails > as clean, short chats. > > > > -------- Original Message -------- > From: Peter Kriens <peter.kri...@aqute.biz> > Sent: Monday, March 13, 2017 07:25 PM > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Subject: Re: [osgi-dev] Building a "profile" system with declarative services > and configuration admin? > >> On 13 Mar 2017, at 12:57, Daghan ACAY <daghana...@hotmail.com >> <mailto:daghana...@hotmail.com>> wrote: >> Hi peter, >> >> As a clarification, i can see this design allows multiple ProfileRunner >> instances (actually as many as IRCProfile configurations) at runtime where >> each ProfileRunner has zero or more IRFfilters whose properties obeys the >> LDAP filter defined by the filters_target value. Now for each ProfileRunner >> instance filters_target value can be configured at runtime through web >> console or @ConfigurerExtender using filters.target in json. Am i right? >> > Yes >> My second clarification is about life cycle of ProfileRunner. If i change >> the IRCProfile configuration of an existing ProfileRunner instance then that >> instance will be recreated and IRFFilters will be injected to the newly >> created instance. Am i right? >> > Yes >> Now two tricky ones. >> >> 1- if we had defined configuration for IRFFilter as you have suggested and >> assume we have for a single IRFFilter component e.g "filter=log". Again >> assume this IRFFilter instance is already injected to one of the existing >> ProfileRunner instance. If i change the IRFFilter component’s property to >> "filter=uppercase", is this IRFFilter removed from the List<IRFFilter> >> without destroying the existing ProfileRunner instance? > Yes because it is a volatile list. This makes the reference dynamic > >> 2- If you had @updated method defined for ProfileRunner and changed the >> filters_target value for an existing ProfileRunner instance from >> (filter=uppercase) to (filter=log), what happens to the List<IRFFilter> >> member, are they refreshed according to the new filters_target value, >> without destroying the existing ProfileRunner instance? >> > I expect they should be updated dynamically but I am not a 100% sure about > it. And if I felt this was an important distinction I might read through the > spec, but to be honest, who cares? I would never optimize a system to prevent > an object from being recreated until I had a real problem. Recreating an > object works very nice and imho has hardly any consequences in a well > designed OSGi system. > > Kind regards, > > Peter Kriens > > >> Thanks in advance. >> >> -daghan >> >> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails >> as clean, short chats. >> >> >> >> -------- Original Message -------- >> From: list+org.o...@io7m.com <mailto:list+org.o...@io7m.com> >> Sent: Monday, March 13, 2017 03:05 PM >> To: Peter Kriens <peter.kri...@aqute.biz <mailto:peter.kri...@aqute.biz>> >> Subject: Re: [osgi-dev] Building a "profile" system with declarative >> services and configuration admin? >> CC: OSGi Developer Mail List <osgi-dev@mail.osgi.org >> <mailto:osgi-dev@mail.osgi.org>> >> >> On 2017-03-13T09:03:49 +0100 >> Peter Kriens <peter.kri...@aqute.biz <mailto:peter.kri...@aqute.biz>> wrote: >> >> > Just use configuration admin. So first define your profile configuration: >> > >> > @ObjectClassDefinition >> > @interface IRCProfile { >> > String username(); >> > String password(); >> > String host(); >> > String filters_target() default “(filter=uppercase)“; >> > } >> > >> > You then create a a runner that does the work: >> > >> > @Designate( ocd= IRCProfile.class, factory=true ) >> > @Component(service=ProfileRunner.class) >> > public class ProfileRunner { >> > >> > @Reference >> > volatile List<IRFFilter> filters; >> > >> > @Activate >> > void activate( IRCProfile profile ) { >> > … >> > // start a thread? >> > } >> > >> > } >> > >> > This runner can now be created as many times as you want with WebConsole. >> > Each configuration you create is automatically cause a ProfileRunner to be >> > instantiated when its filters are registered. The filters are coupled to >> > the component via the `filters.target` configuration field. The default >> > currently shows that it needs the ‘uppercase’ filter. However, with the or >> > (|) operator you can make it any number of filters: >> > (|(filter=uppercase)(filter=log)). If you need ordering in the filters, >> > use the service.ranking property on the filter components. >> > >> > You can now make any number of filters that look like: >> > >> > @Component( property={“filter=uppercase”, “service.ranking=-100”}) >> > public class UpperCaseFilter implements IRCFilterType { >> > >> > String process( String s) { >> > return s.toUpperCase(); >> > } >> > } >> > >> > I do not think you need anything more? Of course your IRCFilterType are >> > now components so they can be configured independently in a similar vein >> > as the ProfileRunner. >> >> Interesting, thanks! >> >> I'm reading through the DS spec right now and I'm not sure I understand >> how the filters_target() method ends up coupling the components. I >> understand how filters work, I'm just not sure how the OSGi runtime >> knows to use that method... >> >> The rest seems fairly straightforward. >> >> > Having file based configuration is always a bad smell in OSGi. >> > Configuration Admin looks different from what most developers know but it >> > is quite powerful. >> >> To be clear, I was referring to the property files that back Felix's >> implementation of the Configuration Admin service. The implementation >> appears to want one configuration file per service PID, so in a system >> with a lot of components, that can mean a lot of separate configuration >> files. That ends up being a fairly user-hostile thing in a system like >> this because the user then has to understand service PIDs and know what >> all of them are for the components in order to configure the client. >> >> M >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev