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