I would prefer to nuke the phonix stuff and just move forward. I'm not really active atm, so feel free to ignore me ;-)
cheers, Norman 2009/3/9 Robert Burrell Donkin <[email protected]>: > On Fri, Mar 6, 2009 at 5:39 PM, Stefano Bagnara <[email protected]> wrote: >> Robert Burrell Donkin ha scritto: >>> On Tue, Mar 3, 2009 at 9:20 AM, Stefano Bagnara <[email protected]> wrote: >>>> Robert Burrell Donkin ha scritto: >>>>> On Sun, Mar 1, 2009 at 8:05 PM, David Jencks <[email protected]> >>>>> wrote: >>>>>> I'd kind of worry that if you start using annotations you are going to be >>>>>> building yet another wiring framework which may not be the ideal focus of >>>>>> this project. >>>>> (unfortunately) i'm not sure a consensus would be possible about >>>>> picking a more modern approach >>>> I would prefer the use of an external wiring library instead of writing >>>> our own. JAMES is complex enough to require some complex wiring and >>>> writing our own library is not the right thing to do IMHO. >>> >>> i see no hope of gaining the consensus required to pick a new container >> >> Why? Did we recently had a poll or did anyone expressed strong opinions >> against one or another container? I know I'm less active lately and I >> don't remember this. > > history > >>>> As far as we can go there's no way to ship only container-agnostic >>>> components. One way or another we'll have to use a container and to put >>>> wiring/configuration there and the wiring/configuration is part of the >>>> distribution. We have to choose a container and use its facilities. One >>>> thing we should do is to avoid to put container stuff all around our >>>> code, but we should not write our own container to avoid being >>>> container-specific. >>> >>> my suggestion is that we develop phoenix to a point where james can >>> easily be run on other containers. this requires the development of >>> some james specific wiring and a micro-kernel to plugin into phoenix. >>> the development of a new container is not necessary. >> >> what I meant is that I prefer to use an existing micro-kernel than >> writing our own. > > depends how big your micro-kernel is ;-) > > the smallest service micro-kernel is a Map > >> xbean+spring, for example, is not documented, true, but at least it is >> used and tested. Something written from scratch would be unused and >> undocumented and less bulletproof. > > this sounds a good way for the spring deployment to go but i'm not > sure that this would be easy to adapt phoenix to use this approach. if > volunteers step forward who were willing to re-work and maintain the > phoenix container to use a spring-xbeans based micro-kernel that'd be > great by me but i'm not willing to devote the time required. > >> BTW this is just a preference. If you are convinced that writing your >> own stuff is better and you're prepared to write it and make it work, >> well, I won't stop you! > > i'm proposing a modification to the phoenix container, not creating a > new one. it doesn't need to be bullet proof, just good enough to allow > the james code base to move forward. > > - robert > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
