Am Donnerstag, den 13.07.2006, 16:48 +0200 schrieb Stefano Bagnara: > Hi all, > > This is a test, I hope it will work because I don't see another simple > solution to move forward from the current stall. > > I'm starting this vote because I saw that there is a lot moving around > this issue and we probably currently don't share a common idea, so it's > better to see what the preferences/likes/dislikes/vetoes are in the > various aspects of this issue. > > I expect to receive clear -1...+1 votes (decimal values allowed) even if > this is not a "standard" vote. I'd like to keep discussion out from this > thread in order to keep this clean (there are a lot of options, so it's > better to keep it clean). > > I think that a small sentence explaing the vote should be allowed, but > please *small* or this will become a mess (maybe you want to add > priorities and dependencies on other votes). > > The votes are many and are not clearly organized, but I hope this will > give us a first overview on the things where we have agreements and > things that may be discussed more. We have a broad range of > possibilities for our architecture, so we should try to narrow the real > options that will not be vetoed and get more consensus. > > I want to see if there is at least one option that will not be vetoed by > someone :-/ > > This is far from complete, but I saw that we was not reaching an > agreement, so we need to understand what is the current position of each > committer before starting working on things that will be vetoed. > > I hope that after this one it will be more clean what are the liked > scenarios and that we can start with small proposals for solutions, > roadmap and specific votes. > > I will put my votes in a reply to this. > > Here is a glossary: > > "API Components" => Matcher/Mailets/"new CommandHandlers" > "Top Level Components" => The components currently wired in assembly.xml > "Other James Components" => Other components instantiated by Top Level > Components but not directly handled by Phoenix. > > "Phoenix" => Our current Avalon container > "Avalon" => The avalon framework > "Cornerstone" => I will consider both Cornerstone and Excalibur > components inside this name > > Example votes: > > "+1" => I really like this and I will put my hands in for this to happen > "+0.1 .. +0.9" => I like this solution > "+0" => I'm not against this > "-0" => I can live with it, but I prefer something else. > "-0.1 .. -0.9" => I don't like it, but I will not veto it > "-1" => I'm probably going to veto this > > And now the bulk questions: > > A. Deprecate phoenix > A1. Replace it with Plexus (http://plexus.codehaus.org/) +0 Never used.. > A2. Replace it with another Avalon compliant container (name it) -0 > A3. Replace it with Felix (http://incubator.apache.org/felix/) +0.5 Felix seems to be very intressting.. But maybe its a bit overkill..
> > B. Remove avalon > B1. Remove it from "API Components" +0.8 That whould be cool.. I don't like the idea of need knowing about avalon to write mailets or smtphandler etc.. > B2. Remove it from both API Components and Other James Components -0.5 > B3. Remove it from all the codes and keep wrapper for Top Level > Components to be adapted to the container (Avalon or other). -0.5 > > C. Remove Cornerstone > C1. Remove cornerstone dependencies in favor of Jakarta commons > libraries where available +0.5 > C2. Use MINA to replace sockets/connection dependencies +1 After what i see on apacheCon this seems to be the best way to get a better rid of many connections etc. > C3. Import code from not replaceable libraries to James codebase > (refactoring it to remove Avalon and anything else needed) -0 > > Now I expect that many will have replied +X to A3 or at least to one of > the B*, so here are further votes related to this scenario. > > D. Lifecycle and dependency management > D1. Use JNDI everywhere (ala J2EE) +0 Can say anything about this.. no expirence > D2. Keep Avalon interfaces but write our own mini container for non Top > Level Components. +0.5 I like avalon ;-) > D3. Introduce new interfaces to replace the one from Avalon and create > our own container (that may delegate to the real container we use) to > manage lifecycle and dependencies. (see also "Central class for service > injection" topic by Bernd) +0.8 I like Bernds idea.. > > E. Specific API Components issues: > E1. Use JNDI to lookup datasources +0 like i said no expirences with JNDI > E2. Use JNDI to lookup users/mail repositories, the store and any other > James component. +0 > E3. Add datasource, re > positories, store and any other used service to > the MailetContext API (this also mean adding the interfaces for this > objects to the Mailet APIs) -0 > E4. Use Dependency Injection (setter based, constructor based, enabling > interfaces, service locator injection) to automatically satisfy > components dependencies. +0.8 > E5. Keep the ServiceManager as a property stored in the MailetContext. -0.5 Seems to be more a hack.. > > If you voted +X to something DI related please also vote this: > > G. Dependency Injection > G1. Use CDI (constructor base DI) +0 > G2. Use Setters +0.5 > G3. Use Setters with Enabling Interfaces +0.5 > G4. Keep single setter for ServiceLocator (ala Avalon) +0 > G5. Use reflection and convention over configurations for the above DI +0 > > Furthermore these technologies could be used to sole one or more aspects > of the above points, please give your opinions. > H1. Use Spring -0 > H2. Use XBean +0 > H3. Use OSGi Declarative Services +0.5 > > > Stefano > > PS: I'm willing to track this thread and produce an (i hope unbiased) > overview of the result. bye Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
