Bernd Fondermann ha scritto: > On 10/9/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: >> On 10/9/07, Bernd Fondermann <[EMAIL PROTECTED]> wrote: >>> Let's face it - there will be nothing what could remind you of Phoenix >>> in the combined code base. >>> But it probably will work similar to Spring IoC-Container. Much >>> flexibility, simplicity. >>> Anyway, every container apart from Phoenix will be fine. >> pheonix is tightly coupled with the excaliber components we use. > > it's funny you write that. "the IoC container is tightly coupled with > its components" ;-) > James is not dependend on Phoenix (the only part I managed to get > around in James/Spring), but it is very tightly coupled indeed with > excalibur components. We'd probably have to rewrite much of our code > to loosen these strings.
I don't agree with Robert and you about Phoenix being tightly coupled with components we use. IMHO it is a good coincidence IF Phoenix uses some of the same components we also decided to use to build JAMES Server. This means less memory used as the container and the contained application share something. There is nothing, but Avalon interfaces that really bind us to Phoenix, and your spring module is the final proof. >> it is >> possible that excaliber may be refactored into pojos and avalon >> bindings. > > I'd like to see that happen. Anyone already working on that or is this > only in theory? > > Bernd First we have to make a classification: Excalibur jars are often splitted in api and impl: API does not have dependencies on Avalon or anything container related. IMPLs often refer some activity marker interface (Disposable) and the Avalon Logger (to be injected). IMHO you can use them like any POJO: inject the dependencies and use them. In many cases excalibur code become some commons-* utility: there is a documentation page, somewhere, that explain what common jar deprecated each excalibur library. Cornerstone are instead integration components to simplify using the libraries above in a Avalon/Phoenix environment. They are very simple jars often containing only 1 interface and 1 implementation, and this is a common result of IoC frameworks. If you don't use them or you don't include such "utility classes" in your main code you will end up writing utility code for your framework. This also happens in spring. Spring try to provide utility classes for most common libraries out there, but often projects have to provide their own: http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/mina/mina-integration-spring/1.1.3/ Sometimes our components directly extends cornerstone components: we do this because we extend that code and not because we need to satisfy some special obsolete container requirement. Let me be clear: I don't like Phoenix as it is obsolete code no more mantained, but I don't really think that Spring is the panacea and most of the problems people is reporting about Phoenix are there also with Spring. Too much times we use Avalon instead of Phoenix and viceversa, but here we also have Excalibur and Cornerstone and each one have 2 kind of dependency (api/descriptors and implementation). I would say that JAMES is currently distributed with: - avalon-api - avalon-impl - various excalibur-api - various excalibur-impl - various cornerstone-api - various cornerstone-impl - some phoenix block descriptor (I consider them like an API, even if it is not introduce direct dependencies like an interface) - phoenix itself. The spring module replaced phoenix itself and ATM it keep using the phoenix configuration files and descriptors. I have difficult understanding what you (you all) want to refactor when you talk about POJO, avalon, excalibur by mixing issues. Can we agree on the above classification for our "dependencies" and be more specific in the discussion? Many times in past I started working on extracting the whole avalon stuff (all of the above dependencies) from our base code to Avalon wrappers, but, as I wrote multiple times, there are JAMES core components using avalon interfaces as THEIR OWN way to manage lifecycle for their contained/managed objects. So the avalon "extraction" would have required a big big big refactoring and every time I started discussing each step concretely discussion lead to nothing. IMHO the only way to go is replace one thing at a time (one of that dependencies at a time): the only thing we partially did is to support setter injection for services in addition to the ServiceManager. This is a first step. This allow other users of the code to not understand what ServiceManager is (and depend on it) and to directly work with the real dependencies. Then you have the Log issue: you can use/inject the logger from commons-logging but they don't support child loggers, so either you create your own interface and implements it via commons-logging, or you simply keep using avalon logger and implements it via commons-logging (like you already do in the spring module, right?). Then you have the avalon Context: I think I managed to isolate the context usage to the AvalonFileSystem block and removed it from everywhere. As I wrote in past, and I rephrase it for the newer committers, I do not favor removing "avalon framework api" interfaces from our code by simply creating new interfaces in our packages and use them. IMHO if we do not need different interfaces it does not make sense to duplicate avalon interfaces: this add incompatibility with the avalon world, and does not add any advantage. IMHO avalon interfaces are the last thing to care about, IF and ONCE we won't use phoenix anymore and we'll have removed any outdated components. The "complicate" steps to remove avalon can be found looking for the ContainerUtil class usage. They are the key of our usage of the avalon container logic INSIDE our components. Once they are factored out from the code (using Factories or any other pattern you can think about) then everything else will be much smoother. Keep talking about POJOs, avalon-free, and other similar thing without solving this concrete step is something we already did for years. And maybe this is not so complicate: it requires someone that do it and most of others to be happy to see many changes committed. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
