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. What do you have in mind for Spring? 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).
> > > 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.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
