cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Dependency on WebApplicationContext
Date Sun, 26 Feb 2006 22:41:24 GMT
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> IMO the use of both application contexts and service managers in the 
>> tree processor is not such a good idea. It makes the code really hard to 
>> follow, we should avoid mixed models in the same piece of code.
> Absolutely; remember :) this is the first version which aim was to "just
> work"; so removing all the Avalon based stuff should be the next step.

Hmm, here we need to discuss what we aiming for. Replacing our own ECM 
with Spring for creating Avalon components is great as we don't need to 
support our own container anymore. Giving users a better possibility to 
use Spring for their applications is also great.

Giving us and them the possibility to mix Spring and Avalon setup in the 
same block and even in the same component is less great IMO.

It would IMO be a step forward if we could replace most uses of 
Serviceable with setter injection, this would lead to components that 
are easier to reuse and test. But making a mechanical replacement of 
ServiceManager with BeanFactory will be much work with questionable 

Also Spring configurations are not exactly easier to manage than our 
current configuration files,

So before we run away and remove all the Avalon stuff we need to make 
clear what we aiming for.

>> It might be that we at some point want to switch from Avalon style to 
>> setter injection in our components. But that must be done one component 
>> at the time not for parts of the component.
> Please note, that with spring you do not depend on setter injection. You
> can get the application context (= service manager) and then dynamically
> lookup the components *if* you want; but of course this is not the
> "clean spring way of doing it".

Yes I know that Spring can make all kinds of things and provide a lot of 
flexibility. For Cocoon core parts we should choose one style and stick 
with that. Mixing styles makes the code hard to understand and support.

>>> Hmm, I see that ECMBlockServiceManager has several problems; for example
>>> it creates a Core and a settings object which it definitly should not as
>>> there should only be one Core object and settings object for the whole
>>> Cocoon installation.
>> Then we need to change the Core as it contain the current ServletContext 
>> which is block local. Each block is an isolated unit with its own 
>> context. Because of this I needed one Core for each block. On a 
>> different note most of the methods in Core doesn't seem to be used anywhere.
> Not yet, they are a try to move away from the avalon Context object; but
> I understand your concern with the servlet context. Hmm, I'll have a
> look at that as well.


>> The Settings could probably be made global.
> Hmm, I think perhaps a hierarchy of settings would make sense: one for
> the core and then a settings object per block which inherits global
> settings from the core settings object.

That could work.

>>> Now, I see that the current ECMBlockServiceManager implements the usual
>>> Avalon stuff; can we assume that the service manager which is feed into
>>> the service() method is either the root service manager or a child of
>>> it? In that case, that one already contains the Core object etc.
>> There is no real root service manager in the current blocks fw, the 
>> service managers of the blocks are siblings. The parent manager for the 
>> blocks is just the service manager registry that redirect the look up to 
>> the block that contains the component.
> Hmm, is there no "core" or some equivalent to that, which sets up the
> blocks system?

The BlocksManager sets up the blocks. When we move it to OSGi there will 
be a small set of services: log service, http service (bridge), 
configurations service, declarative components service and maybe a 
preferences service, that are started  before all the blocks and that 
provide commonly needed functionality and settings.

>> and then in practice we depend on an interface with maybe 100 methods.
> The question is: is the dependency wrong or is the interface wrong?

Booth ;)

>>> If we don't want this dependency
>>> then I fear we have to create our own "container" interface as
>>> ServiceManager is definitly not enough. For example, we need a way to
>>> get the parent container
>> If we use Spring, HierarchicalBeanFactory should be enough.
>>> and we need a way to shutdown the container and
>>> it's childs etc.
>> DisposableBean
> No, this is not enough because of the hierarchy. We can dispose a tree
> processor using DisposableBean, but in this case all childs of this tree
> processor must be disposed as well. I think, we can get this running
> somehow.

Sounds good.

>> Not convinced. As said above: Setter injection, yes. Minimal service 
>> manager or bean factory type interfaces, yes. ApplicationContext, no thanks.
> Ok, I start to see your point; may be we should forget about the whole
> application context and just use the bean factory. I'll see if this
> works out.


>> Of course we need to create the container somewhere. But that code 
>> should be isolated, we should really avoid having dependencies on heavy 
>> weight containers all other the place.
> I absolutely agree; I think we should move the container code out of the
> tree processor, so the tree processor is just for processing the
> pipelines and parsing *that* part of the sitemap. The container code
> will also read the sitemap, but only the components part. This requires
> to read the sitemap twice, but cleans up the concerns. WDYT?

Agree. One possibility would be to make a component of the 
SitemapLanguage.createApplicationContext method (except maybe for the 
listener setup in the end). It could be BeanFactoryAware and LogEnabled, 
and have the createApplicationContext method as its API. AFAICS it would 
only be needed to be created if the sitemap actually contain a 
configuration element. Which would make the treeprocessor container 
dependent only when it needs internaly configured components.


View raw message