Hi Martin, maybe there are two other options:
1. Use serviceloader in all NON-OSGi environments and only for OSGi use the old mechanism. 2. Implement a switch to tell the Wicket-Application to use the service loader or the old mechanism.
Also I would allow the user to implement another way to load the wicket properties (make the method protected) to cover solutions which might not work either with ServiceLoader nor with the old mechanism.
kind regards Tobias P.S.: I personally prefer the solution mentioned with point 2. Am 13.10.15 um 21:28 schrieb Martin Grigorov:
Hi devs, There are some issues with the new code for scanning for wicket.properties in 7.0.0: - https://issues.apache.org/jira/browse/WICKET-5997 (also discussed at http://stackoverflow.com/questions/33043321/has-anybody-been-able-to-run-wicket-7-0-0-on-websphere-liberty-profile-8-5-5-7 ) - https://github.com/apache/wicket/pull/138 At both reports ServiceLoader (SL) is suggested as a better solution for this functionality. When I implemented the current solution I've ignored SL because I remember having issues with it in OSGi environment and I've preferred the current solution because it works well for WebJars. Adding support for SL is easy. The problem is what to do with the current solution. I see these solutions: 1. Add support for SL and "deprecate" the current solution by logging WARNs 1.1. Log WARNs for several releases and then drop the current solution 1.2. Log WARNs until Wicket 8.0.0 2. Add support for SL and remove the current solution for the next release At the moment we log WARN when the old /wicket.properties is detected on the classpath! I am for 1.1 because the current solution is buggy (in uberjar and OSGi envs) and there is no point to support it. But at the same time I see that this would be a bigger change that probably should wait for major release. Opinions? Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov
