cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Core split status
Date Mon, 01 Jan 2007 17:50:41 GMT
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> I'm not certain that the configuration and the deployment stuff belongs 
>> together. Also to make the deployment util more usable outside Cocoon, 
>> something like the block context source is needed. Would it be possible 
>> to implement the block context source as a Spring resource and move it 
>> to the same module as the deployer?
> I'm not sure, but I think Spring does not provide a pluggable resource
> resolving system like we have. When you have an application context, the
> application context is the ResourceLoader (= source resolver). So adding
> own protocols means adding functionality to the application context. It
> might be that it's possible to configure an additional resource loader,
> but I haven't looked into that.

I looked at it and AFAICS the only way is to extend the application 
context :/

> The current configurator is doing several things that I think belong
> together. Adding configurations and properties to the Spring application
> context is in fact deploying beans (or configuration files), so I think
> it makes sense to have the deployment of web application resources at
> the same place. If you have a jar with both, bean configurations and a
> COB-INF directory, it might not make sense to deploy only one of those
> twos; they belong together and need to be deployed both.
> I think we should leave this stuff in the configurator for now; release
> this stuff as 1.0 and use it. If the needs arises to split up, we can
> make a configurator 2.0 version and change things.

Makes sense.

>> Pipeline
>> --------
>> </snip/>
>> Maybe the component module should be split into a base and an optional 
>> module?
> Yepp.
>> The Avalon support should preferably be moved to a separate module.
> Yes, I tried it but failed :( Currently the avalon stuff is mixed with
> tree processor stuff, so you can't easily separate one from the other :(
> This has to change!

What are the main remaining problems?

IIUC, one problem is context handling for components. One way to solve 
that could be to create a custom "sitemap scope" for Spring. If the 
components that are directly dependent on what sitemap they are used in 
are defined to be sitemap scoped and use the AOP scoped proxy 

the components that depends on them in turn does not need to know 
anything about the current sitemap context anymore.


View raw message