If you really can pull this off then a big +1. However....
Can you post a sample configuration? I'd love to see what the mixture of spring and avalon-style configuration looks like.
And if we can ban poolables once and for all then this will greatly simplify things. However, I'd love to see some performance comparisons on some of the sample pages (including logging into the portal) before buying off on this. I'd really like to make sure that our "theory" that pooling doesn't buy much is really true.
Ralph Carsten Ziegeler wrote:
What about replacing ECM++ with Spring? I've a prototype on my harddisk which sets up a Spring BeanFactory based on our current Avalon configuration files (roles and xconf with includes and property replacements). This makes all of our components real spring beans while allowing a smooth migration path. The benefit of this is that you can simply use Spring without any bridging stuff or tricks. And your Spring beans can depend on the Avalon components (and vice versa) without any problems (as there are only Spring beans). And the container is then final no longer our business, we just use the most used/known one. The prototype supports all Avalon lifecycle interfaces right now - with the exception of Poolable/Recyclable as Spring does not have a way to release a bean. We could use our Proxy based approach for thread safe poolables for compatibility while trying to bann all poolable components anyway. So what do people think? Carsten
