james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [server] Java 5, Spring And Phoenix
Date Wed, 12 Nov 2008 22:49:58 GMT
On Wed, Nov 12, 2008 at 8:03 PM, Noel J. Bergman <noel@devtech.com> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message