Hi Tobias, The problem is that if you use some library (e.g. wicket-extensions, wicket-jquery-ui, ...) then these libraries should implement both/all ways. I.e. if you implement your own way then these libraries most probably won't work.
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Oct 14, 2015 at 8:51 AM, Tobias Soloschenko < [email protected]> wrote: > 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 >> >> >
