On Sun, Sep 7, 2008 at 7:01 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On Sun, Sep 7, 2008 at 6:22 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >> Doens't imap classes >> (ImapHandler/ImapServer/DefaultMailboxManagerProvider/PhoenixUserManager/PosterMailboxAdapter) >> deserve a function like the activemq and jcr stuff so to be able to publish >> imap also in the spring deployment? > > quite possibly > >> Shouldn't PhoenixUserManager be named "DefaultUserManager" as it is not >> specific to Phoenix at all and should also be used by the spring deployment? > > quite possibly
imapserver-function has turned out to be (at best) a very mixed bag :-/ one of the reasons why i just dumped stuff into pheonix deployment was ATM i don't think it's possible to fix things properly. the problem is that in order to make IMAP theoretically (but not practically) available to the spring deployment, a lot of stuff is being fudged or regressed in terms of coupling. at least dumping everything in pheonix means that it's easier to see the problems. dumping everything in imapserver-function just hides the unaddressed problems and introduces unnatural couplings into the modules. i think this probably indicates some misunderstandings of my underlying reasoning. i'll try to outline them more clearly now. please forgive the length (i think that we all understand but use different language and terminology). avalon is an old, intrusive IoC container. this has some very major negative consequences for the james server codebase. Separating Services from Assembly ------------------------------------------------ by a service, i mean a discrete facade independent of the current component. for example, for SMTP, DNS is a service. by assambly, i mean the act of assembling an application-scale component from constituent sub-components. for example, IMAP is an application scale component composed from many sub-components. it is possible to assemble IMAP using different sub-components allowing pluggable customisation of the component. so, assembly is about pluggable extension. avalon does not allow a clean separation between the assembly of an (application-scale) component and the provision of services to that component. more modern approaches encourage separate service provision. one promising future for james would be to use OSGi to replace avalon service provision and spring (or pico) for component assembly. this will require adopting a clean and clear separation of service and assembly concerns. there are various solutions in the codebase which have been adopted to workaround this basic problem at various times including creating lots of small services for assembly and loading classes by name based on the configuration. preserving configuration file compatibility is important. assembly details needs to be mutable in the short or medium term. they should therefore not be included directly in the configuration file. the solution i propose is to create fully assembled default classes. however, these are just workarounds for the limitations of avalon and really shouldn't be used in more expressive containers. moving these defaults from pheonix-deployment typically causes unfortunate and unwanted direct coupling in modules. Avalon Services --------------------- Setting aside assembly concerns and focussing on interactions between high level components within james, let's consider the avalon approach to services. Configuration ------------------ in addition to pluggable extension through assembly, the james server uses a configuration which allows components to take runtime configuration from a central document. (ATM this is a file but i see no reason why any general resource could not be used.) avalon has an intrusive approach to configuration: component require facades which interpret configurations from avalon specific input. it does mean that components are tightly coupled to avalon. this is an excellent fit with the james approach to configuration: a single canonical configuration document. modern container approaches tend to use per-service configuration documents. this allows radically different extensions to be created and configured. going forward, configuration compatibility is important for james users. avalon makes it difficult to add new components. once this limitation starts to ease, allowing configuration of pluggable elements in the primary configuration will make maintaining compatibility increasingly difficult. the most promising solution would be (i think) to both start codifying a schema for james which can be preserved between upgrades. configuring pluggable components would not be supported though avalon but though the native configuration systems of alternative assemblers. so (for example) if someone wanted to customise the default SMTP beyond the limited settings available through the james configuration, they would need to use spring (for example) for assembly of the SMPT service. classes implementing Configurable belong in pheonix-deployment. protocols should include clean, avalon indendent classes. Service Provision ------------------------ like configuration, service provision using avalon is intrusive. any class which implements Serviceable is tightly coupled to avalon and cannot correctly be used with more modern IoC containers. james makes use of many excalibur components design for use with avalon. it is perfectly reasonable for these to be tightly couple to avalon. i hope that it will be possible to correctly separate concerns by introducing intermediary interfaces and so avoid direct coupling outside deployment. this may well mean duplicating some small amounts of glue code between deployments but i think that this is a price well worth paying. many services should need no coupling to excalibur. in the medium term, these services should be refactored into POJOs in the modules and avalon-coupled adapters in pheonix-deployment. these adapters are likely but again, reusing trivial glue code is likely to come at a high cost in terms of correct modularity. Service Definition ------------------------ services are defined in xinfo and assembly configuration files. there are avalon specific and belong in pheonix-deployment. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
