|
[
Permlink
| « Hide
]
Nick Sieger added a comment - 04/Aug/04 11:09 AM
Cleaned up imports in the second version
I did yesterday a quite similar modification to GenericCollectionCA in the MX_PROPOSAL branch. I'll have a look.
Another approach would be to register the child comps and the array/GCCA in a parent container and put the composite in a child container, but using two containers might seem like overkill.
Not really. The arrays have to be generated on the fly, since they may change ... unless the container is read-only.
In my haste I didn't even realize that GCCA is a package-private class only used by the CICA! So the testInstantiateCompositeDependingOnComponentArrayRequiresPreInstantiationAndCaching case wouldn't even normally work. I still end up having to create the array manually and registering it as a component instance. I basically end up with this, which now does not even leverage GCCA:
public void testInstantiateCompositeDependingOnComponentArrayRequiresPreInstantiationAndCaching() { Object[] arr = (Object[]) pc.getComponentInstance("x"); assertNotNull(arr); pc.registerComponentImplementation(CompositeComponent.class, Component cc = (Component) pc.getComponentInstance(CompositeComponent.class); assertNotNull(cc); So the patch isn't really valid.
Even so, it would still be nice for the following to just work with minimal extra config. I guess this is related to Thomas' comments on the list about the greedy nature of the GCCA – see http://article.gmane.org/gmane.comp.java.picocontainer.devel/3491 public static interface Component {} public static class CompositeComponent implements Component { public CompositeComponent(Object[] children) {
this.children = children;
} public static class LeafComponent implements Component { pc.registerComponentInstance(LeafComponent.class); Have a look at the GenericCollectionAdapterTestCase. This should demonstrate, what you want.
|
|||||||||||||||||||||||||||||||||||||||||||||||