[
https://issues.apache.org/jira/browse/WICKET-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116231#comment-13116231
]
Emond Papegaaij commented on WICKET-4088:
-----------------------------------------
We wanted to override a setting set by one of the initializers. init() is
called before the initializers run, so it is not possible to do it there.
initializeComponents() (the method that runs the initializers) is final, so
can't do it there either. Which only leaves validateInit(), but this method is
really not meant for that. I agree that you should not rely on the exact order
in which initializers are loaded, but as I said, the context classloader always
comes last. This at least gives you a chance to define your own initializer
that runs after the others. As far as I'm concerned, that's the only usecase
this is supposed to support.
Of course, this could also be solved by another init method, which is called
right after initializeComponents(). Perhaps a componentsInitialized() method?
> IInitializers are executed out-of-order
> ---------------------------------------
>
> Key: WICKET-4088
> URL: https://issues.apache.org/jira/browse/WICKET-4088
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.18, 1.5.0
> Reporter: Emond Papegaaij
> Priority: Minor
>
> wicket.properties urls are added to an HashSet, causing the IInitializers to
> be loaded in random order. In AbstractClassResolver.getResources, the HashSet
> should be changed to a LinkedHashSet.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
