Re: DefaultMarkupIDGenerator

[Martin Grigorov]

On Tue, Sep 17, 2024 at 11:07 AM Korbinian Bachl
 wrote:

> Hi,
>
> I've stumbled over a not so old blog post describing the problem when many
> components with AJAX are used:
>
> https://www.coderdreams.com/tracking-down-a-bug-in-production-wicket-application/
>
> Can this problem still happen?
>

Probably!
The blog author never contacted us to report the issue ...


>
> After watching
> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/DefaultMarkupIdGenerator.java
> and especially line 70, I think yes?
>
> This could explain why I had JS errors in production that I never
> discovered the reason for but went away after I set the markup ID manually
> within a repeater
>

Care to open a Pull Request ? Or at least file a ticket at Jira ?



>
> Best,
>
> KB
>

Re: wicket version definition in maven poms

[Martin Grigorov]

I guess because it "Just Works TM".
Our release scripts will need to be adapted to any changes...

On Wed, Jun 19, 2024 at 10:33 AM Korbinian Bachl
 wrote:

> Hi,
>
> is there any reason wicket has static
> 9.19.0-SNAPSHOT
> everywhere, even in modules
>
> 
> org.apache.wicket
> wicket-parent
> 9.19.0-SNAPSHOT
> ../pom.xml
> 
>
>
>
> instead of a single defined properties in Wicket Parent:
>
> ${revision}${changelist}
> ...
> 
> 9.19.0
> -SNAPSHOT
> ...
> 
>
>
> and in submodules:
>
> 
> org.apache.wicket
> wicket-parent
> ${revision}${changelist}
> 
>
>
> That feature was introduced in maven 3.5 in 2017.
>
> KB
>

Re: [VOTE] Release Apache Wicket 8.16.0

[Martin Grigorov]

+1 to release

On Thu, Jun 13, 2024 at 12:13 AM Andrea Del Bene 
wrote:

> This is a vote to release Apache Wicket 8.16.0
>
> Please download the source distributions found in our staging area
> linked below.
>
> I have included the signatures for both the source archives. This vote
> lasts for 72 hours minimum.
>
> [ ] Yes, release Apache Wicket 8.16.0
> [ ] No, don't release Apache Wicket 8.16.0, because ...
>
> Distributions, changelog, keys and signatures can be found at:
>
>  https://dist.apache.org/repos/dist/dev/wicket/8.16.0
>
> Staging repository:
>
> https://repository.apache.org/content/repositories/orgapachewicket-1205
>
> The binaries are available in the above link, as are a staging
> repository for Maven. Typically the vote is on the source, but should
> you find a problem with one of the binaries, please let me know, I can
> re-roll them some way or the other.
>
> Staging git repository data:
>
>  Repository:  g...@github.com:bitstorm/wicket.git
>  Branch:  build/wicket-8.16.0
>  Release tag: rel/wicket-8.16.0
>
>
> 
>
>  The signatures for the source release artefacts:
>
>
> Signature for apache-wicket-8.16.0.zip:
>
>  -BEGIN PGP SIGNATURE-
>
> iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAmZqB+QACgkQh48B+qjT
> VuGz+xAAqu5r2R39HGtVLFDQ+t26pP/0DNGZv95sJvPbAjZjlnmPvw2zrbM+p69/
> G2JC1BYn9kSae2FVPALS6bcZ+c55Lg8atoA8o7RFOsbvQmRaXCXnU+ISu02xKlvg
> +6EL4a2aXka4jF4nDSWIBfU9jm9Nk3CTMwYKTVd0r7LdVEcANB/LCSq74j08/PVM
> CCh9vF0/FqLjC6GfD6uu6kL13r24aVk9RmvLXq5uZIOs/nnsfEx5jZtH818kdqre
> fvuuT3wbTUJye9DDpuKTESAzMo+aXTKP9M1+pZOmiKnTDiN2aFi02vCo7YrmWpKO
> +03LiQt5WZorDUamuBZwetzWajA1lyc+SGWwgnTCTEOkvZ6hMq3zRvo1awb+w0GL
> hKGspHRWrlXuwueaIT7/ZDyE26UzIR+oo7l5C0iXPZkAz9ejG6lyoQz4B0sifJlC
> ob3j5goApWIXBZMX/FyU1pHivLEbY7Uf8PNcq0g/NYtNuSk+/3yENH1cW+79gWEW
> XvaxYfrhTjyIxhnv3cPz3erwSZTHA3r1xURrOYlrlsv8Aqd+Jj+USUhRPP60mc/W
> S9bM3o05eFsZVY1rtJVfGl+nYuFEri1T8RgWNeolAdh37S5wdJy+iHn0jUnsPMQK
> d27lFJ5neYqYC4F826vwBKDIg8FWUyrX1CDKfXidkJV/IAA03NE=
> =Wi7u
> -END PGP SIGNATURE-
>
> Signature for apache-wicket-8.16.0.tar.gz:
>
>  -BEGIN PGP SIGNATURE-
>
> iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAmZqB+QACgkQh48B+qjT
> VuEdjA/+P1szVHdIcom1H1hBTFBSaVaEM8aGf2S4dGplaFiHF3tySsvXzWnbFApU
> 7ycylRMheTz6BXRTpo1XGC57WNiqKCE5R9EFZkPqQiQMoFVb6lmEtTQqV+l8Tbxb
> L2D1HEN3FhZ/KfPGKm6q46bjMfvfC+hb2mFbcsA8EftnkyKkZ0QfSYfXOCFSaEmF
> mEruwXLeQAx2VRTzXgJzhQanjmNiqb1o7x0lCF26m7J6fgXMk+dl7wMg1/Lzl+tV
> 8It+eD598zs19hoytO5lKLDVbLPeSVAfxYEChH5BTpR2MTjY2YDBtngo8U5HtHTs
> Sd0ICr/oOAWbu86GKCyMNk+uYNdcQCEZtdA4/qQUTq4O0UsFS5UcAUWT4Z0uoq3S
> 6c4Aa6S2faPw4ThhaCWSO56PMN3xKBAmERA8gmADv41PHh4N3BDuTANB3bwSrN/3
> b1I39Hxol+OXyuKMnivMeG9OdjoalSlSMhZkA4Tu0dokiZpDVslKltQcnApZdOyd
> 6BQuF7j8sQugiZLjtRPzyvIMo3oILNz1bVLOvltYEKI/AB4+C9ShBIX+EO1KlThO
> 0P2PjZXgPKNPKS51EsFGZa33tMEDCiuITEDGFeH0XveEnG0BLbBkE/Yx5lJfULdr
> hZzNoF2E7tbktMsC0fSIoSQ6rCwrgeF0FTqZrkQuuKzMFJ1fdck=
> =4MXn
> -END PGP SIGNATURE-
>
> 
>
>  CHANGELOG for 8.16.0:
>
> ** Bug
>
>  * [WICKET-7056] - HttpSessionStore#getAttribute called on
> invalidated session
>
>

Re: [VOTE] Release Apache Wicket 10.1.0

[Martin Grigorov]

+1 to release

Tested:
- local build from sources
- various examples

On Tue, May 28, 2024 at 10:35 PM Andrea Del Bene 
wrote:

> This is a vote to release Apache Wicket 10.1.0
>
> Please download the source distributions found in our staging area
> linked below.
>
> I have included the signatures for both the source archives. This vote
> lasts for 72 hours minimum.
>
> [ ] Yes, release Apache Wicket 10.1.0
> [ ] No, don't release Apache Wicket 10.1.0, because ...
>
> Distributions, changelog, keys and signatures can be found at:
>
>  https://dist.apache.org/repos/dist/dev/wicket/10.1.0
>
> Staging repository:
>
> https://repository.apache.org/content/repositories/orgapachewicket-1204/
>
> The binaries are available in the above link, as are a staging
> repository for Maven. Typically the vote is on the source, but should
> you find a problem with one of the binaries, please let me know, I can
> re-roll them some way or the other.
>
> Staging git repository data:
>
>  Repository:  g...@github.com:bitstorm/wicket.git
>  Branch:  build/wicket-10.1.0
>  Release tag: rel/wicket-10.1.0
>
>
> 
>
>  CHANGELOG for 10.1.0:
>
> ** Bug
>
>  * [WICKET-7102] - Error in LiveSessionsPage
>  * [WICKET-7104] - wicket-autocomplete.min.js minified too aggressively
>  * [WICKET-7111] - Greek Application i18n is broken due to wrong
> file name
>
> ** New Feature
>
>  * [WICKET-7109] - Create a ready to use dropdown supporting grouping
>
> ** Improvement
>
>  * [WICKET-7098] - [Websockets] malformed XML is generated if
> runtime exceptions happen during rendering phase of a web socket push
> request
>  * [WICKET-7101] - auto-label is not automatically updated when
> related form component is updated.
>  * [WICKET-7103] - Enhance ModalDialog API
>  * [WICKET-7110] - Add stack trace of lock holding thread in
> CouldNotLockPageException
>
> ** Wish
>
>  * [WICKET-7105] - Remove 'final' from
> AbstractPartialPageRequestHandler#add(Component...)
>
>

Re: new wicket releases?

[Martin Grigorov]

Someone wants to take a look at https://github.com/apache/wicket/pull/846
before the new release ?
The contributor spent time debugging the issue and offering a fix. It would
be nice to give some feedback.

On Wed, May 8, 2024 at 7:49 AM Maxim Solodovnik 
wrote:

> Previous release was ~6 weeks ago
>
> so +1 for release :)
>
> On Tue, 7 May 2024 at 23:08, Ernesto Reinaldo Barreiro
>  wrote:
> >
> > Hi,
> >
> > Maybe it is time for the next releases of wicket 10 and 9? WDYT?
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
>
>
>
> --
> Best regards,
> Maxim
>

Re: Could not lock page exception improvement

[Martin Grigorov]

Hi,

On Tue, May 7, 2024 at 2:20 PM Martijn Dashorst 
wrote:

> Hi!
>
> I was looking at our exception reporting in our application(s), and noticed
> that when the CouldNotLockPageException is thrown, it only logs the stack
> elements of the request that keeps the lock.
>

"... of the request that keeps the lock"
Isn't that the important stacktrace ?
I.e. it does not log the stacktrace of the current request but of the one
that keeps the lock, i.e. hangs.


>
> What I'd like to do is to construct an exception and fill that exception's
> stack trace elements with the stack of the lock keeping request, and
> setting that as the cause of the CouldNotLockPageException.
>
> While this is a bit esoteric in nature, I think it is functionally correct
> in that the page that keeps the lock is actually the cause of the CNLPE.
>
> This would make debugging the occurrences of the CNLPE a bit better, as the
> exception itself is not informative, and you're actually interested in the
> cause. So this would alleviate the need to peruse the logs of one's
> application, and you can just look in the reported exception itself.
>
> WDYT?
>
> Martijn
>

Re: [VOTE] Release Apache Wicket 10.0.0 - TAKE 2

[Martin Grigorov]

+1 to release !

Tested:
- local build from the .tar.gz file
- create a new project from the archetype
- build and test wicket-jquery-selectors, wicket-webjars and
wicket-bootstrap
- test various Wicket examples on Tomcat 11

On Fri, Mar 8, 2024 at 8:55 PM Andrea Del Bene  wrote:

> This is a vote to release Apache Wicket 10.0.0
>
> Please download the source distributions found in our staging area
> linked below.
>
> I have included the signatures for both the source archives. This vote
> lasts for 72 hours minimum.
>
> [ ] Yes, release Apache Wicket 10.0.0
> [ ] No, don't release Apache Wicket 10.0.0, because ...
>
> Distributions, changelog, keys and signatures can be found at:
>
>  https://dist.apache.org/repos/dist/dev/wicket/10.0.0
>
> Staging repository:
>
> https://repository.apache.org/content/repositories/orgapachewicket-1200/
>
> The binaries are available in the above link, as are a staging
> repository for Maven. Typically the vote is on the source, but should
> you find a problem with one of the binaries, please let me know, I can
> re-roll them some way or the other.
>
> Staging git repository data:
>
>  Repository:  g...@github.com:bitstorm/wicket.git
>  Branch:  build/wicket-10.0.0
>  Release tag: rel/wicket-10.0.0
>
>
> 
>
>  CHANGELOG for 10.0.0:
>
> ** Sub-task
>
>  * [WICKET-7089] - Set cookie SameSite only if the container supports
> it
>
> ** Bug
>
>  * [WICKET-7081] - Open packages to expose resources to other modules
>  * [WICKET-7086] - Injecting Spring bean may cause ClassCastException
>  * [WICKET-7087] - AjaxLazyLoadPanelTester not available in 10.0.0-M2
>  * [WICKET-7090] - Files in release jars do not have a modification
> timestamp set
>  * [WICKET-7091] - FilePageStore throws NPE
>  * [WICKET-7096] - stylesheets referenced via automatic linking miss
> nonce attribute
>
> ** Improvement
>
>  * [WICKET-7080] - [Events] make default events delivery machinery
> pluggable and roll usable annotation based one
>  * [WICKET-7082] - Easier to work with polymorphic values inside IModel
>  * [WICKET-7083] - Trigger client side validation when using
> SubmitLinks
>  * [WICKET-7088] - Improve test reliability by resolving
> nondeterministic order of Set and Map
>  * [WICKET-7093] - Add support for missing CSP directives
>  * [WICKET-7094] - Make all CSP schemes configurable
>  * [WICKET-7099] - Validate FormTester constructor parameter
> workingForm
>
> ** Task
>
>  * [WICKET-7079] - Update the user guide with the new wicket-tester
> module
>  * [WICKET-7100] - Update commons-fileupload2 to 2.0.0-M2
>
>
>

Re: Commons Fileupload M2

[Martin Grigorov]

Done with https://issues.apache.org/jira/browse/WICKET-7100

On Mon, Feb 12, 2024 at 9:51 AM Martin Grigorov 
wrote:

> Hi,
>
> On Sun, Feb 11, 2024 at 2:40 PM Thomas Heigl  wrote:
>
>> Hi all,
>>
>> There is a new milestone for commons-fileupload (M2):
>>
>> https://github.com/apache/commons-fileupload/blob/master/RELEASE-NOTES.txt
>>
>> They decided to split servlet support into two modules:
>>
>> - commons-fileupload2-jakarta-servlet5
>> - commons-fileupload2-jakarta-servlet6
>>
>> We should probably upgrade to this new release before releasing Wicket 10
>> because the upgrade requires changes to imports:
>>
>
> +1
>
>
>>
>> org.apache.commons.fileupload2.jakarta.JakartaServletRequestContext ->
>>
>> org.apache.commons.fileupload2.jakarta.servlet6.JakartaServletRequestContext
>>
>> Which servlet version are we planning to support for Wicket 10? The
>> migration page currently says 5.0+, so we should probably use the jakarta5
>> module? I'm not sure though.
>>
>
> Servlet5!
> Unless there is something really nice in Servlet6 that we don't want to
> miss!
>
>
>
>>
>> Any thoughts?
>>
>> Best,
>>
>> Thomas
>>
>

Re: Commons Fileupload M2

[Martin Grigorov]

Hi,

On Sun, Feb 11, 2024 at 2:40 PM Thomas Heigl  wrote:

> Hi all,
>
> There is a new milestone for commons-fileupload (M2):
>
> https://github.com/apache/commons-fileupload/blob/master/RELEASE-NOTES.txt
>
> They decided to split servlet support into two modules:
>
> - commons-fileupload2-jakarta-servlet5
> - commons-fileupload2-jakarta-servlet6
>
> We should probably upgrade to this new release before releasing Wicket 10
> because the upgrade requires changes to imports:
>

+1


>
> org.apache.commons.fileupload2.jakarta.JakartaServletRequestContext ->
>
> org.apache.commons.fileupload2.jakarta.servlet6.JakartaServletRequestContext
>
> Which servlet version are we planning to support for Wicket 10? The
> migration page currently says 5.0+, so we should probably use the jakarta5
> module? I'm not sure though.
>

Servlet5!
Unless there is something really nice in Servlet6 that we don't want to
miss!



>
> Any thoughts?
>
> Best,
>
> Thomas
>

Re: wicket 10 production ready plan

[Martin Grigorov]

Hi,

We work on the non-technical tasks (press release, announcement, etc.).
IMO it should be released in the next few weeks!

Martin

On Wed, Jan 10, 2024 at 7:13 AM any sdk  wrote:

> Hello wicket team,
>
> May I ask you when the wicket 10 production ready version will be released?
>
>
> https://stackoverflow.com/questions/77790782/apache-wicket-10-production-release-date
>

Re: Wicket 10 and wicket bootstrap 7.0.2-SNAPSHOT error in modal

[Martin Grigorov]

Hi Andrea,

Please use Wicket-Bootstrap's issues or StackOverflow for questions about
Wicket-Bootstrap. Or us...@wicket.apache.org.
dev@wicket.a.o is about the development of Apache Wicket itself.

On Mon, Jan 8, 2024 at 6:57 PM Andrea Patricelli <
andreapatrice...@apache.org> wrote:

> Hi all,
>
> I've just upgraded a project to wicket-bootstrap 7.0.2-SNAPSHOT and
> wicket 10.0.0-M2.
>
> I'm getting as clear as cryptic error with a multivalued panel when
> clicking the "+" button to add a new text field panel.
>
> Basically the multivalued panel goal is to manage multivalued attributes
> of an object, especially a list of strings, nothing too much complex.
>
> The error is:
>
> POST
>
> http://localhost:9090/syncope-console/wicket/bookmarkable/org.apache.syncope.client.console.pages.Realms?3-1.0-body-content-body-container-content-tabbedPanel-panel-searchResult-outerObjectsRepeater-0-outer-form-content-form-view-plainSchemas-tabs-0-body-content-schemas-8-panel-multiValueContainer-innerForm-content-view-0-panelPlus-add&selectedIndex=1
> 400 (Bad Request)
> Wicket.Ajax.Call.failure: Error while parsing response: Bad Request
>
> The error occurs only when I'm in a boostrap modal window by
> wicket-bootstrap-core. The very same panel outside the modal is working
> fine.
>
> The multivalued panel class structure is quite complex, but the button
> that fires such AJAX behavior is here [1].
>
> Moreover I've also reproduced the same structure (simplified) with the
> wicket sample archetype, but no error occurs and I'm not able to
> reproduce the issue.
>
> I'd like to ask not a solution, but at least the most effective way to
> debug and to find some more hints about the error (logs, whatever) and
> why the request is returning 400 without any apparent wrong input.
>
> I'm working in dev mode and using the chrome dev console, but did not
> find any clue to solve the issue.
>

I'd compare the request url and parameters when using the modal and without
it. Is there any noticeable difference ?
The next step is to set a breakpoint at HttpServletResponse#sendError() and
see who calls it and the reason why it is being called.



>
> Thanks and regards,
> Andrea
>
> [1]
>
> https://github.com/apache/syncope/blob/master/client/idrepo/common-ui/src/main/java/org/apache/syncope/client/ui/commons/markup/html/form/AbstractMultiPanel.java#L94-L125
>
> --
> Andrea Patricelli
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Member at The Apache Software Foundation
> Syncope
>
>

Re: Upgrade to Wicket 10 and Bootstrap 5

[Martin Grigorov]

On Thu, Jan 4, 2024 at 2:01 PM Andrea Patricelli <
andreapatrice...@apache.org> wrote:

> Thanks for the quick reponse Martin.
>
> We're ok to use the SNAPSHOT and going to report issues, if any. But we
> do not find on oss.sonatype.org, will it be available there soon or do
> we have to get from some other source?
>

Please try again!


>
> Best regards,
> Andrea
>
> On 04/01/24 12:44, Martin Grigorov wrote:
> > Hi,
> >
> > On Thu, Jan 4, 2024 at 1:05 PM Andrea Patricelli <
> > andrea.patrice...@tirasa.net> wrote:
> >
> >> Good morning all and happy new year,
> >>
> >> I'm currently upgrading my frontend application to wicket 10, I'm on
> >> 10.0.0-M2. I'm also using some de.agilecoders.wicket.wicket-bootstrap
> >> libraries.
> >>
> >> Which version of wicket-bootstrap do you suggest to fully comply with
> >> bootstrap 5 and correctly upgrade the whole frontend? Is the current
> >> released 7.0.1 good enough or should I move to 7.0.2-SNAPSHOT?
> >>
> > If you are OK to use a -SNAPSHOT then use it! It contains some
> improvements
> > since Oct 20 2023!
> > This way you will test them and report if there are regressions!
> > Once you need a proper release just request one at
> > https://github.com/l0rdn1kk0n/wicket-bootstrap/issues/new !
> >
> >
> >> Thanks and regards,
> >> Andrea
> >>
> >> --
> >> Andrea Patricelli
> >>
> >> Tirasa - Open Source Excellence
> >> http://www.tirasa.net/
> >>
> >> PMC Member at The Apache Software Foundation
> >> Syncope
> >>
> >>
> --
> Andrea Patricelli
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Member at The Apache Software Foundation
> Syncope
>
>

Re: Incorrect modification time in jars

[Martin Grigorov]

On Thu, Jan 4, 2024 at 1:02 PM Emond Papegaaij 
wrote:

> >
> > I've just opened a PR with this change (
> > https://github.com/apache/wicket/pull/758). I don't think this change
> > will be problematic, but as it only really influences the release builds,
> > it's hard to test its effect without doing an actual release.
> >
>
> It turned out that maven-bundle-plugin doesn't set these timestamps at all.
> The fix was to switch back to jar-packaging and use the maven-bundle-plugin
> to generate the manifest only. The jar is now again built by the
> maven-jar-plugin, which does respect project.build.outputTimestamp. The
> contents of the manifest.mf is equivalent (not identical, because the
> entries are sorted differently and the line length is different), so I
> think this change is ok.
>

Sounds good to me!
I hope the OSGi support isn't broken. I am not sure what else the
maven-bundle-plugin does. Hopefully some OSGi user will test it and report
back!
Thank you, Emond!



>
> Best regards,
> Emond
>

Re: Upgrade to Wicket 10 and Bootstrap 5

[Martin Grigorov]

Hi,

On Thu, Jan 4, 2024 at 1:05 PM Andrea Patricelli <
andrea.patrice...@tirasa.net> wrote:

> Good morning all and happy new year,
>
> I'm currently upgrading my frontend application to wicket 10, I'm on
> 10.0.0-M2. I'm also using some de.agilecoders.wicket.wicket-bootstrap
> libraries.
>
> Which version of wicket-bootstrap do you suggest to fully comply with
> bootstrap 5 and correctly upgrade the whole frontend? Is the current
> released 7.0.1 good enough or should I move to 7.0.2-SNAPSHOT?
>

If you are OK to use a -SNAPSHOT then use it! It contains some improvements
since Oct 20 2023!
This way you will test them and report if there are regressions!
Once you need a proper release just request one at
https://github.com/l0rdn1kk0n/wicket-bootstrap/issues/new !


>
> Thanks and regards,
> Andrea
>
> --
> Andrea Patricelli
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> PMC Member at The Apache Software Foundation
> Syncope
>
>

Re: Wicket 10(-M?) checkpoint

[Martin Grigorov]

On Wed, Dec 20, 2023 at 5:56 PM Maxim Solodovnik 
wrote:

> Hello All,
>
> Do we still need `javax.servlet` and `javax.servlet.http` packages in
> `wicket-util` ?
>

Hm!
I think they could be removed now!
They were needed for the dependencies which didn't have jakarta.** releases.
I am not sure about wicket-cdi - some (test) dependencies there still have
only Java EE releases...



>
> On Mon, 18 Dec 2023 at 07:33, Vit Rozkovec  wrote:
> >
> > One more catch: https://github.com/apache/wicket/pull/749
> >
> >
> > On 15. 12. 23 13:24, Martin Grigorov wrote:
> > > It seems we are good to go!
> > >
> > > On Mon, Dec 11, 2023 at 3:10 PM Thomas Heigl 
> wrote:
> > >
> > >> Hi all,
> > >>
> > >> I upgraded our main application to Wicket 10.0.0-M2, Spring 6.1, and
> Spring
> > >> Boot 3.2 last week.
> > >>
> > >> All my (thousands) of tests are green and I did some exploratory
> testing.
> > >>
> > >> LGTM!
> > >>
> > >> Thomas
> > >>
> > >>
> > >> On Wed, Dec 6, 2023 at 2:08 PM Vit Rozkovec 
> wrote:
> > >>
> > >>>
> > >>> On 06. 12. 23 13:08, Martin Grigorov wrote:
> > >>>> The reason is SameSite support -
> > >>>>
> > >>
> https://github.com/apache/wicket/commit/f0b4b1b3b63f33e12c8b2b04e22fcf73b773ec34
> > >>>> It is easy for us to fix the version in the wiki!
> > >>>> How easy is it for you to use a container that supports Servlet API
> 6 ?
> > >>>>
> > >>> Unfortunately some libraries do not support Jetty 12 yet, so I'm
> stuck
> > >>> with Jetty 11 that supports only Servlet API 5:
> > >> https://eclipse.dev/jetty/
> > >>> The solution you've done in
> > >>>
> > >>>
> > >>
> https://github.com/apache/wicket/commit/a68536eb095bb5cf59e4063b6af9436523ddc623
> > >>> works for me, tried with locally built M3-SNAPSHOT.
> > >>>
> >
> >
> >
>
>
> --
> Best regards,
> Maxim
>

Re: Wicket 10(-M?) checkpoint

[Martin Grigorov]

It seems we are good to go!

On Mon, Dec 11, 2023 at 3:10 PM Thomas Heigl  wrote:

> Hi all,
>
> I upgraded our main application to Wicket 10.0.0-M2, Spring 6.1, and Spring
> Boot 3.2 last week.
>
> All my (thousands) of tests are green and I did some exploratory testing.
>
> LGTM!
>
> Thomas
>
>
> On Wed, Dec 6, 2023 at 2:08 PM Vit Rozkovec  wrote:
>
> >
> >
> > On 06. 12. 23 13:08, Martin Grigorov wrote:
> > >
> > > The reason is SameSite support -
> > >
> >
> https://github.com/apache/wicket/commit/f0b4b1b3b63f33e12c8b2b04e22fcf73b773ec34
> > > It is easy for us to fix the version in the wiki!
> > > How easy is it for you to use a container that supports Servlet API 6 ?
> > >
> > Unfortunately some libraries do not support Jetty 12 yet, so I'm stuck
> > with Jetty 11 that supports only Servlet API 5:
> https://eclipse.dev/jetty/
> >
> > The solution you've done in
> >
> >
> https://github.com/apache/wicket/commit/a68536eb095bb5cf59e4063b6af9436523ddc623
> > works for me, tried with locally built M3-SNAPSHOT.
> >
>

Re: Incorrect modification time in jars

[Martin Grigorov]

On Wed, Dec 6, 2023 at 7:45 PM Emond Papegaaij 
wrote:

> Op wo 6 dec 2023 18:22 schreef Richard Eckart de Castilho  >:
>
> > > We can switch from LastModifiedResourceVersion to something else in our
> > > applications to work around this issue, but maybe we should consider
> > > tracking down this issue and release a 9.16.1. I'd expect we are not
> the
> > > only ones using LastModifiedResourceVersion.
> >
> > I wonder how this is supposed to work at all...
> >
> > AFAIK git does not track the last modification date - so I guess that
> date
> > would reflect whatever the modification date is on the machine of the
> > developer that does the release...?
> >
>
> I'm not sure either, but using the last modification date of a local
>

https://github.com/apache/wicket/blob/a68536eb095bb5cf59e4063b6af9436523ddc623/wicket-core/src/main/java/org/apache/wicket/settings/ResourceSettings.java#L650-L664
LastModifiedResourceVersion is used in DEV mode by default.
MessageDigestResourceVersion is for PROD.



