On Wed, May 20, 2009 at 5:39 PM, Stefano Bagnara <[email protected]> wrote: > David Jencks ha scritto: >> On May 20, 2009, at 7:44 AM, Robert Burrell Donkin wrote: >>> On Wed, May 20, 2009 at 2:23 PM, Stefano Bagnara <[email protected]> wrote: >>>> Robert Burrell Donkin ha scritto: >>>>> On Wed, May 20, 2009 at 11:52 AM, Stefano Bagnara <[email protected]> >>>>> wrote: >>>>>> Robert Burrell Donkin ha scritto: >>>>> this means that sometime soon i won't be running pheonix locally. most >>>>> other mail application developers (who post on list) also seem to be >>>>> using the spring deployment. >>>> >>>> let me clarify that I think that moving to another container is a good >>>> thing. But I don't think that moving to any other container is good. A >>>> choice has to be made and it will be critical for the future. OSGi seems >>>> to be a good option but I still have to see a good configuration service >>>> for osgi components. I don't know OSGi enough to understand if this is a >>>> limit in the "specification" or something that simply has not be done, >>>> or something that exists but I don't know. >> >> I'm not 100% sure I know what you mean by a configuration service for >> osgi components but... > > User interface to application level configuration. > Whenever you embrace a modular framework the main issue is to keep a > central place for the user to configure your modular application. > OSGi try to provide Preferences but IMHO they are too limited or simply > I've yet to see a good usage of them. > Eclipse did something along this, but last time I looked at it (2 years > ago) most of it was eclipse specific code and not usable outside from > eclipse.
felix has an OSGi configuration service >> Spring has proposed formalizing much of their xml plan handling stuff as >> the osgi blueprint service. It's getting a bunch of independent review >> and (IMO) clarification and improvement and is very close to the final >> spec draft. There's a TCK. A few people from servicemix and geronimo >> are working on an apache implementation, currently hosted at geronimo. >> So I'd recommend using the blueprint service as the "standard" component >> wiring technique. >> >> I'm not a blueprint expert.... however I think that the service only >> wires up stuff in one bundle, while allowing component references to >> osgi services and publishing components as osgi services. So, I think >> that rather than having one monolithic server configuration file, you >> can have each piece of the mail server configured in a separate bundle >> and wire the large-scale component assemblies together using services. >> >> One issue I have not yet found out how to solve in osgi is how to locate >> the server installation on the file system so you can have stuff like >> file-based storage relative to the installation. For instance in >> geronimo we have a var directory in the server installation and tell >> everyone to put their file based data somewhere inside that, rather than >> trying to store it inside the application itself somehow (as people seem >> to like to do with web apps) There may be a built in or easy solution >> to this but I don't know what it is yet. > > Maybe it worth forgetting at all about phoenix in trunk and try this > way, but this require someone doing this. If there is no one interested > in pushing a new container we can stop discussing. Or at least we can > remove "roadmap" from the subject and simply have a bar conversation > about container/kernels/frameworks. > > Reading this one (http://markmail.org/thread/mib3hlxqh7g7h5gm) I > understand karaf is the direct evolution of ServiceMix and that it will > support BluePrint. I liked ServiceMix in past. > > If Robert is willing to try karaf for IMAP then I'd love to review that > stuff. IMO is an higher priority to see karaf in IMAP than to have any > featureless release for james. i'm no longer interested in pushing any container solution: i don't have time IMHO given the documentation effort required and resources available, moving users (as opposed to mail application developers) to a new platform not realistic. an undocumented 3.x running on a novel container isn't going to offer mail server users a good deal. but the point is that karaf doesn't require invasive changes to the code base IMHO it would make most sense to retain 2.x as a pheonix based solution aimed at mail server users reusing libraries from a spring based 3.x aimed at mail application developers >>> that's fine >>> >>> i'm almost certainly going to move to karaf. i no longer have time for >>> avalon and i'm out of hope that any sort of consensus about new >>> containers for 3.x will be every reached. > > You told this also some months ago. My impression was that most people > don't care too much nowadays and that the PMC will agree on anything > that remove phoenix. While I'm not sure I share this vision I'd bet that > a vote (started by you) to move trunk to karaf would pass. Why don't you > simply try it? whenever we start to discuss any moves, it just dissolves. there just isn't enough consensus. everyone knows that i favour factoring out libraries which can be reused between 2.x and 3.x but there just isn't consensus support for this. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
