On Sun, Sep 14, 2008 at 4:50 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: >> >> 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 :-/ > > Like most of the other modules... > E.g: I feel less comfortable with domain-api being mixed bad than > imapserver-function. > >> 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 totally disagree :-) > > phoenix-deployment is a module like imapserver-function. > dumping things in one or another does not hide or show anything. Instead of > you put that code in phoenix-deployment then we have a non functional > spring-deployment.
spring-deployment is unlikely to work with the current stuff > IMO avalon code does not belong to phoenix-deployment until we have a pring > deployment using an avalon-spring bridge and we don't have alternative > avalon-free implementations. > Code should be moved to phoenix-deployment when the same very feature is > already available in the spring deployment by using specific wrappers or > spring-features, otherwise they need to be in a function. This is a limit > (you already said this was done by purpose, and I may agree) of the ant > build. We only have api/util, library, function, deployment layers. > Currently we would need an "avalon-deployment" and then having the > phoenix-deployment and spring-deployment as phoenix-package and > spring-package because both of them are deployments of the avalon stuff. the current spring-deployment as proposed was never going to be a peer of pheonix-deployment but a dependent module. trying to make it anything else will just prevent progress elsewhere. what'll end up happening is that is that an additional avalon-compatibility layer will be required between function and deployment or nasty coupling resulting in hotch-potch modules (such as imapserver-function) and nothing at all in pheonix-deployment. >> 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. > > This is not an avalon limit but a phoenix limit. AFAICT plexus supports > distributed assembly configuration. plexus is a post-avalon container with avalon compatibility > But I agree in general on your > statement. While I evaluated moving to newer avalon containers multiple > times (in fact I also have a loom based james deployed and one year ago I > evaluated plexus for this) I don't think this is a good option for james > anymore. the problem isn't really the container but the component system that avalon has imposed on james <snip> >> 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. > > IIRC in phoenix we could use a config file per block strategy too (but maybe > I'm confusing this with loom). > This depends more on the avalon container than on avalon itself. > Plexus, as an example, makes the configurability and the assembly > distributed and autodiscovered. plexus is post-avalon > But back on Avalon Configuration I think that a hierarchical configuration > object is not needed by most components. Setters/fields based configuration > or a POJO configuration bean is often more appropriate these days. > This simply require effort: split avalon specific classes in 2 separating > the component logic from the avalon stuff. > In some case (like the spoolmanager/stateawareprocessorlist/linearprocessor > stuff we discussed recently, or the jamesserver/jameshandler stuff) it is > more difficult than this, but in many cases it is a matter of simple > refactorings. from the difficult cases i've reviewed, there are problems which should be fixed at the component level >> 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. > > I'm interested in this. Expecially wrt mailet/matcher configuration or the > smtp handlers configuration. The standard user is expected to deal with that > configurations.. do you want him to work with that in the spring (for > example) assembly? Otherwise, what kind of configuration do you propose > (this is not a simple "properties" configuration)? i see two distinct categories of use case matching the dual nature of james as both a mail application similar to sendmail and a platform for running advanced mail processors a user with an administrator hat on may want to switch ports or fine tune a mailet processing chain. this should be done by editing the standard main configuration document. a user with a mail processor hat on may want to customise IMAP (say) by plugging in a custom command. this should be done by creating a custom independent assembly configuration. >> classes implementing Configurable belong in pheonix-deployment. >> protocols should include clean, avalon indendent classes. > > I agree. But this does not mean that I think that imapserver content is > ready to be moved in phoenix-deployment, at least until spring-deployment is > not able to run imap without using that code. i doubt spring-deployment will run IMAP anyway. my narrow aim is to allow james server application to ship a milestone sometime before IMAP is finished. i see no reason to ship anything other than the pheonix container as the milestone. <snip> >> 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. > > This is true for excalibur components, but not for cornerstone stuff. > Isolating cornerstone would mean writing alternative implementations. i meant isolating coupled components and factoring out good APIs rather than creating replacements >> 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. > > I'm in favor of moving avalon-coupled code to phoenix-deployment, but once > spring-deployment can run the same component the same way. > ATM spring-deployment has been written to read the standard config.xml and > this make it more coupled to the avalon stuff. > I don't know what is the best evolutionary/revolutionary approach to deal > with this. i'm not sure what the aim of the current spring-deployment is other than the very useful proof of concept. i don't want worries about this to stop progress elsewhere which it seems to be doing. >> Service Definition >> ------------------------ >> >> services are defined in xinfo and assembly configuration files. there >> are avalon specific and belong in pheonix-deployment. > > Most times xinfo are for avalon specific classes. In this case they belong > to the same modules of the class they declare. Once the avalon-specific > wrappers will be moved to phoenix-deployment (because spring will be able to > run the components without that classes) the xinfo will follow the classes. > assembly is already in phoenix-deployment. > it also is in spring-deployment because that's the way spring-deployment has > been built: it parses the assembly and use it as its own configuration file. > > I find the double deployment module a critical issue much more than the > ant+m2 duplication issue Bernd raised previously. Mainly because it seems we > have active mantainers for the 2 builds while we don't have active > mantainers for the spring-deployment that is broken more often than not > since we started major refactorings. Having no automated tests to know that > the server is at least able to start with both deployments made us ignoring > the spring-deployment at all. > > ATM the spring-deployment is an alternative avalon container and not an > avalon-free deployment. I think this is the main difficult in understanding > each other about what belongs to functions and what belongs to > phoenix-deployment. i'm not sure it's an alternative container. when it was mooted, the idea was proposed that the spring deployment would depend on pheonix at least for a while. i'm not sure what's changed since then. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