> checkout would be better than using no timestamp at all. For this part of
> the code, it's not a big problem if the modification date is set to a later
> date than what it actually is. It might cause some cached files to be sent
> anyway when in fact the file did not change. The current situation causes
> files to not be sent when they really should be. Actually it would be fine
> if the modification date was set to the current timestamp during the
> release.
>
> Best regards,
> Emond
>
> >
>

Re: Wicket 10(-M?) checkpoint

[Martin Grigorov]

On Wed, Dec 6, 2023 at 2:08 PM Martin Grigorov  wrote:

>
>
> On Wed, Dec 6, 2023 at 12:40 PM Vit Rozkovec  wrote:
>
>> Hi,
>> in parent pom.xml you are referencing
>> 6.0.0
>>
>> but here you state that Servlet 5+ is required:
>>
>> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0#MigrationtoWicket10.0-Wicket10requiresServlet5+
>>
>> I've been bitten by this today when users couldn't sign in the app as
>> CookieUtils.initializeCookie uses 6.0.0 api, start of the stacktrace:
>>
>> java.lang.NoSuchMethodError: 'void
>> jakarta.servlet.http.Cookie.setAttribute(java.lang.String,
>> java.lang.String)'
>>  at
>>
>> org.apache.wicket.util.cookies.CookieUtils.initializeCookie(CookieUtils.java:341)
>>  at
>> org.apache.wicket.util.cookies.CookieUtils.save(CookieUtils.java:294)
>>  at
>> org.apache.wicket.util.cookies.CookieUtils.save(CookieUtils.java:168)
>>  at
>>
>> org.apache.wicket.authentication.strategy.DefaultAuthenticationStrategy.save(DefaultAuthenticationStrategy.java:148)
>>
>> Cookie.setAttribute is not present in 5.0.0 jservlet-api.
>>
>
> The reason is SameSite support -
> https://github.com/apache/wicket/commit/f0b4b1b3b63f33e12c8b2b04e22fcf73b773ec34
> It is easy for us to fix the version in the wiki!
> How easy is it for you to use a container that supports Servlet API 6 ?
>

https://issues.apache.org/jira/browse/WICKET-7089
https://github.com/apache/wicket/commit/a68536eb095bb5cf59e4063b6af9436523ddc623



>
>
>
>>
>> Vit
>>
>>
>>
>> On 28. 11. 23 17:05, Martin Grigorov wrote:
>> > Hi,
>> >
>> > On Tue, 28 Nov 2023 at 16:55, Andrea Del Bene 
>> wrote:
>> >
>> >> Just a brief mail to summarize the job status for Wicket 10. AFAIK
>> there
>> >> are some few minor activity that should be done before releasing the
>> new
>> >> main release, for example reworking the ApacheLicenseHeaderTest to
>> make it
>> >> work with JPMS.
>> >
>> > There is no such issue. The test works fine today!
>> > Some people suggested to replace it with maven-rat-plugin but this is
>> just
>> > an idea to replace one solution with another.
>> >
>> >
>> >> However I think we might start to contact press team to start working
>> on
>> >> the official release statement which (by experience) is a non trivial
>> task
>> >> that might take some time before coming to final draft.
>> >> Do you think the time is right to plan this activity or do you prefer
>> to
>> >> wait until the open activities are completed? Do you thing an M3
>> version is
>> >> needed?
>> >
>> > I’ll let others share their experiences with M2.
>> > I’d just ask for reviews of the currently open PRs.
>> >
>> >
>> >> --
>> >> Andrea Del Bene.
>> >> Apache Wicket committer.
>> >>
>>
>>

Re: Wicket 10(-M?) checkpoint

[Martin Grigorov]

On Wed, Dec 6, 2023 at 12:40 PM Vit Rozkovec  wrote:

> Hi,
> in parent pom.xml you are referencing
> 6.0.0
>
> but here you state that Servlet 5+ is required:
>
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0#MigrationtoWicket10.0-Wicket10requiresServlet5+
>
> I've been bitten by this today when users couldn't sign in the app as
> CookieUtils.initializeCookie uses 6.0.0 api, start of the stacktrace:
>
> java.lang.NoSuchMethodError: 'void
> jakarta.servlet.http.Cookie.setAttribute(java.lang.String,
> java.lang.String)'
>  at
>
> org.apache.wicket.util.cookies.CookieUtils.initializeCookie(CookieUtils.java:341)
>  at
> org.apache.wicket.util.cookies.CookieUtils.save(CookieUtils.java:294)
>  at
> org.apache.wicket.util.cookies.CookieUtils.save(CookieUtils.java:168)
>  at
>
> org.apache.wicket.authentication.strategy.DefaultAuthenticationStrategy.save(DefaultAuthenticationStrategy.java:148)
>
> Cookie.setAttribute is not present in 5.0.0 jservlet-api.
>

The reason is SameSite support -
https://github.com/apache/wicket/commit/f0b4b1b3b63f33e12c8b2b04e22fcf73b773ec34
It is easy for us to fix the version in the wiki!
How easy is it for you to use a container that supports Servlet API 6 ?



>
> Vit
>
>
>
> On 28. 11. 23 17:05, Martin Grigorov wrote:
> > Hi,
> >
> > On Tue, 28 Nov 2023 at 16:55, Andrea Del Bene 
> wrote:
> >
> >> Just a brief mail to summarize the job status for Wicket 10. AFAIK there
> >> are some few minor activity that should be done before releasing the new
> >> main release, for example reworking the ApacheLicenseHeaderTest to make
> it
> >> work with JPMS.
> >
> > There is no such issue. The test works fine today!
> > Some people suggested to replace it with maven-rat-plugin but this is
> just
> > an idea to replace one solution with another.
> >
> >
> >> However I think we might start to contact press team to start working on
> >> the official release statement which (by experience) is a non trivial
> task
> >> that might take some time before coming to final draft.
> >> Do you think the time is right to plan this activity or do you prefer to
> >> wait until the open activities are completed? Do you thing an M3
> version is
> >> needed?
> >
> > I’ll let others share their experiences with M2.
> > I’d just ask for reviews of the currently open PRs.
> >
> >
> >> --
> >> Andrea Del Bene.
> >> Apache Wicket committer.
> >>
>
>

Re: Wicket 10(-M?) checkpoint

[Martin Grigorov]

Hi,

On Tue, 28 Nov 2023 at 16:55, Andrea Del Bene  wrote:

> Just a brief mail to summarize the job status for Wicket 10. AFAIK there
> are some few minor activity that should be done before releasing the new
> main release, for example reworking the ApacheLicenseHeaderTest to make it
> work with JPMS.


There is no such issue. The test works fine today!
Some people suggested to replace it with maven-rat-plugin but this is just
an idea to replace one solution with another.


> However I think we might start to contact press team to start working on
> the official release statement which (by experience) is a non trivial task
> that might take some time before coming to final draft.
> Do you think the time is right to plan this activity or do you prefer to
> wait until the open activities are completed? Do you thing an M3 version is
> needed?


I’ll let others share their experiences with M2.
I’d just ask for reviews of the currently open PRs.


>
> --
> Andrea Del Bene.
> Apache Wicket committer.
>

Re: is 9.x branch build broken?

[Martin Grigorov]

https://github.com/apache/wicket/blob/wicket-9.x/wicket-core/src/test/java/org/apache/wicket/model/IModelTest.java#L240

LGTM

On Wed, Nov 1, 2023 at 7:52 PM Ernesto Reinaldo Barreiro 
wrote:

> sealed interface TextMatchingStatus
> {
> record NotSubmitted() implements TextMatchingStatus {}
> record Queued() implements TextMatchingStatus {}
> record Analysed(int matchingInPercent) implements TextMatchingStatus {}
> record Error(int errorCode, String humanReadableMessage) implements
> TextMatchingStatus
> {}
> }
>
> ?
> --
> Regards - Ernesto Reinaldo Barreiro
>

Re: [VOTE] Release Apache Wicket 10.0.0-M2 - take 2

[Martin Grigorov]

+1 to release

On Fri, Oct 13, 2023 at 1:37 AM Andrea Del Bene 
wrote:

> This is a vote to release Apache Wicket 10.0.0-M2
>
> Please download the source distributions found in our staging area
> linked below.
>
> I have included the signatures for both the source archives. This vote
> lasts for 72 hours minimum.
>
> [ ] Yes, release Apache Wicket 10.0.0-M2
> [ ] No, don't release Apache Wicket 10.0.0-M2, because ...
>
> Distributions, changelog, keys and signatures can be found at:
>
> https://repository.apache.org/content/repositories/orgapachewicket-1193/
>
> Staging repository:
>
>  https://repository.apache.org/content/repositories//
>
> The binaries are available in the above link, as are a staging
> repository for Maven. Typically the vote is on the source, but should
> you find a problem with one of the binaries, please let me know, I can
> re-roll them some way or the other.
>
> Staging git repository data:
>
>  Repository:  g...@github.com:bitstorm/wicket.git
>  Branch:  build/wicket-10.0.0-M2
>  Release tag: rel/wicket-10.0.0-M2
>
>
> 
>
>  CHANGELOG for 10.0.0-M2:
>
>
> ** Bug
>
>  * [WICKET-7056] - HttpSessionStore#getAttribute called on
> invalidated session
>  * [WICKET-7061] - When I move from 9.13.0->9.14.0, my importmaps
> fail to parse correctly due to presence of the CDATA wrapping.
>  * [WICKET-7065] - TextFilteredPropertyColumn violates CSP
>  * [WICKET-7067] - DefaultExceptionMapper should not set
> disableCaching for  WebSocketResponse
>  * [WICKET-7070] - Quick start generated app has multiple errors
>  * [WICKET-7071] - Problems when calling request.getInputStream()
> before executing WicketFilter
>  * [WICKET-7072] - JUnit code in /src/main/java breaks JPMS support
> in Eclipse IDE
>  * [WICKET-7074] - [AJAX] malformed XML is produced if an error is
> produced during AJAX rendering and a redirect is issued
>  * [WICKET-7076] - JavaScriptReferenceType newly created is not
> serializable
>  * [WICKET-7077] - 2 spring web application contexts are created
>
> ** Improvement
>
>  * [WICKET-7039] - Improve Accessibility of wicket-autocomplete.js
>  * [WICKET-7060] - Minor improvements to wicket-examples
>  * [WICKET-7063] - Convert all Application_*.properties to
> Application_*.utf8.properties
>  * [WICKET-7066] - Add possibility to define type-Attribute of
> JavascriptHeaderItem as "module"
>  * [WICKET-7068] - Current tree themes are not RTL friendly
>  * [WICKET-7078] - CSP: inline JS in Choices and Selection of Palette
>
> ** Task
>
>  * [WICKET-7064] - commons-fileupload2 dependency should be added back
>  * [WICKET-7069] - assertTrue(equals()) in tests should be replaced
> with assertEquals
>  * [WICKET-7073] - Update JQuery to 3.7.1
>
>

Re: DOAP on projects.a.o points to svn instead of our website

[Martin Grigorov]

On Wed, Sep 6, 2023 at 9:37 AM Martin Grigorov  wrote:

>
>
> On Wed, Sep 6, 2023 at 9:17 AM Martin Grigorov 
> wrote:
>
>> I made a small fix in the doap file -
>> https://github.com/apache/wicket-site/pull/15
>>
>
>> Does the file have to start with YAML -
>> https://github.com/apache/wicket-site/blob/eb26085e15759da6b9510c56942b8b232a7a4e11/doap.rdf#L1-L3
>> ?
>> The content is a XML but the YAML header bothers me ...
>>
>
> All is good!
> https://github.com/apache/wicket-site/blob/asf-site/*content*/doap.rdf
> looks OK and https://www.w3.org/RDF/Validator/ confirms it!
>
>
>> On Tue, Sep 5, 2023 at 6:08 PM Martijn Dashorst <
>> martijn.dasho...@gmail.com> wrote:
>>
>>> There was some rumblings that a lot of projects don't have a DOAP file
>>> (which is processed by https://projects.apache.org) and when I looked at
>>> our description on projects.a.o it noted:
>>>
>>> 6.19.0 (2015-02-02): Latest Stable Release
>>>
>>> Which is AFAIK incorrect :-D
>>>
>>> It appears that the DOAP registration points to the SVN repository of our
>>> site publishing thing, which hasn't been in use since at last 2 February
>>> 2015, 8 years ago.
>>>
>>> This should be fixed in the projects.a.o administration to point to our
>>> DOAP file that's published on the website (
>>> https://wicket.apache.org/doap.rdf), and I think the SCM location should
>>> also be changed from subversion to something git like.
>>>
>>
>> Do you know where this change has to be done ?
>>
>
> To answer myself:
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml
>

SVN revision: 1912119



>
>
>>
>>
>>>
>>> The projects.a.o site: https://projects.apache.org/project.html?wicket
>>>
>>> Any takers?
>>>
>>> Martijn
>>>
>>

Re: DOAP on projects.a.o points to svn instead of our website

[Martin Grigorov]

On Wed, Sep 6, 2023 at 9:17 AM Martin Grigorov  wrote:

> I made a small fix in the doap file -
> https://github.com/apache/wicket-site/pull/15
>
> Does the file have to start with YAML -
> https://github.com/apache/wicket-site/blob/eb26085e15759da6b9510c56942b8b232a7a4e11/doap.rdf#L1-L3
> ?
> The content is a XML but the YAML header bothers me ...
>

All is good!
https://github.com/apache/wicket-site/blob/asf-site/*content*/doap.rdf
looks OK and https://www.w3.org/RDF/Validator/ confirms it!


> On Tue, Sep 5, 2023 at 6:08 PM Martijn Dashorst <
> martijn.dasho...@gmail.com> wrote:
>
>> There was some rumblings that a lot of projects don't have a DOAP file
>> (which is processed by https://projects.apache.org) and when I looked at
>> our description on projects.a.o it noted:
>>
>> 6.19.0 (2015-02-02): Latest Stable Release
>>
>> Which is AFAIK incorrect :-D
>>
>> It appears that the DOAP registration points to the SVN repository of our
>> site publishing thing, which hasn't been in use since at last 2 February
>> 2015, 8 years ago.
>>
>> This should be fixed in the projects.a.o administration to point to our
>> DOAP file that's published on the website (
>> https://wicket.apache.org/doap.rdf), and I think the SCM location should
>> also be changed from subversion to something git like.
>>
>
> Do you know where this change has to be done ?
>

To answer myself:
https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml


>
>
>>
>> The projects.a.o site: https://projects.apache.org/project.html?wicket
>>
>> Any takers?
>>
>> Martijn
>>
>

Re: DOAP on projects.a.o points to svn instead of our website

[Martin Grigorov]

I made a small fix in the doap file -
https://github.com/apache/wicket-site/pull/15

Does the file have to start with YAML -
https://github.com/apache/wicket-site/blob/eb26085e15759da6b9510c56942b8b232a7a4e11/doap.rdf#L1-L3
?
The content is a XML but the YAML header bothers me ...

On Tue, Sep 5, 2023 at 6:08 PM Martijn Dashorst 
wrote:

> There was some rumblings that a lot of projects don't have a DOAP file
> (which is processed by https://projects.apache.org) and when I looked at
> our description on projects.a.o it noted:
>
> 6.19.0 (2015-02-02): Latest Stable Release
>
> Which is AFAIK incorrect :-D
>
> It appears that the DOAP registration points to the SVN repository of our
> site publishing thing, which hasn't been in use since at last 2 February
> 2015, 8 years ago.
>
> This should be fixed in the projects.a.o administration to point to our
> DOAP file that's published on the website (
> https://wicket.apache.org/doap.rdf), and I think the SCM location should
> also be changed from subversion to something git like.
>

Do you know where this change has to be done ?


>
> The projects.a.o site: https://projects.apache.org/project.html?wicket
>
> Any takers?
>
> Martijn
>

Re: TinyMce 6 and possible alternatives

[Martin Grigorov]

Hi Johannes,



On Thu, Jul 13, 2023 at 3:23 PM Johannes Renoth  wrote:

> Hi all,
>
> First of all: Thanks for providing continued support and even further
> development for Wicket.
>
> Now to my questions:
>
> Since Wicketstuff only has TinyMCE until version 4 but this version has
> some serious vulnerabilites https://security.snyk.io/package/npm/tinymce
> and the version used in wicketstuff is really old (4.3.4) i have begun
> to implement a Wicket-Integration of trumbowyg
> https://alex-d.github.io/Trumbowyg/ and
> https://github.com/renoth/wicket-trumbowyg
>
> I already have a maven nexus account to release artifacts on maven
> central, but before i do this i have some questions
>
> Do you plan to update Tinymce to latest version?
>

WicketStuff hosts libraries maintained by the community.
That is, someone like you needed a WYSIWYG Wicket component and used
TinyMCE. Coded it, polished it and contributed it to WicketStuff so other
user could use and improve it.
If you think TinyMCE 6.x is a nice widget (better than Trumbowyg ?!) then
you can update the WicketStuff component from 4.x to 6.x and send a PR!


>
> Is there an alternative already implemented?
>

There are!
E.g.
https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/wicket-9.x/bootstrap-extensions/src/main/java/de/agilecoders/wicket/extensions/markup/html/bootstrap/editor
provides such integration with https://summernote.org/


> Would you be interested in integrating the code into wicketstuff? If
> yes, would you do a code review?
>

We could add you as a contributor to WicketStuff to make it easier for you
to maintain it. But using Pull Request with reviews is usually recommended
for better qualitiy!


>
> The plugin structure of trumbowyg is somewhat finegrained and there is
> some serious loading of lots of js and css files necessary at the moment
> see
>
> https://github.com/renoth/wicket-trumbowyg/blob/master/src/main/java/dev/renoth/trumbowyg/TrumboWygBehavior.java#L70-L107,
>
> maybe someone has an idea how to improve it to only need one request per
> JS and CSS in total
>
> Other than that i works great with a quickstart.
>
> Thank you for your time,
>
> Johannes Renoth
>
>
>
>

Re: wicket and commons-fileupload 2.0.0-M1

[Martin Grigorov]

On Wed, Jul 12, 2023 at 2:51 PM Maxim Solodovnik 
wrote:

> On Wed, 12 Jul 2023 at 18:34, Martin Grigorov 
> wrote:
> >
> > On Wed, Jul 12, 2023 at 8:03 AM Maxim Solodovnik 
> > wrote:
> >
> > > BTW here is the discussion regarding future of commons-fileupload:
> > > https://lists.apache.org/thread/koclgykqx0sfkrz8tf1w37n15zyql822
> > > please join :)
> > >
> >
> > Regarding commons-fileupload vs. Servlet API: I've mentioned the reason
> why
> > Wicket does not use Servlet file upload APIs :
> > - https://issues.apache.org/jira/browse/WICKET-5192
> > - https://issues.apache.org/jira/browse/WICKET-5924 (also shows some
> > limitations)
> >
> > Regarding the release of commons-fileupload:
> > I understand it is volunteer work but the Commons people talk about
> making
> > a release for 3 years now...
> > OK, let's assume they release -M1 next weekend. How much more would it
> take
> > for a final release ?!
> > The funny part is that commons-fileupload classes were part of
> wicket-util
> > back in the days but I replaced them with a proper dependency with
> > https://issues.apache.org/jira/browse/WICKET-5503 :-)
> >
>
> I believe the whole above comment should go to mail thread in commons ;)
>

I think only the first part is relevant to them and I posted it before my
answer here (
https://lists.apache.org/thread/brrpsx977jqbwsohjdohnq2515dxk1zs)
The second part is "part of the volunteer work", so we cannot demand/expect
anything from anyone.



>
> >
> >
> > >
> > > On Fri, 16 Jun 2023 at 21:35, Ernesto Reinaldo Barreiro
> > >  wrote:
> > > >
> > > > Hi,
> > > >
> > > > Yes but then we, wicket developers, will be responsible for tracking
> file
> > > > upload related issues and port to wicket fixes done in the original
> > > project
> > > > (and vice versa, e.g. I already fixed one thing in wicket copy and
> had to
> > > > submit a PR to the original project).
> > > >
> > > > On Fri, Jun 16, 2023 at 5:23 PM Matt Pavlovich 
> > > wrote:
> > > >
> > > > > Hi Maxim-
> > > > >
> > > > > I understand that preference— this is a build-vs-buy decision. My
> > > point is
> > > > > that a file upload handler makes sense for Wicket to host itself,
> > > > > considering it is a small set of functions and relates to storage
> > > > > management needed by Wicket apps. Also, Wicket is more active in
> > > > > development and adopting JDK and Jakarta EE than the commons-file
> > > upload
> > > > > project. I suspect we’ll be right back here as the Servlet spec is
> > > evolving
> > > > > in Jakarta EE.
> > > > >
> > > > > -Matt
> > > > >
> > > > > > On Jun 16, 2023, at 2:32 AM, Maxim Solodovnik <
> solomax...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > On Thu, 15 Jun 2023 at 00:40, Matt Pavlovich  >
> > > wrote:
> > > > > >>
> > > > > >> Why add it back? The feature is just a couple of classes.
> > > > > commons-fileupload2 can continue to serve as a reference
> > > implementation to
> > > > > draw from.
> > > > > >>
> > > > > >> These backside dependencies create headaches when building web
> > > > > applications with Wicket that are platforms that allow end-users to
> > > provide
> > > > > their own plugins or extensions that may use the same or similarly
> > > > > versioned dependencies.
> > > > > >
> > > > > > IMO it's bad practice to copy/paste other libraries,
> > > > > > having fileupload2 as dependency we have all fixes and additional
> > > > > testing :)
> > > > > >
> > > > > > BTW the build of my branch seems to be green, only minor issues
> with
> > > > > > Automatic-Module-Name remain unresolved :)
> > > > > >
> > > > > >>
> > > > > >> Thanks,
> > > > > >> Matt
> > > > > >>
> > > > > >>> On Jun 14, 2023, at 11:48 AM, Maxim Solodovnik <
> > > solomax...@gmail.com>
> > > > > wrote:
> > > > > >>>
> > > > > >>> Hello

Re: wicket and commons-fileupload 2.0.0-M1

[Martin Grigorov]

On Wed, Jul 12, 2023 at 8:03 AM Maxim Solodovnik 
wrote:

> BTW here is the discussion regarding future of commons-fileupload:
> https://lists.apache.org/thread/koclgykqx0sfkrz8tf1w37n15zyql822
> please join :)
>

Regarding commons-fileupload vs. Servlet API: I've mentioned the reason why
Wicket does not use Servlet file upload APIs :
- https://issues.apache.org/jira/browse/WICKET-5192
- https://issues.apache.org/jira/browse/WICKET-5924 (also shows some
limitations)

Regarding the release of commons-fileupload:
I understand it is volunteer work but the Commons people talk about making
a release for 3 years now...
OK, let's assume they release -M1 next weekend. How much more would it take
for a final release ?!
The funny part is that commons-fileupload classes were part of wicket-util
back in the days but I replaced them with a proper dependency with
https://issues.apache.org/jira/browse/WICKET-5503 :-)



>
> On Fri, 16 Jun 2023 at 21:35, Ernesto Reinaldo Barreiro
>  wrote:
> >
> > Hi,
> >
> > Yes but then we, wicket developers, will be responsible for tracking file
> > upload related issues and port to wicket fixes done in the original
> project
> > (and vice versa, e.g. I already fixed one thing in wicket copy and had to
> > submit a PR to the original project).
> >
> > On Fri, Jun 16, 2023 at 5:23 PM Matt Pavlovich 
> wrote:
> >
> > > Hi Maxim-
> > >
> > > I understand that preference— this is a build-vs-buy decision. My
> point is
> > > that a file upload handler makes sense for Wicket to host itself,
> > > considering it is a small set of functions and relates to storage
> > > management needed by Wicket apps. Also, Wicket is more active in
> > > development and adopting JDK and Jakarta EE than the commons-file
> upload
> > > project. I suspect we’ll be right back here as the Servlet spec is
> evolving
> > > in Jakarta EE.
> > >
> > > -Matt
> > >
> > > > On Jun 16, 2023, at 2:32 AM, Maxim Solodovnik 
> > > wrote:
> > > >
> > > > On Thu, 15 Jun 2023 at 00:40, Matt Pavlovich 
> wrote:
> > > >>
> > > >> Why add it back? The feature is just a couple of classes.
> > > commons-fileupload2 can continue to serve as a reference
> implementation to
> > > draw from.
> > > >>
> > > >> These backside dependencies create headaches when building web
> > > applications with Wicket that are platforms that allow end-users to
> provide
> > > their own plugins or extensions that may use the same or similarly
> > > versioned dependencies.
> > > >
> > > > IMO it's bad practice to copy/paste other libraries,
> > > > having fileupload2 as dependency we have all fixes and additional
> > > testing :)
> > > >
> > > > BTW the build of my branch seems to be green, only minor issues with
> > > > Automatic-Module-Name remain unresolved :)
> > > >
> > > >>
> > > >> Thanks,
> > > >> Matt
> > > >>
> > > >>> On Jun 14, 2023, at 11:48 AM, Maxim Solodovnik <
> solomax...@gmail.com>
> > > wrote:
> > > >>>
> > > >>> Hello All,
> > > >>>
> > > >>> I've start working on migration back to commons-fileupload 2.0.0-M1
> > > >>> (the branch is here: [1] :)))
> > > >>>
> > > >>> Latest version of commons-fileupload2 has couple of issues
> > > >>> 1) missing `Automatic-Module-Name`
> > > >>> 2) FileItemHeadersImpl is not public anymore
> > > >>> (discussion is here: [2])
> > > >>>
> > > >>> I'm going to have vacation in a couple of days (will be offline
> almost
> > > >>> all the time :)
> > > >>>
> > > >>> Can someone take a look at [2] ?
> > > >>> So we have all required features at 2.0.0-M1 release?
> > > >>>
> > > >>> Thanks in advance :)
> > > >>>
> > > >>> [1] https://github.com/apache/wicket/blob/commons-fileupload2-back
> > > >>> [2]
> https://lists.apache.org/thread/gjglf0c1xzdrhm143swfcq0xpg5ofrqk
> > > >>>
> > > >>> --
> > > >>> Best regards,
> > > >>> Maxim
> > > >>
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Maxim
> > >
> > >
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
>
>
>
> --
> Best regards,
> Maxim
>

Re: [VOTE] Release Apache Wicket 10.0.0-M1

[Martin Grigorov]

+1 to release

Checked:
- build from source
- tested various examples on Tomcat 11 alpha with JDK 22 EA b1

On Mon, Jun 12, 2023 at 3:35 PM Andrea Del Bene 
wrote:

