I agree that something should be cleaned up. But like I said in the comment to that Jira ticket, I think it should in fact move more toward passing the class rather than the uninitialized instance. I like my objects to be predictable, and I like it even more when I don't have to think about any traps, even if they are well-documented.
I think (I also wrote that in the comment) that perhaps IComponentInstantiationListener should be deprecated and eventually removed, since IComponentInitializationListener should be able to cover all the same use cases without having the unfinished constructor problem. Is there a use case that would not be handled by the initialization listener? Carl-Eric On Fri, 20 Dec 2013 10:53:40 +0200 Martin Grigorov <mgrigo...@apache.org> wrote: > Hi, > > The reporter of https://issues.apache.org/jira/browse/WICKET-5454 > asked to pass the Component instance > to IAuthorizationStrategy#isInstantiationAuthorized() instead of > just its class. > I have no idea why the API has been designed this way but Carl-Eric > gave a good explanation - the component is not yet fully constructed. > > The thing that bothers me is why it is OK to use the instance in my > custom IComponentInstantiationListener and it is not OK to do the > same in IAuthorizationStrategy#isInstantiationAuthorized() ? > If there is a javadoc explaining the possible problem (as for > IComponentInstantiationListener#onInstantiation()) then it is OK. > > Even more - at > https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/Application.java#L276you > can see that right ater rejecting the *Class* we pass the *instance* > to > the UnauthorizedComponentInstantiationListener! > > > Martin Grigorov > Wicket Training and Consulting
