cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Core split status
Date Mon, 01 Jan 2007 15:49:32 GMT
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.

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.

> Pipeline
> --------
> </snip/>
> Maybe the component module should be split into a base and an optional 
> module?

> 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!

> So as you can see we are starting to get a nice structure, but there are 
> still many open questions where your input or even better, work would be 
> needed.


Carsten Ziegeler - Chief Architect

View raw message