> This is a vote to release Apache Wicket 10.0.0-M1
>
> Please download the source distributions found in our staging area
> linked below.
>
> I have included the signatures for both the source archives. This vote
> lasts for 72 hours minimum.
>
> [ ] Yes, release Apache Wicket 10.0.0-M1
> [ ] No, don't release Apache Wicket 10.0.0-M1, because ...
>
> Distributions, changelog, keys and signatures can be found at:
>
>  https://dist.apache.org/repos/dist/dev/wicket/10.0.0-M1
>
> Staging repository:
>
> https://repository.apache.org/content/repositories/orgapachewicket-1187
>
> The binaries are available in the above link, as are a staging
> repository for Maven. Typically the vote is on the source, but should
> you find a problem with one of the binaries, please let me know, I can
> re-roll them some way or the other.
>
> Staging git repository data:
>
>  Repository:  g...@github.com:bitstorm/wicket.git
>  Branch:  build/wicket-10.0.0-M1
>  Release tag: rel/wicket-10.0.0-M1
>
>
> 
>
>  CHANGELOG for 10.0.0-M1:
>
>
> ** Bug
>
>  * [WICKET-6895] - Links to examples in documentation points to old
> version of 8x
>  * [WICKET-6896] - AutoCompleteTextField re-opens dropdown item list
> after item has been selected
>  * [WICKET-6897] - Javadoc build fails on fresh checkout of master
> or rel/wicket-9.3.0
>  * [WICKET-6902] - Change of PartialPageUpdate order of
> onAfterResponse and writePriorityEvaluations makes
> IListener.onAfterResponde ignore prepended javascripts
>  * [WICKET-6908] - Possible bug / edge case where page is not detached
>  * [WICKET-6913] - Java 17 compatibility with cglib
>  * [WICKET-6914] - Visibility change of "File Upload" via ajax
> causes "missing" form-data
>  * [WICKET-6921] - MultipartFormComponentListener breaks on hidden
> components
>  * [WICKET-6936] - FilePageStore fails on windows
>  * [WICKET-6944] - Memory leak in WicketEndpoint
>  * [WICKET-6945] - MultipartFormComponentListener modifies enctype
> on invisible forms, leading to javascript errors
>  * [WICKET-6947] - IndicatingAjaxButton does not work with Bootstrap 4
>  * [WICKET-6953] - JavaScriptDeferHeaderResponse not working
> correctly for AJAX requests
>  * [WICKET-6955] - Wicket uses unstable slf4j version
>  * [WICKET-6965] - Memory leak in WicketEndpoint
>  * [WICKET-6966] - IndexOutOfBounds in InSessionPageStore
>  * [WICKET-6970] - Unnecessary string building in
> AssociatedMarkupSourcingStrategy
>  * [WICKET-6971] - NullPointerException in ModificationWatcher
>  * [WICKET-6974] - JavaxUpgradeHttpRequest returns an empty contextPath
>  * [WICKET-6975] - Behavior.renderHead may be called multiple times
>  * [WICKET-6981] - InSessionPageStore does not trigger flushSession
>  * [WICKET-6988] - String.format used in JS generation leads to errors
>  * [WICKET-6990] - DiskPageStore loses pages when container re-binds
> attributes
>  * [WICKET-6996] - NotSerializableException near
> KeyInSessionSunJceCryptFactory
>  * [WICKET-6999] - Missing Export-Package of packages with
> "internal" in name
>  * [WICKET-7005] - ByteBuddy IllegalStateException: Cannot inject
> already loaded type
>  * [WICKET-7007] - Code snippets for CSRF documentation fixing
>  * [WICKET-7013] - IndexOutOfBoundsException in InSessionPageStore
>  * [WICKET-7022] - JavaScriptStripper fails to detect regular
> expression correctly
>  * [WICKET-7028] - CSP header not rendered when using
> RedirectPolicy.NEVER_REDIRECT
>  * [WICKET-7034] - WebSocket.Closed event not fired when error occurred
>  * [WICKET-7037] - [Ajax Download] cookie used to track download
> complete misses the SameSite attribute
>  * [WICKET-7040] - find a different way to add CSP headers
>  * [WICKET-7044] - Images in the Wicket 9.x reference guide are not
> displayed.
>  * [WICKET-7052] - Interrupting a task should not be logged as an error
>  * [WICKET-7054] - Tag 

Re: Plans for Wicket 10 Release

[Martin Grigorov]

On Sat, Jun 10, 2023 at 4:49 PM Andrea Del Bene 
wrote:

> Hi,
>
> I'm having some module related problems building Wicket 10.0.0-M1. On my
> first attempt build failed with message
>
> "Error: log4j-api-2.9.0.jar is a multi-release jar file but
> --multi-release option is not set"
>

How to reproduce the failure ?
"mvn clean install" works fine here.



>
> So I decided to use Apache Maven JDeps Plugin as suggested here :
>
> https://stackoverflow.com/questions/46662286/error-log4j-api-2-9-0-jar-is-a-multi-release-jar-file-but-multi-release-optio
>
> But know I receive this complain about modules and
> wicket-commons-fileupload:
>
> INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jdeps-plugin:3.1.1:jdkinternals (default)
> on project wicket-commons-fileupload:
> [INFO] [ERROR] Exit code: 1 - Exception in thread "main"
> java.lang.module.FindException: Module org.apache.commons.io not found,
> required by org.apache.wicket.commons.fileupload
> [INFO] [ERROR] at
> java.base/java.lang.module.Resolver.findFail(Resolver.java:893)
> [INFO] [ERROR] at
> java.base/java.lang.module.Resolver.resolve(Resolver.java:192)
> [INFO] [ERROR] at
> java.base/java.lang.module.Resolver.resolve(Resolver.java:141)
> [INFO] [ERROR] at
> java.base/java.lang.module.Configuration.resolve(Configuration.java:421)
> [INFO] [ERROR] at
> java.base/java.lang.module.Configuration.resolve(Configuration.java:255)
> [INFO] [ERROR] at
>
> jdk.jdeps/com.sun.tools.jdeps.JdepsConfiguration$Builder.build(JdepsConfiguration.java:564)
> [INFO] [ERROR] at
> jdk.jdeps/com.sun.tools.jdeps.JdepsTask.buildConfig(JdepsTask.java:603)
> [INFO] [ERROR] at
> jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:557)
> [INFO] [ERROR] at
> jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:533)
> [INFO] [ERROR] at jdk.jdeps/com.sun.tools.jdeps.Main.main(Main.java:49)
> [INFO] [ERROR]
> [INFO] [ERROR] Command line was: /bin/sh -c
> '/usr/lib/jvm/temurin-17-jdk-amd64/bin/jdeps' '-cp'
> '/home/andrea/.m2/repository/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar:/home/andrea/.m2/repository/jakarta/servlet/jakarta.servlet-api/6.0.0/jakarta.servlet-api-6.0.0.jar:/home/andrea/.m2/repository/org/slf4j/slf4j-api/2.0.6/slf4j-api-2.0.6.jar'
>
> '--multi-release' '17'
>
> '/home/andrea/WicketBuild/wicket/target/checkout/wicket-commons-fileupload/target/classes'
>
> Do you have any suggestion about this?
>
> Thank you.
>
>
> On 08/06/23 16:28, Martin Grigorov wrote:
> > I don’t have any tasks for 10 at the moment
> >
> > On Thu, 8 Jun 2023 at 16:17, Andrea Del Bene 
> wrote:
> >
> >> Ready when you are :-)...if everything is in place I can start working
> on
> >> RC1 release on this weekend
> >>
> >> On Wed, Jun 7, 2023 at 4:06 PM Martin Grigorov 
> >> wrote:
> >>
> >>> The PR has been merged!
> >>>
> >>> On Wed, Jun 7, 2023 at 3:32 PM Greb Lindqvist <
> greb.lindqv...@gmail.com>
> >>> wrote:
> >>>
> >>>> I am looking forward to testing RC1 in several projects.
> >>>>
> >>>> Thank you for moving this forward!
> >>>>
> >>>> On Wed, Jun 7, 2023 at 6:00 AM Martin Grigorov 
> >>>> wrote:
> >>>>
> >>>>> On Wed, May 31, 2023 at 7:37 AM Maxim Solodovnik <
> >> solomax...@gmail.com
> >>>>> wrote:
> >>>>>
> >>>>>> Should be fixed with this:
> >> https://github.com/apache/wicket/pull/591
> >>>> :)
> >>>>> If no one has a better solution than I suggest to merge this PR and
> >>>> release
> >>>>> Wicket 10 RC1
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Tue, 30 May 2023 at 22:16, Maxim Solodovnik <
> >> solomax...@gmail.com
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> from mobile (sorry for typos ;)
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, May 30, 2023, 20:05 Jeroen Steenbeeke <
> >>>>> j.steenbeeke...@gmail.com>
> >>>>>> wrote:
> >>>>>>>> The current wicket-commons-fileupload 10.0.0-M1-SNAPSHOT jar in
> >>> the
> >>>>>> Apache
> >>>>>>>> snapshots repo du

Re: Plans for Wicket 10 Release

[Martin Grigorov]

I don’t have any tasks for 10 at the moment

On Thu, 8 Jun 2023 at 16:17, Andrea Del Bene  wrote:

> Ready when you are :-)...if everything is in place I can start working on
> RC1 release on this weekend
>
> On Wed, Jun 7, 2023 at 4:06 PM Martin Grigorov 
> wrote:
>
> > The PR has been merged!
> >
> > On Wed, Jun 7, 2023 at 3:32 PM Greb Lindqvist 
> > wrote:
> >
> > > I am looking forward to testing RC1 in several projects.
> > >
> > > Thank you for moving this forward!
> > >
> > > On Wed, Jun 7, 2023 at 6:00 AM Martin Grigorov 
> > > wrote:
> > >
> > > > On Wed, May 31, 2023 at 7:37 AM Maxim Solodovnik <
> solomax...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Should be fixed with this:
> https://github.com/apache/wicket/pull/591
> > > :)
> > > > >
> > > >
> > > > If no one has a better solution than I suggest to merge this PR and
> > > release
> > > > Wicket 10 RC1
> > > >
> > > >
> > > >
> > > > >
> > > > > On Tue, 30 May 2023 at 22:16, Maxim Solodovnik <
> solomax...@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > from mobile (sorry for typos ;)
> > > > > >
> > > > > >
> > > > > > On Tue, May 30, 2023, 20:05 Jeroen Steenbeeke <
> > > > j.steenbeeke...@gmail.com>
> > > > > wrote:
> > > > > >>
> > > > > >> The current wicket-commons-fileupload 10.0.0-M1-SNAPSHOT jar in
> > the
> > > > > Apache
> > > > > >> snapshots repo duplicates classes from commons-io, Jakarta
> Servlet
> > > and
> > > > > >> SLF4J and is triggering my Maven Enforcer's BanDuplicateClasses
> > > rule.
> > > > > >
> > > > > >
> > > > > > Sounds interesting
> > > > > > Could you share details? :)
> > > > > >
> > > > > >>
> > > > > >> Op za 27 mei 2023 om 21:53 schreef Martin Grigorov <
> > > > > mgrigo...@apache.org>:
> > > > > >>
> > > > > >> > On Sat, May 27, 2023 at 8:18 PM smallufo 
> > > > wrote:
> > > > > >> >
> > > > > >> > > Hi
> > > > > >> > > Where can I get wicket-10 snapshot ?
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/wicket/blob/master/archetypes/quickstart/src/main/resources/archetype-resources/pom.xml#L175-L186
> > > > > >> >
> > > > > >> > I cannot find it in mvnrepository.com ...
> > > > > >> >
> > > > > >> > I've upgrade all subsystems from javax to jakarta , and
> spring 5
> > > to
> > > > > spring
> > > > > >> > 6
> > > > > >> > > But a lot of incompatibility issues are in wicket 9
> > > > > >> > > Since it has no major issues , how about releasing it ASAP ?
> > > > > >> > > Thanks.
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > János Cserép  於 2023年5月25日 週四
> 下午3:51寫道：
> > > > > >> > >
> > > > > >> > > > Just a thought...
> > > > > >> > > >
> > > > > >> > > > I've been using Wicket 10 snapshot builds in production
> for
> > > over
> > > > > a year
> > > > > >> > > now
> > > > > >> > > > with latest Spring and Jakarta libs without any major
> > issues,
> > > so
> > > > > if
> > > > > >> > that
> > > > > >> > > is
> > > > > >> > > > an option for you, go ahead. You can mitigate risks by
> > > creating
> > > > > release
> > > > > >> > > > from a known git rev yourself if your release process does
> > not
> > > > > like
> > > > > >> > > > SNAPSHOT dependencies.
> > > > > >> > > >
> > > > > >> > > > j
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > On Thu, 25 May 2023 at 09:15, Tony Tkacik <
> > > > > tony.tka...@evolveum.com
> > > > > >> > > > .invalid>
> > > > > >> > > > wrote:
> > > > > >> > > >
> > > > > >> > > > > Hi,
> > > > > >> > > > > I would like to ask about your timeline / plans
> regarding
> > > > > release of
> > > > > >> > > > > Wicket 10?
> > > > > >> > > > >
> > > > > >> > > > > We are in process of upgrading our open-source project
> > > > midPoint
> > > > > to
> > > > > >> > > latest
> > > > > >> > > > > Spring releases and that requires Wicket to be updated
> to
> > > > > version 10
> > > > > >> > > > > in order to support Spring 6.
> > > > > >> > > > >
> > > > > >> > > > > Thanks,
> > > > > >> > > > > Anton Tkacik
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Jeroen Steenbeeke
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Maxim
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > > > For additional commands, e-mail: users-h...@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Andrea Del Bene.
> Apache Wicket committer.
>

Re: Plans for Wicket 10 Release

[Martin Grigorov]

The PR has been merged!

On Wed, Jun 7, 2023 at 3:32 PM Greb Lindqvist 
wrote:

> I am looking forward to testing RC1 in several projects.
>
> Thank you for moving this forward!
>
> On Wed, Jun 7, 2023 at 6:00 AM Martin Grigorov 
> wrote:
>
> > On Wed, May 31, 2023 at 7:37 AM Maxim Solodovnik 
> > wrote:
> >
> > > Should be fixed with this: https://github.com/apache/wicket/pull/591
> :)
> > >
> >
> > If no one has a better solution than I suggest to merge this PR and
> release
> > Wicket 10 RC1
> >
> >
> >
> > >
> > > On Tue, 30 May 2023 at 22:16, Maxim Solodovnik 
> > > wrote:
> > > >
> > > >
> > > >
> > > > from mobile (sorry for typos ;)
> > > >
> > > >
> > > > On Tue, May 30, 2023, 20:05 Jeroen Steenbeeke <
> > j.steenbeeke...@gmail.com>
> > > wrote:
> > > >>
> > > >> The current wicket-commons-fileupload 10.0.0-M1-SNAPSHOT jar in the
> > > Apache
> > > >> snapshots repo duplicates classes from commons-io, Jakarta Servlet
> and
> > > >> SLF4J and is triggering my Maven Enforcer's BanDuplicateClasses
> rule.
> > > >
> > > >
> > > > Sounds interesting
> > > > Could you share details? :)
> > > >
> > > >>
> > > >> Op za 27 mei 2023 om 21:53 schreef Martin Grigorov <
> > > mgrigo...@apache.org>:
> > > >>
> > > >> > On Sat, May 27, 2023 at 8:18 PM smallufo 
> > wrote:
> > > >> >
> > > >> > > Hi
> > > >> > > Where can I get wicket-10 snapshot ?
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > >
> >
> https://github.com/apache/wicket/blob/master/archetypes/quickstart/src/main/resources/archetype-resources/pom.xml#L175-L186
> > > >> >
> > > >> > I cannot find it in mvnrepository.com ...
> > > >> >
> > > >> > I've upgrade all subsystems from javax to jakarta , and spring 5
> to
> > > spring
> > > >> > 6
> > > >> > > But a lot of incompatibility issues are in wicket 9
> > > >> > > Since it has no major issues , how about releasing it ASAP ?
> > > >> > > Thanks.
> > > >> > >
> > > >> > >
> > > >> > > János Cserép  於 2023年5月25日 週四 下午3:51寫道：
> > > >> > >
> > > >> > > > Just a thought...
> > > >> > > >
> > > >> > > > I've been using Wicket 10 snapshot builds in production for
> over
> > > a year
> > > >> > > now
> > > >> > > > with latest Spring and Jakarta libs without any major issues,
> so
> > > if
> > > >> > that
> > > >> > > is
> > > >> > > > an option for you, go ahead. You can mitigate risks by
> creating
> > > release
> > > >> > > > from a known git rev yourself if your release process does not
> > > like
> > > >> > > > SNAPSHOT dependencies.
> > > >> > > >
> > > >> > > > j
> > > >> > > >
> > > >> > > >
> > > >> > > > On Thu, 25 May 2023 at 09:15, Tony Tkacik <
> > > tony.tka...@evolveum.com
> > > >> > > > .invalid>
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > > Hi,
> > > >> > > > > I would like to ask about your timeline / plans regarding
> > > release of
> > > >> > > > > Wicket 10?
> > > >> > > > >
> > > >> > > > > We are in process of upgrading our open-source project
> > midPoint
> > > to
> > > >> > > latest
> > > >> > > > > Spring releases and that requires Wicket to be updated to
> > > version 10
> > > >> > > > > in order to support Spring 6.
> > > >> > > > >
> > > >> > > > > Thanks,
> > > >> > > > > Anton Tkacik
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >> Jeroen Steenbeeke
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Maxim
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > For additional commands, e-mail: users-h...@wicket.apache.org
> > >
> > >
> >
>

Re: Plans for Wicket 10 Release

[Martin Grigorov]

On Wed, May 31, 2023 at 7:37 AM Maxim Solodovnik 
wrote:

> Should be fixed with this: https://github.com/apache/wicket/pull/591 :)
>

If no one has a better solution than I suggest to merge this PR and release
Wicket 10 RC1



>
> On Tue, 30 May 2023 at 22:16, Maxim Solodovnik 
> wrote:
> >
> >
> >
> > from mobile (sorry for typos ;)
> >
> >
> > On Tue, May 30, 2023, 20:05 Jeroen Steenbeeke 
> wrote:
> >>
> >> The current wicket-commons-fileupload 10.0.0-M1-SNAPSHOT jar in the
> Apache
> >> snapshots repo duplicates classes from commons-io, Jakarta Servlet and
> >> SLF4J and is triggering my Maven Enforcer's BanDuplicateClasses rule.
> >
> >
> > Sounds interesting
> > Could you share details? :)
> >
> >>
> >> Op za 27 mei 2023 om 21:53 schreef Martin Grigorov <
> mgrigo...@apache.org>:
> >>
> >> > On Sat, May 27, 2023 at 8:18 PM smallufo  wrote:
> >> >
> >> > > Hi
> >> > > Where can I get wicket-10 snapshot ?
> >> > >
> >> >
> >> >
> >> >
> https://github.com/apache/wicket/blob/master/archetypes/quickstart/src/main/resources/archetype-resources/pom.xml#L175-L186
> >> >
> >> > I cannot find it in mvnrepository.com ...
> >> >
> >> > I've upgrade all subsystems from javax to jakarta , and spring 5 to
> spring
> >> > 6
> >> > > But a lot of incompatibility issues are in wicket 9
> >> > > Since it has no major issues , how about releasing it ASAP ?
> >> > > Thanks.
> >> > >
> >> > >
> >> > > János Cserép  於 2023年5月25日 週四 下午3:51寫道：
> >> > >
> >> > > > Just a thought...
> >> > > >
> >> > > > I've been using Wicket 10 snapshot builds in production for over
> a year
> >> > > now
> >> > > > with latest Spring and Jakarta libs without any major issues, so
> if
> >> > that
> >> > > is
> >> > > > an option for you, go ahead. You can mitigate risks by creating
> release
> >> > > > from a known git rev yourself if your release process does not
> like
> >> > > > SNAPSHOT dependencies.
> >> > > >
> >> > > > j
> >> > > >
> >> > > >
> >> > > > On Thu, 25 May 2023 at 09:15, Tony Tkacik <
> tony.tka...@evolveum.com
> >> > > > .invalid>
> >> > > > wrote:
> >> > > >
> >> > > > > Hi,
> >> > > > > I would like to ask about your timeline / plans regarding
> release of
> >> > > > > Wicket 10?
> >> > > > >
> >> > > > > We are in process of upgrading our open-source project midPoint
> to
> >> > > latest
> >> > > > > Spring releases and that requires Wicket to be updated to
> version 10
> >> > > > > in order to support Spring 6.
> >> > > > >
> >> > > > > Thanks,
> >> > > > > Anton Tkacik
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >>
> >> --
> >> Jeroen Steenbeeke
>
>
>
> --
> Best regards,
> Maxim
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Plans for Wicket 10 Release

[Martin Grigorov]

Since we use a local copy of commons-fileupload2 I see no stopper for a
release! A milestone one or a release candidate.

The last problem is in the CDI module - several dependencies still miss
jakarta impls (e.g. cdi-unit). I cannot say how big of an issue this is for
a Wicket itself.

On Thu, May 25, 2023 at 11:01 AM Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi,
>
> As far as I know release of wicket 10 is blocked by commons upload project.
> That project has been cloned as part of wicket 10.x branch and we have
> fixed at least one bug in it (and in parallel in the original project).
> Maybe other more experienced committers can comment?
>
> On Thu, May 25, 2023 at 10:52 AM János Cserép 
> wrote:
>
> > Just a thought...
> >
> > I've been using Wicket 10 snapshot builds in production for over a year
> now
> > with latest Spring and Jakarta libs without any major issues, so if that
> is
> > an option for you, go ahead. You can mitigate risks by creating release
> > from a known git rev yourself if your release process does not like
> > SNAPSHOT dependencies.
> >
> > j
> >
> >
> > On Thu, 25 May 2023 at 09:15, Tony Tkacik  > .invalid>
> > wrote:
> >
> > > Hi,
> > > I would like to ask about your timeline / plans regarding release of
> > > Wicket 10?
> > >
> > > We are in process of upgrading our open-source project midPoint to
> latest
> > > Spring releases and that requires Wicket to be updated to version 10
> > > in order to support Spring 6.
> > >
> > > Thanks,
> > > Anton Tkacik
> > >
> >
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>

Re: using fileupload2

[Martin Grigorov]

On Fri, Apr 21, 2023 at 7:18 AM Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi,
>
> I was looking into the Form's code for wicket 10.x and I just noticed that
> by using file fileupload2 we will lose the ability to distinguish between
> one file that is too big and the whole request is too big.
>

I guess the problem is from
https://github.com/apache/wicket/commit/8f8951b64db7006b131f7acfc8ad8f32bc6dca8a
Gary Gregory refactored commons-fileupload2 recently and removed the logic
-
https://github.com/apache/commons-fileupload/commit/355d264689c8430a4ee7bd8dfd36fcf8d9459bcf
The best is to file an issue to commons-fileupload -
https://issues.apache.org/jira/projects/FILEUPLOAD


>
> https://issues.apache.org/jira/browse/WICKET-7051
>
> Besides that I would like to ask why do we need to jump to fileupload2? Is
> it because of the "Jakarta thing"?
>

Yes!



>
> --
> Regards - Ernesto Reinaldo Barreiro
>

Re: addying support for upload to resource

[Martin Grigorov]

On Wed, Mar 15, 2023 at 2:16 PM Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Ok. Then I will create an issue... Things I will try to achieve:
>
>
>- Upload to a resource in an asynchronous non page blocking request
>- Add an optional way to block the user from leaving the page while the
>upload is happening
>- Ways to cancel the upload
>- Adapt the upload progress bar to work with this new "component" and
>improve its code as in some corner cases it is producing client side
> errors
>(I created an issue for that some time ago).
>- Maybe useful too:  create a web socket based progress bar, as the
>upload progress bar now works pulling the server every second.
>
> Shall this work be done for 10.x only or two for 9.x? I think both would be
> good.
>

Both is fine!

I think it would be good also to add an example to wicket-examples that
uses a smart JS uploader, llike in the blog.
This way you will verify that the new APIs are easily extendable.


>
> On Wed, Mar 15, 2023 at 1:59 PM Martin Grigorov 
> wrote:
>
> > On Wed, Mar 15, 2023 at 12:25 PM Ernesto Reinaldo Barreiro <
> > reier...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > In our application we are heavily using web socket push (repainting web
> > > wicket components via web-socket push). One problem we found is that in
> > > some pages we have some uploads and those uploads can be very large,
> and
> > > while they are happening the page is "frozen" and no new web socket
> > > messages are received. Because of that, I have implemented a custom
> > upload
> > > to a wicket resource. In essence some adaptation of
> > >
> > >
> > >
> >
> https://github.com/martin-g/blogs/blob/master/file-upload/src/main/java/com/mycompany/fileupload/AbstractFileUploadResource.java
> > >
> > >
> > > But I also had to adapt the upload progress bar in order to be able to
> > > report progress upload. Would this be something interesting to have in
> > > a "generic" way in Wicket itself?
> > >
> >
> > +1
> > I think it would be a good addition!
> >
> >
> >
> > >
> > >
> > > --
> > > Regards - Ernesto Reinaldo Barreiro
> > >
> >
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>

Re: addying support for upload to resource

[Martin Grigorov]

On Wed, Mar 15, 2023 at 12:25 PM Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi,
>
> In our application we are heavily using web socket push (repainting web
> wicket components via web-socket push). One problem we found is that in
> some pages we have some uploads and those uploads can be very large, and
> while they are happening the page is "frozen" and no new web socket
> messages are received. Because of that, I have implemented a custom upload
> to a wicket resource. In essence some adaptation of
>
>
> https://github.com/martin-g/blogs/blob/master/file-upload/src/main/java/com/mycompany/fileupload/AbstractFileUploadResource.java
>
>
> But I also had to adapt the upload progress bar in order to be able to
> report progress upload. Would this be something interesting to have in
> a "generic" way in Wicket itself?
>

+1
I think it would be a good addition!



>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>

Re: Time for Wicket M1?

[Martin Grigorov]

BTW there is a ticket from Apache Causeway team requesting to extract
WicketTester in its own Maven module because currently it causes problems
when trying to use wicket-core as a Java module.

https://issues.apache.org/jira/browse/WICKET-7019

But maybe it could be done for M2

On Thu, Feb 9, 2023 at 1:10 PM Maxim Solodovnik 
wrote:

> from mobile (sorry for typos ;)
>
>
> On Thu, Feb 9, 2023, 18:03 Andrea Del Bene  wrote:
>
> > Excuse my silly question but isn't ok for milestone version to depend on
> a
> > snapshot version (fileupload 2.0-SNAPSHOT)?
> >
>
> Unfortunately not :(
> The build will not be reproducible
>
>
>
> > On Thu, Feb 9, 2023 at 8:36 AM Emond Papegaaij <
> emond.papega...@gmail.com>
> > wrote:
> >
> > > Op do 9 feb. 2023 om 08:32 schreef Martin Grigorov <
> mgrigo...@apache.org
> > >:
> > >
> > > > On Thu, Feb 9, 2023 at 9:16 AM Emond Papegaaij <
> > > emond.papega...@gmail.com>
> > > > wrote:
> > > >
> > > > > Op do 9 feb. 2023 om 07:47 schreef Martin Grigorov <
> > > mgrigo...@apache.org
> > > > >:
> > > > >
> > > > > > Please update
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0
> > > > > > that the Component Queueing is gone
> > > > > >
> > > > > > Before releasing M1 I think we need to:
> > > > > > 1) update all dependencies to their latest stable version
> > > > > > 2) copy over commons-fileupload2 classes to wicket-util or a new
> > > Maven
> > > > > > module
> > > > > >
> > > > >
> > > > > What about shading the classes in an internal package? I'm a bit
> > > > concerned
> > > > > with having to cope with different classes with the same fqcn when
> > some
> > > > > other dependency also pulls in commons-fileupload.
> > > > >
> > > >
> > > > I am not sure whether Maven would be happy to use a -SNAPSHOT for the
> > > > shading process when making a release. If you mean
> maven-shade-plugin.
> > > > Doing it manually should work!
> > > >
> > >
> > > Yes, releasing against a SNAPSHOT version is not a very good idea, even
> > if
> > > shaded. That will give issues trying to rebuild a certain version if
> > > something has changed. Copy-pasting and changing the package should be
> > ok.
> > >
> > > Best regards,
> > > Emond
> > >
> >
> >
> > --
> > Andrea Del Bene.
> > Apache Wicket committer.
> >
>

