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.
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.
Kind regards,
Peter Kriens
> On 12 Mar 2017, at 21:52, [email protected] wrote:
>
> Hello.
>
> I'm putting together a small experimental application (an IRC client)
> and would like to fundamentally base it on the idea of _profiles_. A
> profile in this case is basically a set of configuration options such
> as the username, IRC server address, a set of filters, a configuration
> for logging, etc. There can be [0, n] profiles active at any given time.
> A "filter" in this case can be thought of as a function that's evaluated
> for each received message (possibly only for the function's side
> effects). In practice, it'd be an implementation of a published
> IRCFilterType interface.
>
> I'm running up against various architectural questions.
>
> I think what I should do is create a Profile component that
> instantiates a tree of services/components in the whiteboard pattern: A
> component for maintaining a connection to an IRC server, a component
> that handles logging of messages, a set of components for filtering,
> etc, etc.
>
> In my case, I'm using Felix as the OSGi container and I think what I
> need to do is create various configuration files in a directory
> monitored by the fileinstall and configuration admin services.
> For example, if the directory is "etc", then:
>
> etc/com.io7m.eirc.logger-PROFILE1.cfg
>
> ... results in an instantiation of the component with service pid
> "com.io7m.eirc.logger". However, it doesn't seem like anything in the
> OSGi standards allow me to get access to the "PROFILE1" name. I'm not
> sure if this is deliberate, or an oversight, or something else.
>
> It seems like I'd quickly need a ton of different configuration files
> and am not sure how it would be obvious to the user how all of the
> configuration files are tied together to form a profile. Do I need to
> declare some form of "profile identifier" myself? What happens if, for
> example, I want to instantiate two instances of the same component with
> different configurations within a single profile?
>
> Is there some way to express "instantiate all required components
> that have an application-specific profile ID of P" with declarative
> services? I feel like, normally, the answer would be filtering based on
> a given "profile ID" property. In my case, though, the value of the
> property would only be known at run-time and therefore I couldn't do
> this purely through annotations.
>
> What happens if the configuration data for a specific component is
> missing? With the configuration data spread over multiple files, can I
> get good error reporting in that case? I suspect what I'd get is
> basically silent failure... A required component can't be started up,
> so everything just sits there doing nothing.
>
> M
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
