cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [Ann/RFC] Virtual Sitemap Components
Date Tue, 12 Apr 2005 10:50:53 GMT
Daniel Fagerstrom wrote:

> Sylvain Wallez wrote:

>> Sorry, not much time to dig into the implementation for now, but I 
>> will :-)
> Good :)

In order to have a better opinion on the naming issue (virtual-blah / 
special src="..." / no src) I started digging in the implementation.

VPCs aren't an easy problem, and what follows isn't a criticism of the 
hard work that's been done but a desire to have a robust implementation. 
This may also bring some light on this naming issue.

                                 -- oOo --

First of all, let's detail the process that happens to build and use VPCs.

1 - TreeBuilder creates the TreeProcessor
1.1 - A service manager is built with the contents of <map:components>
1.1.1 - This manager has its own Avalon context object, that inherits 
the context of the parent service manager
1.1.2 - Some of these components are VPCs. Important point: these are 
pooled components for which no instance is created at this time.

1.2 - The TreeBuilder crawls the sitemap program to build the 
ProcessingNode tree
1.2.1 - parsing of <map:components> invokes VPCNodeBuilder that stores 
the processing node for a VPC in the Avalon context (see 1.1.1)

2 - TreeProcessor is invoked to build a pipeline
2.1 - The processing tree is executed and feeds a pipeline object with 
pipeline components
2.2 - The pipeline object looks up pipeline components
2.2.1 - VPCs are instanciated and get their processing node from the 
Avalon context (they've been put there in 1.2.1)

2.3 - The pipeline calls setup() on pipeline components
2.3.1 - VPCs invoke their processing node to build their partial pipeline
2.4 - The pipeline calls generator.generate().

                                 -- oOo --

A first important point: the current implementation relies on the fact 
that VPCs are pooled and that no instance is created at startup. Should 
some instances be pre-allocated at startup, they will fail in getting 
their processing node and throw an exception. Fixing this mostly 
requires to get the processing node later in the lifecycle, e.g. in 
setup(), so that's not much a problem.

                                 -- oOo --

What we see here is that VPCs aren't regular components from the way 
their "configuration" is parsed. This configuration isn't parsed by the 
component itself, but by the surrounding environment which is the 

Considering the way component declaration includes are handled today 
(parsing included sources on the fly rather than building a large single 
expanded configuration), this means that VPC declarations must be kept 
in the sitemap file and cannot be located in included files. Users have 
to be clearly warned about this unless we refactor the include mechanism.

The service manager in 2.2 allows for a flat fortress-style naming of 
components and the enclosing elements for selectors is useless when 
individual components specify their class names (e.g. source factories 
or input modules, but not datasources which use hints such as "jdbc" or 
"j2ee"). What this means is that <map:generators> <map:transformers> etc 
are useless and can potentially be omited. Now the TreeProcessor 
specifically relies on them to build VPCs.

                                 -- oOo --

Nothing seriously blocking here, but a general feeling that sitemap 
fragments used by VPCs are really of a different nature than component 
configuration. IMO placing them in <map:components> is mixing different 
concerns and may bring confusion and component management problems in 
the future. You may consider this as FUD, but this isn't my intent: I 
express my bad feelings about this.

                                 -- oOo --

So in the end, my opinion is that sitemap fragments for VPCs should be 
declared in their own section of the sitemap, just as views, resources 
and flows. Components for VPCs will be added to the ServiceManager by 
the TreeBuilder (let's recall that TreeBuilder has full control on the 
ServiceManager as it is the one that creates it).

Rather than having TreeProcessor and ServiceManager mix their stuff in a 
single <map:components>, this allows the TreeProcessor to augment the 
ServiceManager with components that are aliased to their corresponding 
processing nodes. Concerns a kept separate for the sitemap writer, but 
remain unified as regular components from the outside world.



Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message