Re: Time for Wicket M1?

[Martin Grigorov]

On Thu, Feb 9, 2023 at 9:18 AM Korbinian Bachl <
korbinian.ba...@whiskyworld.de> wrote:

> When looking at
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0
>
> I wondered what Jakarta version is required?


Any.


>
> Is Jakarta 9.0 enough? Because, it says Java 17 needed - this is even
> above Jakarta 9.1 abd 10 that both have a JDK 11 baseline?


Wicket (mostly) uses the Servlet API, so any version that is jakarta.** is
fine!
The same is valid for CDI and Bean Validator.



>
>
>
> Oh and also what does this remove of component-queuing mean?
>
> Best,
>
> KB
>
> - Ursprüngliche Mail -
> > Von: "Martin Grigorov" 
> > An: "dev" 
> > Gesendet: Donnerstag, 9. Februar 2023 07:45:50
> > Betreff: Re: Time for Wicket M1?
>
> > Please update
> >
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0
> > that the Component Queueing is gone
> >
> > Before releasing M1 I think we need to:
> > 1) update all dependencies to their latest stable version
> > 2) copy over commons-fileupload2 classes to wicket-util or a new Maven
> > module
> >
> >
> > On Thu, Feb 9, 2023 at 7:49 AM Ernesto Reinaldo Barreiro <
> reier...@gmail.com>
> > wrote:
> >
> >> Hi Sven!
> >>
> >> On Wed, Feb 8, 2023 at 9:30 PM Sven Meier  wrote:
> >>
> >> > I've removed queuing on branch
> >> > https://github.com/apache/wicket/tree/remove-queuing
> >> > Still ready to be merged.
> >> >
> >> > We agreed to remove it from Wicket 10, didn't we?
> >> >
> >>
> >> Yes! Many many thanks for your work. I remember someone complaining in
> >> wicket's user list when thai was introduced about wicket being slower
> after
> >> queuing.
> >>
> >> +1 to get rid of this.
> >>
> >>
> >> > Sven
> >> >
> >> >
> >> > On 08.02.23 12:54, Ernesto Reinaldo Barreiro wrote:
> >> > > No idea. There was some effort (by Sven) to remove component
> >> queueing...
> >> > No
> >> > > idea if that landed on the master branch?
> >> > >
> >> > > On Wed, Feb 8, 2023 at 1:03 PM Andrea Del Bene <
> an.delb...@gmail.com>
> >> > wrote:
> >> > >
> >> > >> Hi,
> >> > >>
> >> > >> I've seen that lately there have been some activities and questions
> >> > related
> >> > >> to Wicket 10. Although we have some pending issues before
> proposing a
> >> > >> release candidate, I think it's the right time for a first
> milestone
> >> > >> release. What do you think?
> >> > >>
> >> > >> --
> >> > >> Andrea Del Bene.
> >> > >> Apache Wicket committer.
> >> > >>
> >> > >
> >> >
> >>
> >>
> >> --
> >> Regards - Ernesto Reinaldo Barreiro
>

Re: Time for Wicket M1?

[Martin Grigorov]

On Thu, Feb 9, 2023 at 9:16 AM Emond Papegaaij 
wrote:

> Op do 9 feb. 2023 om 07:47 schreef Martin Grigorov :
>
> > Please update
> >
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0
> > that the Component Queueing is gone
> >
> > Before releasing M1 I think we need to:
> > 1) update all dependencies to their latest stable version
> > 2) copy over commons-fileupload2 classes to wicket-util or a new Maven
> > module
> >
>
> What about shading the classes in an internal package? I'm a bit concerned
> with having to cope with different classes with the same fqcn when some
> other dependency also pulls in commons-fileupload.
>

I am not sure whether Maven would be happy to use a -SNAPSHOT for the
shading process when making a release. If you mean maven-shade-plugin.
Doing it manually should work!


>
> Best regards,
> Emond
>

Re: Time for Wicket M1?

[Martin Grigorov]

Please update
https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0
that the Component Queueing is gone

Before releasing M1 I think we need to:
1) update all dependencies to their latest stable version
2) copy over commons-fileupload2 classes to wicket-util or a new Maven
module


On Thu, Feb 9, 2023 at 7:49 AM Ernesto Reinaldo Barreiro 
wrote:

> Hi Sven!
>
> On Wed, Feb 8, 2023 at 9:30 PM Sven Meier  wrote:
>
> > I've removed queuing on branch
> > https://github.com/apache/wicket/tree/remove-queuing
> > Still ready to be merged.
> >
> > We agreed to remove it from Wicket 10, didn't we?
> >
>
> Yes! Many many thanks for your work. I remember someone complaining in
> wicket's user list when thai was introduced about wicket being slower after
> queuing.
>
> +1 to get rid of this.
>
>
> > Sven
> >
> >
> > On 08.02.23 12:54, Ernesto Reinaldo Barreiro wrote:
> > > No idea. There was some effort (by Sven) to remove component
> queueing...
> > No
> > > idea if that landed on the master branch?
> > >
> > > On Wed, Feb 8, 2023 at 1:03 PM Andrea Del Bene 
> > wrote:
> > >
> > >> Hi,
> > >>
> > >> I've seen that lately there have been some activities and questions
> > related
> > >> to Wicket 10. Although we have some pending issues before proposing a
> > >> release candidate, I think it's the right time for a first milestone
> > >> release. What do you think?
> > >>
> > >> --
> > >> Andrea Del Bene.
> > >> Apache Wicket committer.
> > >>
> > >
> >
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>

Re: @Inject in wicket-10

[Martin Grigorov]

On Thu, Jan 12, 2023, 18:51 Maxim Solodovnik  wrote:

> The only place I was to find is
>
> org.apache.wicket.arquillian.testing.pages.ListContacts;
>

Arqillian is not supported since a long time. It is not member of the Maven
reactor.


> On Thu, 12 Jan 2023 at 23:47, Martin Grigorov 
> wrote:
> >
> > On Thu, Jan 12, 2023, 18:43 Maxim Solodovnik 
> wrote:
> >
> > > What about "import javax.annotation.Resource;" ?
> > >
> >
> > Do we use/support it?!
> >
> >
> > > On Thu, 12 Jan 2023 at 23:41, Martin Grigorov 
> > > wrote:
> > > >
> > > > Do it!
> > > >
> > > > On Thu, Jan 12, 2023, 17:33 Maxim Solodovnik 
> > > wrote:
> > > >
> > > > > Hello All,
> > > > >
> > > > > Am I right thinking "import javax.inject.Inject;" should be
> replaced
> > > > > with "import jakarta.inject.Inject;"?
> > > > >
> > > > > Shall I do it in "master" branch of wicket? (My IDE reports "17
> > > > > results in 14 files")
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Maxim
> > > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Maxim
> > >
>
>
>
> --
> Best regards,
> Maxim
>

Re: @Inject in wicket-10

[Martin Grigorov]

On Thu, Jan 12, 2023, 18:43 Maxim Solodovnik  wrote:

> What about "import javax.annotation.Resource;" ?
>

Do we use/support it?!


> On Thu, 12 Jan 2023 at 23:41, Martin Grigorov 
> wrote:
> >
> > Do it!
> >
> > On Thu, Jan 12, 2023, 17:33 Maxim Solodovnik 
> wrote:
> >
> > > Hello All,
> > >
> > > Am I right thinking "import javax.inject.Inject;" should be replaced
> > > with "import jakarta.inject.Inject;"?
> > >
> > > Shall I do it in "master" branch of wicket? (My IDE reports "17
> > > results in 14 files")
> > >
> > > --
> > > Best regards,
> > > Maxim
> > >
>
>
>
> --
> Best regards,
> Maxim
>

Re: wicket-10 spring bean injection

[Martin Grigorov]

On Thu, Jan 12, 2023, 18:06 Maxim Solodovnik  wrote:

> Hello All,
>
> It seems "Injector.get().inject(this);" doesn't work for me as expected
>
> The bean annotated with @Inject or @SpringBean is injected
>

Here you say @Inject injects the proxy.

(WicketProxy, via ByteBuddy but it differs from what is being injected
> by Spring, and all @Inject/@Autowired fields are null :(((
>

Here it is null...
Which one is correct?

Or you mean the transitive dependencies are null? If this is the case then
debug in SpringBeanLocator. It uses Spring APIs to load the real bean.



> What can I troubleshoot?
>
> --
> Best regards,
> Maxim
>

Re: @Inject in wicket-10

[Martin Grigorov]

Do it!

On Thu, Jan 12, 2023, 17:33 Maxim Solodovnik  wrote:

> Hello All,
>
> Am I right thinking "import javax.inject.Inject;" should be replaced
> with "import jakarta.inject.Inject;"?
>
> Shall I do it in "master" branch of wicket? (My IDE reports "17
> results in 14 files")
>
> --
> Best regards,
> Maxim
>

Re: Strange memory leak in CachingResourceStreamLocator

[Martin Grigorov]

https://issues.apache.org/jira/browse/WICKET-7024
The attached quickstart there does not use your finder.

On Thu, Jan 12, 2023 at 12:27 PM Tobias Gierke
 wrote:

>
> I see!
>
> Can you reproduce this in a quickstart ?
>
>
>
> Yes, attached a quickstart to this e-mail (I hope it goes through). It
> somehow seems to be related to the custom IResourceFinder we've registered
> *and*  because if either of those is *not* present, the
> issue goes away. I'm reluctant to file a bug report for that just yet
> because maybe our IResourceFinder implementation does something weird/wrong.
>
> To reproduce:
>
> 1.) Put a conditional "key.style != null" breakpoint on
> CachingResourceStreamLocator#updateCache , line 107 (where the "stream
> instanceof UrlResourceStream") case is getting handled
> 2.) Run the quickstart and click the AJAX button that redirects to the
> homepage
> 3.) Observe that the breakpoint gets hit with style != null
>
>

Re: Strange memory leak in CachingResourceStreamLocator

[Martin Grigorov]

On Thu, Jan 12, 2023 at 10:21 AM Tobias Gierke
 wrote:

> Hi Martin,
>
> I wonder why people create images of plain text to paste it in text
> context (email) ... It just makes it hard to do anything with this text,
> e.g. to copy/paste the relevant part!
>
> Good point, will try to better myself ;)
>

You did it again! :-)

>
> In your first email the CacheKey says that the scope is o.a.w.Application,
> but here we see that it actually is
> com.vodecc.voipmngPageWithLoginScreenLayout
>
> The heap dump I'm talking about in my first e-mail is from one of our
> largest customers and was provided to me by one of our support guys.
> Because the code is running inside a highly secured internal network (telco
> business), I cannot do any remote debugging there. So my debugger
> screenshots are taken on my local dev machine running the same GIT tag.
> There's only a single page in the whole application where those resources
> (except for the PNG image which is used elsewhere as well) are being used -
> and that is the application's login page.
>
> the "name" is "css/qrystal.css"
> and there are no locale/style/variation at all in the url (link's href),
> as expected
>
> I probably didn't explain this very well, the memory leak happens during
> processing of the "redirect to login page" AJAX request triggered when a
> user clicks a button on our "session expired" page (see below) and we
> perform an internal redirect to the login page.
>
>
> Does it help if you change the above to
setResponsePage(WicketLoginPage.class, p) ?

> also there is no page instance information in the css' href (pageId,
> renderCount, behaviorId)...
> the hashing 167344540504 is not related to the CacheKey
>
> I'd suggest you to put a conditional breakpoint at
> WicketFilter#processFilter() and see whether there are requests to url that
> contains both "o.a.w.Application" and "qrystal-login"
> If this does not break then do the same in CacheKey constructor
>
>
> 1.) Put a conditional breakpoint on "key.style != null" in
> CachingResourceStreamLocator#updateCache()
>
> As I've said before, we're never calling WebSession#setStyle() so this
> breakpoint should never trigger.
>
> 2.) After starting the application in debug mode, I enter the URL of a
> mounted,protected (=login required) page into the browser's navigation bar
> and am being redirected to our application's "Page expired/Login required"
> page with the AJAX button mentioned above.
>
> 3.) Clicking the AJAX button immediately makes the debugger stop at the
> "impossible" breakpoint
>
>
> 3.) Going up the call stack to the WicketFilter class shows that the
> request currently being processed is in fact the AJAX request triggered by
> the "Go to login page" button
>
>
> The "CacheKey.style" is "1.0" which matches what is present in the request
> URL.
>
> So the memory leak happens during rendering the response for "onclick"
> AJAX request, which is our login page.
>

I see!

Can you reproduce this in a quickstart ?

Re: Strange memory leak in CachingResourceStreamLocator

[Martin Grigorov]

I wonder why people create images of plain text to paste it in text context
(email) ... It just makes it hard to do anything with this text, e.g. to
copy/paste the relevant part!

In your first email the CacheKey says that the scope is o.a.w.Application,
but here we see that it actually is
com.vodecc.voipmngPageWithLoginScreenLayout
the "name" is "css/qrystal.css"
and there are no locale/style/variation at all in the url (link's href), as
expected
also there is no page instance information in the css' href (pageId,
renderCount, behaviorId)...
the hashing 167344540504 is not related to the CacheKey

I'd suggest you to put a conditional breakpoint at
WicketFilter#processFilter() and see whether there are requests to url that
contains both "o.a.w.Application" and "qrystal-login"
If this does not break then do the same in CacheKey constructor

The requests to resources (js, css) know nothing about the page (instance)
that triggered them.
I suspect that your custom parsing of the heap dump might be broken
somehow. Do you see o.a.w.Application in MAT when expanding the fields of
the cache items ?


On Wed, Jan 11, 2023 at 5:03 PM Tobias Gierke
 wrote:

> Hi Martin,
>
> What is the url for any of the problematic resources in the generated HTML
> ?
> The resources' urls are not related to page *instances*, so I don't
> expect to see anything like pageId, renderCount and behaviorId in them.
>
> Not really sure I understood your question correctly...  the final markup
> (debug mode enabled, hence the wicket tags are still visible) received by
> the browser looks like this:
>
> while the XHTML template looks like this:
>
> Not sure this is relevant here but for historic reasons (many years ago
> our application got migrated gradually from Struts2 to Wicket) we're
> registering a custom IResourceFinder in WebApplication#init() that handles
> "css/*" , "script/*" and "img/*" paths.
>
>
>
>
> On Wed, Jan 11, 2023 at 2:17 PM Tobias Gierke
> 
>  wrote:
>
>> Hi guys,
>>
>> I'm currently investigating a memory leak inside our application (running
>> Wicket 8.14.0). Sorry for the large amount of images in this (HTML) mail
>> but the issue is rather complicated and as the saying goes, "A picture is
>> worth a thousand words".
>>
>> Inspecting the CachingResourceStreamLocator's internal ConcurrentHashMap
>> reveals that around 500.000 of the cache entries are all related to a set
>> of only 5 *static* resources:
>>
>> Further digging into the cache map's content reveals that the reason for
>> this duplication is that the
>> org.apache.wicket.core.util.resource.locator.caching.CachingResourceStreamLocator$CacheKey
>> instances used as keys in the map for these 5 static resources only deviate
>> by their "style" attribute:
>>
>> Note that this output was generated by parsing the heap dump using some
>> custom tooling I wrote (as Eclipse MAT is not powerful enough to do this
>> via OQL/Calcite) where I parsed all the CacheKey field values and then
>> concatenated them as a string like so:
>>
>> to generate CSV output in "map key;map value" format. Also note the
>> somewhat mangled looking style values with the trailing '.' (I
>> double-checked my program output against Eclipse MAT and both agree that
>> the strings are indeed ending with a trailing dot).
>>
>> Since we're never calling WebSession#setStyle(), this looks weird to me.
>> One of the URLs being parsed is an AJAX callback URL generated by an
>> onclick AjaxEventBehaviour attached to a button:
>>
>> I stepped through the Wicket code and this URL gets parsed by
>> org.apache.wicket.resource.ResourceUtil
>>
>> I checked how the AJAX callback URL is generated and noticed that what is
>> mistaken as "style" by ResourceUtil is ".":
>>
>>
>> The weird thing about all of this is that the issue seems to only affect
>> 5 static application-level resources (though we obviously use a lot more
>> static application-level resources everywhere) and 4 out of those 5
>> resources are used by a single WebPage of our application only (the login
>> page).
>>
>> Since our application is rather old (>10 years) and - for various reasons
>> - quite deeply integrated with Wicket internals, I wouldn't rule out that
>> we're doing something wrong (I checked our custom CSRFMapper since it shows
>> up in the stack trace but couldn't see any obvious relationship to the
>> observed behaviour).
>>
>> Any ideas ?
>>
>> Cheers,
>> Tobias
>>
> --
> Tobias Gierke
> Software Developer
>
> Voipfuture GmbH   Wendenstr. 4   20097 Hamburg   Germany
> Phone +49 40 688 9001 64   Fax +49 40 688 9001 99
> Managing Directors   Jan Bastian   Eyal Ullert
> Commercial Court AG Hamburg   HRB 109896   VAT ID DE263738086
>
>

Re: Strange memory leak in CachingResourceStreamLocator

[Martin Grigorov]

What is the url for any of the problematic resources in the generated HTML ?
The resources' urls are not related to page *instances*, so I don't expect
to see anything like pageId, renderCount and behaviorId in them.

On Wed, Jan 11, 2023 at 2:17 PM Tobias Gierke
 wrote:

> Hi guys,
>
> I'm currently investigating a memory leak inside our application (running
> Wicket 8.14.0). Sorry for the large amount of images in this (HTML) mail
> but the issue is rather complicated and as the saying goes, "A picture is
> worth a thousand words".
>
> Inspecting the CachingResourceStreamLocator's internal ConcurrentHashMap
> reveals that around 500.000 of the cache entries are all related to a set
> of only 5 *static* resources:
>
> Further digging into the cache map's content reveals that the reason for
> this duplication is that the
> org.apache.wicket.core.util.resource.locator.caching.CachingResourceStreamLocator$CacheKey
> instances used as keys in the map for these 5 static resources only deviate
> by their "style" attribute:
>
> Note that this output was generated by parsing the heap dump using some
> custom tooling I wrote (as Eclipse MAT is not powerful enough to do this
> via OQL/Calcite) where I parsed all the CacheKey field values and then
> concatenated them as a string like so:
>
> to generate CSV output in "map key;map value" format. Also note the
> somewhat mangled looking style values with the trailing '.' (I
> double-checked my program output against Eclipse MAT and both agree that
> the strings are indeed ending with a trailing dot).
>
> Since we're never calling WebSession#setStyle(), this looks weird to me.
> One of the URLs being parsed is an AJAX callback URL generated by an
> onclick AjaxEventBehaviour attached to a button:
>
> I stepped through the Wicket code and this URL gets parsed by
> org.apache.wicket.resource.ResourceUtil
>
> I checked how the AJAX callback URL is generated and noticed that what is
> mistaken as "style" by ResourceUtil is ".":
>
>
> The weird thing about all of this is that the issue seems to only affect 5
> static application-level resources (though we obviously use a lot more
> static application-level resources everywhere) and 4 out of those 5
> resources are used by a single WebPage of our application only (the login
> page).
>
> Since our application is rather old (>10 years) and - for various reasons
> - quite deeply integrated with Wicket internals, I wouldn't rule out that
> we're doing something wrong (I checked our custom CSRFMapper since it shows
> up in the stack trace but couldn't see any obvious relationship to the
> observed behaviour).
>
> Any ideas ?
>
> Cheers,
> Tobias
>

Re: Release Wicket 10.0.0-M1?

[Martin Grigorov]

According to
https://issues.apache.org/jira/browse/FILEUPLOAD-309?focusedCommentId=17652022&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17652022
and
https://jakarta.ee/specifications/platform/9/apidocs/jakarta/servlet/annotation/multipartconfig
it seems @MultipartConfig could be used only on Servlet, but not on a
Filter.

I still believe copying the classes to wicket-util or
wicket-commons-fileupload is the best way to proceed. if we preserve the
package name then we can just drop them once commons-fileupload2 is
officially released.

On Mon, Dec 19, 2022 at 5:41 PM Matt Pavlovich  wrote:

> IMO relying on the annotation to do configuration would be a show stopper.
>
> > On Dec 17, 2022, at 7:01 AM, Martijn Dashorst <
> martijn.dasho...@gmail.com> wrote:
> >
> > Is commons-fileupload still necessary with the addition of multipart
> > support?
> >
> > https://www.baeldung.com/upload-file-servlet
> >
> > I assume we require servlet 3.0 at the minimum?
> >
> > Martijn
> >
> >
> > On Sat, Dec 17, 2022 at 1:56 AM Maxim Solodovnik 
> > wrote:
> >
> >> According to this:
> >> https://lists.apache.org/thread/22ro2qbstmrhrdq92g370kdsgf3fpfv2
> >>
> >> There should be release soon :)
> >>
> >>
> >> from mobile (sorry for typos ;)
> >>
> >>
> >> On Sat, Dec 17, 2022, 01:38 Martin Grigorov 
> wrote:
> >>
> >>> Maybe copy the commons-file upload classes in a new Maven module?
> >>>
> >>> On Fri, Dec 16, 2022, 17:07 Thomas Heigl  wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> There doesn't seem to be any progress with commons-fileupload. Should
> >> we
> >>>> start exploring other options? Or should we try to push some more on
> >> the
> >>>> JIRA?
> >>>>
> >>>> I'm still blocked by one other dependency (Apache Shiro) but they are
> >>> close
> >>>> to releasing Jakarta artifacts.
> >>>>
> >>>> Best,
> >>>>
> >>>> Thomas
> >>>>
> >>>>
> >>>> On Tue, Apr 19, 2022 at 9:27 PM Martin Grigorov  >
> >>>> wrote:
> >>>>
> >>>>> On Tue, Apr 19, 2022 at 2:42 PM Thomas Heigl 
> >>>> wrote:
> >>>>>
> >>>>>> OK I just saw that Martin already asked them to do a release in
> >>>>>>
> >>>>
> >>
> https://issues.apache.org/jira/projects/FILEUPLOAD/issues/FILEUPLOAD-309
> >>>>> .
> >>>>>>
> >>>>>
> >>>>> 1 year ago ...
> >>>>> I see you JIRA voted for the issue. I think no one cares about the
> >>> number
> >>>>> of votes. Better add a comment! Comments go to the mailing list and
> >> the
> >>>>> maintainers are notified.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> On Tue, Apr 19, 2022 at 1:35 PM Thomas Heigl 
> >>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I started migrating our app to the new Jakarta APIs. Wicket is
> >> the
> >>>> only
> >>>>>>> dependency that doesn't yet have a pre-release. Is there anything
> >>>>>>> preventing us from releasing 10.0.0-M1?
> >>>>>>>
> >>>>>>> Is the SNAPSHOT dependency on commons-fileupload the only
> >> remaining
> >>>>>> issue?
> >>>>>>> If so, we should probably ask them to create a release candidate.
> >>>>>>>
> >>>>>>> Best,
> >>>>>>>
> >>>>>>> Thomas
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
>
>

Re: Release Wicket 10.0.0-M1?

[Martin Grigorov]

Maybe copy the commons-file upload classes in a new Maven module?

On Fri, Dec 16, 2022, 17:07 Thomas Heigl  wrote:

> Hi,
>
> There doesn't seem to be any progress with commons-fileupload. Should we
> start exploring other options? Or should we try to push some more on the
> JIRA?
>
> I'm still blocked by one other dependency (Apache Shiro) but they are close
> to releasing Jakarta artifacts.
>
> Best,
>
> Thomas
>
>
> On Tue, Apr 19, 2022 at 9:27 PM Martin Grigorov 
> wrote:
>
> > On Tue, Apr 19, 2022 at 2:42 PM Thomas Heigl 
> wrote:
> >
> > > OK I just saw that Martin already asked them to do a release in
> > >
> https://issues.apache.org/jira/projects/FILEUPLOAD/issues/FILEUPLOAD-309
> > .
> > >
> >
> > 1 year ago ...
> > I see you JIRA voted for the issue. I think no one cares about the number
> > of votes. Better add a comment! Comments go to the mailing list and the
> > maintainers are notified.
> >
> >
> >
> > >
> > > On Tue, Apr 19, 2022 at 1:35 PM Thomas Heigl 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > I started migrating our app to the new Jakarta APIs. Wicket is the
> only
> > > > dependency that doesn't yet have a pre-release. Is there anything
> > > > preventing us from releasing 10.0.0-M1?
> > > >
> > > > Is the SNAPSHOT dependency on commons-fileupload the only remaining
> > > issue?
> > > > If so, we should probably ask them to create a release candidate.
> > > >
> > > > Best,
> > > >
> > > > Thomas
> > > >
> > >
> >
>

Re: Regarding JDK 11/17 support for Apache Wicket v7

[Martin Grigorov]

Hi,

Yes, Wicket 7 should work just fine with any JDK newer than JDK 8!

But, Wicket 7.x receives only security related fixes!
If you find any non-security issues then most probably they won't be fixed!
This is valid also for JDK 8! We recommend you to upgrade to a newer
version!

Martin

On Wed, Nov 30, 2022 at 12:55 PM Jagdish, Bhore Akshay
 wrote:

> Hello,
>
> We are currently using Apache Wicket v7 in our application (running on
> JDK8). And, we are planning to upgrade our java to JDK 11 (also
> subsequently to JDK 17).
> While we do have Wicket upgrade to v8 planned, we would like to know
> whether Apache Wicket v7 supports JDK 11 (also JDK 17).
> As I couldn't find any documentation regarding JDK support for wicket v7.
>
> Awaiting your reply.
>
>
> Thanks & Regards,
> Akshay Jagdish Bhore
>
>
>

Re: Time for 9.12.0?

[Martin Grigorov]

Nothing has changed.

I am fine to proceed with the release.

On Thu, Sep 29, 2022 at 2:20 PM 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.
>

Re: Time for 9.12.0?

[Martin Grigorov]

On Wed, Sep 14, 2022 at 10:22 AM Martijn Dashorst <
martijn.dasho...@gmail.com> 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?
>

Right!
The only difference is that 1.7.x is not a JSPM module and this leads to
some warnings in Wicket's build and some more problems if an application
tries to go full JSPM.
So, it is either JSPM or OSGi at the moment.
IMO option 3) is the best but someone has to investigate how to manage
Import-Package for OSGi.


>
> 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
>
>
>
> On Wed, Sep 14, 2022 at 9:15 AM Martin Grigorov 
> wrote:
>
> > Hi,
> >
> > I have one concern - https://issues.apache.org/jira/browse/WICKET-6958
> >
> > Some history:
> > Some time ago I have upgraded slf4j-api from 1.7.x to
> > 2.x-alpha/beta/stable. The reason to do it was because 2.x is a JSPM
> > module.
> > SLF4J 2.x is API compatible with 1.7.x but there is a difference - 1.7.x
> > uses static binding, 2.x uses ServiceLoader. So the application should
> use
> > an SLF4J implementation for the respective API version!
> > An (non-OSGi) application can easily downgrade the used version by
> > declaring an explicit dependency to 1.7.x.
> > But!
> > WICKET-6958 has problems in OSGi environment due to the Import-Package
> > directive in the META-INF/MANIFEST file. Bnd (via maven-bundle-plugin)
> sets
> > the value to [2,3) and it seems this makes it hard for the user
> application
> > to downgrade to 1.7.x
> >
> > Here are the options I see:
> > 1) do nothing, just mark it as a known issue
> > 2) change the version back to 1.7.x
> > 3) investigate what should be done by maven-bundle-plugin to set the
> value
> > manually to [1.7,3). I expected that the issue reporter will do it but he
> > waits for us...
> >
> >
> > Martin
> >
> > On Tue, Sep 13, 2022 at 2:14 PM Andrea Del Bene 
> > wrote:
> >
> > > Looks like we have enough material to promote a new release. WDYT?
> > >
> > > --
> > > Andrea Del Bene.
> > > Apache Wicket committer.
> > >
> >
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>

