cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Dependency on WebApplicationContext
Date Sun, 26 Feb 2006 14:21:16 GMT
Daniel Fagerstrom wrote:
> Made some work in that direction. Now only the SitemapLanguage has a 
> direct dependency on XmlWebApplicationContext. I'll see if I can find a 
> way to make that dependency stricter as well.
> I introduced a NameForAliasAware interface in the process. Didn't know 
> enough about the alias handling to know if the knowledge about alias 
> really is necessary outside the container.
I'll have a look at that.

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

> 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".

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

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

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

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

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


Carsten Ziegeler - Open Source Group, S&N AG

View raw message