Re: Time for 9.12.0?

[Andrea Del Bene]

I think we are ready to proceed with the release. To port WICKET-6999 I've
added osgi configuration also to experimental modules modules for HTTP2:

https://github.com/apache/wicket/commit/3054cb6249dfdc61efa5ded2f419359edf847224

It should be ok, just let me know if I did something wrong.

On Fri, Sep 30, 2022 at 9:16 PM Matt Pavlovich  wrote:

> PR #540 is ready for review. I completed updates for the wicket modules
> that we use and can spot check.
>
> Note— It would be contract-breaking to ship wicket-9.x w/ slf4j 2.0
> without this change in place, so next up it’d be good to back-port this to
> the wicket-9.x branch and get some testing underway.
>
> Completed:
>
> wicket-util
> wicket-request
> wicket-core
> wicket-auth-roles
> wicket-devutils
> wicket-extensions
> wicket-jmx
>
> Not yet updated:
>
> wicket-bean-validation
> wicket-cdi
> wicket-guice
> wicket-ioc
> wicket-native-websocket
> wicket-objectsizeof-agent
> wicket-spring
> wicket-velocity
>
> Thanks,
> Matt
>
> > On Sep 30, 2022, at 12:44 PM, Matt Pavlovich  wrote:
> >
> > Update — draft PR here: https://github.com/apache/wicket/pull/540 <
> https://github.com/apache/wicket/pull/540>
> >
> > This PR works for wicket-util and wicket-request modules right now.
> >
> > At issue is the use of enforcer plugin to limit configurations
> per-execution. maven-bundle-plugin runs at various phases and if there is
> not a config for each, the default behavior will execute on the last phase
> and we don’t get the version override as configured in the 'instructions'.
> I’m working on identifying the last goal that runs and perhaps we can get
> away with a single definition for that phase without changing the enforcer
> plugin rules.
> >
> > Thanks,
> > Matt
> >
> >> On Sep 29, 2022, at 2:35 PM, Andrea Del Bene  > wrote:
> >>
> >> Thank you Matt!
> >>
> >> On 29/09/22 16:43, Matt Pavlovich wrote:
> >>> I got pulled off onto other tasks. I will have time to get the PR out
> this weekend.
> >>>
> >>> Thanks,
> >>> Matt Pavlovich
> >>>
>  On Sep 29, 2022, at 6:19 AM, Andrea Del Bene  > wrote:
> 
>  I think I've lost track about this activity...what do we still miss to
>  proceed with the new release?
>  Thank you.
> 
>  On Fri, Sep 16, 2022 at 6:19 PM Matt Pavlovich  > wrote:
> 
> > I can help w/ the OSGi import package. Should just be a simple
> override in
> > the bundle plugin config.
> >
> >> On Sep 15, 2022, at 3:00 PM, Andrea Del Bene  >
> > wrote:
> >> I agree with Martijn. Probably the downgrade is the best solution
> at the
> > moment. Like Martin suggests it would be nice to investigate how
> > Import-Package for OSGi are generated, but it's not a trivial task
> and we
> > need someone with more experience with OSGi
> >> On 14/09/22 09:22, Martijn Dashorst wrote:
> >>> IIUC sfl4j 2.0.0 API is the same as 1.7.x API, so from a Wicket
> > perspective
> >>> it doesn't matter if we ship with 2.0.0 or 1.7.x, right?
> >>>
> >>> If that is the case, I suggest we fall back to 1.7.x, and note
> that one
> > can
> >>> easily upgrade to 2.0.0 without issue if someone so desires.
> >>>
> >>> This will keep it working for most folks, yet give an upgrade path
> for
> >>> those that wish so. It is harder to convince someone to downgrade
> from
> > 2.0
> >>> to 1.7 than to upgrade to 2.0 from 1.7.
> >>>
> >>> But this is my .02 (which is even worth less with the current
> exchange
> >>> rates).
> >> ...😁
> >>> Martijn
> >>>
> >>>
> >
>  --
>  Andrea Del Bene.
>  Apache Wicket committer.
> >
>
>

-- 
Andrea Del Bene.
Apache Wicket committer.

Re: an idea: wicket-resilient mode?

[Martin Terra]

It has evolved a bit:
https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+1.5#MigrationtoWicket1.5-RequestCycle

**
Martin

ma 10. lokak. 2022 klo 10.11 Martin Terra (martin.te...@koodaripalvelut.com)
kirjoitti:

> Yes. You can override runtime handling yourself @
> RequestCycle.onRuntimeException (at least used to be with such name)
>
> In production it is recommended to do so as you best see fit.
>
> **
> Martin
>
> ma 10. lokak. 2022 klo 9.45 Korbinian Bachl (
> korbinian.ba...@whiskyworld.de) kirjoitti:
>
>> Hi,
>>
>> we use wicket for many years now and so far it is a great framework to
>> use. One thing that however seems still a bit of a problem is the way
>> wicket handles (runtime) errors.
>> If you look at a page then the content is often composed of 100's of
>> panels and components.
>> As long as every single component is working all is fine... but if just 1
>> of the many 100 components has any kind of runtime-errors it leads to a 500
>> server error.
>> So I wondered: what stops us from letting wicket have a "resilient mode"?
>> - A mode where an runtime error in any component doesnt lead to the error
>> beeing done as a 500 but instead only let this single component/panel
>> silently fail (by not outputting it - as if it would be .visible(false))
>> and do this gracefully in the background?
>> While wicket doing error-logging in the background?
>> All beeing done by having a setting to let wicket be gracefully/resilient
>> in deploymode?
>>
>> What do you think about this approach?
>>
>> Best,
>>
>> Korbinian
>>
>>
>>
>>

Re: an idea: wicket-resilient mode?

[Martin Terra]

Yes. You can override runtime handling yourself @
RequestCycle.onRuntimeException (at least used to be with such name)

In production it is recommended to do so as you best see fit.

**
Martin

ma 10. lokak. 2022 klo 9.45 Korbinian Bachl (korbinian.ba...@whiskyworld.de)
kirjoitti:

> Hi,
>
> we use wicket for many years now and so far it is a great framework to
> use. One thing that however seems still a bit of a problem is the way
> wicket handles (runtime) errors.
> If you look at a page then the content is often composed of 100's of
> panels and components.
> As long as every single component is working all is fine... but if just 1
> of the many 100 components has any kind of runtime-errors it leads to a 500
> server error.
> So I wondered: what stops us from letting wicket have a "resilient mode"?
> - A mode where an runtime error in any component doesnt lead to the error
> beeing done as a 500 but instead only let this single component/panel
> silently fail (by not outputting it - as if it would be .visible(false))
> and do this gracefully in the background?
> While wicket doing error-logging in the background?
> All beeing done by having a setting to let wicket be gracefully/resilient
> in deploymode?
>
> What do you think about this approach?
>
> Best,
>
> Korbinian
>
>
>
>