Re: Time for 9.12.0?

[Martin Grigorov]

Hi,

I have one concern - https://issues.apache.org/jira/browse/WICKET-6958

Some history:
Some time ago I have upgraded slf4j-api from 1.7.x to
2.x-alpha/beta/stable. The reason to do it was because 2.x is a JSPM module.
SLF4J 2.x is API compatible with 1.7.x but there is a difference - 1.7.x
uses static binding, 2.x uses ServiceLoader. So the application should use
an SLF4J implementation for the respective API version!
An (non-OSGi) application can easily downgrade the used version by
declaring an explicit dependency to 1.7.x.
But!
WICKET-6958 has problems in OSGi environment due to the Import-Package
directive in the META-INF/MANIFEST file. Bnd (via maven-bundle-plugin) sets
the value to [2,3) and it seems this makes it hard for the user application
to downgrade to 1.7.x

Here are the options I see:
1) do nothing, just mark it as a known issue
2) change the version back to 1.7.x
3) investigate what should be done by maven-bundle-plugin to set the value
manually to [1.7,3). I expected that the issue reporter will do it but he
waits for us...


Martin

On Tue, Sep 13, 2022 at 2:14 PM Andrea Del Bene 
wrote:

> Looks like we have enough material to promote a new release. WDYT?
>
> --
> Andrea Del Bene.
> Apache Wicket committer.
>

Re: JDK 19 first Release Candidates!

[Martin Grigorov]

Hi David,

Apache Wicket's build and tests pass successfully with JDK 19 b36 and 20
b11 on both Ubuntu x86_64 and openEuler OS ARM64.

Regards,
Martin

On Mon, Aug 22, 2022 at 4:23 PM David Delabassee <
david.delabas...@oracle.com> wrote:

> Greetings!
>
> I hope you had a chance to take some time off. On our side, and despite
> the summer vacation, everything is on track for the Java 19 GA release
> on September 20th with JDK 19 now in the Release Candidate Phase [1]. If
> you haven't done so yet, it is time to start testing your project(s)
> using JDK 20 Early-Access builds. Speaking of Early-Access builds, there
> is now a new set of EA builds, i.e., the jextract EA builds. jextract is
> a tool developed under the Project Panama umbrella whose goal is to
> mechanically generates Java bindings from native library headers. If you
> are using the Foreign Function & Memory API (Preview Feature in JDK 19),
> make sure to check jextract too (see the jextract section below).
>
> [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006861.html
>
>
> ## Heads-up - New system properties for `System.out` and `System.err` in
> JDK 19
>
> Two new system properties, `stdout.encoding` and `stderr.encoding`, have
> been introduced. The value of these system properties is the encoding
> used by the standard output (`System.out`) and standard error
> (`System.err`) streams. The default values of these system properties
> depend on the platform. The values take on the value of the
> `native.encoding` property when the platform does not provide streams
> for the console. The properties can be overridden on the launcher's
> command line option, with `-D`, to set them to UTF-8 where required. For
> more details see https://bugs.openjdk.org/browse/JDK-8283620
>
>
> ## Heads-up - SSLSocketImpl finalizer implementation removed in JDK 19
>
> The finalizer implementation in SSLSocket has been removed, with the
> underlying native resource releases now done by the Socket
> implementation. With this update, the TLS close_notify messages will no
> longer be emitted if SSLSocket is not explicitly closed. Not closing
> Sockets properly is an error condition that should be avoided.
> Applications should always close sockets and not rely on garbage
> collection. For more details see
> https://bugs.openjdk.org/browse/JDK-8212136
>
>
> ## Heads-up - New providerPath jarsigner option in JDK 19
>
> A new `-providerPath` option has been added to the jarsigner. This
> option is used to specify the class path of an alternate keystore
> implementation, it can be used together with the -providerClass option.
> For more details see https://bugs.openjdk.org/browse/JDK-8281175
>
>
> ## JDK 19 Release Candidate builds
>
> JDK 19 first Release Candidates (builds 36) are now available [2], and
> are provided under the GNU General Public License v2, with the Classpath
> Exception. The Release Notes are available here [3].
>
> [2] https://jdk.java.net/19/
> [3] https://jdk.java.net/19/release-notes
>
>
> ## JDK 20 Early-Access builds
>
> JDK 20 Early-Access builds 11 are now available [4], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> The Release Notes are available here [5].
>
> [4] https://jdk.java.net/20/
> [5] https://jdk.java.net/20/release-notes
>
> ### Recent changes that maybe of interest:
>
> - JDK-8282730: LdapLoginModule throw NPE from logout method after login
> failure
> - JDK-8290706: Remove the support for inline contiguous allocations
> - JDK-8289551: Conversions between bit representations of half precision
> values and floats
> - JDK-8290485: [vector] REVERSE_BYTES for byte type should not emit any
> instructions
> - JDK-8289137: Automatically adapt Young/OldPLABSize and when setting
> only MinTLABSize
> - JDK-8290034: Auto vectorize reverse bit operations.
> - JDK-8290868: NMT: MallocSiteTable statistics improvements
> - JDK-8291822: ARM32: Build errors with GCC 11 in
> frame::saved_oop_result [Reported by JaCoCo]
> - JDK-8289249: Add methods to Elements for record constructors
> - JDK-8283232: x86: Improve vector broadcast operations
> - JDK-8288327: Executable.hasRealParameterData should not be volatile
> - JDK-8291360: Create entry points to expose low-level class file
> information
> - JDK-8290840: Refactor the "os" class
> - JDK-8292327: InflaterInputStream.read throws EOFException
> - JDK-8155246: Throw error if default java.security file is missing
> - JDK-8289332: Auto-generate ids for user-defined headings
> - JDK-8292153: x86: Represent Registers as values
>
>
> ## Jextract Early-Access Builds
>
> Early Access Builds 19-jextract+2-3 (2022/7/19) are now available [6].
> These open-source builds are provided under the GNU General Public
> License, version 2, with the Classpath Exception.
>
> These builds are from the OpenJDK jextract project [7] which is part of
> Code Tools [8]. jextract is a tool developed under the Panama umbrealla
> whose goal is to mechanically generate 

Re: [CVE-2020-11976] Apache Wicket information disclosure vulnerability

[Martin Grigorov]

Hi,

Wicket 6.x is no more supported.
Wicket 7.x is the current security maintaince branch.

Your options are:
- patch locally
- upgrade to a newer version

On Wed, Aug 10, 2022 at 6:17 PM Daniel Stoch  wrote:

> Hi,
>
> Is there any JIRA issue for this? I tried to find but none issue in Wicket
> JIRA points directly to CVE-2020-11976.
> One possible candidate to me is WICKET-6792 :). Am I right? If yes, this is
> already fixed also for Wicket 6.31.0, can you release this version?
>
> --
> Best regards,
> Daniel Stoch
>
>
> pon., 10 sie 2020 o 18:23  napisał(a):
>
> > Severity: Important
> >
> > Vendor:
> > The Apache Software Foundation
> >
> > Versions Affected:
> > Apache Wicket 7.16.0, 8.8.0 and 9.0.0-M5
> >
> > Description:
> >
> > By crafting a special URL it is possible to make Wicket deliver
> > unprocessed HTML templates.
> > This would allow an attacker to see possibly sensitive information
> > inside a HTML template that is usually removed during rendering.
> > For example if there are credentials in the markup which are never
> > supposed to be visible to the client:
> >
> >
> >   some secret
> >
> >
> > The application developers are recommended to upgrade to:
> > - Apache Wicket 7.17.0
> > 
> > - Apache Wicket 8.9.0
> > 
> > - Apache Wicket 9.0.0
> > 
> >
> > Credit:
> > The vulnerability has been found and reported by Mariusz Popławski from
> > Afine.
> >
> > Apache Wicket Team
> >
>

Re: Possibility for each browser tab to have independent wicket session

[Martin Grigorov]

On Wed, Aug 10, 2022 at 10:33 AM Martin Terra <
martin.te...@koodaripalvelut.com> wrote:

> Ok. We'll put some efforts onto this, dig this deeper, and make a patch
> proposal.
>
> Do you think version 8 is a good place to start and easy to migrate
> upwards?
>

Wicket 10 (master) is the best place for new features.
Once we have the complete picture/diff we could decide whether it can be
backported and to which version.



>
> **
> Martin
>
> ke 10. elok. 2022 klo 10.21 Martin Grigorov (mgrigo...@apache.org)
> kirjoitti:
>
> > No, I have no other ideas than the proposed in the ticker one.
> >
> > On Wed, Aug 10, 2022 at 10:13 AM Martin Terra <
> > martin.te...@koodaripalvelut.com> wrote:
> >
> > > Thanks. Do you have a proposal for solution? If you have, I can put
> some
> > > resources to this to get this to a closure.
> > >
> > > **
> > > Martin
> > >
> > > ke 10. elok. 2022 klo 10.00 Martin Grigorov (mgrigo...@apache.org)
> > > kirjoitti:
> > >
> > > > Hi,
> > > >
> > > > Looking at the ticket comments I guess you already know the answer.
> > > > Claudia Hirt and yourself reported problems which no one addressed
> in 5
> > > > years. So, no.
> > > >
> > > >
> > > > On Wed, Aug 10, 2022 at 8:29 AM Martin Terra <
> > > > martin.te...@koodaripalvelut.com> wrote:
> > > >
> > > > > Hi!
> > > > >
> > > > > Can the feature:
> > > > >
> > > > > Possibility for each browser tab to have independent wicket session
> > > > > <https://issues.apache.org/jira/browse/WICKET-6358>
> > > > >
> > > > > be considered complete for commit into main branches or does it
> need
> > > more
> > > > > testing?
> > > > >
> > > > > **
> > > > > Martin
> > > > >
> > > >
> > >
> >
>

Re: Possibility for each browser tab to have independent wicket session

[Martin Grigorov]

No, I have no other ideas than the proposed in the ticker one.

On Wed, Aug 10, 2022 at 10:13 AM Martin Terra <
martin.te...@koodaripalvelut.com> wrote:

> Thanks. Do you have a proposal for solution? If you have, I can put some
> resources to this to get this to a closure.
>
> **
> Martin
>
> ke 10. elok. 2022 klo 10.00 Martin Grigorov (mgrigo...@apache.org)
> kirjoitti:
>
> > Hi,
> >
> > Looking at the ticket comments I guess you already know the answer.
> > Claudia Hirt and yourself reported problems which no one addressed in 5
> > years. So, no.
> >
> >
> > On Wed, Aug 10, 2022 at 8:29 AM Martin Terra <
> > martin.te...@koodaripalvelut.com> wrote:
> >
> > > Hi!
> > >
> > > Can the feature:
> > >
> > > Possibility for each browser tab to have independent wicket session
> > > <https://issues.apache.org/jira/browse/WICKET-6358>
> > >
> > > be considered complete for commit into main branches or does it need
> more
> > > testing?
> > >
> > > **
> > > Martin
> > >
> >
>

Re: Possibility for each browser tab to have independent wicket session

[Martin Grigorov]

Hi,

Looking at the ticket comments I guess you already know the answer.
Claudia Hirt and yourself reported problems which no one addressed in 5
years. So, no.


On Wed, Aug 10, 2022 at 8:29 AM Martin Terra <
martin.te...@koodaripalvelut.com> wrote:

> Hi!
>
> Can the feature:
>
> Possibility for each browser tab to have independent wicket session
> 
>
> be considered complete for commit into main branches or does it need more
> testing?
>
> **
> Martin
>

Re: JDK 19: Rampdown Phase 2 + JavaOne

[Martin Grigorov]

Hi David,

Apache Wicket build and tests pass successfully with JDK 19-ea+32-2220
and 20-ea+7-379 on Ubuntu 20.04 x86_64 and openEuler 20.03 aarch64 !

Regards,
Martin

On Mon, Jul 25, 2022 at 6:06 PM David Delabassee <
david.delabas...@oracle.com> wrote:

> Greetings!
>
> JDK 19 is now in Rampdown Phase Two [1]. The overall feature set is
> frozen. Per the JDK Release Process [2] we now turn our focus to P1 and
> P2 bugs, which can be fixed with approval [3]. Late enhancements are
> still possible, with approval, but the bar is now extraordinarily high [4].
>
> Given the current state of affairs, it is a good time to start testing
> your project(s) on JDK 20 Early-Access builds. To conclude, please make
> sure to check the heads-up below, including the one covering JavaOne!
>
> [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-July/006803.html
> [2] https://openjdk.org/jeps/3
> [3] https://openjdk.org/jeps/3#Fix-Request-Process
> [4] https://openjdk.org/jeps/3#Late-Enhancement-Request-Process
>
>
> ## Heads-up - JavaOne is back!
>
> After a long hiatus, JavaOne is back! From October 17-20 in Las Vegas,
> JavaOne will be jam-packed with hundreds of valuable and actionable
> sessions directly from the experts: learning sessions, tutorials,
> hands-on labs, lightning talks, panels, an unconference, BoF's, etc. The
> full JavaOne content catalog will be released soon. In the meantime,
> make sure to check https://inside.java/javaone/ for more updates.
>
> And if you are planning to attend JavaOne, please ping me. I'd like to
> meet you in person to chat over OpenJDK and the Quality Outreach
> program. And the drinks will be on me!
>
>
> ## Heads-up - JavaFX Media enhancements survey
>
> The JavaFX team is conducting a short survey [5] to gather input on
> potential JavaFX Media enhancements.
> The process is quite simple as the feedback will be collected via the
> openjfx-dev [6] mailing list. So if you are using JavaFX, make sure to
> raise your voice.
>
> [5] https://mail.openjdk.org/pipermail/openjfx-dev/2022-July/034949.html
> [6] https://mail.openjdk.org/mailman/listinfo/openjfx-dev
>
>
> ## JDK 19
>
> JDK 19 Early-Access builds 32 are now available [7], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> The Release Notes are available here [8].
>
> [7] https://jdk.java.net/19/
> [8] https://jdk.java.net/19/release-notes
>
> ### JEPs integrated to JDK 19:
> - JEP 405: Record Patterns (Preview)
> - JEP 422: Linux/RISC-V Port
> - JEP 424: Foreign Function & Memory API (Preview)
> - JEP 425: Virtual Threads (Preview)
> - JEP 426: Vector API (4th Incubator)
> - JEP 427: Pattern Matching for switch (3rd Preview)
> - JEP 428: Structured Concurrency (Incubator)
>
> ### Recent changes that maybe of interest:
> - JDK-8289127: Apache Lucene triggers: DEBUG MESSAGE: duplicated
> predicate failed which is impossible
> - JDK-8290596: Update java.net.InetAddress to Detect Ambiguous IPv4
> Address Literals
> - JDK-8290615: Remove the Alternate ThreadLocal Implementation of the
> Subject::current and Subject::callAs APIs
> - JDK-8290417: CDS cannot archive lamda proxy with useImplMethodHandle
> - JDK-8287809: Revisit implementation of memory session
> - JDK-8289278: Suspend/ResumeAllVirtualThreads need both can_suspend and
> can_support_virtual_threads
> - JDK-8288589: Files.readString ignores encoding errors for UTF-16
> - JDK-8288425: Footprint regression due MH creation when initializing
> StringConcatFactory
>
>
> ## JDK 20
>
> JDK 20 Early-Access builds 7 are now available [9], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
>
> [9] https://jdk.java.net/20/
>
> ### Recent changes that maybe of interest:
> - JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines
> [Logged by Apache PDFBox]
> - JDK-8284997: arm32 build crashes since JDK-8283326 [Logged by JaCoCo]
> - JDK-8286101: Support formatting in @value tag
> - JDK-8289260: BigDecimal movePointLeft() and movePointRight() do not
> follow their API spec
> - JDK-8287835: Add support for additional float/double to integral
> conversion for x86
> - JDK-8283091: Support type conversion between different data sizes in SLP
> - JDK-8288573: Make Executable.getParameterCount() actually abstract
> - JDK-8266670: Better modeling of access flags in core reflection
> - JDK-8290601: Update java.net.InetAddress to Detect Ambiguous IPv4
> Address Literals
> - JDK-8290334: Update FreeType to 2.12.1
> - JDK-8286030: Avoid JVM crash when containers share the same /tmp dir
> - JDK-8289743: AArch64: Clean up patching logic
> - JDK-8288107: Auto-vectorization for integer min/max
> - JDK-8274235: -Xshare:dump should not call vm_direct_exit
>
>
> ## Topics of Interest:
>
> * What is OpenJDK? - Inside Java Newscast
> https://inside.java/2022/06/30/insidejava-newscast-028/
>
> * “Towards Generational ZGC!” - Inside Java Podcast
> https://inside.java/2022/06/29/podcast-024/
>
> * HotSpot Deep Di

Re: JDK 19: Rampdown Phase 1 + EA builds 26 & JDK 20: EA builds 1

[Martin Grigorov]

Hi David,

Same for JDK 20-ea+1-3 !

Regards,
Martin

On Tue, Jun 14, 2022 at 10:28 AM Martin Grigorov 
wrote:

> Hi David,
>
> Apache Wicket build and tests pass successfully with JDK 19-ea+26-2060 on
> both Linux x86_64 and aarch64!
>
> Regards,
> Martin
>
> On Mon, Jun 13, 2022 at 4:42 PM David Delabassee <
> david.delabas...@oracle.com> wrote:
>
>> Greetings!
>>
>> JDK 19 has now entered Rampdown Phase One (RDP1) [1], which means that
>> the main-line has been forked into a dedicated JDK 19 stabilization
>> repository. At this point, the overall JDK 19 feature set is frozen and
>> no additional JEPs will be targeted to JDK 19. The stabilization
>> repository is open for select bug fixes and, with approval, late
>> low-risk enhancements per the JDK Release Process [2]. Any change pushed
>> to the main line is now bound for JDK 20, unless it is explicitly
>> back-ported to JDK 19.
>>
>> The next few weeks should be leveraged to try to identify and resolve as
>> many issues as possible, i.e. before JDK 19 enters the Release
>> Candidates phase. Moreover, we encourage you to test your project with
>> the `enable-preview` flag as described in this Quality Outreach Heads-up
>> [3], and even if you don't intend to use Virtual Threads in the near
>> future.
>>
>> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-June/006735.html
>> [2] https://openjdk.java.net/jeps/3
>> [3] https://inside.java/2022/05/16/quality-heads-up/
>>
>>
>> ## Heads-up - openjdk.java.net ➜ openjdk.org DNS transition
>>
>> The OpenJDK infrastructure is moving from the old openjdk.java.net
>> subdomain to the openjdk.org top-level domain. This will affect all
>> active subdomains (i.e., bugs, cr, db, git, hg, mail, and wiki) and the
>> old hostnames (*.openjdk.java.net) will now act as aliases for the new
>> names. No actions are required as this transition should be transparent
>> and is mostly done. It should be mentioned that https://jdk.java.net/ is
>> not changing.
>>
>> More infirmation can be found in the original proposal
>> https://mail.openjdk.java.net/pipermail/discuss/2022-May/006089.html
>>
>>
>> ## JDK 19 Early-Access builds
>>
>> JDK 19 Early-Access builds 26 are now available [4], and are provided
>> under the GNU General Public License v2, with the Classpath Exception.
>> The Release Notes are available here [5]. Given that JDK 19 is now in
>> RDP1, the initial JDK 20 Early-Access builds are now also available [6].
>>
>> [4] https://jdk.java.net/19/
>> [5] https://jdk.java.net/19/release-notes
>> [6] https://jdk.java.net/20/
>>
>>
>> ### JEPs integrated to JDK 19:
>> - JEP 405: Record Patterns (Preview)
>> - JEP 422: Linux/RISC-V Port
>> - JEP 424: Foreign Function & Memory API (Preview)
>> - JEP 425: Virtual Threads (Preview)
>> - JEP 426: Vector API (Fourth Incubator)
>> - JEP 427: Pattern Matching for switch (Third Preview)
>> - JEP 428: Structured Concurrency (Incubator)
>>
>> ### Recent changes that may be of interest:
>>
>> Build 26:
>> - JDK-8284199: Implementation of Structured Concurrency (Incubator)
>> - JDK-8282662: Use List.of() factory method to reduce memory consumption
>> - JDK-8284780: Need methods to create pre-sized HashSet and LinkedHashSet
>> - JDK-8250950: Allow per-user and system wide configuration of a
>> jpackaged app
>> - JDK-8236569: -Xss not multiple of 4K does not work for the main thread
>> on macOS
>> - JDK-4511638: Double.toString(double) sometimes produces incorrect
>> results
>> - JDK-8287714: Improve handling of JAVA_ARGS
>> - JDK-8286850: [macos] Add support for signing user provided app image
>> - JDK-8287425: Remove unnecessary register push for
>> MacroAssembler::check_k…
>> - JDK-8283694: Improve bit manipulation and boolean to integer conversion
>> o…
>> - JDK-8287522: StringConcatFactory: Add in prependers and mixers in
>> batches
>>
>> Build 25:
>> - JDK-8284960: Integration of JEP 426: Vector API (Fourth Incubator)
>> - JDK-8287244: Add bound check in indexed memory access var handle
>> - JDK-8287292: Improve TransformKey to pack more kinds of transforms
>> effici…
>> - JDK-8287003: InputStreamReader::read() can return zero despite writing
>> a …
>> - JDK-8287064: Modernize ProxyGenerator.PrimitiveTypeInfo
>>
>> Build 24:
>> - JDK-8286908: ECDSA signature should not return parameters
>> - JDK-8261768: SelfDestructTimer should accept seconds
>> - JDK-8286304: Removal of diagnostic

Re: JDK 19: Rampdown Phase 1 + EA builds 26 & JDK 20: EA builds 1

[Martin Grigorov]

Hi David,

Apache Wicket build and tests pass successfully with JDK 19-ea+26-2060 on
both Linux x86_64 and aarch64!

Regards,
Martin

On Mon, Jun 13, 2022 at 4:42 PM David Delabassee <
david.delabas...@oracle.com> wrote:

> Greetings!
>
> JDK 19 has now entered Rampdown Phase One (RDP1) [1], which means that
> the main-line has been forked into a dedicated JDK 19 stabilization
> repository. At this point, the overall JDK 19 feature set is frozen and
> no additional JEPs will be targeted to JDK 19. The stabilization
> repository is open for select bug fixes and, with approval, late
> low-risk enhancements per the JDK Release Process [2]. Any change pushed
> to the main line is now bound for JDK 20, unless it is explicitly
> back-ported to JDK 19.
>
> The next few weeks should be leveraged to try to identify and resolve as
> many issues as possible, i.e. before JDK 19 enters the Release
> Candidates phase. Moreover, we encourage you to test your project with
> the `enable-preview` flag as described in this Quality Outreach Heads-up
> [3], and even if you don't intend to use Virtual Threads in the near
> future.
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-June/006735.html
> [2] https://openjdk.java.net/jeps/3
> [3] https://inside.java/2022/05/16/quality-heads-up/
>
>
> ## Heads-up - openjdk.java.net ➜ openjdk.org DNS transition
>
> The OpenJDK infrastructure is moving from the old openjdk.java.net
> subdomain to the openjdk.org top-level domain. This will affect all
> active subdomains (i.e., bugs, cr, db, git, hg, mail, and wiki) and the
> old hostnames (*.openjdk.java.net) will now act as aliases for the new
> names. No actions are required as this transition should be transparent
> and is mostly done. It should be mentioned that https://jdk.java.net/ is
> not changing.
>
> More infirmation can be found in the original proposal
> https://mail.openjdk.java.net/pipermail/discuss/2022-May/006089.html
>
>
> ## JDK 19 Early-Access builds
>
> JDK 19 Early-Access builds 26 are now available [4], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> The Release Notes are available here [5]. Given that JDK 19 is now in
> RDP1, the initial JDK 20 Early-Access builds are now also available [6].
>
> [4] https://jdk.java.net/19/
> [5] https://jdk.java.net/19/release-notes
> [6] https://jdk.java.net/20/
>
>
> ### JEPs integrated to JDK 19:
> - JEP 405: Record Patterns (Preview)
> - JEP 422: Linux/RISC-V Port
> - JEP 424: Foreign Function & Memory API (Preview)
> - JEP 425: Virtual Threads (Preview)
> - JEP 426: Vector API (Fourth Incubator)
> - JEP 427: Pattern Matching for switch (Third Preview)
> - JEP 428: Structured Concurrency (Incubator)
>
> ### Recent changes that may be of interest:
>
> Build 26:
> - JDK-8284199: Implementation of Structured Concurrency (Incubator)
> - JDK-8282662: Use List.of() factory method to reduce memory consumption
> - JDK-8284780: Need methods to create pre-sized HashSet and LinkedHashSet
> - JDK-8250950: Allow per-user and system wide configuration of a
> jpackaged app
> - JDK-8236569: -Xss not multiple of 4K does not work for the main thread
> on macOS
> - JDK-4511638: Double.toString(double) sometimes produces incorrect results
> - JDK-8287714: Improve handling of JAVA_ARGS
> - JDK-8286850: [macos] Add support for signing user provided app image
> - JDK-8287425: Remove unnecessary register push for
> MacroAssembler::check_k…
> - JDK-8283694: Improve bit manipulation and boolean to integer conversion
> o…
> - JDK-8287522: StringConcatFactory: Add in prependers and mixers in batches
>
> Build 25:
> - JDK-8284960: Integration of JEP 426: Vector API (Fourth Incubator)
> - JDK-8287244: Add bound check in indexed memory access var handle
> - JDK-8287292: Improve TransformKey to pack more kinds of transforms
> effici…
> - JDK-8287003: InputStreamReader::read() can return zero despite writing a
> …
> - JDK-8287064: Modernize ProxyGenerator.PrimitiveTypeInfo
>
> Build 24:
> - JDK-8286908: ECDSA signature should not return parameters
> - JDK-8261768: SelfDestructTimer should accept seconds
> - JDK-8286304: Removal of diagnostic flag GCParallelVerificationEnabled
> - JDK-8267038: Update IANA Language Subtag Registry to Version 2022-03-02
> - JDK-8285517: System.getenv() returns unexpected value if environment
> vari…
> - JDK-8285513: JFR: Add more static support for event classes
> - JDK-8287024: G1: Improve the API boundary between HeapRegionRemSet and
> G1…
> - JDK-8287139: aarch64 intrinsic for unsignedMultiplyHigh
>
> Build 23:
> - JDK-8282191: Implementation of Foreign Function & Memory API (Preview)
> - JDK-8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms
> - JDK-8282080: Lambda deserialization fails for Object method references
> on interfaces
> - JDK-6782021: It is not possible to read local computer certificates
> with the SunMSCAPI provider
> - JDK-8282191: Implementation of Foreign Function & Memory API (Preview)
> - JDK-82841

Re: JDK 19 - Virtual Threads Testing!

[Martin Grigorov]

Hi David,

Apache Wicket's build and tests pass successfully with JDK 19-ea+22-1598 on
both Linux x86_64 and aarch64!

Regards,
Martin

On Mon, May 16, 2022 at 10:54 AM David Delabassee <
david.delabas...@oracle.com> wrote:

> Welcome to a new OpenJDK Quality Outreach update!
>
> This time, we have one update but a major one: JEP 425 (Virtual Threads
> preview) has been integrated into the OpenJDK mainline! JDK 19
> Early-Access builds 22 are the first mainline builds with Virtual
> Threads (preview) support. So, Project Loom is now getting closer and
> closer!
>
> Please make sure to check the Heads-up below even if you don’t intend to
> use virtual threads in the short future.
>
>
> ## Heads-up - JEP 425 Virtual Threads (preview) testing
>
> The goal of Project Loom is to introduce in the Java platform an
> easy-to-use, high-throughput lightweight concurrency model, and a
> related new concurrent programming model.
>
> Developed in Project Loom, JEP 425 introduces virtual threads to the
> Java Platform. Virtual threads are lightweight threads that dramatically
> reduce the effort of writing, maintaining, and observing high-throughput
> concurrent applications. Note that virtual threads are a preview API in
> JDK 19. Please make sure to read 'JEP 425: Virtual Threads (Preview)'
> for a detailed explanation.
>
> A lot of testing has already been done but we are asking, once again,
> your help to test your project(s) with the latest JDK 19 Early-Access
> builds, even if you don’t intend to use virtual threads any time soon.
>
> There are two approaches to test your project:
> 1. Update your code to use virtual threads …or
> 2. Simply test your existing unchanged code with the preview feature
> enabled.
>
> Both approaches should yield valuable feedback.
>
> If you choose to adapt your application to use virtual threads (cf.
> JavaDoc [2]), be aware that in some cases it’s not just about updating
> your code to use virtual threads instead of platform threads; there are
> some additional considerations. For example, virtual threads shouldn’t
> be pooled [3], code that relies heavily on thread locals [4] will
> require some work to move to a world where there is a new thread for
> each task, etc.
>
> Given that are some minor behavior changes and that `ThreadGroup` has
> been degraded, testing your code as-is, i.e., without using virtual
> threads but with the preview feature enabled at runtime, will also be
> useful. For more details, please check 'JEP 425 - Risks and Assumptions'
> [5].
>
> One difference between to the EA builds published by Project Loom and
> the latest JDK 19 EA builds is that the `--enable-preview` flag is
> required at run-time to use the new APIs. It’s not possible to use the
> APIs with core reflection to avoid the need for `--enable-preview`.
>
> Finally, some tools especially tools relying on JVM TI agents might not
> be fully ready for virtual threads.
>
> Your help testing this important update is greatly appreciated, all
> feedback should be sent to the 'loom-dev' mailing list [6].
>
> [1] https://openjdk.java.net/jeps/425
> [2]
>
> https://download.java.net/java/early_access/jdk19/docs/api/java.base/java/lang/Thread.html
> [3] https://openjdk.java.net/jeps/425#Do-not-pool-virtual-threads
> [4] https://openjdk.java.net/jeps/425#Thread-local-variables
> [5] https://openjdk.java.net/jeps/425#Risks-and-Assumptions
> [6] https://mail.openjdk.java.net/pipermail/loom-dev/
>
>
> ## JDK 19 Early-Access builds
>
> JDK 19 Early-Access builds 22 are now available [7], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> Make sure to check the Release Notes [8] and the JavaDoc [9].
>
> [7] https://jdk.java.net/19/
> [8] https://jdk.java.net/19/release-notes
> [9] https://download.java.net/java/early_access/jdk19/docs/
>
> ### Current JDK 19 JEPs
> - 405: Record Patterns (Preview) - Proposed to target
> - 422: Linux/RISC-V Port - Integrated
> - 424: Foreign Function & Memory API (Preview) - Integrated
> - 425: Virtual Threads (Preview) - Integrated
> - 426: Vector API (4th Incubator) - Targeted
> - 427: Pattern Matching for switch (3rd Preview) - Targeted
>
> ### Recent changes that may be of interest:
>
> Build 22:
> - JDK-8284161: Implementation of Virtual Threads (Preview)
> - JDK-8285947: Avoid redundant HashMap.containsKey calls in ZoneName
> - JDK-8212136: Remove finalizer implementation in SSLSocketImpl
> - JDK-8285872: JFR: Remove finalize() methods
> - JDK-8285914: AppCDS crash when using shared archive with old class file
> - JDK-8286163: micro-optimize Instant.plusSeconds
> - JDK-8282420: JFR: Remove event handlers
> - JDK-8282559: Allow multiple search terms in javadoc search
>
> Build 21:
> - JDK-822: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms
> - JDK-8278370: [win] Disable side-by-side installations of multiple JDK
> updates in Windows JDK installers
> - JDK-8281010: [macos] Disable side-by-side installations of multiple
> JDK up

Re: Release Wicket 9.10.0?

[Martin Grigorov]

+1

On Fri, Apr 29, 2022 at 3:16 PM Thomas Heigl  wrote:

> Hi all,
>
> What do you think about releasing Wicket 9.10.0?
>
> https://issues.apache.org/jira/projects/WICKET/versions/12351540
>
> I'd very much like to roll out all the recent allocation improvements.
>
> Best,
>
> Thomas
>

Re: [DISCUSSION] Shall we clean-up git branches?

[Martin Grigorov]

Hi,

Easy win is to delete all branches which are already merged.
The next step is to review the "closed" ones.

On Thu, Apr 28, 2022 at 5:55 AM Maxim Solodovnik 
wrote:

> Hello All,
>
> Currently we have 130 git branches:
> https://github.com/apache/wicket/branches
> Maybe we can perform clean-up? :))
>
> --
> Best regards,
> Maxim
>

