Hi Martin, maybe it is possible to extract the functionality into a submodule of wicket all libraries can use.
kind regards Tobias > Am 14.10.2015 um 09:28 schrieb Martin Grigorov <[email protected]>: > > 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 >>
