> On 13 Mar 2017, at 12:57, Daghan ACAY <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 > Sent: Monday, March 13, 2017 03:05 PM > To: Peter Kriens <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> > > On 2017-03-13T09:03:49 +0100 > Peter Kriens <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