Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
>> 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?
>
> It would be great to get rid of ECM++.
>
> What kind of dependencies will Cocoon get on Spring?
>
It'll depend on the springframework (core) and will not work without it.
> As we are in the process of finally getting the real blocks usable it
> would be painful to need to integrate it with a new component system
> right now. Could you make your code available somewhere so that I have
> the possibility to evaluate the consequences of it, before you start to
> commit it?
>
The current code is just a prototype. Setting up the spring bean factory
is just a "new Factory('LOCATION OF XCONF')" (this is not the exact
code, but it's near to that). This sets up the factory and provides a
service manager. For compatibility it requires a valid Context and a Logger.
If we want to go down this road I can commit the code to the scratchpad
in the next days.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
