Details
Description
Using the Groovy Builder, it appears currently impossible to implicitly propagate parent container types and adapterfactories to children containers. The following test case will fail. (NOTE: The test case depends on the BasePicoVisitor enhancement submitted in PICO-235, but it is easy enough to backport)
public void testChildContainerHasParentAdapter() {
Reader script = new StringReader("" +
"builder = new org.nanocontainer.script.groovy.NanoContainerBuilder()\n"
+ "pico = builder.container(parent) { \n"
+ " container()
\n"
+ "}"
);
//Build the parent
ObjectReference parent = new SimpleReference();
parent.set(new DefaultPicoContainer(new BeanPropertyComponentAdapterFactory(new DefaultComponentAdapterFactory())));
//Build target
ScriptedContainerBuilder builder = new GroovyContainerBuilder(script, Thread.currentThread().getContextClassLoader());
builder.buildContainer(new SimpleReference(),parent,null, true);
//Collect a list of all containers.
final List allContainers = new ArrayList();
PicoVisitor testingVisitor = new BasePicoVisitor() {
public void visitContainer(PicoContainer pico)
};
testingVisitor.traverse((PicoContainer)parent.get());
//Verify that default component adapter factory gets propagated
//down the hierarchy much in the way that pico.makeChildContainer() works.
for (Iterator i = allContainers.iterator(); i.hasNext()
}
Issue Links
- relates to
-
NANO-118 AspectablePicoContainer's handling of .makeChildContainer() wrong
Activity
Field | Original Value | New Value |
---|---|---|
Component/s | core [ 10193 ] | |
Fix Version/s | 1.0 [ 10148 ] | |
Component/s | groovy [ 11631 ] |
Attachment | ParentPropagationNanoPatch.diff [ 16219 ] |
Resolution | Fixed [ 1 ] | |
Fix Version/s | 1.0 [ 10148 ] | |
Status | Open [ 1 ] | Resolved [ 5 ] |
Fix Version/s | 1.0-RC2 [ 11851 ] |
As discussed on the mailing list, here is the patch for the functionality with test case.