On Wed, May 20, 2009 at 4:31 PM, David Jencks <[email protected]> wrote: > > 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: >>>>>> >>>>>> i've been having a little think recently, in particular about user >>>>>> postings on the list. i think i can see a realistic path if there's a >>>>>> consensus that this is the way we want to take james forward... >>>>>> >>>>>> Observations: >>>>>> * Felix Karaf (OSGi container) is very cool. this opens up lots of >>>>>> cool possibilities for mixing protocols and is very interesting to me. >>>>> >>>>> Interesting. I'd like to see a POC about it, before embracing such a >>>>> technology. >>>> >>>> it will support the stuff i'm interested in without invasive changes >>>> to james. all that's needed are features (dependencies) and spring >>>> (assembly) documents. >>>> >>>> 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... > > 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.
cool karaf started out as the servicemix OSGi kernel. there's some support for blueprint in the latest development version. > 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. karaf does something like that but yes, james would need this sort of thing <snip> >>> That's a real pity. If Karaf is a way out then we'll have to pay more >>> attention to understand exactly what we are embracing or it will be the >>> next iron ball at the leg of any future release manager. >> >> that's not needed. karaf does the stuff that i need it to do for my >> interests but the spring deployment should still work independently. > > hopefully s/spring/blueprint most developers understand spring so support is useful <snip> >>>>> Backporting stuff from 3.x to 2.x is simply unfeasible for most >>>>> interesting code because we had to change interfaces and break some >>>>> compatibility in order to support the new features. I BET backporting >>>>> some of them will take *much* more time than testing trunk as a whole. >>>>> People keep claiming that v2.3 is stable and trunk is not, but the fact >>>>> is that simply no one tested trunk and confirmed it is unstable. Maybe >>>>> it is, but until I'll see bug reports about instability against trunk I >>>>> won't consider this. >>>> >>>> i wasn't proposing to backport but to factor out multi-module >>>> libraries which can be shared. bugs can then be fixed against trunk. >>> >>> components are linked together via interfaces. To factor out modules >>> that can work in both v2.3 and trunk we have to deal on common >>> interfaces. The components you talked about rely on changed interfaces >>> or define the interfaces used by the rest of james. >> >> yes, there would need to be some glue code back ported. this don't >> think that this should be a major issue. >> >> it does mean that the interfaces can be agreed by a release and >> versioned independently. > > > Using karaf doesn't mean you'll depend on it. I think that osgi + blueprint > will be a really good direction to move in. yep IMHO we need gradual approach to OSGi unless some volunteers step forward. hence the need to break down into libraries which can be OSGified in a sequential fashion. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