Re: Disable Travis builds?

[Martin Grigorov]

No need to kill it all!
I've removed the part for JS testing.

On Thu, Apr 21, 2022 at 10:43 AM Thomas Heigl  wrote:

> Hi,
>
> Given that our Travis builds aren't working anymore, should we delete the
> travis.yml files?
>
> It is annoying that all builds show up as failed on Github because the
> Travis status check is failing.
>
> Thomas
>

Re: New JDK 19 EA builds and JCE Survey!

[Martin Grigorov]

Hi David,

Apache Wicket's build and tests pass successfully with JDK 19-ea+18-1211 on
both Linux x86_64 and aarch64!

Regards,
Martin

On Wed, Apr 20, 2022 at 5:18 AM David Delabassee <
david.delabas...@oracle.com> wrote:

> Greetings!
>
> The proposed schedule for JDK 19 is now known [1] with ‘Rampdown Phase
> One’ set for June 9th and ‘General Availability’ set for September 20th.
> The next several weeks will be interesting to watch as the scope of JDK
> 19 is revealed.
>
> You also play an important roll during these phases, which is your
> opportunity to share feedback . When developers such as yourself tell us
> of issues faced in the latest OpenJDK early-access (EA) builds, we then
> have a chance to fix them before that feature release reaches general
> availability (GA).
>
> We also enjoy when people tell us that all their tests are green! It
> gives us confidence ;-) So regardless of the tests color (red or green),
> please do not hesitate to send me a short mail as both types of feedback
> are useful.
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-April/006481.html
>
>
> ## Heads-Up: Java Cryptographic Extension Survey
>
> The Java Cryptographic Extension (JCE) has been in Java SE for a long
> time and has made incremental changes over the years. The OpenJDK
> Security Team is conducting a survey [2] to know more about how projects
> are using JCE and what changes, features, and API enhancements would be
> useful going forward.
>
> The survey is clossing on April 29 so if you have written or maintain
> code that uses the JCE API, please make sure to fill this short survey
> [2] as soon as possible.
>
> [2] https://www.questionpro.com/t/AUzP7ZrFWv
>
>
> ## Heads-Up: New macOS Rendering Pipeline on macOS
>
> JEP 382 [3] introduced in JDK 17 support for the new macOS Metal
> graphics pipeline for Swing and Java2D. JDK 19 starting build 18 is
> switching the default to be the new macOS Metal rendering pipeline
> instead of the old Apple OpenGL API. For more details please see
> JDK-8284378 [4].
>
> Java applications running on macOS (10.14 or later) will not need to
> take any action, as they will automatically benefit from faster graphics
> with lower power consumption, and the use of a more modern stable
> graphics API which will be able to work better on current and future
> Apple systems.
>
> [3] https://openjdk.java.net/jeps/382
> [4] https://bugs.openjdk.java.net/browse/JDK-8284378
>
>
> ## JDK 19 Early-Access builds
>
> JDK 19 Early-Access builds 18 are now available [5], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> The Release Notes are available here [6].
>
> [5] https://jdk.java.net/19/
> [6] https://jdk.java.net/19/release-notes
>
> ### JEPs targeted to JDK 19, so far:
> - JEP 422: Linux/RISC-V Port https://openjdk.java.net/jeps/422
>
> ### Recent changes that maybe of interest:
>
> Build 18:
> - JDK-8284378: Make Metal the default Java 2D rendering pipeline for macOS
> - JDK-8265315: Update CLDR to version 41
> - JDK-8270090: C2: LCM may prioritize CheckCastPP nodes over projections
> [Reported by JaCoCo]
> - JDK-8284361: Updating ASM to 9.3 for JDK 19
> - JDK-8284330: jcmd may not be able to find processes in the container
> - JDK-8284579: Improve VarHandle checks for interpreter
>
> Build 17:
> - JDK-8282819: Deprecate Locale class constructors
> - JDK-8254935: Deprecate the PSSParameterSpec(int) constructor
> - JDK-8283060: RawNativeLibraries should allow multiple clients to
> load/unload the same library
>
> Build 16:
> - JDK-8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by default
> - JDK-8264160: Regex \b is not consistent with \w without
> UNICODE_CHARACTER_CLASS
> - JDK-8163327: Remove 3DES from the default enabled cipher suites list
> - JDK-8267319: Use larger default key sizes and algorithms based on CNSA
> - JDK-8283350: (tz) Update Timezone Data to 2022a
>
>
> ## Project Loom Updates
>
> The first Loom related JEP is now in Candidate phase, i.e. JEP: 425:
> Virtual Threads (Preview) [7]. As of now, JEP 425 doesn't yet 'propose
> to target' any particular feature release.
>
> [7] https://openjdk.java.net/jeps/425
>
> In addition, Project Loom early-access builds 19-loom+5-429 (2022/4/4)
> are now available [8] with related Javadoc [9].
>
> These builds are based on JDK 19 and are provided under the GNU General
> Public License, version 2, with the Classpath Exception and are produced
> for the purpose of gathering feedback. Use for any other purpose is at
> your own risk. Proper feedback should be sent to the `loom-dev` mailing
> list [10].
>
> [8] https://jdk.java.net/loom/
> [9] https://download.java.net/java/early_access/loom/docs/api/
> [10] https://mail.openjdk.java.net/mailman/listinfo/loom-dev
>
>
> ## Topics of Interest:
>
> * New candidate JEP: 426: Vector API (4th Incubator)
> https://openjdk.java.net/jeps/426
>
> * Virtual Thread Deep Dive - Inside Java Newscast #23
> https://inside.java/2022/

Re: Release Wicket 10.0.0-M1?

[Martin Grigorov]

On Tue, Apr 19, 2022 at 2:42 PM Thomas Heigl  wrote:

> OK I just saw that Martin already asked them to do a release in
> https://issues.apache.org/jira/projects/FILEUPLOAD/issues/FILEUPLOAD-309.
>

1 year ago ...
I see you JIRA voted for the issue. I think no one cares about the number
of votes. Better add a comment! Comments go to the mailing list and the
maintainers are notified.



>
> On Tue, Apr 19, 2022 at 1:35 PM Thomas Heigl  wrote:
>
> > Hi,
> >
> > I started migrating our app to the new Jakarta APIs. Wicket is the only
> > dependency that doesn't yet have a pre-release. Is there anything
> > preventing us from releasing 10.0.0-M1?
> >
> > Is the SNAPSHOT dependency on commons-fileupload the only remaining
> issue?
> > If so, we should probably ask them to create a release candidate.
> >
> > Best,
> >
> > Thomas
> >
>

Re: Wicket-8.x compatibility with Servlert-5

[Martin Grigorov]

Hi,

On Tue, Apr 5, 2022, 21:37 satya inv  wrote:

> Hi Team,
> We are trying to host wicket-8.11 application on Tomcat 10.
> While migrating, we could observe that wicket-8.11 has dependency on
> javax.servlet packages and is not compiling when we change servlet packages
> from javax.servlet to jakarta.servlet.
>

Right!

We assume Wicket-8.11 can work only with Servlet-api-3, but not with
> Servlet-api-5.
>

Wrong!

Can you please confirm the same from your end?
>

You can use Tomcat or Eclipse Jakarta migration tools to migrate any
javax... class to jakarta...
Just put the .war file in $CATALINA_HOME/javaee-webapps/ folder and Tomcat
will do if automatically.

Also, referred below link
> https://www.mail-archive.com/dev@wicket.apache.org/msg21047.html
>
> Your quick response would be highly appreciated.
>
> Regards,
> Satya
>

Re: [VOTE] Release Apache Wicket 9.9.1

[Martin Grigorov]

Hi,

I won't be able to help in the next few days. Just go ahead and improve it
the way you find good!

Martin

On Sun, Apr 3, 2022, 12:53 Thomas Heigl  wrote:

> I have to take back my +1.
>
> I found one more issue with WICKET-6965 while stress testing our staging
> environment:
>
>
> https://issues.apache.org/jira/browse/WICKET-6965?focusedCommentId=17516488&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17516488
>
> I think we should fix this before releasing 9.9.1.
>
> This websocket code seems to be quite hard to get right.
>
> Best,
>
> Thomas
>
> On Sat, Apr 2, 2022 at 11:34 AM Thomas Heigl  wrote:
>
> > +1
> >
> > I think the changelog for WICKET-6963 should read "Revert: Use singletons
> > for PanelMarkupSourcingStrategy", to make clear that it was reverted.
> >
> > Thomas
> >
> >
> > On Fri, Apr 1, 2022 at 10:21 PM Andrea Del Bene 
> > wrote:
> >
> >> This is a vote to release Apache Wicket 9.9.1
> >>
> >> Please download the source distributions found in our staging area
> >> linked below.
> >>
> >> I have included the signatures for both the source archives. This vote
> >> lasts for 72 hours minimum.
> >>
> >> [ ] Yes, release Apache Wicket 9.9.1
> >> [ ] No, don't release Apache Wicket 9.9.1, because ...
> >>
> >> Distributions, changelog, keys and signatures can be found at:
> >>
> >>  https://dist.apache.org/repos/dist/dev/wicket/9.9.1
> >>
> >> Staging repository:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachewicket-1172/
> >>
> >> The binaries are available in the above link, as are a staging
> >> repository for Maven. Typically the vote is on the source, but should
> >> you find a problem with one of the binaries, please let me know, I can
> >> re-roll them some way or the other.
> >>
> >> Staging git repository data:
> >>
> >>  Repository:  g...@github.com:bitstorm/wicket.git
> >>  Branch:  build/wicket-9.9.1
> >>  Release tag: rel/wicket-9.9.1
> >>
> >>
> >> 
> >>
> >>  CHANGELOG for 9.9.1:
> >>
> >> ** Bug
> >>
> >>  * [WICKET-6966] - IndexOutOfBounds in InSessionPageStore
> >>
> >> ** Improvement
> >>
> >>  * [WICKET-6963] - Use singletons for PanelMarkupSourcingStrategy
> >>
> >>
>

Re: Hotfix 9.9.1

[Martin Grigorov]

Please update Spring!

On Fri, Apr 1, 2022, 19:55 Thomas Heigl  wrote:

> +1. Thank you Andrea!
>
> On Fri, Apr 1, 2022 at 6:22 PM Ernesto Reinaldo Barreiro <
> reier...@gmail.com>
> wrote:
>
> > +1. Many thanks for taking care of releases!
> >
> > On Fri, Apr 1, 2022 at 8:22 AM Andrea Del Bene 
> > wrote:
> >
> > > I will start to rollout this version in few hours. If I have to wait
> for
> > > some last-minute change let me know.
> > >
> > > --
> > > Andrea Del Bene.
> > > Apache Wicket committer.
> > >
> >
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
> >
>

Re: [DISSCUSSION] can we drop wicketstuff-pushd*

[Martin Grigorov]

+1 to drop it!

If someone uses it then (s)he can use the old releases and send a PR later
to revive it!

On Fri, Apr 1, 2022 at 5:20 AM Maxim Solodovnik 
wrote:

> Hello All,
>
> AFAIK these days push is available out-of-the-box via websockets
> Do we need all these components?
>
> If we do need them can anyone take a look at `push-cometd`?
> cometd-java-client/cometd-java-server seems to be changed a lot
> and the version we are currently using reported to be vulnerable:
>
> https://sbom.lift.sonatype.com/report/T1-a0368c8f29fdaa555824-83a6cd82eac598-1648715554-9fa6855eebd24639bf9f6239d6d95ddf
>
> WDYT? :))
>
> --
> Best regards,
> Maxim
>

Re: wicket 9.9.0 - MarkupExceptions after upgrade - any idea why I get this?

[Martin Grigorov]

Hi,

The changelog is quite short:

  CHANGELOG for 9.9.0:

** Bug

 * [WICKET-6957] - Declare JSPM 'uses' for IInitializer
 * [WICKET-6965] - Memory leak in WicketEndpoint

** Improvement

 * [WICKET-6960] - Reduce allocations when encoding ComponentInfo
 * [WICKET-6963] - Use singletons for PanelMarkupSourcingStrategy
 * [WICKET-6964] - Do not allocate when escaping empty string

Maybe WICKET-6963 causes the regression ?!

Can you reproduce it in a quickstart app ?


On Thu, Mar 31, 2022 at 10:56 AM Korbinian Bachl <
korbinian.ba...@whiskyworld.de> wrote:

> Hi,
>
> I deployed our app on 9.9.0 this morning and after initializing a crawl of
> the page I ended up getting a low quote of 503s.
>
> The 503s are always the same:
> 2022-03-31 09:35:05,031 ERROR [org.apache.wicket.DefaultExceptionMapper]
> Unexpected error occurred
> org.apache.wicket.markup.MarkupException:  tags are only
> allowed before , ,  etc. tag
> at
> org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.nextHeaderMarkup(AssociatedMarkupSourcingStrategy.java:341)
> ~[wicket-core-9.9.0.jar:9.9.0]
> at
> org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHeadFromAssociatedMarkupFile(AssociatedMarkupSourcingStrategy.java:236)
> ~[wicket-core-9.9.0.jar:9.9.0]
> at
> org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHead(AssociatedMarkupSourcingStrategy.java:204)
> ~[wicket-core-9.9.0.jar:9.9.0]
> at
> org.apache.wicket.Component.internalRenderHead(Component.java:2649)
> ~[wicket-core-9.9.0.jar:9.9.0]
> 
> at
> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:569)
> [nucleus-grizzly-all.jar:?] at
> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:549)
> [nucleus-grizzly-all.jar:?] at java.lang.Thread.run(Thread.java:829) [?:?]
>
> Any idea how to debug this or where it may come from (race condition in
> our code as wicket became faster?)?
> It somehow seems to be a happen when requests coming in at the same
> time with 9.8.0 we got no such errors.
>
> Best,
>
> KB
>
>
>
>

Re: Add destroyed flag to application?

[Martin Grigorov]

On Tue, Mar 22, 2022 at 12:47 PM Thomas Heigl  wrote:

> Hi,
>
> Yesterday, I discovered that our attempted fix for
> https://issues.apache.org/jira/browse/WICKET-6944 didn't work. Application
> destroy listeners are still registered for every new Websocket connection
> and never cleared.
>
> I can see two options to fix this:
>
> 1. Keep the current listeners and try to find a solution based on static
> fields and careful registering and unregistering of application listeners.
>

https://github.com/apache/wicket/pull/505
A possible solution for this approach.



> 2. Add an AtomicBoolean Application#destroyed field that is set during
> Application#destroy and can be queried via Application#isAlive or
> Application#isDestroyed. This would allow us to replace the current
> listener based approach with something much simpler.
>

I don't mind this approach too!



>
> WDYT?
>
> Best,
>
> Thomas
>

Re: JDK 18 Release Candidate builds & JDK 19 Early-Access builds

[Martin Grigorov]

Hi David,

Apache Wicket build and tests are green with JDK 18+36-2087 and
19-ea+11-661 on Linux x86_64 and aarch64!

Regards,
Martin

On Mon, Feb 28, 2022 at 10:29 PM David Delabassee <
david.delabas...@oracle.com> wrote:

> Martin, All,
>
> The Release Candidates of JDK 18 have been released [1]. At this stage,
> only P1 issues will be evaluated [2]. And with the JDK 18 General
> Availability sets for March 22nd, it is now time to shift the focus to
> JDK 19. I'd like to thank those of you who have already provided
> feedback on the early Early Builds of JDK 19. Feedback is always
> extremely useful, even more, when it comes early in the development cycle.
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006404.html
> [2] https://openjdk.java.net/jeps/3
>
>
> ## JDK 18 Release Candidate
>
> The Release Candidate builds of JDK 18 are now available [3], and are
> provided under the GNU General Public License v2, with the Classpath
> Exception. The Release Notes are available here [4].
>
> [3] https://jdk.java.net/18/
> [4] https://jdk.java.net/18/release-notes
>
>
> ## JDK 19 Early-Access builds
>
> JDK 19 Early-Access builds 11 are now available [5], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> The Release Notes are available here [6].
>
> [5] https://jdk.java.net/19/
> [6] https://jdk.java.net/19/release-notes
>
> Recent changes that maybe of interest:
>
> * JDK-8278067: Make HttpURLConnection default keep alive timeout
> configurable
> * JDK-8281000: ClassLoader::registerAsParallelCapable throws NPE if
> caller is null
> * JDK-8282279: Interpret case-insensitive string locale independently
> * JDK-8176706: Support CLDR's Additional (Skeleton) Date-Time Formats
> * JDK-5041655: (ch) FileLock: negative param and overflow issues
> * JDK-8255266: Update Public Suffix List to 3c213aa
> * JDK-8280958: G1/Parallel: Unify marking code structure
> * JDK-8072070: Improve interpreter stack banging
> * JDK-8277175: Add a parallel multiply method to BigInteger
> * JDK-8278947: Support for array constants in constant table
> * JDK-8281462: Annotation toString output for enum not reusable for
> source input
> * JDK-8281175: Add a -providerPath option to jarsigner
> * JDK-8277795: ldap connection timeout not honoured under contention
> * JDK-8279842: HTTPS Channel Binding support for Java GSS/Kerberos
> * JDK-8280744: Allow SuppressWarnings to be used in all declaration
> contexts
> * JDK-8272984: javadoc support for reproducible builds
> * JDK-8272317: jstatd has dependency on Security Manager which needs to
> be removed
>
>
> ## New Project Loom Early-Access builds
>
> Project Loom Early-Access builds19-loom+4-115 (2022/2/13) are available
> [7] with the related Javadoc [8].
>
> These EA builds are based on JDK 19 (jdk-19+9). In those builds, the
> APIs for Structured Concurrency and Scope Locals have been moved into
> the `jdk.incubator.concurrent` incubator module. Note that the module
> name may change later. To use those APIs, simply use `--add-modules
> jdk.incubator.concurrent` at compile and runtime.
>
> Those EA builds are provided under the GNU General Public License,
> version 2, with the Classpath Exception and are produced for the purpose
> of gathering feedback. Use for any other purpose is at your own risk.
> Proper feedback should be sent to the `loom-dev` mailing list [9].
>
> [7] https://jdk.java.net/loom/
> [8] https://download.java.net/java/early_access/loom/docs/api/
> [9] https://mail.openjdk.java.net/mailman/listinfo/loom-dev
>
>
> ## Topics of Interest
>
> * JDK 18 - Card Table Card Size Shenanigans
> https://tschatzl.github.io/2022/02/15/card-table-card-size.html
> * Compiled & Tested Code In Javadoc - Inside Java Newscast #20
> https://inside.java/2022/02/10/insidejava-newscast-020/
> * New candidate JEP: 423: Region Pinning for G1
> https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006368.html
> * Refactoring Java 8 code with Java 17 new features - JEP Café #9
> https://inside.java/2022/02/01/jepcafe9/
>
>
>
> As always, let us know if you find any issues while testing your
> projects on the latest JDK Early Access builds. Thanks for your support!
>
> --David
>
>

Re: new 9.8.0 release

[Martin Grigorov]

On Wed, Feb 2, 2022 at 3:35 PM Ernesto Reinaldo Barreiro 
wrote:

> I haven't cherry-picked my PR for web sockets to mater yet... because I
> think cherrypick will not work as in master we are using Jakarta API
> instead of JAVAX.
>

Right!
The cherry-picking will fail with merge conflicts which you will have to
resolve, then git add, git commit && git push.



>
> On Wed, Feb 2, 2022 at 7:46 AM Martin Grigorov 
> wrote:
>
> > On Wed, Feb 2, 2022 at 1:34 PM Thomas Heigl  wrote:
> >
> > > Hi,
> > >
> > > My PR is merged as well. It only needs to be back-ported to 9.x.
> > >
> > > Martin, how do you usually do the back-porting? Simply cherry-pick the
> > > commit?
> > >
> >
> > Yes!
> > git cherry-pick -x [hash]
> >
> >
> >
> > >
> > > Best,
> > >
> > > Thomas
> > >
> > > On Tue, Feb 1, 2022 at 6:28 PM Andrea Del Bene 
> > > wrote:
> > >
> > > > On Tue, Feb 1, 2022 at 6:24 PM Thomas Heigl 
> > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I just created one minor performance related PR:
> > > > >
> > > > > https://github.com/apache/wicket/pull/497
> > > > >
> > > > > If we can wait one more day, I'd like to see it included in 9.8.0.
> > > > >
> > > >
> > > >  +1 me too!
> > > >
> > > >
> > > > >
> > > > > Best,
> > > > >
> > > > > Thomas
> > > > >
> > > > > On Tue, Feb 1, 2022 at 1:45 PM Ernesto Reinaldo Barreiro <
> > > > > reier...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Sat, Jan 29, 2022 at 6:27 AM Andrea Del Bene <
> > > an.delb...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I see there's WICKET-6950 in progress, so I will wait for it to
> > be
> > > > > > > finished, ok?
> > > > > > >
> > > > > >
> > > > > > Thanks for waiting. WICKET-6950 has landed in the 9.x branch.
> From
> > my
> > > > > side
> > > > > > we are ready to go.
> > > > > >
> > > > > > Thanks for taking care of releases!
> > > > > >
> > > > > > --
> > > > > > Regards - Ernesto Reinaldo Barreiro
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Andrea Del Bene.
> > > > Apache Wicket committer.
> > > >
> > >
> >
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>

Re: new 9.8.0 release

[Martin Grigorov]

On Wed, Feb 2, 2022 at 1:34 PM Thomas Heigl  wrote:

> Hi,
>
> My PR is merged as well. It only needs to be back-ported to 9.x.
>
> Martin, how do you usually do the back-porting? Simply cherry-pick the
> commit?
>

Yes!
git cherry-pick -x [hash]



>
> Best,
>
> Thomas
>
> On Tue, Feb 1, 2022 at 6:28 PM Andrea Del Bene 
> wrote:
>
> > On Tue, Feb 1, 2022 at 6:24 PM Thomas Heigl  wrote:
> >
> > > Hi,
> > >
> > > I just created one minor performance related PR:
> > >
> > > https://github.com/apache/wicket/pull/497
> > >
> > > If we can wait one more day, I'd like to see it included in 9.8.0.
> > >
> >
> >  +1 me too!
> >
> >
> > >
> > > Best,
> > >
> > > Thomas
> > >
> > > On Tue, Feb 1, 2022 at 1:45 PM Ernesto Reinaldo Barreiro <
> > > reier...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > On Sat, Jan 29, 2022 at 6:27 AM Andrea Del Bene <
> an.delb...@gmail.com>
> > > > wrote:
> > > >
> > > > > I see there's WICKET-6950 in progress, so I will wait for it to be
> > > > > finished, ok?
> > > > >
> > > >
> > > > Thanks for waiting. WICKET-6950 has landed in the 9.x branch. From my
> > > side
> > > > we are ready to go.
> > > >
> > > > Thanks for taking care of releases!
> > > >
> > > > --
> > > > Regards - Ernesto Reinaldo Barreiro
> > > >
> > >
> >
> >
> > --
> > Andrea Del Bene.
> > Apache Wicket committer.
> >
>

