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, list+org.o...@io7m.com 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 > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev