Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: core
-
Labels:None
-
Number of attachments :
Description
Currently Deployer automatically adds the constructed script to the parent container ie, calling buildContainer() with the 3rd parameter equal to true.
This will work great for composition scripts like this:
pico = builder.container() {
//Do something.
}
But in my case, I've assembled a fancy dancy parent pico container with some JMX registration capabilities, etc that I want to pass down to the items to be deployed. So I use:
pico = builder.container(parent:parent) {
//Do something.
}
So now the composition script calls parent.makeChildContainer() which nicely propagates all my fancy services down to the deployed component. Only one problem: Because I'm instructing ContainerBuilder.buildContainer() to add the created container to the parent, my container is getting added twice!
Since I have a heavily modified Deployer in my code base, I could certainly just have ContainerBuilder.buildContainer() NOT add the created container to the parent.
But instead of risking detached containers because someone forgot to use
pico = builder.container(parent:parent) {}
in their composition scripts but just wrote
pico = builder.container() {},
I'd like to propose a slight modification to the "add created container to script" functionality in ContainerBuilder:
I would like the script to check the script handed back by whatever script was run and if the container does NOT have a parent, but "add to parent" functionality was specified, then we could automatically add it but if no parent container existed , then the container builder would dutifully add the created container to the parent as expected.
Would this mess people up?
-Mike (R)
Activity
When you say adding container to parent, do you mean as a component or as child-container. I think the latter.
You're basically trying to guard against usages of "pico = builder.container() {}," in components that are not in codebases you control? Things that are being pluged into your env as guests ?
Paul Hammant
added a comment - When you say adding container to parent, do you mean as a component or as child-container. I think the latter.
You're basically trying to guard against usages of "pico = builder.container() {}," in components that are not in codebases you control? Things that are being pluged into your env as guests ?
Yes, adding a child container to a parent container the usage scenario is sort of along the lines of a Microcontainer. So from the root container, I need to be able to manage all my child containers and perform a lifecycle on an entire hierarchy of containers.
Thanks for giving it some thought!
-Mike (R)
Michael Rimov
added a comment - Yes, adding a child container to a parent container the usage scenario is sort of along the lines of a Microcontainer. So from the root container, I need to be able to manage all my child containers and perform a lifecycle on an entire hierarchy of containers.
Thanks for giving it some thought!
-Mike (R)
Well, I implemented something that would do these things locally, but it was nasty as all getout because since the hierarchies are isolated by proxies, it is impossible to determine if the container you just received actually exists in the parent's children collection or not
I ultimately had to create a "container counting visitor" that would count the hierarchy before and after a container was built via script and if there was no difference, add the newly created container to the parent. Messy!
Perhaps a real fix should be put off until Pico 2 because I can't see any way of making it work with the Pico api as it is.