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 TreeProcessor.
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.
So, WDYT?
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