Re: [VOTE] Release Apache Wicket 8.14.0

[Martin Grigorov]

+1 to release

Tested local build and various examples

On Sat, Jan 29, 2022 at 6:00 PM Andrea Del Bene 
wrote:

> This is a vote to release Apache Wicket 8.14.0
>
> Please download the source distributions found in our staging area
> linked below.
>
> I have included the signatures for both the source archives. This vote
> lasts for 72 hours minimum.
>
> [ ] Yes, release Apache Wicket 8.14.0
> [ ] No, don't release Apache Wicket 8.14.0, because ...
>
> Distributions, changelog, keys and signatures can be found at:
>
>  https://dist.apache.org/repos/dist/dev/wicket/8.14.0
>
> Staging repository:
>
> https://repository.apache.org/content/repositories/orgapachewicket-1169
>
> The binaries are available in the above link, as are a staging
> repository for Maven. Typically the vote is on the source, but should
> you find a problem with one of the binaries, please let me know, I can
> re-roll them some way or the other.
>
> Staging git repository data:
>
>  Repository:  g...@github.com:bitstorm/wicket.git
>  Branch:  build/wicket-8.14.0
>  Release tag: rel/wicket-8.14.0
>
>
> 
>
>  The signatures for the source release artefacts:
>
>
> Signature for apache-wicket-8.14.0.zip:
>
>  -BEGIN PGP SIGNATURE-
>
> iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAmH1X3QACgkQh48B+qjT
> VuGPnhAArxTlotpVmY/L4MPJ9cdHomvdSa/CoyLwUyGI/eg5DNnMvS369X4wnb92
> X3h/TAc4/U1to5yacqFu3/wcyZYwXKsUcLRx7UH840NaRJDyiJERvOT6b60CGXBG
> NW7gPF80dpuSoeP2qqIegGF8EZF2ujt2cMmOQadWBTad+S5Dc3zH2vsEFGm3rv/l
> awb9I/PjgcCaX8YLvcYh2eOLd5+05AI90R1rx7g/yY9/PvoRgFi4mRnfzMzWDhu9
> iuf8I2lHjIo4OzHoMzWoilCuiRzzQbUnhx9vL5OT7nNtJs8+SrrwDF4tz8f8r9F/
> n0GMuY9fhzzDkEmIE8Tw2T8ukL0GJrVnYZio25bTTtXfsO8Ub5R/pllSuIkPoyph
> gkDZp4eQnpuamolxEH4uls81Y06LRch7ji+Db+QLcroodLYGWAOvMpeMMDHLKxME
> 8NVZe/pqHzsIbJeyTjSpsKxuBQ7Fc2vnsckZW79siXRZaeFK+dMGesGeF9TQtNeq
> g9R7I1vu65dXJ4gHPMsmGZrolUEH41z1aTHRYc8RXMQ/L6XRIX9U/sG2/XfR/7uC
> qgcnefJPhgmXOwYKosMwyxpUnz31MwLhYW5TXFV9TcRIvOvBbo3Q5ZjsR8WYrmG0
> iWtm6biS8MxnJHTV6TZgB2m3k8CrQM4zJ+ZUDNMVPBNl8rd3UOk=
> =4xUM
> -END PGP SIGNATURE-
>
> Signature for apache-wicket-8.14.0.tar.gz:
>
>  -BEGIN PGP SIGNATURE-
>
> iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAmH1X3QACgkQh48B+qjT
> VuGyHg/+OQ5Mr3kzwN180JbygHOPqmU3nVjG6NdcC45oyrlgnDcmzPxTh4apwRxY
> Bbo60kXXO2kyaIqk//H8F074r1GSlMzCQLRAswn5dbakatf9eE0Nl0wEaSLQDCVC
> 3/POMo4KzcWF63mqOQpKXrIFi8ztjmi9qgfzPN+vCNka37V65UBLtGbU2UZc4yrY
> Rtx19b4xFtNieisd+R47ESei91FyKNBeIOrCXCMaULAs/vb3oQpKBwMO8biR4ofm
> c/qXsYWtNR499zoNCMMO0auojDeQ0y4d1T3aAxqU90lN8b0JUWciG5tQ7uDCi7V3
> 9SRK5Sr4FyBFnhLu7+uVNaAhLyWFkGKYQuhmGsePQpRTisb15xPEX3lV5JK/1WLm
> Iae3tYL7ZAOHDtCnUY/8QwGdN+OzrYovN/f1p2chqsfJCzDEpFjso7zQHqnEoChK
> ffKEFqO0wuyDQTZjmF6Qh5Wkqvn6psiG7ECm0/9+FfkGtcbz9t62RQhEC+13lhl4
> QbTj7vUeXIBaNbMyBV62is+SQDnH4KE6dNy+bfjbGtxn9gyejZ8x0jJO23hqhW1N
> ab8aF8xsMQEAmxwN1rfKcy78luPRaozkypL359/1lgAgSf2fGaPNSyF3aelS9aZ+
> y2X03dHmTeTaDLPNolObTAFQJHjU2EhiuQ4v1x+6ySO4Dh6dYK4=
> =hseu
> -END PGP SIGNATURE-
>
> 
>
>  CHANGELOG for 8.14.0:
>
> ** Bug
>
>  * [WICKET-6908] - Possible bug / edge case where page is not detached
>  * [WICKET-6910] - StalePageException not thrown
>  * [WICKET-6914] - Visibility change of "File Upload" via ajax
> causes "missing" form-data
>  * [WICKET-6931] - User guide: 'determinate' is not a verb; should
> be changed into 'to determine'
>  * [WICKET-6944] - Memory leak in WicketEndpoint
>  * [WICKET-6945] - MultipartFormComponentListener modifies enctype
> on invisible forms, leading to javascript errors
>
> ** Task
>
>  * [WICKET-6919] - Improve EnclosureContainer's javadoc to explain
> that it should not be used with 
>  * [WICKET-6937] - Update the keystore used by the quickstart
> application
>  * [WICKET-6942] - Replace usage of log4j 1.x in tests and
> wicket-examples with slf4j-simple
>
>

Re: JDK 18 Rampdown Phase 2 & JDK 19 Early-Access Builds

[Martin Grigorov]

Hi David,

Apache Wicket's build and tests pass successfully with JDK 18-ea+33-2077
and 19-ea+7-366 on both Linux x86_64 and aarch64!

Regards,
Martin

On Mon, Jan 31, 2022 at 11:33 AM David Delabassee <
david.delabas...@oracle.com> wrote:

> Greetings!
>
> First off, on behalf of Oracle’s Java Team, I’d like to wish you a happy
> and prosperous new year!
>
> In 2022, two Java releases will be made available:
> - JDK 18 (March 2022)
> - JDK 19 (September 2022)
>
> JDK 18[1] has entered Rampdown Phase Two (RDP2)[2]. Given that and to be
> better prepared for the future, it makes sense to begin testing your
> project(s) using early access (EA) builds of JDK 19[3]. Your feedback
> allows us to evaluate and address issues you find while testing EA builds.
>
> This time, we have two heads-up to share:
>
> ## Heads-Up: JDK 18 - JEP 421 Deprecate Finalization for Removal
>
> Finalization is an outdated and brittle resource cleaning mechanism
> present in the platform since, well, forever. Its use has been
> discouraged for quite some time in favor of better alternatives (i.e.,
> 'try with resources' and Cleaners). JEP 421 is another step towards the
> removal of finalizers as it offers tools to investigate if a codebase is
> still using finalization. To learn more, you should read JEP 421[4]. You
> should also listen to the latest episode of the Inside Java Podcast[5]
> dedicated to this topic. We encourage you to check if your project is
> still using finalizers. If so, you should start to think about removing
> them and rely instead on either 'try with resources' or Cleaners.
>
> ## Heads-Up: JVM does not flag constant class entries ending in '/'
>
> Prior to JDK 19, the JVM is loading classes (1) whose class file major
> version is <49, i.e., before JDK 1.5, and (2) the class's name ends with
> a '/'. This violates section 4.2.1 of the JVM specification [6] and is
> addressed in JDK 19. In JDK 19, the JVM is throwing, for such classes, a
> ClassFormatError exception as it already does with newer classes (JDK
> 1.5+). Given that this issue affects only pre-JDK 1.5 classes, we expect
> the compatibility risk to be very low.
>
> For more details, see JDK-8278448[7].
>
> [1] https://jdk.java.net/18/
> [2]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2022-January/006361.html
> [3] https://jdk.java.net/19/
> [4] https://openjdk.java.net/jeps/421
> [5] https://inside.java/podcast/21
> [6]
> https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.2.1
> [7] https://bugs.openjdk.java.net/browse/JDK-8278448
>
>
> ## JDK 18
>
> JDK 18 is now in RDP2 (Rampdown Phase Two) with its feature set frozen a
> few weeks back when it entered RDP1.
>
> ### JEPs integrated to JDK 18:
>
> - JEP 400: UTF-8 by Default
> - JEP 408: Simple Web Server
> - JEP 413: Code Snippets in Java API Documentation
> - JEP 416: Reimplement Core Reflection with Method Handles
> - JEP 417: Vector API (Third Incubator)
> - JEP 418: Internet-Address Resolution SPI
> - JEP 419: Foreign Function & Memory API (Second Incubator)
> - JEP 420: Pattern Matching for switch (Second Preview)
> - JEP 421: Deprecate Finalization for Removal
>
> JDK 18 Early-Access builds 33 are now available[8], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> Also available are the Release Notes[9].
>
> [8] https://jdk.java.net/18/
> [9] https://jdk.java.net/18/release-notes
>
> ### Changes in JDK 18 since Rampdown Phase One that are of interest:
>
> - JDK-8278373: Correcting References to Overloaded Methods in Javadoc
> Documentation
> - JDK-8279065: Deserialization filter and filter factory property error
> reporting under specified
> - JDK-8255409: SunPKCS11 Provider Now Supports Some PKCS#11 v3.0 APIs
> - JDK-8275610: C2: Object field load floats above its null check
> resulting in a segfault [Reported by Apache POI]
>
>
> ## JDK 19
>
> JDK 19 Early-Access builds 7 are now available[10], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> Also available are the Release Notes[11].
>
> [10] https://jdk.java.net/19/
> [11] https://jdk.java.net/19/release-notes
>
> ### Changes in recent JDK 19 EA builds that maybe of interest:
>
> - JDK-8279258: Auto-vectorization enhancement for two-dimensional array
> operations
> - JDK-8273914: Indy string concat changes order of operations
> - JDK-8268081: Upgrade Unicode Data Files to 14.0.0
> - JDK-8278087: Deserialization filter and filter factory property error
> reporting under specified
> - JDK-8276766: Enable jar and jmod to produce deterministic timestamped
> content
> - JDK-8274679: Remove unnecessary conversion to String in security code
> in java.base
> - JDK-8279833: Loop optimization issue in String.encodeUTF8_UTF16
> - JDK-8279064: New options for ktab to provide non-default salt
> - JDK-8280055: JFR: Improve ObjectContext implementation
> - JDK-8268831: Improve javadoc tool handling of streams
>
>
> ## Topics of Interest:
>
> - "

Re: CI for wicketstuff

[Martin Grigorov]

I've merged the PR!

But it failed because there are no env vars/secrets for deploying to
oss.sonatype.org
Travis was using
https://github.com/wicketstuff/core/blob/b3f84bb0f49f1ebee8eec5100cb31b22176d5a4b/.travis.yml#L22-L26
If anyone knows what were those credentials then please set them up at
https://github.com/wicketstuff/core/settings/secrets/actions with names
CI_DEPLOY_USERNAME and CI_DEPLOY_PASSWORD (
https://github.com/wicketstuff/core/blob/b3f84bb0f49f1ebee8eec5100cb31b22176d5a4b/.github/workflows/ci.yml#L54-L56
)
Otherwise we could run just 'mvn verify'

On Fri, Jan 14, 2022 at 9:51 AM Martin Grigorov 
wrote:

>
>
> On Fri, Jan 14, 2022 at 9:32 AM Maxim Solodovnik 
> wrote:
>
>> On Thu, 13 Jan 2022 at 10:29, Maxim Solodovnik 
>> wrote:
>> >
>> > I'm +1 for any solution :)
>> > I can ask INFRA if we can use Jenkins :)
>> >
>> > On Thu, 13 Jan 2022 at 02:47, Martin Grigorov 
>> wrote:
>> > >
>> > > Shall we move to Github Actions ?
>>
>> Are you familiar with "Github Actions"
>> Maybe you can set it up and we will see how it will suit our needs :)
>>
>
> No problemo! :-)
>
>
>>
>> > > TravisCI degrades day by day :-(
>> > > CircleCI is also a very good alternative!
>> > >
>> > > On Wed, Jan 12, 2022 at 6:52 PM Maxim Solodovnik <
>> solomax...@gmail.com>
>> > > wrote:
>> > >
>> > > > Hello All,
>> > > >
>> > > > Maybe you know what is the current status of CI for wicketstuff
>> > > >
>> > > > I was unable to find latest snapshot
>> > > > And the job at travis-ci.com :(
>> > > >
>> > > > from mobile (sorry for typos ;)
>> > > >
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Maxim
>>
>>
>>
>> --
>> Best regards,
>> Maxim
>>
>

Re: CI for wicketstuff

[Martin Grigorov]

On Fri, Jan 14, 2022 at 9:32 AM Maxim Solodovnik 
wrote:

> On Thu, 13 Jan 2022 at 10:29, Maxim Solodovnik 
> wrote:
> >
> > I'm +1 for any solution :)
> > I can ask INFRA if we can use Jenkins :)
> >
> > On Thu, 13 Jan 2022 at 02:47, Martin Grigorov 
> wrote:
> > >
> > > Shall we move to Github Actions ?
>
> Are you familiar with "Github Actions"
> Maybe you can set it up and we will see how it will suit our needs :)
>

No problemo! :-)


>
> > > TravisCI degrades day by day :-(
> > > CircleCI is also a very good alternative!
> > >
> > > On Wed, Jan 12, 2022 at 6:52 PM Maxim Solodovnik  >
> > > wrote:
> > >
> > > > Hello All,
> > > >
> > > > Maybe you know what is the current status of CI for wicketstuff
> > > >
> > > > I was unable to find latest snapshot
> > > > And the job at travis-ci.com :(
> > > >
> > > > from mobile (sorry for typos ;)
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Maxim
>
>
>
> --
> Best regards,
> Maxim
>

Re: CI for wicketstuff

[Martin Grigorov]

Shall we move to Github Actions ?
TravisCI degrades day by day :-(
CircleCI is also a very good alternative!

On Wed, Jan 12, 2022 at 6:52 PM Maxim Solodovnik 
wrote:

> Hello All,
>
> Maybe you know what is the current status of CI for wicketstuff
>
> I was unable to find latest snapshot
> And the job at travis-ci.com :(
>
> from mobile (sorry for typos ;)
>

Re: Use non-final dependencies in master branch ?!

[Martin Grigorov]

Merged them!
Thank you!

On Wed, Dec 22, 2021 at 12:44 PM Andrea Del Bene 
wrote:

> +1 for merging
>
> On Wed, Dec 22, 2021 at 10:50 AM Maxim Solodovnik 
> wrote:
>
> > +1
> > hopefully final versions will be released soon :)
> >
> > On Wed, 22 Dec 2021 at 16:20, Sven Meier  wrote:
> > >
> > > +1 for merging
> > >
> > > Sven
> > >
> > >
> > > On 22.12.21 09:53, Martin Grigorov wrote:
> > > > Hi,
> > > >
> > > > What do you think about merging
> > > > - https://github.com/apache/wicket/pull/486 - use
> commons-fileupload2
> > > > 2.0-SNAPSHOT
> > > > - https://github.com/apache/wicket/pull/487 - use Spring 6.0.0-M1
> > (Java 17!)
> > > >
> > > > This way only wicket-cdi (Weld & cdi-unit) still needs the temporary
> > javax
> > > > hack.
> > > >
> > > > Martin
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Maxim
> >
>
>
> --
> Andrea Del Bene.
> Apache Wicket committer.
>

Re: CI status

[Martin Grigorov]

On Wed, Dec 22, 2021 at 4:21 PM Martin Grigorov 
wrote:

> Hi Andrea,
>
> I maintain Github Actions and Buildbot.
> Buildbot has been updated recently from ver. 0.8 to 3.x. The new url is
> https://ci2.apache.org/#/builders. There are several builders for
> different JDKs. Yesterday I removed wicket-9.x-java16 from the config. I
> guess it will disappear once we push something to 9.x.
>

The Buildbot config is at
https://github.com/apache/infrastructure-bb2/blob/master/wicket.py


>
> At the moment on Buildbot uploads javadocs and guide to
> https://nightlies.apache.org/wicket/
> That reminds me we need to update the site to point the new location.
>

Done!


>
> Maxim has setup the Jenkins job.
> From time to time it fails on the JS tests for some reason but I didn't
> spend time on debugging why.
>
> On Wed, Dec 22, 2021 at 3:55 PM Andrea Del Bene 
> wrote:
>
>> Sorry but I've lost track about it. Which platform are we "actually" using
>> for CI? I guess we still use Apache buildbot, but lately it seems not to
>> be
>> triggered when we commit something: it's stuck since October.
>> Earlier this year I've started paling with Apache Jenkins which is still
>> active, but I don't know if someone is actually using it. Martin is using
>> GitHub CI support but I don't think it performs tasks like updating
>> javadoc
>> or user guide.
>>
>> ...
>>
>> --
>> Andrea Del Bene.
>> Apache Wicket committer.
>>
>

Re: CI status

[Martin Grigorov]

Hi Andrea,

I maintain Github Actions and Buildbot.
Buildbot has been updated recently from ver. 0.8 to 3.x. The new url is
https://ci2.apache.org/#/builders. There are several builders for different
JDKs. Yesterday I removed wicket-9.x-java16 from the config. I guess it
will disappear once we push something to 9.x.

At the moment on Buildbot uploads javadocs and guide to
https://nightlies.apache.org/wicket/
That reminds me we need to update the site to point the new location.

Maxim has setup the Jenkins job.
>From time to time it fails on the JS tests for some reason but I didn't
spend time on debugging why.

On Wed, Dec 22, 2021 at 3:55 PM Andrea Del Bene 
wrote:

> Sorry but I've lost track about it. Which platform are we "actually" using
> for CI? I guess we still use Apache buildbot, but lately it seems not to be
> triggered when we commit something: it's stuck since October.
> Earlier this year I've started paling with Apache Jenkins which is still
> active, but I don't know if someone is actually using it. Martin is using
> GitHub CI support but I don't think it performs tasks like updating javadoc
> or user guide.
>
> ...
>
> --
> Andrea Del Bene.
> Apache Wicket committer.
>

Use non-final dependencies in master branch ?!

[Martin Grigorov]

Hi,

What do you think about merging
- https://github.com/apache/wicket/pull/486 - use commons-fileupload2
2.0-SNAPSHOT
- https://github.com/apache/wicket/pull/487 - use Spring 6.0.0-M1 (Java 17!)

This way only wicket-cdi (Weld & cdi-unit) still needs the temporary javax
hack.

Martin

Re: JDK 18: Rampdown Phase 1 & Early-Access builds 27

[Martin Grigorov]

On Fri, Dec 10, 2021 at 10:10 AM Martin Grigorov 
wrote:

> Hi David,
>
> Apache Wicket build and tests pass successfully with JDK 8-ea+27-1924 on
> both Linux x86_64 and aarch64!
>

I meant 18-ea+27-1924


>
> Regards,
> Martin
>
> On Fri, Dec 10, 2021 at 9:58 AM David Delabassee <
> david.delabas...@oracle.com> wrote:
>
>> Martin,
>>
>> Thank you for being part of the OpenJDK Quality Outreach Program. As
>> year-end 2021 approaches, I'd like to share some updates on JDK 18,
>> which is scheduled for General Availability on March 22, 2022.
>>
>> JDK 18 has now entered Rampdown Phase One (RDP1) [1], which means that
>> the main-line has been forked into a dedicated JDK 18 stabilization
>> repository. At this point, the overall JDK 18 feature set is now frozen
>> and no additional JEPs will be targeted to JDK 18. Only low-risk
>> enhancements that add small bits of missing functionality or improve
>> usability might still be considered. The next few weeks should be
>> leveraged to try to identify and resolve as many issues as possible
>> (i.e. before JDK 18 enters the Release Candidates phase).
>>
>> And as you can see below, JDK 18 EA Builds 26 & 27 include fixes for
>> issues that were reported by you! So thank you for your help
>> contributing to the overall quality of OpenJDK!
>>
>> [1]
>> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006287.html
>>
>>
>> ## JEP 400 - UTF-8 by Default
>>
>> All JEPs are now integrated, but we would like to draw your attention to
>> JEP 400 especially if you are deploying on Windows as it might induce
>> some incompatible behavior on that platform.
>>
>> JEP 400 [2] is changing the default charset to UTF-8. This aligns with
>> the existing `newBufferedReader`/`Writer` methods of the
>> `java.nio.file.Files` class where UTF-8 is the default when no explicit
>> charset is set. By making UTF-8 the default charset, the JDK I/O APIs
>> will now always work in the same, predictable manner, with no need to
>> pay attention to the host and or user’s environment!
>>
>> Further, we encourage you to test your project(s) with the latest JDK 18
>> Early Access builds. We don't expect issues on macOS and Linux as their
>> default encoding is already UTF-8. On Windows, especially for East Asian
>> locales such as Chinese/Japanese/Korean, some incompatible behavior
>> could be anticipated. If that’s the case, please consider a mitigation
>> strategy [3].
>>
>> [2] https://openjdk.java.net/jeps/400
>> [3] https://inside.java/2021/10/04/the-default-charset-jep400/
>>
>>
>> ## JDK 18
>>
>> JDK 18 Early-Access builds 27 are now available [4], and are provided
>> under the GNU General Public License v2, with the Classpath Exception.
>> Make sure to check the Release Notes [5]. As usual, we encourage you to
>> test your project(s) using those EA builds and provide us feedback.
>>
>> [4] https://jdk.java.net/18/
>> [5] https://jdk.java.net/18/release-notes
>>
>> ### JEPs integrated to JDK 18:
>>
>> - JEP 400: UTF-8 by Default
>> - JEP 408: Simple Web Server
>> - JEP 413: Code Snippets in Java API Documentation
>> - JEP 416: Reimplement Core Reflection with Method Handles
>> - JEP 417: Vector API (Third Incubator)
>> - JEP 418: Internet-Address Resolution SPI
>> - JEP 419: Foreign Function & Memory API (Second Incubator)
>> - JEP 420: Pattern Matching for switch (Second Preview)
>> - JEP 421: Deprecate Finalization for Removal
>>
>> ### Changes in recent builds that maybe of interest:
>>
>>  Build 27:
>>
>> - JDK-8266435: WBMPImageReader.read() should not truncate the input
>> stream [Reported by PDFBox]
>> - JDK-8278078: Cannot reference super before supertype constructor has
>> been called
>> - JDK-8177819: DateTimeFormatterBuilder zone parsing should recognise DST
>> - JDK-8277965: Enclosing instance optimization affects serialization
>> - JDK-8275821: Optimize random number generators developed in
>> JDK-8248862 using Math.unsignedMultiplyHigh()
>> - JDK-8225181: KeyStore should have a getAttributes method
>> - JDK-8275082: Update XML Security for Java to 2.3.0
>> - JDK-8278270: ServerSocket is not thread safe
>> - JDK-8277863: Deprecate sun.misc.Unsafe methods that return offsets
>>
>>  Build 26:
>>
>> - JDK-8277451: j.l.r.Field::set on static field with invalid argument
>> type should throw IAE [Reported by Hibernate & ByteBuddy]
>> - JDK-8258117: jar tool sets 

Re: JDK 18: Rampdown Phase 1 & Early-Access builds 27

[Martin Grigorov]

Hi David,

Apache Wicket build and tests pass successfully with JDK 8-ea+27-1924 on
both Linux x86_64 and aarch64!

Regards,
Martin

On Fri, Dec 10, 2021 at 9:58 AM David Delabassee <
david.delabas...@oracle.com> wrote:

> Martin,
>
> Thank you for being part of the OpenJDK Quality Outreach Program. As
> year-end 2021 approaches, I'd like to share some updates on JDK 18,
> which is scheduled for General Availability on March 22, 2022.
>
> JDK 18 has now entered Rampdown Phase One (RDP1) [1], which means that
> the main-line has been forked into a dedicated JDK 18 stabilization
> repository. At this point, the overall JDK 18 feature set is now frozen
> and no additional JEPs will be targeted to JDK 18. Only low-risk
> enhancements that add small bits of missing functionality or improve
> usability might still be considered. The next few weeks should be
> leveraged to try to identify and resolve as many issues as possible
> (i.e. before JDK 18 enters the Release Candidates phase).
>
> And as you can see below, JDK 18 EA Builds 26 & 27 include fixes for
> issues that were reported by you! So thank you for your help
> contributing to the overall quality of OpenJDK!
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006287.html
>
>
> ## JEP 400 - UTF-8 by Default
>
> All JEPs are now integrated, but we would like to draw your attention to
> JEP 400 especially if you are deploying on Windows as it might induce
> some incompatible behavior on that platform.
>
> JEP 400 [2] is changing the default charset to UTF-8. This aligns with
> the existing `newBufferedReader`/`Writer` methods of the
> `java.nio.file.Files` class where UTF-8 is the default when no explicit
> charset is set. By making UTF-8 the default charset, the JDK I/O APIs
> will now always work in the same, predictable manner, with no need to
> pay attention to the host and or user’s environment!
>
> Further, we encourage you to test your project(s) with the latest JDK 18
> Early Access builds. We don't expect issues on macOS and Linux as their
> default encoding is already UTF-8. On Windows, especially for East Asian
> locales such as Chinese/Japanese/Korean, some incompatible behavior
> could be anticipated. If that’s the case, please consider a mitigation
> strategy [3].
>
> [2] https://openjdk.java.net/jeps/400
> [3] https://inside.java/2021/10/04/the-default-charset-jep400/
>
>
> ## JDK 18
>
> JDK 18 Early-Access builds 27 are now available [4], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> Make sure to check the Release Notes [5]. As usual, we encourage you to
> test your project(s) using those EA builds and provide us feedback.
>
> [4] https://jdk.java.net/18/
> [5] https://jdk.java.net/18/release-notes
>
> ### JEPs integrated to JDK 18:
>
> - JEP 400: UTF-8 by Default
> - JEP 408: Simple Web Server
> - JEP 413: Code Snippets in Java API Documentation
> - JEP 416: Reimplement Core Reflection with Method Handles
> - JEP 417: Vector API (Third Incubator)
> - JEP 418: Internet-Address Resolution SPI
> - JEP 419: Foreign Function & Memory API (Second Incubator)
> - JEP 420: Pattern Matching for switch (Second Preview)
> - JEP 421: Deprecate Finalization for Removal
>
> ### Changes in recent builds that maybe of interest:
>
>  Build 27:
>
> - JDK-8266435: WBMPImageReader.read() should not truncate the input
> stream [Reported by PDFBox]
> - JDK-8278078: Cannot reference super before supertype constructor has
> been called
> - JDK-8177819: DateTimeFormatterBuilder zone parsing should recognise DST
> - JDK-8277965: Enclosing instance optimization affects serialization
> - JDK-8275821: Optimize random number generators developed in
> JDK-8248862 using Math.unsignedMultiplyHigh()
> - JDK-8225181: KeyStore should have a getAttributes method
> - JDK-8275082: Update XML Security for Java to 2.3.0
> - JDK-8278270: ServerSocket is not thread safe
> - JDK-8277863: Deprecate sun.misc.Unsafe methods that return offsets
>
>  Build 26:
>
> - JDK-8277451: j.l.r.Field::set on static field with invalid argument
> type should throw IAE [Reported by Hibernate & ByteBuddy]
> - JDK-8258117: jar tool sets the time stamp of module-info.class entries
> to the current time [Reported by Apache Maven]
> - JDK-8268743: Require a better way for copying data between
> MemorySegments and on-heap arrays [Reported by Apache Lucene]
> - JDK-8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime
> [Reported by Apache Ant]
> - JDK-8277861: Terminally deprecate Thread.stop
> - JDK-8276665: ObjectInputStream.GetField.get(name, object) should throw
> ClassNotFoundException
> - JDK-8271623: Omit enclosing instance fields from inner classes that
> don't use it
> - JDK-8231107: Allow store password to be null when saving a PKCS12
> KeyStore
> - JDK-8193682: Infinite loop in ZipOutputStream.close()
> - JDK-8277459: Add `jwebserver` tool [see Topics of Interest]
>
>  Build 25:
>
> - JDK-8259643: ZGC can return me

Re: rolling out wicket 9.7.0?

[Martin Grigorov]

On Thu, Nov 25, 2021 at 9:29 AM Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi,
>
> Who can do the keystore changes?
>

Done with https://issues.apache.org/jira/browse/WICKET-6937


>
> On Wed, Nov 24, 2021 at 2:21 PM Martin Grigorov 
> wrote:
>
> > On Wed, Nov 24, 2021 at 1:11 PM Andrea Del Bene 
> > wrote:
> >
> > > +1 to release. Even if the current one still quite fresh I think we can
> > go
> > > ahead with the next release, after WICKET-6934
> > > <https://issues.apache.org/jira/browse/WICKET-6934> has been solved.
> > >
> >
> > WICKET-6934 has been removed from 9.7.0
> > The only known issue is the expired keystore for the quickstart app.
> >
> >
> > >
> > > On Tue, Nov 23, 2021 at 12:25 PM Maxim Solodovnik <
> solomax...@gmail.com>
> > > wrote:
> > >
> > > > 9.4.44 is the latest version :)
> > > >
> > > > On Tue, 23 Nov 2021 at 18:16, Sebastien Briquet  >
> > > > wrote:
> > > > >
> > > > > Just got this automatic PR for wicket-jquery-ui, following the
> > upgrade
> > > to
> > > > > the same version than in wicket quickstart. Maybe it is worth to
> > > upgrade
> > > > in
> > > > > the wicket quickstart too to prevent security checks
> warning/reports
> > to
> > > > be
> > > > > raised...
> > > > >
> > > > > [sebfz1/wicket-jquery-ui] Bump jetty-webapp from 9.4.42.v20210604
> to
> > > > > 9.4.43.v20210629 in /wicket-jquery-ui-samples (PR #340)
> > > > >
> > > > > This automated pull request fixes a security vulnerability
> (moderate
> > > > > severity).
> > > > >
> > > > > Best regards,
> > > > > Sébastien
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Maxim
> > > >
> > >
> > >
> > > --
> > > Andrea Del Bene.
> > > Apache Wicket committer.
> > >
> >
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>

Re: rolling out wicket 9.7.0?

[Martin Grigorov]

On Wed, Nov 24, 2021 at 1:11 PM Andrea Del Bene 
wrote:

> +1 to release. Even if the current one still quite fresh I think we can go
> ahead with the next release, after WICKET-6934
>  has been solved.
>

WICKET-6934 has been removed from 9.7.0
The only known issue is the expired keystore for the quickstart app.


>
> On Tue, Nov 23, 2021 at 12:25 PM Maxim Solodovnik 
> wrote:
>
> > 9.4.44 is the latest version :)
> >
> > On Tue, 23 Nov 2021 at 18:16, Sebastien Briquet 
> > wrote:
> > >
> > > Just got this automatic PR for wicket-jquery-ui, following the upgrade
> to
> > > the same version than in wicket quickstart. Maybe it is worth to
> upgrade
> > in
> > > the wicket quickstart too to prevent security checks warning/reports to
> > be
> > > raised...
> > >
> > > [sebfz1/wicket-jquery-ui] Bump jetty-webapp from 9.4.42.v20210604 to
> > > 9.4.43.v20210629 in /wicket-jquery-ui-samples (PR #340)
> > >
> > > This automated pull request fixes a security vulnerability (moderate
> > > severity).
> > >
> > > Best regards,
> > > Sébastien
> >
> >
> >
> > --
> > Best regards,
> > Maxim
> >
>
>
> --
> Andrea Del Bene.
> Apache Wicket committer.
>

Re: rolling out wicket 9.7.0?

[Martin Grigorov]

On Tue, Nov 23, 2021 at 10:12 AM Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi,
>
> What do you think about rolling outwicket 9.7.0?
>
>
9.6.0 has been released at Nov 2nd

Here is the list of issues for 9.7.0:
https://issues.apache.org/jira/projects/WICKET/versions/12350748
One of them is still In Progress -
https://issues.apache.org/jira/browse/WICKET-6934. Either remove its "Fix
Version" value or improve it.


> I have added, with the help of Matin, some improvements to WEB sockets that
> it would be nice if I can use for our next release :-) As well as some
> minor changes to datatable and the fix Sven added for PageFileStore.
>
> --
> Regards - Ernesto Reinaldo Barreiro
>

Re: rolling out wicket 9.7.0?

[Martin Grigorov]

Hi,

On Tue, Nov 23, 2021 at 10:48 AM Sebastien Briquet 
wrote:

> Hi Ernesto,
>
> Then it might be good to add a new keystore to the quickstart ; the
> existing one seems to have expired a couple of weeks ago...
>

+1 to fix this issue!


>
> Thanks and best regards,
> Sébastien
>

Re: JDK 18 Early-Access builds 23 are available

[Martin Grigorov]

Hi David,

I have already tested JDK 18 b23 and reported the only issue I've found:
https://github.com/openjdk/jdk/pull/5027#issuecomment-968177213

I've reworked Wicket's test to conform to the new rules and now the build
and tests pass successfully on both Linux x86_64 and aarch64!

Regards,
Martin

On Tue, Nov 16, 2021 at 1:09 PM  wrote:

> Hi Martin,
>
> I’m happy to announce that moving forward Oracle’s Java DevRel Team will
> manage the Quality Outreach Program. I would like to thank Rory for all
> the efforts he's put into this program and wish him all the joy and
> happiness that retirement can bring! We have big shoes to fill but we’re
> excited to continue building off the amazing structure Rory has put in
> place.
>
>
> The JDK 18 schedule is now known [1] with a feature freeze date
> (Rampdown Phase One) less than 4 weeks away! This time, we have 2
> important heads-ups, one related to JEP 411 (Deprecate the Security
> Manager for Removal), and one related to JEP 416 (Reimplement Core
> Reflection with Method Handles). We're asking your help to test and
> confirm that your project works seamlessly now that those 2 JEPs are
> integrated in the JDK 18 Early-Access builds.
>
> [1] https://openjdk.java.net/projects/jdk/18/
>
>
> # JEP 411 - Deprecate the Security Manager for Removal
>
> Starting JDK 18 b21 [2], the default value of the
> 'java.security.manager' system property is set to "disallow". This means
> that any application or library that enables the Security Manager by
> calling `System.setSecurityManager` will now have to specify
> `-Djava.security.manager=allow` on the command-line in order for that
> code to continue working as expected. This change was originally
> targeted for JDK 17, but after some discussion/feedback from the
> community, the change was delayed until JDK 18 [3].
>
> [2] https://bugs.openjdk.java.net/browse/JDK-8270380
> [3] https://openjdk.java.net/jeps/411#Description
>
>
> # JEP 416 - Reimplement Core Reflection with Method Handles
>
> JEP 416 [4] reimplements `java.lang.reflect.Method`,
> `java.lang.reflect.Constructor`, and `java.lang.reflect.Field` on top of
> `java.lang.invoke` method handles. Making method handles the underlying
> mechanism for reflection will reduce the maintenance and development
> cost of both the `java.lang.reflect` and `java.lang.invoke` APIs. This
> is solely an implementation change but we encourage you to test your
> project to identify any behavior or performance regressions.
>
> [4] https://openjdk.java.net/jeps/416
>
>
> OpenJDK 18 Early-Access builds 23 are now available [5], and are
> provided under the GNU General Public License v2, with the Classpath
> Exception. The Release Notes are available [6].
>
> [5] https://jdk.java.net/18/
> [6] https://jdk.java.net/18/release-notes
>
>
> # JEPs integrated to JDK 18, so far:
>
> - JEP 400: UTF-8 by Default https://openjdk.java.net/jeps/400
> - JEP 408: Simple Web Server https://openjdk.java.net/jeps/408
> - JEP 413: Code Snippets in Java API Documentation
> https://openjdk.java.net/jeps/413
> - JEP 416: Reimplement Core Reflection with Method Handles
> https://openjdk.java.net/jeps/416
> - JEP 418: Internet-Address Resolution SPI
> https://openjdk.java.net/jeps/418
>
>
> # JEPs targeted to JDK 18, so far:
>
> - JEP 417: Vector API (Third Incubator) https://openjdk.java.net/jeps/417
>
>
> # JEPs proposed to target JDK 18, so far:
>
> - JEP 419: Foreign Function & Memory API (Second Incubator)
> https://openjdk.java.net/jeps/419
> - JEP 420: Pattern Matching for switch (Second Preview)
> https://openjdk.java.net/jeps/420
>
>
> # Changes in recent builds that maybe of interest:
>
> ## Build 23:
>
> - JDK-8275509: ModuleDescriptor.hashCode isn't reproducible across builds
> - JDK-8276220: Reduce excessive allocations in DateTimeFormatter
> - JDK-8276298: G1: Remove unused G1SegmentedArrayBufferList::add
> - JDK-8273922: (fs) UserDefinedFileAttributeView doesn't handle file
> names that are just under the MAX_PATH limit (win)
>
> ## Build 22:
>
> - JDK-8271820: Implementation of JEP 416: Reimplement Core Reflection
> with Method Handle
> - JDK-8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
> implementations
> - JDK-8251468: X509Certificate.get{Subject,Issuer}AlternativeNames and
> getExtendedKeyUsage do not throw CertificateParsingException if
> extension is unparseable
>
> ## Build 21:
>
> - JDK-8270380: Change the default value of the java.security.manager
> system property to disallow
> - JDK-8275319: java.net.NetworkInterface throws java.lang.Error instead
> of SocketException
> - JDK-8270490: Charset.forName() taking fallback default value
> - JDK-8269336: Malformed jdk.serialFilter incorrectly handled
>
>
> # Project Loom update
>
> New Project Loom 18-loom+4-273 (2021/11/10) Early-Access builds are
> available [7] with related Javadocs [8].
>
> [7] https://jdk.java.net/loom/
> [8] https://download.java.net/java/early_access/loom/docs/api/
>
> These EA builds are provided u

JDK 18 b23 - Impossible to set a new value for "static final" field

[Martin Grigorov]

Hi Oracle team,

I've just tested JDK 18-ea+23-1525 with Apache Wicket and I've faced the
following problem:

[ERROR] Tests run: 29, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
0.125 s <<< FAILURE! - in org.apache.wicket.util.string.StringsTest
[ERROR] org.apache.wicket.util.string.StringsTest.stripJSessionId  Time
elapsed: 0.011 s  <<< ERROR!
java.lang.InternalError: java.lang.IllegalAccessException: static final
field has no write access:
org.apache.wicket.util.string.Strings.SESSION_ID_PARAM/java.lang.String/putStatic,
from class java.lang.Object (module java.base)
at
org.apache.wicket.util.string.StringsTest.stripJSessionId(StringsTest.java:73)
Caused by: java.lang.IllegalAccessException: static final field has no
write access:
org.apache.wicket.util.string.Strings.SESSION_ID_PARAM/java.lang.String/putStatic,
from class java.lang.Object (module java.base)
at
org.apache.wicket.util.string.StringsTest.stripJSessionId(StringsTest.java:73)

The related code could be seen at:
1)
https://github.com/apache/wicket/blob/d95a3c526229092ecc035ca3e901f5d9a7d4e1c2/wicket-util/src/main/java/org/apache/wicket/util/string/Strings.java#L66
2)
https://github.com/apache/wicket/blob/d95a3c526229092ecc035ca3e901f5d9a7d4e1c2/wicket-util/src/test/java/org/apache/wicket/util/string/StringsTest.java#L56-L70

