Details
Major Description
Wicket has a very powerful IComponentResolver interface that allows a developer to supply their own IComponentResolver implementation which allows component based assembly of pages from a prebuilt collection of panels without needing to make hard coded instantiations of the entire set of panels into every page class that may use them. This flexibility is incredibly powerful and means that a great amount of page assembly can take place purely in the markup.
Unfortunately any components embedded within a <wicket:enclosure> markup </wicket:enclosure> tag (and possibly other 'wrapping' style tags like wicket:border) will not trigger the normal 'component resolution' process that calls the IComponentResolver implementation and so the children cause a 'component not found' page crash unless they are explicitly added to the page that will contain them.
This is extremely undesirable because there can be potentially many, many choices of components/panels that can be enclosed. For reasons of flexibility, code maintainability, efficient CPU and memory usage it is undesirable to add the entire collection of child component candidates to every page that could get instantiated with an enclosure in it.
This bug is trivial to reproduce - set up an IComponentResolver that resolves a simple panel, do not add that panel explicitly to a page, but refer to it inside a wicket:enclosure tag in the page markup. Display the page in a browser.
I think this would be a fairly straightforward fix for someone who has a good understanding of the wicket framework lifecycles. I had a few attempts at rectifying the issue but after much trial and error seem unable to locate the appropriate place for the 'component resolution' to be triggered.
