-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 7 Feb 2006, Carsten Ziegeler wrote:
Date: Tue, 07 Feb 2006 20:41:51 +0100 From: Carsten Ziegeler <[EMAIL PROTECTED]> Reply-To: [email protected] To: Cocoon-Dev <[email protected]> Subject: [RT] Using Spring instead of ECM++ 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.
Haha, you're soo funny. I've had to dig deep into Spring recently and found that almost all Avalonmight be replaceable by a Spring BeanFactory. But I didn't had the courage to step up for now :-)
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.
Yes.
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
Uh, what's a "thread safe poolable"??
anyway. So what do people think?
Icannot see the implication ATM. What about stuff like ParentAware (or somehow) or those with Thread affinity?
- -- Giacomo Pati
Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD6QVxLNdJvZjjVZARAiImAJ9b9ldg06kNjScKoI52ciXSVzAEqQCgmC3H C5I1tXJUbwSIbSZ7hDobQaw= =jlm9 -----END PGP SIGNATURE-----
