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
pgpIYxaagusTv.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev