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
(http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-custom-using),
the components that depends on them in turn does not need to know
anything about the current sitemap context anymore.
/Daniel
