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.


Attachment: pgpIYxaagusTv.pgp
Description: OpenPGP digital signature

OSGi Developer Mail List

Reply via email to