On Wed, Nov 12, 2008 at 8:03 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin wrote: > >> OSGi is fine for containing coursely grained services but avoiding >> spring for configuration and assembly of these services is going to >> make a *lot* of work. > > OSGi is about assembly.
depends on what you mean by assembly ;-) for example, composing a socket service library, a protocol library and a repository to create a complete service is the kind of assembly that OSGi is very strong. OSGi is weaker at the assembly of a service from finely grained components with an IoC design where the selection of components is the configuration. spring is strong in this case. > What do you have in mind for Spring? 1. easy configuration and assembly of components that are already spring enabled into a service loadable and composable by OSGi (spring already supports this BTW) for example, a major part of the work involved in creating a basic activeMQ based spool manager without spring is creating code to configure and assemble the component. so use spring for assemble and finely grained custom configuration then use OSGi to load and compose the service, providing standardised high level configuration information. 2. for some allowing easy customisation for deeply IoC services for example, imap, fail fast and jsieve both use flexible handler chains to allow developer customization of the components assembled into the service. > And configuration can be pretty nicely handled by Commons Configuration if we > want a configuration object, else we can use DI using annotation (for > example). i agree (and had in mind that this is how most of the existing services would be ported) but i would prefer to avoid supporting yet another IoC container for components maintained outside James >> > > Danny proposes the use of a configuration service that injects >> > > configuration to the component to be configured, which would >> > > allow us to use Spring or Commons Configuration or anything else. > >> i would go further. i would really like to avoid using a service at >> all for configuration and assembly. (using a service to load services >> would create a nasty design knot that would be better avoided.) > >> OSGi would allow services to be delivered as self-assembling, >> self-configuring applications linked to each other by dynamic >> service references (we use dynamic proxies for these initially). >> the applications would be able to use spring, commons, hand >> rolled, pico etc - whatever is most convenient. > > Would you please clarify your seeming contradictions above? From where are > these self-configuring applications going to get their configuration > information? And please remember that we are delivering an application that > some administrator has to be able to configure in a sane, sensible and > consistent manner. So, no, it is not acceptable for each bundle to have its > own ad hoc means of configuration. We want the ability to have a consistent > configuration delivered to the service, and that seemed to be what Danny had > in mind: a service that read configuration from some source, and delivered > it to the dependent services. i think we need to think of two separate cases: 1. configuration of James by an administrator 2. easy extension of James by a developer or deployer IMHO a standard, simple and fixed configuration is needed for administrators. the superset of all possible configuration options for all extensions is just too complex. therefore, finely grained configuration and assembly information which is not generally application should not be added to the james configuration file. whether an option is readable and understandable for a james adminstrator would be a good test. so, IMHO each service needs to become a self-contained application capable of self-assembly and specialist configuration for example, IMAP (or fail fast SMTP) has some basic qualities such as ports which all implementations should share. so, these should be loaded from the james configuration. configuration and assembly details such as the precise choice of handler chains should not be loaded from the james configuration but by the service itself as it boots. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
