cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Dependency on WebApplicationContext
Date Sun, 26 Feb 2006 11:09:57 GMT
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> The users are not the only stakeholders the developers are at least as 
>> important, especially in an open source community. One of the recurring 
>>    themes in all the NG discussions is that people are deeply frustrated 
>> with not being able to try their new ideas because of the complexity of 
>> Cocoon. This must be solved by simplify Cocoon and by making the 
>> contracts between different parts clearer.
> I totally agree here.
> 
>> IMO the direct dependence of
>> the XmlWebApplicationContext is a step in the opposite direction.
> Not necessarily - XmlWebApplicationContext has a hugh interface, but in
> fact this one is easy and everyone who knows spring knows this one
> anyway. But if we can get this one out of the tree processor, I'm all
> for it.

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.

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.

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.

>> Most of the code in the ecm block service manager 
>> http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-ecm-impl/src/main/java/org/apache/cocoon/container/ECMBlockServiceManager.java,

>> is about setting up a block local source resolver, which not is as easy 
>> as one  might assume.
>>
>> That particular mechanism for having a block local service manager that 
>> makes components available for other blocks was mainly designed for ecm. 
>> So we can do it in some other way for a Spring block service manager.
>>
>> Any ideas about how to proceed?
>>
> 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.

The Settings could probably be made global.

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

> But in the end, we have the same problem here as the tree processor has:
> we need to setup a Spring application context which should have a parent
> Spring application context. Setting up this context is easy, the problem
> is getting the parent context. And this is imho exactly the point where
> we depend on the container implementation. The current block
> implementation uses the Avalon interfaces which we could for example
> replace with the Spring application context (no dependency to Avalon
> anymore).

After having taking a closer look at the Spring APIs I fail to feel 
enthusiastic about this scenario. Setter injection is nice and the 
BeanFactory is OK, but the rest of the interfaces looks like a mess IMO. 
And makes me better appreciate the elegance of the Avalon interfaces.

I would rather stay away from the fatter breed of interfaces from Spring.

> Agreed, the Spring application context interface is bigger than the
> simple ServiceManager interface, but again - it's well known - and it
> provides more useful functionality.

I find it quite ironic that Spring aim that:

* Your application code should not depend on Spring APIs

http://www.springframework.org/about

and then in practice we depend on an interface with maybe 100 methods.

> 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

> But we would again create interfaces noone knows
> upfront, increasing the learning curve.
> So I suggest, let us base all the component stuff on Spring, use the
> Spring application context (or more precisley the CocoonXml...) and
> continue from there.

Not convinced. As said above: Setter injection, yes. Minimal service 
manager or bean factory type interfaces, yes. ApplicationContext, no thanks.

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.



> This would mean, first seeing how this block registry could look like
> and from there implement the spring blocks impl which should be really
> trivial.

OK.

/Daniel


Mime
View raw message