You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martin Grigorov <mg...@apache.org> on 2015/10/13 21:28:14 UTC
Issues with /META-INF/wicket/*.properties
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
Re: Issues with /META-INF/wicket/*.properties
Posted by Tobias Soloschenko <to...@googlemail.com>.
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 <mg...@apache.org>:
>
> 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 <
> tobiassoloschenko@googlemail.com> 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
>>
Re: Issues with /META-INF/wicket/*.properties
Posted by Martin Grigorov <mg...@apache.org>.
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 <
tobiassoloschenko@googlemail.com> 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
>>
>>
>
Re: Issues with /META-INF/wicket/*.properties
Posted by Tobias Soloschenko <to...@googlemail.com>.
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
>
Re: Issues with /META-INF/wicket/*.properties
Posted by Martin Grigorov <mg...@apache.org>.
... and I see it is not in the changelog too :-(
@Martijn: did you forget to pull before doing the release ? :-)
I'd like to have this change in 7.1.0 because it is a bug that requires big
break in minor release to get rid of it. I'd would be better to remove it
sooner before some libraries make use of it and next month need to remove
it.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Oct 19, 2015 at 10:16 PM, Sebastien <se...@gmail.com> wrote:
> Hi Martin,
>
> Actually the feature works with 7.1.0-SNAPSHOT but not with 7.1.0...
>
>
> On Mon, Oct 19, 2015 at 10:14 PM, Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Hi,
> >
> > It must be included.
> > I haven't checked but Martijn cut the release after my commits.
> > Please check the -sources.tgz. Or start Wicket-JQuery-UI examples against
> > 7.1.0 and put a breakpoint in any of the IInitializer impls to see
> whether
> > its #init() method is called during start of the app.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Mon, Oct 19, 2015 at 10:04 PM, Sebastien <se...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Is this feature included (or supposed to be) in the 7.1.0 staging
> release
> > > of yesterday?
> > >
> > > Thanks & best regards,
> > > Sebastien.
> > >
> >
>
Re: Issues with /META-INF/wicket/*.properties
Posted by Sebastien <se...@gmail.com>.
Hi Martin,
Actually the feature works with 7.1.0-SNAPSHOT but not with 7.1.0...
On Mon, Oct 19, 2015 at 10:14 PM, Martin Grigorov <mg...@apache.org>
wrote:
> Hi,
>
> It must be included.
> I haven't checked but Martijn cut the release after my commits.
> Please check the -sources.tgz. Or start Wicket-JQuery-UI examples against
> 7.1.0 and put a breakpoint in any of the IInitializer impls to see whether
> its #init() method is called during start of the app.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, Oct 19, 2015 at 10:04 PM, Sebastien <se...@gmail.com> wrote:
>
> > Hi,
> >
> > Is this feature included (or supposed to be) in the 7.1.0 staging release
> > of yesterday?
> >
> > Thanks & best regards,
> > Sebastien.
> >
>
Re: Issues with /META-INF/wicket/*.properties
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
It must be included.
I haven't checked but Martijn cut the release after my commits.
Please check the -sources.tgz. Or start Wicket-JQuery-UI examples against
7.1.0 and put a breakpoint in any of the IInitializer impls to see whether
its #init() method is called during start of the app.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Oct 19, 2015 at 10:04 PM, Sebastien <se...@gmail.com> wrote:
> Hi,
>
> Is this feature included (or supposed to be) in the 7.1.0 staging release
> of yesterday?
>
> Thanks & best regards,
> Sebastien.
>
> On Sun, Oct 18, 2015 at 11:31 AM, Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Thanks for the responses!
> >
> > I'll work on 1.1
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Wed, Oct 14, 2015 at 1:38 PM, Martijn Dashorst <
> > martijn.dashorst@gmail.com> wrote:
> >
> > > 1.1 for me as well
> > >
> > > Martijn
> > >
> > > On Wed, Oct 14, 2015 at 12:33 PM, Sven Meier <sv...@meiers.net> wrote:
> > > > Hi Martin,
> > > >
> > > > I'd prefer solution 1.1:
> > > >
> > > > - the old solution worked fine, but the properties couldn't be merged
> > for
> > > > uberjar (but nothing I ever worried about)
> > > > - the current solution is flawed, we should get rid of it as soon as
> > > > possible
> > > > - ServiceLoader seems to be a simple working standard.
> > > >
> > > > Regards
> > > > Sven
> > > >
> > > >
> > > >
> > > > On 13.10.2015 21:28, Martin Grigorov wrote:
> > > >>
> > > >> 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
> > > >>
> > > >
> > >
> > >
> > >
> > > --
> > > Become a Wicket expert, learn from the best: http://wicketinaction.com
> > >
> >
>
Re: Issues with /META-INF/wicket/*.properties
Posted by Sebastien <se...@gmail.com>.
Hi,
Is this feature included (or supposed to be) in the 7.1.0 staging release
of yesterday?
Thanks & best regards,
Sebastien.
On Sun, Oct 18, 2015 at 11:31 AM, Martin Grigorov <mg...@apache.org>
wrote:
> Thanks for the responses!
>
> I'll work on 1.1
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Oct 14, 2015 at 1:38 PM, Martijn Dashorst <
> martijn.dashorst@gmail.com> wrote:
>
> > 1.1 for me as well
> >
> > Martijn
> >
> > On Wed, Oct 14, 2015 at 12:33 PM, Sven Meier <sv...@meiers.net> wrote:
> > > Hi Martin,
> > >
> > > I'd prefer solution 1.1:
> > >
> > > - the old solution worked fine, but the properties couldn't be merged
> for
> > > uberjar (but nothing I ever worried about)
> > > - the current solution is flawed, we should get rid of it as soon as
> > > possible
> > > - ServiceLoader seems to be a simple working standard.
> > >
> > > Regards
> > > Sven
> > >
> > >
> > >
> > > On 13.10.2015 21:28, Martin Grigorov wrote:
> > >>
> > >> 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
> > >>
> > >
> >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> >
>
Re: Issues with /META-INF/wicket/*.properties
Posted by Martin Grigorov <mg...@apache.org>.
Thanks for the responses!
I'll work on 1.1
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Oct 14, 2015 at 1:38 PM, Martijn Dashorst <
martijn.dashorst@gmail.com> wrote:
> 1.1 for me as well
>
> Martijn
>
> On Wed, Oct 14, 2015 at 12:33 PM, Sven Meier <sv...@meiers.net> wrote:
> > Hi Martin,
> >
> > I'd prefer solution 1.1:
> >
> > - the old solution worked fine, but the properties couldn't be merged for
> > uberjar (but nothing I ever worried about)
> > - the current solution is flawed, we should get rid of it as soon as
> > possible
> > - ServiceLoader seems to be a simple working standard.
> >
> > Regards
> > Sven
> >
> >
> >
> > On 13.10.2015 21:28, Martin Grigorov wrote:
> >>
> >> 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
> >>
> >
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
Re: Issues with /META-INF/wicket/*.properties
Posted by Martijn Dashorst <ma...@gmail.com>.
1.1 for me as well
Martijn
On Wed, Oct 14, 2015 at 12:33 PM, Sven Meier <sv...@meiers.net> wrote:
> Hi Martin,
>
> I'd prefer solution 1.1:
>
> - the old solution worked fine, but the properties couldn't be merged for
> uberjar (but nothing I ever worried about)
> - the current solution is flawed, we should get rid of it as soon as
> possible
> - ServiceLoader seems to be a simple working standard.
>
> Regards
> Sven
>
>
>
> On 13.10.2015 21:28, Martin Grigorov wrote:
>>
>> 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
>>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Issues with /META-INF/wicket/*.properties
Posted by Sven Meier <sv...@meiers.net>.
Hi Martin,
I'd prefer solution 1.1:
- the old solution worked fine, but the properties couldn't be merged
for uberjar (but nothing I ever worried about)
- the current solution is flawed, we should get rid of it as soon as
possible
- ServiceLoader seems to be a simple working standard.
Regards
Sven
On 13.10.2015 21:28, Martin Grigorov wrote:
> 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
>