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?
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? 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? 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? 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 https://mail.osgi.org/mailman/listinfo/osgi-dev
