Hi Ole, On Thu, 2002-09-26 at 11:11, Ole Bulbuk wrote: > The nice thing about containers is: There are so many to choose ... ;-)) > > I am developing a single server application that should run (about) 24h a > day. So far (for the more prototype stage) I have used Phoenix for the whole > application and inside of it the Excalibur Component Manager (because of the > document "Developing with Apache Avalon"). But now I would like to make the > real production quality implementation but I still don't know which > component/service container to use. The application should be shipped during > January next year. So the container should have release quality then. > > The choice seems to be: > 1. Phoenix: The new official release has just come out and it > seems to support the new service stuff and the > new unified? configuration but seems to be > oversized for a single application because it is > build to host many applications. > Or is this a feature that doesn't cost any > performance during runtime (due to overhead)?
I wouldn't worry about performance overhead because of phoenix too much. I've always found the bottlenecks to be elsewhere. > 2. Tweety: Only for educational purposes and pre-alpha. It's actually more like pre-release but you don't want to use it for this. You don't want to 'use' it at all =) > 3. Myrmidon: Pre-alpha and specially made for Ant2. you don't want it for this =) > 4. Fortress: Pre-alpha and needs a container itself. Actually, work is underway to get a release out of the door, which by my estimate will be well before january. Fortress adds most value (IMHO) when you run it in a servlet environment. If you already run a servlet engine, it'll definately be a good option by jan 2003. > 5. Merlin: Pre-alpha and needs a container itself. > Where is the difference to Fortress when the > unification of interfaces and configuration has > been successful???? There's quite a few differences, but it is likely fortress and merlin2 might actually be merged in the future. Merlin2 can run standalone. I don't think you should bet on having a stable release by jan 2003 for merlin2 though. You don't want to use merlin1. > 6. Plexus: Pre-alpha, specially made for Turbine and needs a > container itself. The container part of plexus will be thrown away in favour of fortress and/or merlin in the future. Don't use. > 7. ECM: The Excalibur Component Manager seems to be > outdated now and needs a container itself. ECM is still maintained and supported, and you can build good apps using it. It is just the newer containers do things a lot 'cleaner' and add some features (mostly support for the org.apache.avalon.framework.service package) that ECM doesn't have. > So is it true that writing new containers has become such a popular sport > that there is none left that can be used without feeling guilty in one way > or the other??? ;-))) probably =) > So in January 2003 I would like to ship a *stable and modern* single server > application but which container should I choose??? if it would be useful for you to run your application in an already installed/used servlet engine (or j2ee server) (like if you don't want to have another JVM process running), I suggest you use Fortress. You can also develop using ECM now and move to fortress later (migration should be allmost painless). If you don't run a servlet engine (or j2ee server), the choice is more difficult. As phoenix offers some neat features (like JMX management support) and was specifically designed to run on its own, it is probably the one you're after. On a longer timetable, the choice becomes more difficult. A merger of Fortress2/Merlin2 will likely offer a good alternative to phoenix even for standalone usage. At that point, your choice would be based on feature comparisons between them. On an even longer schedule (ie 2004), it might become possible for us to sensibly merge the various containers. > Any help/opinion is welcome, there you go. Of course, this is purely my opinion and other avalon developers probably disagree =) cheers, Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
