Vadim Gritsenko wrote:
Berin Loritsch wrote:
The new Cocoon should be able to use the new Fortress container. This should
have little to no impact on component writers. It boasts faster startup, and
it provides easier component definition. I will be happy to do the work.
+1 from me.
+1, but I (still) would like to hear quick comment on Fortress vs Merlin. I heard on avalon-dev that merlin is gonna be that new craze.
Consider Fortress a stepping stone from ECM to Merlin. Once Cocoon has done
all the work to move to Fortress, it becomes trivial to host in Merlin.
The main things here are:
1) Merlin does not support ServiceSelector.
2) Fortress provides mechanisms to make the ServiceSelector unecessary, but
seamlessly supports components that still hold on to it.
3) Merlin does not support the ThreadSafe, SingleThreaded, Poolable interfaces.
4) Fortress still supports them for legacy components--but it encourages the
new meta-data enabled way.
These are the key areas where Cocoon *needs* Fortress for the immediate shift.
I would much rather work toward the immediate need, because we can still work
with Cocoon while we are doing the other migrations.
It is important to note that Merlin has a number of features that Fortress
does not have--but Fortress provides a number of features that ECM doesn't
have. When Merlin is officially released, it will be 100% Fortress compatible.
Ok, then I'll be +1. But this raises a point which is for some reason contentious on the list the last few days:
Wouldn't it be better not to do this change on the 2.1.x line? I am assuming that this change would break back-compatibility in some points at least of custom components, etc. and that should be avoided on a released version.
Could someone (Berin?) give an estimate of what the "damage" would be even if we agree it's a good move?
Geoff
