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