The same code worked with JDK 18 b18 and older versions.
I believe the failure is caused by https://github.com/openjdk/jdk/pull/5027

Is this a regression or an intended new behavior and we should update our
code ?

Regards,
Martin

Re: Wicket 10 based on jakarta.** APIs ?

[Martin Grigorov]

On Thu, Jun 3, 2021 at 2:29 PM Martin Grigorov  wrote:

>
>
> On Thu, Jun 3, 2021 at 2:27 PM Martin Grigorov 
> wrote:
>
>>
>>
>> On Wed, Jun 2, 2021 at 4:12 PM Maxim Solodovnik 
>> wrote:
>>
>>> I've started this work for our project
>>> seems to be doable
>>>
>>> Maybe you can share what are the benefits?
>>>
>>
>> As I said I don't have any practical experience with JPMS, but I hoped to
>> learn something new for Wicket 10 :-)
>>
>
> One more thing to learn for me:
> Replace Reflection APIs usage in PropertyResolver & Co. with MethodHandles.
> People say that MethodHandles are both faster and less memory intensive
> than Reflection APIs.
>

This idea is obsolete now - https://github.com/openjdk/jdk/pull/5027
The Reflection APIs have been reworked to use MethodHandles for JDK 18 !


>
>
>>
>>>
>>> On Wed, 2 Jun 2021 at 15:15, Martin Tzvetanov Grigorov <
>>> mgrigo...@apache.org>
>>> wrote:
>>>
>>> >
>>> >
>>> > On 2021/04/02 11:58:02, Martin Grigorov  wrote:
>>> > > Hi,
>>> > >
>>> > > Now since we have 9.3.0 released is it time to start
>>> thinking/working on
>>> > > Wicket 10 ?
>>> > >
>>> > > Here are few ideas what to break :-)
>>> > >
>>> > > 1) Move to Servlet 5.x, i.e. jakarta.servlet.**
>>> > > 2) Use @Inject + @Named instead of @SpringBean. If everything is
>>> covered
>>> > > by @Inject we may deprecate @SpringBean in 9.x
>>> > > 3) Depending on the release date we may even bump Java to 17 (it is
>>> going
>>> > > to be released this September and it is going to be LTS). I expect
>>> Wicket
>>> > > 10.0.0 to be released in 1-2 years from now, so by this time Java 17
>>> > should
>>> > > be mainstream! :-) I know that this is too brave. Most projects
>>> still use
>>> > > Java 8 for some reason.
>>> >
>>> > One more idea: add proper support for JPMS (Java 9+ modules) in Wicket.
>>> > I still don't have any experience with this, so I am not sure how much
>>> > work this is and what problems we may face with it.
>>> >
>>> > >
>>> > > Regards,
>>> > > Martin
>>> > >
>>> >
>>>
>>>
>>> --
>>> Best regards,
>>> Maxim
>>>
>>

Re: [VOTE] Release Apache Wicket 9.6.0

[Martin Grigorov]

+1 to release !

On Fri, Oct 29, 2021 at 11:24 PM Andrea Del Bene 
wrote:

> This is a vote to release Apache Wicket 9.6.0
>
> Please download the source distributions found in our staging area
> linked below.
>
> I have included the signatures for both the source archives. This vote
> lasts for 72 hours minimum.
>
> [ ] Yes, release Apache Wicket 9.6.0
> [ ] No, don't release Apache Wicket 9.6.0, because ...
>
> Distributions, changelog, keys and signatures can be found at:
>
>  https://dist.apache.org/repos/dist/dev/wicket/9.6.0
>
> Staging repository:
>
> https://repository.apache.org/content/repositories/orgapachewicket-1166/
>
> The binaries are available in the above link, as are a staging
> repository for Maven. Typically the vote is on the source, but should
> you find a problem with one of the binaries, please let me know, I can
> re-roll them some way or the other.
>
> Staging git repository data:
>
>  Repository:  g...@github.com:bitstorm/wicket.git
>  Branch:  build/wicket-9.6.0
>  Release tag: rel/wicket-9.6.0
>
>
> 
>
>  The signatures for the source release artefacts:
>
>
> Signature for apache-wicket-9.6.0.zip:
>
>  -BEGIN PGP SIGNATURE-
>
> iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAmF8V0cACgkQh48B+qjT
> VuFlWg//fx8VsKfQAgFNILQi3m/YuoCEIyoZ4g1DKzOeJwVnttBI+FZBq+1+p9Be
> zEkKNY+U8u6/iITuQTZXkof1mLPxXJTwm/zCeGdkzgTos1+JTARr8jMtZHaIOV+Z
> GtJ2YAQuy9TgUag2NhaIgGkmiwGpgZSzyIdf+PevaAYd+hP42G5WOAQZyXwby0RF
> 4xjhp7gknxNqoVKCqTSQZ3m44GoKWnesyl/CjLZDLTj18z+KPMeI+P75xeIzCiWH
> BV4QKYtg6Mv3Q4EPp7YCncoUg+X/qxGHPsoiHJ0Bc8VlVwrAxPpqOzWHfHbQD2nj
> FpU+WBuk5UkYqKYGYfGiUwJ0lwPisUsE/TSKsLwQODtr4H9Dd3cpuzOAbXhGNyqF
> QeX6nkZwwVJci7VuKX+f94+lIfvRRtkBooZg9DHJCtRmmk1YX4/wARuEqI3ccOuI
> xpb95WgmMNzsfbcnVGU07WjY9gvJ4mYOJhOicGP8YG11MoH4U5EoXfFZWDdfhWEg
> ucsbbuS02xC08YrwXrh4vskIyqFLuGFTV9bkvMs3harsGird4VA0l2KcdqFizMyF
> Jpdt3fiq5xV3BmhN9e84pCXhOMyPVtuXXM9oub7CQ3NM0qapTLHlQvMaoL00E5yu
> OxeTIKDX8FgPaGOPCujryVzPRYm5CQzPRcVIoc4E3alPDox0kfo=
> =SGe1
> -END PGP SIGNATURE-
>
> Signature for apache-wicket-9.6.0.tar.gz:
>
>  -BEGIN PGP SIGNATURE-
>
> iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAmF8V0cACgkQh48B+qjT
> VuHDhg/9HfVvYbrGKOQoendIzufSDuBlLAdtKWizW2LqPGLow33FizbLrqleG9RY
> 7MP+n7VmaeYRA+vxABIE8G+Ye4sV5IgXn+O3YdmEyy/eIW/gOm5SoLmYkEKVuyo1
> Lkw4cngoAVE9eGe9EZkQUsaRzQ0HrevdMWW+MN2OwIMezD0YDLH7SFudiqn/cmb0
> IUgU1HrkvuICOFAmHdwr+cMYSIOXf5kthWLw6/2UcaR+ZCSpgFUX8RYpf0YDDWNO
> IMh1Cq+wxZptkEl4iUs+MBsgT+N5rRlZi88gM3n7Z9aBfDAATQIhrP/sUirnDiDH
> idhUyatNpQ4+Qj2+tYW7diuRsnmD4rkOqQxo8/F05bVHIvUib8t93H5e0LsMDsrs
> D562EKPtfXbEdOVF2ETv/g/JEWfSpV3vOxmDFaBdc6Q5tdnb2XWAfVddecCi+yGX
> Cjfr7BhhUo4L9yC+7FnM4X1YeyIUzvrqpxCzIWeuZFQfKxB+af2tWV5bgbl/8j/v
> jYLyj1evTwfzmhwkkgZQbWk/O0dUR9eRnXKHA8u3MX+s5QnmvF52V5fwl+2y687Q
> gepHoEIZvhhLsQ6xjNYkUh3jgILEO7xtz+s2AzQS5FIQIqA9Ya6EARKv8Q3JOwC4
> rgE7xEurWPFKsZTosxIOQKC04gdJbPeZG7pBRBMSUU4qRS6QMD8=
> =deKp
> -END PGP SIGNATURE-
>
> 
>
>  CHANGELOG for 9.6.0:
>
>
> ** Bug
>
>  * [WICKET-6921] - MultipartFormComponentListener breaks on hidden
> components
>
> ** Improvement
>
>  * [WICKET-6920] - Improve the examples to use the browser's
> light/dark mode
>  * [WICKET-6924] - Allow image/avif in SecurePackageResourceGuard
>  * [WICKET-6927] - Get rid of java.security.AccessController
>
> ** Task
>
>  * [WICKET-6918] - Add links to latest wicket.xsd to the web site
>  * [WICKET-6919] - Improve EnclosureContainer's javadoc to explain
> that it should not be used with 
>  * [WICKET-6925] - Deprecate AbstractWrapModel
>
>

Re: A solution to hide page id with mounted pages?

[Martin Grigorov]

Hi Andrea,

On Fri, Oct 29, 2021 at 2:28 PM Andrea Del Bene 
wrote:

> In my current project I'm building a web app which is essentially made of
> pages mounted at a precise path which I guess it's a quite common design
> pattern with Wicket and web apps in general. Shortly after starting to work
> on this project I was asked to get rid of the page id to make page urls
> more "clean".
>

So, the issue is purely eastetic ?!


> This is something that it's relatively easy to achieve, and it has also
> been discussed different times on StackOverflow and on our mailing list.
> Essentially we have to create a custom MountedMapper overriding
> encodePageComponentInfo in order to skip pageInfo. Something like:
>
> public class NoPageIdMapper extends MountedMapper {
>
> @Override
> protected void encodePageComponentInfo(Url url, PageComponentInfo info) {
>  if (info.getComponentInfo() != null) {
>super.encodePageComponentInfo(url, info);
>   }
>}
> }
>

Wouldn't it be better to use only stateless components and behaviors ?
With NoPageIdMapper you just hide "the problem" but later some
functionality might break because of this.


>
> I've also found that some popular Wicket projects like OneDev or Orienteer
> adopt a similar solution. So I'm starting to wonder if we should consider
> to provide a standard solution for those who are interested in this kind of
> behavior.
>
> WDYT?
>

I've never used NoPageIdMapper in a real app, so I am not sure how stable
solution it is.


>
> --
> Andrea Del Bene.
> Apache Wicket committer.
>

Re: Thank you! JDK 18 Early Access build 20 is now available

[Martin Grigorov]

Hi Rory,

Apache Wicket build and tests pass with JDK 18-ea+20-1248 on Linux x86_64
and aarch64!

Regards,
Martin

On Tue, Oct 26, 2021 at 3:18 PM Rory O'Donnell 
wrote:

> Hi Martin,
> *Thank you.*
>
> I'm retiring at the end of November 2021, it's time to spend more time
> with the family.
>
> We started the Quality Outreach back in October 2014.  We now have 170+
> projects participating.
> Thank you for taking the time to provide Testing feedback , excellent
> bugs and support throughout
> the last seven years.
>
> It's been a pleasure working with you. I am delighted to say that the
> program will continue
> with the support of the Java DevRel Team, with David Delabassee as your
> contact. David has
> been assisting with on-boarding new projects for the last couple of years.
>
> All the best, Rory
>
>
> *OpenJDK 18Early Access build 20is now available
> at**https://jdk.java.net/18/ **
> *
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception .
>   * Release Notes are available athttps://jdk.java.net/18/release-notes
> 
>   * Features:
>   o JEPs integrated to JDK 18, so far:
>   + JEP 400: UTF-8 by Default 
>   + JEP 408: Simple Web Server 
>   + JEP 413: Code Snippets in Java API Documentation
> 
>   o JEPs targeted to JDK 18, so far
>   + JEP 417: Vector API (Third Incubator)
> 
>   o JEPs proposed to target JDK 18:
>   + JEP 416: Reimplement Core Reflection with Method Handles
> 
>
>   * Significant changes since the last availability email:
>   o Build 20:
>   + JDK-8275252: Migrate cacerts from JKS to password-less PKCS12
>   + JDK-8275149: (ch) ReadableByteChannel returned by
> Channels.newChannel(InputStream) throws ReadOnlyBufferException
>   + JDK-8266936: Add a finalization JFR event
>   + JDK-8264849: Add KW and KWP support to PKCS11 provider
>   o Build 19:
>   + JDK-8274840: Update OS detection code to recognize Windows 11
>   + JDK-8274407: (tz) Update Timezone Data to 2021c
>   + JDK-8273102: Delete deprecated for removal the empty
> finalize() in java.desktop module
>   o Build 18:
>   + JDK-8274656: Remove default_checksum and safe_checksum_type
> from krb5.conf
>   + JDK-8274471: Add support for RSASSA-PSS in OCSP Response
>   + JDK-8274227: Remove "impl.prefix" jdk system property usage
> from InetAddress
>   + JDK-8274002: [win11 and winserver2022] JDK executable
> installer from network drive starts with huge delay
>   + JDK-8273670: Remove weak etypes from default krb5 etype list
>   o Build 17:
>   + JDK-8273401: Disable JarIndex Support In URLClassPath
>   + JDK-8231640: (prop) Canonical property storage
>   + Build 16:
>   + JDK-8269039: Disable SHA-1 Signed JARs
>
> *Topics of Interest:*_
> _
>
> _JDK 17:_**
> **
>
>   * *Inside Java Podcast “Java 17 is Here!”*
>   o *Part 1: https://inside.java/2021/09/14/podcast-019/
> *
>   o *Part 2: https://inside.java/2021/09/27/podcast-020/
> *
>   * *G1 GC & Parallel GC Improvements in JDK 17*
>   o *https://inside.java/2021/09/17/jdk-17-gc-updates/
> *
>   * ZGC - What's new in JDK 17**
>   o *https://inside.java/2021/10/05/zgc-in-jdk17/
> *
>   * JDK 17 Security Enhancements**
>   o *https://inside.java/2021/09/15/jdk-17-security-enhancements/
> *
>   * The Vector API in JDK 17 (video)**
>   o *https://inside.java/2021/09/23/devlive-vector-api/
> *
>   * Faster Charset Encoding**
>   o *https://inside.java/2021/10/17/faster-charset-encoding/
> *
>
> _JDK 18:_
>
>   * JEP 400 and the Default Charset
>   o https://inside.java/2021/10/04/the-default-charset-jep400/
> 
>   * JDK 18 augmented `javac -Xlint:serial` checks
>   o https://inside.java/2021/10/20/augmented-serial-checks
> 
>
> _Project Panama - Foreign Function & Memory API:_
>
>   * Finalizing the Foreign APIs
>   o https://in

Time for 9.6.0 ?

[Martin Grigorov]

Hi,

https://issues.apache.org/jira/projects/WICKET/versions/12350602

There is not much! Mostly documentation improvements.
https://issues.apache.org/jira/browse/WICKET-6921 has been reported by few
users and I think it is time to release the fix!
Maybe even as 9.5.1 ?!


Martin