Re: Incorrect modification time in jars

[Emond Papegaaij]

>
> 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.

Best regards,
Emond

Re: Incorrect modification time in jars

[Emond Papegaaij]

Op do 7 dec 2023 om 08:58 schreef Emond Papegaaij :

> Op do 7 dec 2023 om 02:35 schreef Maxim Solodovnik :
>
>> File timestamps might be set to `project.build.outputTimestamp` by Maven
>> This enables "reproducible builds"
>> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
>>
>> I believe Maven `project.build.outputTimestamp` property should be set
>> in the pom.xml by release manager during release
>> should be easy to check :) (sorry, I don't have time to check it myself
>> : )
>>
>
> I think just adding the property set to the current date should be enough.
> The maven-release-plugin will take care of updating the property during the
> release as you can see here:
> https://github.com/apache/maven/commit/3fc399318edef0d5ba593723a24fff64291d6f9b#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R176
>

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.

Best regards,
Emond

Re: Incorrect modification time in jars

[Emond Papegaaij]

Op do 7 dec 2023 om 02:35 schreef Maxim Solodovnik :

> File timestamps might be set to `project.build.outputTimestamp` by Maven
> This enables "reproducible builds"
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
>
> I believe Maven `project.build.outputTimestamp` property should be set
> in the pom.xml by release manager during release
> should be easy to check :) (sorry, I don't have time to check it myself
> : )
>

I think just adding the property set to the current date should be enough.
The maven-release-plugin will take care of updating the property during the
release as you can see here:
https://github.com/apache/maven/commit/3fc399318edef0d5ba593723a24fff64291d6f9b#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R176

Best regards,
Emond

Re: Incorrect modification time in jars

[Emond Papegaaij]

>
>
>
> 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.
>

Yes, I know. I don't know why we ever configured our applications to always
use LastModifiedResourceVersion, but this was working fine for us, until
wicket 9.8.0. Something changed that caused the timestamps to be reset at
that time. I think we should try to find out what caused this, and fix it.
As you said LastModifiedResourceVersion is used by default in dev mode, and
it is currently broken. I'll create a Jira issue for this tomorrow, I
didn't have the time for it today.

For us, I've already recommended everyone to remove our custom
configuration of this setting. The default makes much more sense, and only
developers will be faced with a possible invalid cache entry.

Best regards,
Emond

>

Re: Incorrect modification time in jars

[Emond Papegaaij]

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
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

>

Incorrect modification time in jars

[Emond Papegaaij]

Hi,
With the upgrade to wicket 9.16.0 we've seen some issues with the new
'Wicket.Event.requestSubmit' method that was added to wicket-ajax-jquery.
It turns out that a cached version of the resource was used, and this seems
to be caused by an incorrect version string in the url. The filename is
rendered as 'wicket-ajax-jquery-ver-31820760.js'. The same is true for
JQuery: 'jquery-3.7.1-ver-31820760.js'. This seems to be caused by an
incorrect modification time in the jar. Our repository shows all files in
the wickets jars to have the timestamp 31821120. Other resources (not
from wicket itself) do have correct timestamps.

This seems to be the case since wicket 9.8.0. Versions prior to that have
correct timestamps. Did something change to the way wicket is built between
9.7.0 and 9.8.0? I can't find anything related in the commits.

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.

Best regards,
Emond

Re: Wicket 9.x versions are NOT backward compatible

[Emond Papegaaij]

Op wo 30 aug 2023 om 17:20 schreef Maxim Solodovnik :

> Hello Emond,
>
> On Fri, 25 Aug 2023 at 14:38, Emond Papegaaij 
> wrote:
> >
> > Op vr 25 aug 2023 om 07:02 schreef Maxim Solodovnik <
> solomax...@gmail.com>:
> >
> > > So if (for whatever reason) we do have
> > > wicket-core 9.8.0+ AND wicket-util 9.7.0-
> > >
> > > In class path WebApplication will fail to start with
> > > java.lang.NoSuchMethodError
> > >
> >
> > This is perfectly fine. Semver only is about Wicket as a whole, so you
> > should not be mixing different versions of parts of Wicket.
> >
> here is it's  dependency tree:
>
> [INFO] +-
> de.agilecoders.wicket:wicket-bootstrap-extensions:jar:4.0.4:compile
> [INFO] |  +- de.agilecoders.wicket:jquery-selectors:jar:3.0.3:compile
> [INFO] |  |  +- com.fasterxml.jackson.core:jackson-core:jar:2.11.4:compile
> [INFO] |  |  \-
> com.fasterxml.jackson.core:jackson-databind:jar:2.15.1:compile
> [INFO] |  | \-
> com.fasterxml.jackson.core:jackson-annotations:jar:2.15.1:compile
> [INFO] |  +- org.apache.wicket:wicket-extensions:jar:9.14.0:compile
> [INFO] |  +- org.apache.wicket:wicket-util:jar:9.3.0:compile
> [INFO] |  |  +- commons-fileupload:commons-fileupload:jar:1.4:compile
> [INFO] |  |  +- commons-io:commons-io:jar:2.12.0:compile
> [INFO] |  |  \- org.apache.commons:commons-collections4:jar:4.4:compile
>
> [INFO] \- org.apache.wicket:wicket-core:jar:9.14.0:compile
> [INFO]+- com.github.openjson:openjson:jar:1.0.12:compile
> [INFO]+- org.apache.wicket:wicket-request:jar:9.14.0:compile
> [INFO]\- org.danekja:jdk-serializable-functional:jar:1.9.0:compile
>
> As you can see it directly depends on
> `org.apache.wicket:wicket-core:jar:9.14.0:compile`
> BUT it has no direct dependency on wicket-util :(
>
> The other (very much old) library
> wicket-bootstrap-extensions:jar:4.0.4 has it's dependency
>
> So we have conflict :(
>
> Maybe it worth to add some redundancy to our dependency:tree and add
> `wicket-util` as direct dependency of `wicket-core`?
>

wicket-core already has a dependency on wicket-util. As far as I know,
Maven does not give any guarantees on which version it resolves in
situations like this. This is why you should always use something like the
maven-enforcer to enforce dependency convergence. Actually, at Topicus, we
use even more strict rules: all dependencies, direct or indirect, should
have a managed version.

We could publish a wicket-bom with all wicket modules to make it easier to
manage all wicket modules at once.

Best regards,
Emond

Re: Wicket 9.x versions are NOT backward compatible

[Emond Papegaaij]

Op vr 25 aug 2023 om 07:02 schreef Maxim Solodovnik :

> So if (for whatever reason) we do have
> wicket-core 9.8.0+ AND wicket-util 9.7.0-
>
> In class path WebApplication will fail to start with
> java.lang.NoSuchMethodError
>

This is perfectly fine. Semver only is about Wicket as a whole, so you
should not be mixing different versions of parts of Wicket.

Also, the problem you are describing is about forward compatibility (if
were to be an external piece of code using this new method): you are using
code that is compiled against a newer version of Wicket and use it with an
older version. Semver does guarantee forward compatibility on any level.

Finally, in minor releases you are allowed to add new functionality, this
is by definition not forward compatible. You cannot build something that
uses this new functionality in a piece of code and then expect it to work
with a version of Wicket where this functionality did not yet exist.

Best regards,
Emond

Re: Time for Wicket M1?

[Emond Papegaaij]

Op do 9 feb. 2023 om 08:32 schreef 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!
>

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

Re: Time for Wicket M1?

[Emond Papegaaij]

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.

Best regards,
Emond

Re: [ANNOUNCE] Apache Wicket 9.9.1 released

[Emond Papegaaij]

I had issues with the git repo on Friday. Git fetch told me the repository
did not exist. I'm using https://gitbox.apache.org/repos/asf/wicket.git .
After some time it was working again. Maybe this is related?

Emond

On Sat, Apr 9, 2022 at 12:01 PM Andrea Del Bene 
wrote:

> For some reason I can't update project site with the new version
> announcement :-/ I followed the usual procedure, I don't know where the
> problem is...
>
> On Fri, Apr 8, 2022, 9:16 PM Andrea Del Bene  wrote:
>
> > The Apache Wicket PMC is proud to announce Apache Wicket 9.9.1!
> >
> > Apache Wicket is an open source Java component oriented web application
> > framework that powers thousands of web applications and web sites for
> > governments, stores, universities, cities, banks, email providers, and
> > more. You can find more about Apache Wicket at https://wicket.apache.org
> >
> > This release marks another minor release of Wicket 9. We
> > use semantic versioning for the development of Wicket, and as such no
> > API breaks are present in this release compared to 9.0.0.
> >
> > New and noteworthy
> > --
> >
> > This hotfix reverts WICKET-6963 which causes MarkupException in some
> > particular cases.
> > (see https://lists.apache.org/thread/y0zthfw2on04sm9wpn60my3x53b8cb3n).
> > In addition, this release updates Spring Core dependency to version
> > 5.3.18 which provides a fix
> > for Spring4shell vulnerability (CVE-2022-22965).
> >
> > NOTE: Wicket is NOT directly impacted by Spring4shell. Your application
> > might be exposed to this
> > vulnerability only if you use Spring web frameworks (i.e. Spring MVC and
> > Spring WebFlux).
> >
> > Using this release
> > --
> >
> > With Apache Maven update your dependency to (and don't forget to
> > update any other dependencies on Wicket projects to the same version):
> >
> > 
> >  org.apache.wicket
> >  wicket-core
> >  9.9.1
> > 
> >
> > Or download and build the distribution yourself, or use our
> > convenience binary package you can find here:
> >
> >   * Download: http://wicket.apache.org/start/wicket-9.x.html#manually
> >
> > Upgrading from earlier versions
> > ---
> >
> > If you upgrade from 9.y.z this release is a drop in replacement. If
> > you come from a version prior to 9.0.0, please read our Wicket 9
> > migration guide found at
> >
> >   * http://s.apache.org/wicket9migrate
> >
> > Have fun!
> >
> > — The Wicket team
> >
> >
> > 
> >
> >  CHANGELOG for 9.9.1:
> >
> > ** Bug
> >
> >  * [WICKET-6966] - IndexOutOfBounds in InSessionPageStore
> >  * [WICKET-6965] - Memory leak in WicketEndpoint
> >
> > ** Improvement
> >
> >  * [WICKET-6963] - (REVERTED) Use singletons for
> > PanelMarkupSourcingStrategy
> >
> >
>

Re: @jakarta.inject.Inject + not required

[Emond Papegaaij]

CDI uses javax.enterprise.inject.Instance to inject optional beans. I
don't particular like this solution, but it works. The downside is
that it depends on the CDI API.

Best regards,
Emond

On Wed, Jun 2, 2021 at 10:41 AM Martin Grigorov  wrote:
>
> On Wed, Jun 2, 2021 at 11:31 AM Sven Meier  wrote:
>
> > Hi,
> >
> > I wasn't aware that Optional actually isn't serializable:
> >
>
> The real problem is that it is `final class`.
> Even if it was Serializable we would still wrap it in a proxy that looks up
> the real bean on demand / after deserialization.
> We could use
> https://github.com/nipafx/demo-serialize-optional/blob/master/src/org/codefx/lab/optional/SerializableOptional.java
> but it is yet another extra code to maintain.
>
>
> >
> >
> > https://stackoverflow.com/questions/24547673/why-java-util-optional-is-not-serializable-how-to-serialize-the-object-with-suc#24564612
> >
> > "The JSR-335 EG felt fairly strongly that Optional should not be on any
> > more than needed to support the optional-return idiom only. (Someone
> > suggested maybe even renaming it to OptionalReturn to beat users over
> > the head with this design orientation; perhaps we should have taken that
> > suggestion.)"
> >
> > (I wonder whether we follow this usage guideline everywhere.)
> >
>
> We don't.
> We pass Optional to AjaxFallback**#onClick() methods.
> It works fine so far!
>
>
> >
> > So it seems an optional @Inject is not possible with our usecase.
> >
> > I'm +0 on changing anything here, although @Autowired would be fine too.
> >
>
> Yes, I also wonder whether we should do anything here. There are no
> problems with SpringBean at the moment.
>
>
> >
> > Regards
> > Sven
> >
> >
> > On 02.06.21 10:09, Martin Grigorov wrote:
> > > Hi,
> > >
> > > In my email about ideas what to do for Wicket 10 (
> > > https://markmail.org/message/vpptsmt4ysxbktzc) I have suggested to
> > > drop @SpringBean and use jakarta.inject.Inject/Named instead.
> > > While working on it I've faced one issue - there is no support for
> > > non-required bean:
> > >
> > > @SpringBean(required = false)
> > > private SomeBean someBean;
> > >
> > > If there is no matching bean in the Spring application context then
> > nothing
> > > will be injected. Without 'required = false' the instantiation of the
> > > Component will fail with an Exception.
> > >
> > > With jakarta.inject APIs there is no way to say that something is
> > optional.
> > > I've tried by using java.util.Optional:
> > >
> > > @Inject
> > > private Optional someBean;
> > >
> > > but the problem here is that j.u.Optional is a final class and cannot be
> > > enhanced by CGLib to create a serializable proxy around it.
> > >
> > > Another option is to create a custom annotation, e.g. @Optional in
> > > wicket-ioc.
> > >
> > > Do you have other ideas ?
> > > Or should we stay with @SpringBean or even use Spring's @Autowired ?!
> > >
> > > Martin
> > >
> >

Re: GitHub notifications to a special mailing list (was: How do I unsubscribe from wicket, please?)

[Emond Papegaaij]

Hi,

I agree the mail spams the list a bit and it makes sense to send it
somewhere else, but doesn't it belong in commits@w.a.o?

Best regards,
Emond

On Mon, May 31, 2021 at 5:25 PM Martin Grigorov  wrote:
>
> Hi,
>
> Some people complain that there is too much email traffic on dev@ due to
> the GitHub notifications.
>
> What do you think about creating a new mailing list, e.g. github@w.a.o ?
> This could be easily done via .asf.yaml
> Any objections ?
>
> Regards,
> Martin
>
> -- Forwarded message -
> From: Martin Grigorov 
> Date: Mon, May 31, 2021 at 6:22 PM
> Subject: Re: How do I unsubscribe from wicket, please?
> To: Max Calderoni 
> Cc: Users 
>
>
> Hi,
>
> On Mon, May 31, 2021 at 6:02 PM Max Calderoni 
> wrote:
>
> > ...one more piece of info.. Looks like those email, which I receive, are
> > sent to dev@wicket.apache.org
> >
>
> Yes, those emails are sent by GitHub to dev@.
> To unsubscribe from dev@ please follow the instructions at http://wicket.
> apache.org/help/email.html#dev
> I will see moving these notifications to a specialized list instead of dev@.
>
>
> >
> > On Mon, May 31, 2021 at 1:37 PM Max Calderoni 
> > wrote:
> >
> >> I tried unsubscribing by ignoring its github project
> >>  (set as "never be notified"), but I
> >> am still getting emails from GitBox g...@apache.org like the one below.
> >> What am I supposed to do, please?
> >>
> >>
> >>
> >>
> >> On Sat, May 29, 2021 at 9:32 AM GitBox  wrote:
> >>
> >>>
> >>> svenmeier commented on pull request #471:
> >>> URL: https://github.com/apache/wicket/pull/471#issuecomment-850787702
> >>>
> >>>
> >>>I've build a lot of these components over the years for different
> >>> projects, and each had to be different according to the needs of the
> >>> current project.
> >>>
> >>>There are a whole lot of issues with this implementation, from less
> >>> important ones like documentation and coding style to larger conceptual
> >>> errors, performance considerations and code duplication.
> >>>
> >>>I'd rather not pull this code chunk into Wicket as is, and
> >>> restructuring it might take a long time.
> >>>
> >>>
> >>> --
> >>> This is an automated message from the Apache Git Service.
> >>> To respond to the message, please log on to GitHub and use the
> >>> URL above to go to the specific comment.
> >>>
> >>> For queries about this service, please contact Infrastructure at:
> >>> us...@infra.apache.org
> >>>
> >>>
> >>>
> >>
> >> --
> >> Max Calderoni
> >>
> >> --
> >> Max Calderoni
> >>
> >
> >
> > --
> > Max Calderoni
> >

CVE-2021-23937: Apache Wicket: DNS proxy and possible amplification attack

[Emond Papegaaij]

Description:

A DNS proxy and possible amplification attack vulnerability in
WebClientInfo of Apache Wicket allows an attacker to trigger arbitrary
DNS lookups from the server when the X-Forwarded-For header is not
properly sanitized. This DNS lookup can be engineered to overload an
internal DNS server or to slow down request processing of the Apache
Wicket application causing a possible denial of service on either the
internal infrastructure or the web application itself.

This issue affects Apache Wicket Apache Wicket 9.x version 9.2.0 and
prior versions; Apache Wicket 8.x version 8.11.0 and prior versions;
Apache Wicket 7.x version 7.17.0 and prior versions and Apache Wicket
6.x version 6.2.0 and later versions.

Mitigation:

Sanitize the X-Forwarded-For header by running an Apache Wicket
application behind a reverse HTTP proxy. This proxy should put the
client IP address in the X-Forwarded-For header and not pass through
the contents of the header as received by the client.

The application developers are recommended to upgrade to:
- Apache Wicket 7.18.0

- Apache Wicket 8.12.0

- Apache Wicket 9.0.0


Credit:

Apache Wicket would like to thank Jonathan Juursema from
Topicus.Healthcare for reporting this issue.

Apache Wicket Team

Re: Next release cycle.

[Emond Papegaaij]

I agree. It would have been nice to have it backported to 8, but it's
not a big deal and not worth the effort of backporting all those other
things.

On Sun, Mar 21, 2021 at 9:18 PM Martin Grigorov  wrote:
>
> On Sun, Mar 21, 2021, 18:47 Maxim Solodovnik  wrote:
>
> > Let it be 9.x exclusive feature? :))
> >
>
> Actually, CSP, COEP & COOP are 9.x only. So, security enhancements go only
> to 9.x :-)
>
>
>
> >
> >
> > On Sun, 21 Mar 2021 at 23:44, Andrea Del Bene 
> > wrote:
> >
> > > Hi,
> > >
> > > I think it's time to work on the next release cycle. Let me know if you
> > > wish to finish any task before proceeding. Speaking of which...I'm not
> > sure
> > > what to do with WICKET-6864. Initially I wanted to port it to wicket-8x
> > but
> > > the task is everything but trivial. Wicket 8 doesn't have the security
> > > configuration part to use a centralized random number generator and I'm
> > not
> > > sure we can port everything back without breaking api compatibility.
> > > We might apply the initial commit Sven did for this task (see the link
> > > below) but I'm not sure if such a watered-down compromise is worth it.
> > And
> > > I would avoid to delay the next release too long just for this task.
> > >
> > > WDYT?
> > >
> > >
> > >
> > https://github.com/apache/wicket/pull/462/commits/7bc47ec03cbbf273570ae72b535fa4663024737e
> > >
> > > --
> > > Andrea Del Bene.
> > > Apache Wicket committer.
> > >
> >
> >
> > --
> > Best regards,
> > Maxim
> >

Re: JDK 16 is in Rampdown Phase One

[Emond Papegaaij]

Hi,

Before we go that way, please do some performance tests. We've seen
very bad performance in StackWalker, especially when it is called many
times over. This may have improved in more recent JDKs, but in Java 11
the overhead was so significant that a single StackWalker call in a
log call would kill the server slowly over time:
https://issues.redhat.com/browse/LOGMGR-263

Best regards,
Emond

On Tue, Dec 15, 2020 at 8:45 AM Martin Grigorov  wrote:
>
> Hi Chris,
>
> Thank you for your advices!
>
> On Mon, Dec 14, 2020 at 6:11 PM Chris Hegarty 
> wrote:
>
> >
> > > On 14 Dec 2020, at 10:03, Rory O'Donnell 
> > wrote:
> > >
> > > ...
> > > On 14/12/2020 09:45, Martin Grigorov wrote:
> > >> Hi Rory,
> > >>
> > >> Apache Wicket build and tests are OK with JDK 16 b28 for both aarch64
> > and
> > >> x86_64 (Ubuntu 20.10)!
> > >>
> > >> I had to add --add-opens=java.base/java.io=ALL-UNNAMED to
> > >> maven-surefire-plugin's JVM arguments because it seems this plugin does
> > not
> > >> use the (automatic) module name of the Maven project and the JDK sees
> > it as
> > >> unnamed.
> > >> And because of this Wicket was not able to install its hooks into Java
> > >> Serialization API.
> > >>
> > >>
> > https://github.com/apache/wicket/commit/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef__;!!GqivPVa7Brio!OG8UiKWp8imcsbWbsHgnGZT9g23KrXftUL9elEebSECla8O_rUMab08gGqzzNApXj5k$
> >
> > Opening the `java.io` package will of course work, but requires all
> > deployments of Wicket to do so. Maybe there is a better alternative.
> >
> >
> Actually there is no problem.
> The unit tests were failing because of 'module java.base does not "opens
> java.io" to unnamed module'.
> It seems maven-surefire-plugin does not use the Maven module's (automatic)
> module name while running the tests and the JVM sees it as "unnamed".
> So, I've added the exception to maven-surefire-plugin's JVM args:
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/pom.xml#L1086-L1097
> If I deploy a .war file to a web container like Apache Tomcat then there is
> no such exception at runtime. I haven't verified but I guess all is fine
> due to the Automatic-Module-Name in META-INF/MANIFEST.MF (
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/pom.xml#L989-L1004
> )
>
>
> > I see that `org.apache.wicket.serialize.java.JavaSerializer` is using
> > `setAccessible(true)` to access the private static method
> > `latestUserDefinedLoader` in `java.io.ObjectInputStream`. There is a
> > straightforward way of implementing similar functionality with the
> > standard java.lang.StackWalker API. If you do this, then the
> > `--add-opens` can probably be dropped.
> >
>
> I will try to improve this with your suggestion!
>
> But the problem I solved was for
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/wicket-core/src/main/java/org/apache/wicket/core/util/objects/checker/CheckingObjectOutputStream.java#L251-L282
> Here Wicket uses Reflection for ObjectStreamClass and ObjectStreamField to
> be able to pinpoint which member field of a Java object is not Serializable
> for debugging purposes.
>
>
> >
> > Here is an example of such:
> >
> > static {
> > PrivilegedAction pa1 =
> > () ->
> > StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
> > PrivilegedAction pa2 =
> > () -> ClassLoader.getPlatformClassLoader();
> > STACKWALKER = AccessController.doPrivileged(pa1);
> > PLATFORM_LOADER = AccessController.doPrivileged(pa2);
> > }
> >
> > /**
> >  * Returns the first non-null and non-platform class loader (not
> > counting
> >  * class loaders of generated reflection implementation classes) up the
> >  * execution stack, or the platform class loader if only code from the
> >  * bootstrap and platform class loader is on the stack.
> >  */
> > private static ClassLoader latestUserDefinedLoader() {
> > return STACKWALKER.walk(s ->
> > s.map(StackWalker.StackFrame::getDeclaringClass)
> >  .map(Class::getClassLoader)
> >  .filter(Objects::nonNull)
> >  .filter(cl -> !PLATFORM_LOADER.equals(cl))
> >  .findFirst()
> >  .orElse(PLATFORM_LOADER));
> > }
> >
> > Remove the PrivilegedAction / doPrivileged stuff if not interested in
> > running with a security manager enabled.
> >
> > Let me know if I can do anything further to help.
> >
> > -Chris.
> >
> >

Re: new release 9.2.0 ?

[Emond Papegaaij]

-1 to start the release now. We just discovered a (very likely) new
issue with the flush before detach:
https://issues.apache.org/jira/browse/WICKET-6848

We are currently checking if the changes made with WICKET-6847 fix
this, but I think this is a different problem. Maybe someone with a
bit more knowledge about the session invalidation can give a hint?

Best regards,
Emond

On Thu, Oct 29, 2020 at 11:09 AM Thomas Heigl  wrote:
>
> +1
>
> On Thu, Oct 29, 2020 at 8:32 AM Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > +1
> >
> > On Thu, Oct 29, 2020 at 3:54 AM Maxim Solodovnik 
> > wrote:
> >
> > > +1
> > > fixes to PageSerializers are worth to be released! :))
> > >
> > > And maybe it's time to start Wicket10? or maybe collect ideas :))
> > >
> > > On Thu, 29 Oct 2020 at 06:30, Tobias Soloschenko
> > >  wrote:
> > >
> > > > +1 for release
> > > >
> > > > kind regards
> > > >
> > > > Tobias
> > > >
> > > > > Am 28.10.2020 um 23:27 schrieb Sven Meier :
> > > > >
> > > > > Hi all,
> > > > >
> > > > > wicket-9.x got some important fixes, so we should release a 9.2.0
> > soon.
> > > > >
> > > > > WDYT?
> > > > >
> > > > > Sven
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Maxim
> > >
> >
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
> >

Re: New release

[Emond Papegaaij]

Hi Andrea,

Yes, WICKET-6702 is completed. I've resolved the ticket.

Emond

On Fri, Oct 2, 2020 at 11:59 AM Andrea Del Bene  wrote:
>
> The changelog for 9.1.0 is exploding :-). I think we can proceed releasing
> it.  That said, I don't know if WICKET-6702
>  can be considered
> completed with the resolution of WICKET-6831
>  . Can you give me some
> hints about it?
>
> Thanks.
>
>
> On Wed, Sep 16, 2020 at 5:59 PM Andrea Del Bene 
> wrote:
>
> > Hi,
> >
> > there's a lot of stuff ready for Wicket 9.1.0.  Are you ok with a new
> > release cycle or you have pending activities?
> >
> >
> > --
> > Andrea Del Bene.
> > Apache Wicket committer.
> >
>
>
> --
> Andrea Del Bene.
> Apache Wicket committer.

Re: buildbot failure in on wicket-branch-8.x

[Emond Papegaaij]

Ok, so now both master and wicket-8.x are broken, but I'm pretty sure
I didn't cause either of these failures.

On Thu, Oct 1, 2020 at 4:18 PM  wrote:
>
> The Buildbot has detected a new failure on builder wicket-branch-8.x while 
> building wicket. Full details are available at:
> https://ci.apache.org/builders/wicket-branch-8.x/builds/202
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: bb_slave6_ubuntu
>
> Build Reason: The SingleBranchScheduler scheduler named 
> 'on-wicket-branch-8.x-commit' triggered this build
> Build Source Stamp: [branch wicket-8.x] 
> bed559fdf531b15dab3ae0367873f2e27b2fcdcc
> Blamelist: Emond Papegaaij ,Sven Meier 
> 
>
> BUILD FAILED: failed compile
>
> Sincerely,
>  -The Buildbot
>
>
>

Re: Flush request before detach

[Emond Papegaaij]

Indeed, I still remembered that Martijn was working on this years ago,
but he didn't remember anymore :)

It seems we didn't come to a real conclusion back then. I did not
notice the problems Martijn had with the client waiting for the
connection to be closed. Chrome immediately displayed the new page
right after flush. I tested mostly with bookmarkable links to stateful
pages, so a click would lead to 2 requests: render page to buffer ->
redirect -> fetch result. I had a breakpoint in the serializer, to
keep the first request open indefinitely, and was able to navigate
through our application.

Next week I want to give it some more testing, to see how well it
works in our application when put under stress.

Best regards,
Emond

On Fri, Sep 18, 2020 at 12:27 PM Martin Grigorov  wrote:
>
> It seems this issue has been discussed 7 years ago:
> http://markmail.org/message/y5gfntpzqesavyif
>
> On Wed, Sep 16, 2020 at 6:53 PM Martijn Dashorst 
> wrote:
>
> > I don't see any problem, other than that users can interact with the page
> > while the server is still processing the previous request.
> >
> > Some pages (from co-workers, never my own pages) detach very slowly and
> > serialize for long due to very large component trees that need to be
> > processed.
> >
> > I don't see a way other than letting the requests wait until the detaching
> > and serializing have been done though.
> >
> > Martijn
> >
> >
> > On Wed, Sep 16, 2020 at 4:56 PM Emond Papegaaij  > >
> > wrote:
> >
> > > Hi all,
> > >
> > > After a suggestion in WICKET-6702, I decided to have a look at where
> > > request processing is blocked from the perspective of the browser. I
> > > put a breakpoint in JavaSerializer, clicked on a link, and noticed
> > > that the browser was indeed blocked by my breakpoint. When stepping
> > > out, the new page was displayed as soon as I hit webResponse.flush()
> > > in this part in WicketFilter:
> > >
> > > if (requestCycle.processRequestAndDetach()) {
> > > webResponse.flush();
> > > }
> > >
> > > It almost seems too easy to change this to (disregarding the exception
> > > handling for simplicity):
> > >
> > > if (requestCycle.processRequest()) {
> > > webResponse.flush();
> > > }
> > > requestCycle.detach();
> > >
> > > I did it nonetheless, and my first smoke tests didn't show any
> > > problems. The browser is no longer blocked while pages are being
> > > detached and serialized. Naturally, the request thread is still busy,
> > > so server resources are not freed earlier. Also, the page lock is
> > > still held, causing fast subsequent requests to be blocked while the
> > > first is being finished. But this is as expected. What do you think?
> > > Can this be changed in Wicket 9 or could this have nasty unforeseen
> > > consequences? I've created a ticket for this with my experiment on a
> > > branch:
> > > https://issues.apache.org/jira/browse/WICKET-6831 . Do note that I did
> > > not yet update AbstractUpgradeFilter, which should also be done if we
> > > want to proceed with this.
> > >
> > > Best regards,
> > > Emond
> > >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> >

Flush request before detach

[Emond Papegaaij]

Hi all,

After a suggestion in WICKET-6702, I decided to have a look at where
request processing is blocked from the perspective of the browser. I
put a breakpoint in JavaSerializer, clicked on a link, and noticed
that the browser was indeed blocked by my breakpoint. When stepping
out, the new page was displayed as soon as I hit webResponse.flush()
in this part in WicketFilter:

if (requestCycle.processRequestAndDetach()) {
webResponse.flush();
}

It almost seems too easy to change this to (disregarding the exception
handling for simplicity):

if (requestCycle.processRequest()) {
webResponse.flush();
}
requestCycle.detach();

I did it nonetheless, and my first smoke tests didn't show any
problems. The browser is no longer blocked while pages are being
detached and serialized. Naturally, the request thread is still busy,
so server resources are not freed earlier. Also, the page lock is
still held, causing fast subsequent requests to be blocked while the
first is being finished. But this is as expected. What do you think?
Can this be changed in Wicket 9 or could this have nasty unforeseen
consequences? I've created a ticket for this with my experiment on a
branch:
https://issues.apache.org/jira/browse/WICKET-6831 . Do note that I did
not yet update AbstractUpgradeFilter, which should also be done if we
want to proceed with this.

Best regards,
Emond

Re: Contribution - CSP support for Wicket

[Emond Papegaaij]

Hi Santiago,

It's always nice to get some help in maintaining Wicket. Wicket has
always been strong wrt security. That's one of the reasons why at
Topicus we use it to power our Identity and Access Management solution
called Topicus KeyHub.

Just a few weeks ago I filed the following ticket
https://issues.apache.org/jira/browse/WICKET-6786 . Wicket already has
some form of CSRF protection, but it uses the Origin header to detect
cross-site requests. This works most of the time, but is not as
reliable as using the new fetch metadata. IMHO the current
implementation should be enhanced with support for the fetch metadata
headers, with a fallback to the old approach. I haven't had the time
to work on the implementation, but it's on my todo list.

I must admit I did not yet know about the existence of trusted types.
I do think Wicket would be a good fit for that protection. It already
defines clear paths through which the DOM can be manipulated.

Best regards,
Emond

On Fri, Jun 5, 2020 at 12:38 PM Santiago Díaz
 wrote:
>
> Hello Wicket devs!
>
> Thanks for pointing out the Jira tickets that I missed! I didn't realise that 
> you already have extensive CSP support. Great job on getting rid of both 
> unsafe-inline & unsafe-eval!
>
> In that case, we will be shifting focus towards improving Wicket's security 
> through one or more of the following security enhancements:
>
>  - Protecting against DOM XSS:
>   - Trusted Types is a strong protection against DOM XSS. There is a 
> great primer at https://web.dev/trusted-types/
>
> - Protecting against Cross-Site Request Forgery, XS-Leaks, Spectre & timing 
> attacks through site isolation:
>   - Fetch Metadata. See 
> https://developer.mozilla.org/en-US/docs/Glossary/Fetch_metadata_request_header#:~:text=A%20fetch%20metadata%20request%20header,not%20be%20modified%20from%20JavaScript.
>   - Cross-Origin Opener Policy. See https://web.dev/why-coop-coep/
>
> I am somewhat familiar with ASF's general contribution guidelines but if you 
> would like to point us to any resources that you think will make our 
> collaboration smoother, I will be happy to share them internally. Tobias' 
> suggestion on giving some additional context on challenges you've found 
> sounds great.
>
> We are still at a very early stage of our project, but I will use this thread 
> to keep you updated on progress & questions.
>
> Cheers!
>
>
> On Fri, Jun 5, 2020 at 12:12 PM Andrew Kondratev  wrote:
>
> On 2020/06/05 10:09:23, Andrew Kondratev  wrote:
> > >> IMO we should explain that the CSP support has been already added in 9.x
> > >> and to close this forgotten JIRA ticket.
> > >> Then if they still think there are ways to improve the current
> > >> implementation they are very welcome to contribute!
> >
> > Martin, I did tell it first:
> >
> > >> Hi Santiago.
> > >>
> > >> The CSP support has actually improved a lot since then.
> > >> Wicket got rid of evals in the code, see here
> > https://github.com/apache/wicket/pull/384 /
> > https://issues.apache.org/jira/browse/WICKET-6703
> > >>
> > >> How exactly are you going to boost the work and how can I personally
> > help you?
> > >>
> > >> I'll forward your question to dev@wicket.apache.org
> > >>
> > >> Cheers,
> > >> Andrew
> >
> > пт, 5 июн. 2020 г. в 18:31, Martin Grigorov :
> >
> > > Hi,
> > >
> > > On Fri, Jun 5, 2020 at 6:17 AM Tobias Soloschenko
> > >  wrote:
> > >
> > > > Hi,
> > > >
> > > > to my opinion they just want to contribute to Wicket. I would simply
> > > > explain how the process of contribution works at ASF (PRs, etc.) and 
> > > > give
> > > > them some information what challenges we were faced with till now.
> > > >
> > >
> > > IMO we should explain that the CSP support has been already added in 9.x
> > > and to close this forgotten JIRA ticket.
> > > Then if they still think there are ways to improve the current
> > > implementation they are very welcome to contribute!
> > >
> > > @Andrew feel free to point them to this discussion. One can join at
> > >
> > > https://lists.apache.org/thread.html/rbd8b1500fff1140d136a08e35cf8c0f5cf200bf8a60b6a58204ef9a7%40%3Cdev.wicket.apache.org%3E
> > >
> > >
> > > >
> > > > kind regards
> > > >
> > > > Tobias
> > > >
> > > > > Am 05.06.2020 um 02:18 schrieb Andrew Kondratev  > > >:
> > > > >
> > > > > Hi colleagues! I just received this email. Not sure what this all
> > > means.
> > > > >
> > > > > -- Forwarded message -
> > > > > От: Santiago Díaz 
> > > > > Date: чт, 4 июн. 2020 г. в 21:47
> > > > > Subject: Contribution - CSP support for Wicket
> > > > > To: 
> > > > >
> > > > >
> > > > > Hello Andrew,
> > > > >
> > > > > My name is Santiago, I'm a Security Engineer at Google. I am currently
> > > > > making preparations to receive a small group of interns for this
> > > summer's
> > > > > Google internships and found your email during the course of my
> > > research.
> > > > >
> > > > > *Context*
> > > > > Here at Google we have a lot of experience 

Re: Stable behavior ids

[Emond Papegaaij]

Hi All,

With Sven's comment in mind and the fact that Andrea did not directly
understand the implications of the new method, I decided that the new
method was indeed not a good idea. It complicates the API and brings
too little benefit. I've updated the PR once more to clarify the
impact and usefulness of getBehaviorId without introducting a new
method. I did make one minor change to the API: you can no longer
request stable ids for temporary behaviors. IMHO that does not make
sense. The behavior will be gone the next request.

Can this now be merged?

Best regards,
Emond

On Mon, May 11, 2020 at 11:12 PM Emond Papegaaij
 wrote:
>
> Hi Sven,
>
> I agree with you that this method is not very nice. It indeed complicates the 
> API even more and it is very hard to explain why it is needed. It however is 
> the most efficient implementation I could think of.
>
> There is a compromise we can use: we can freeze all behavior ids when one is 
> requested. This can be stored via a flag in the component. The downside is 
> that after this flag has been set, it is no longer possible to compact the 
> array of behaviors. This can lead to an increased serialization size when 
> behaviors are removed from the component. It is a compromise I can live with. 
> The API is cleaner and the increase in size is small and only in corner 
> cases. What do you think?
>
> Even with this change, we should clarify the docs.
>
> Best regards,
> Emond
>
> Op ma 11 mei 2020 17:56 schreef Sven Meier :
>>
>> Hi Edmond,
>>
>> I agree that we should get rid of BehaviorIdList, it's probably the most
>> inefficient implementation.
>>
>> But I'm against complicating matters even more with an additional method
>> - at least until we know how the implementation will be improved post-9.0.
>>
>> Why would anyone need a non-stable id? How often does this happen?
>> What if the method returns true, but getId() is never actually called?
>>
>> IMHO this is the wrong timing to adjust the API.
>>
>> Have fun
>> Sven
>>
>>
>> On 08.05.20 07:59, Emond Papegaaij wrote:
>> > Hi Sven,
>> >
>> > Yes, this is all about optimization. It already was. It is not difficult to
>> > keep stable ids for behaviors, you can simply store an id per behavior.
>> > However, this is very inefficient. A long time ago, the decision was made
>> > to only store these ids when needed. Unfortunately, there is no way of
>> > knowing when this is actually needed. Currently, wicket will start
>> > recording these ids when a single id is requested. The getBehaviorId method
>> > has this as a side effect. The method is also called when a behavior that
>> > is not stateless is added to a component.
>> >
>> > There are 3 things I don't like about this: first the side effect, second
>> > the way the ids are stored is very inefficient and last the fact that
>> > whether a behavior is stateless or not has nothing to do with its id.
>> > That's why I propose to introduce this new method. It allows me to solve
>> > all 3 cases.
>> >
>> > To complicate things even more, there is also stateless ajax, which I would
>> > rather call ajax by luck at the moment. Stateless ajax requests a stable id
>> > and then discards the component storing this id. There is no guarantee at
>> > all that the behavior will get the same id in the next request. This
>> > currently is not explained in the javadoc.
>> >
>> > Does this make it more clear? I really feel we should have this ironed out
>> > before the 9 release, even though it has been the way it currently is since
>> > somewhere in 7.x. To me it feels like a loose end in the API and this is
>> > preventing me from improving the code that implements this API.
>> >
>> > Best regards,
>> > Emond
>> >
>> > Op do 7 mei 2020 22:19 schreef Sven Meier :
>> >
>> >> Hi Emond,
>> >>
>> >> I'm not happy with that method.
>> >>
>> >> It's one additional method like many others in Wicket which are not
>> >> clear what they are good for. I didn't understand the description.
>> >>
>> >> What's the reason for this stable id hassle? Why can't the id be stable
>> >> when a behavior wants it?
>> >> Is this really needed for optimization?
>> >>
>> >> Thanks
>> >> Sven
>> >>
>> >>
>> >> On 07.05.20 21:04, Emond Papegaaij wrote:
>> >>> Hi all,
>> >>>
>> >>> I've updated my p

Re: Stable behavior ids

[Emond Papegaaij]

Hi Sven,

I agree with you that this method is not very nice. It indeed complicates
the API even more and it is very hard to explain why it is needed. It
however is the most efficient implementation I could think of.

There is a compromise we can use: we can freeze all behavior ids when one
is requested. This can be stored via a flag in the component. The downside
is that after this flag has been set, it is no longer possible to compact
the array of behaviors. This can lead to an increased serialization size
when behaviors are removed from the component. It is a compromise I can
live with. The API is cleaner and the increase in size is small and only in
corner cases. What do you think?

Even with this change, we should clarify the docs.

Best regards,
Emond

Op ma 11 mei 2020 17:56 schreef Sven Meier :

> Hi Edmond,
>
> I agree that we should get rid of BehaviorIdList, it's probably the most
> inefficient implementation.
>
> But I'm against complicating matters even more with an additional method
> - at least until we know how the implementation will be improved post-9.0.
>
> Why would anyone need a non-stable id? How often does this happen?
> What if the method returns true, but getId() is never actually called?
>
> IMHO this is the wrong timing to adjust the API.
>
> Have fun
> Sven
>
>
> On 08.05.20 07:59, Emond Papegaaij wrote:
> > Hi Sven,
> >
> > Yes, this is all about optimization. It already was. It is not difficult
> to
> > keep stable ids for behaviors, you can simply store an id per behavior.
> > However, this is very inefficient. A long time ago, the decision was made
> > to only store these ids when needed. Unfortunately, there is no way of
> > knowing when this is actually needed. Currently, wicket will start
> > recording these ids when a single id is requested. The getBehaviorId
> method
> > has this as a side effect. The method is also called when a behavior that
> > is not stateless is added to a component.
> >
> > There are 3 things I don't like about this: first the side effect, second
> > the way the ids are stored is very inefficient and last the fact that
> > whether a behavior is stateless or not has nothing to do with its id.
> > That's why I propose to introduce this new method. It allows me to solve
> > all 3 cases.
> >
> > To complicate things even more, there is also stateless ajax, which I
> would
> > rather call ajax by luck at the moment. Stateless ajax requests a stable
> id
> > and then discards the component storing this id. There is no guarantee at
> > all that the behavior will get the same id in the next request. This
> > currently is not explained in the javadoc.
> >
> > Does this make it more clear? I really feel we should have this ironed
> out
> > before the 9 release, even though it has been the way it currently is
> since
> > somewhere in 7.x. To me it feels like a loose end in the API and this is
> > preventing me from improving the code that implements this API.
> >
> > Best regards,
> > Emond
> >
> > Op do 7 mei 2020 22:19 schreef Sven Meier :
> >
> >> Hi Emond,
> >>
> >> I'm not happy with that method.
> >>
> >> It's one additional method like many others in Wicket which are not
> >> clear what they are good for. I didn't understand the description.
> >>
> >> What's the reason for this stable id hassle? Why can't the id be stable
> >> when a behavior wants it?
> >> Is this really needed for optimization?
> >>
> >> Thanks
> >> Sven
> >>
> >>
> >> On 07.05.20 21:04, Emond Papegaaij wrote:
> >>> Hi all,
> >>>
> >>> I've updated my pull request at
> >>> https://github.com/apache/wicket/pull/432 . I've added the method I
> >>> described and changed the current code to use this new method. Also,
> >>> the documentation is updated and clarified to better reflect the rules
> >>> a developer has to follow to keep stable ids. This PR should not
> >>> change any behavior, but it does allow me to keep on working on my
> >>> rewrite without having to break the contract of getBehaviorId. The PR
> >>> splits the stable id part from the behavior being stateful or
> >>> stateless: a stateless behavior can still request a stable id and a
> >>> stateful behavior may not need it. IMHO this change makes it more
> >>> clear to a developer what to expect. I would like to merge this into 9
> >>> before the release, even though strictly speaking it is not an API
> >>> break. What do you th

Re: Stable behavior ids

[Emond Papegaaij]

Hi Sven,

Yes, this is all about optimization. It already was. It is not difficult to
keep stable ids for behaviors, you can simply store an id per behavior.
However, this is very inefficient. A long time ago, the decision was made
to only store these ids when needed. Unfortunately, there is no way of
knowing when this is actually needed. Currently, wicket will start
recording these ids when a single id is requested. The getBehaviorId method
has this as a side effect. The method is also called when a behavior that
is not stateless is added to a component.

There are 3 things I don't like about this: first the side effect, second
the way the ids are stored is very inefficient and last the fact that
whether a behavior is stateless or not has nothing to do with its id.
That's why I propose to introduce this new method. It allows me to solve
all 3 cases.

To complicate things even more, there is also stateless ajax, which I would
rather call ajax by luck at the moment. Stateless ajax requests a stable id
and then discards the component storing this id. There is no guarantee at
all that the behavior will get the same id in the next request. This
currently is not explained in the javadoc.

Does this make it more clear? I really feel we should have this ironed out
before the 9 release, even though it has been the way it currently is since
somewhere in 7.x. To me it feels like a loose end in the API and this is
preventing me from improving the code that implements this API.

Best regards,
Emond

Op do 7 mei 2020 22:19 schreef Sven Meier :

> Hi Emond,
>
> I'm not happy with that method.
>
> It's one additional method like many others in Wicket which are not
> clear what they are good for. I didn't understand the description.
>
> What's the reason for this stable id hassle? Why can't the id be stable
> when a behavior wants it?
> Is this really needed for optimization?
>
> Thanks
> Sven
>
>
> On 07.05.20 21:04, Emond Papegaaij wrote:
> > Hi all,
> >
> > I've updated my pull request at
> > https://github.com/apache/wicket/pull/432 . I've added the method I
> > described and changed the current code to use this new method. Also,
> > the documentation is updated and clarified to better reflect the rules
> > a developer has to follow to keep stable ids. This PR should not
> > change any behavior, but it does allow me to keep on working on my
> > rewrite without having to break the contract of getBehaviorId. The PR
> > splits the stable id part from the behavior being stateful or
> > stateless: a stateless behavior can still request a stable id and a
> > stateful behavior may not need it. IMHO this change makes it more
> > clear to a developer what to expect. I would like to merge this into 9
> > before the release, even though strictly speaking it is not an API
> > break. What do you think?
> >
> > Best regards,
> > Emond
> >
> > On Thu, May 7, 2020 at 1:58 PM Emond Papegaaij
> >  wrote:
> >> Hi Sven and Andrea,
> >>
> >> Sven:
> >> All tests still pass, I've also updated the ImmutableBehaviorIdsTest
> >> with some additional checks. However, the tests I've seen so far are
> >> not very exhaustive on this part. Many of them also pass with a bit of
> >> luck :)
> >>
> >> Andrea:
> >> What I mean with 'moved to the front' is that a behavior with a stable
> >> id is assigned a low number. For example, when you add these 4
> >> behaviors in this order: class-x, class-y, an ajax link and a special
> >> stateless behavior which uses its id, the ajax link will currently get
> >> id 0. If you then request the id of class-y, it will get id 2 (just
> >> after the special one). In my current implementation, the ajax link
> >> will get id 2 and class-y will get 1 (using the index). I'm planning
> >> to change this to move behaviors to the front when a stable id is
> >> required. The special behavior can override this method to return
> >> true, in which case the id's will be 0 for link, 1 for special, 2 for
> >> class-x, 3 for class-y. The difference is this is that for the last 2,
> >> this id is not guaranteed to be stable over requests. For example,
> >> when class-x is removed somewhere during a request, class-y will get
> >> id 2 on the next request, because the array storing the behaviors is
> >> compacted, removing null-slots.
> >>
> >> The default implementation of the new method will simply look at
> >> getStatelessHint on the behavior, stateless means not a stable id. On
> >> ajax behaviors, this can be overridden to return true, even though the
> >> behavior can be stateless. The point is, 

Re: Stable behavior ids

[Emond Papegaaij]

Hi all,

I've updated my pull request at
https://github.com/apache/wicket/pull/432 . I've added the method I
described and changed the current code to use this new method. Also,
the documentation is updated and clarified to better reflect the rules
a developer has to follow to keep stable ids. This PR should not
change any behavior, but it does allow me to keep on working on my
rewrite without having to break the contract of getBehaviorId. The PR
splits the stable id part from the behavior being stateful or
stateless: a stateless behavior can still request a stable id and a
stateful behavior may not need it. IMHO this change makes it more
clear to a developer what to expect. I would like to merge this into 9
before the release, even though strictly speaking it is not an API
break. What do you think?

Best regards,
Emond

On Thu, May 7, 2020 at 1:58 PM Emond Papegaaij
 wrote:
>
> Hi Sven and Andrea,
>
> Sven:
> All tests still pass, I've also updated the ImmutableBehaviorIdsTest
> with some additional checks. However, the tests I've seen so far are
> not very exhaustive on this part. Many of them also pass with a bit of
> luck :)
>
> Andrea:
> What I mean with 'moved to the front' is that a behavior with a stable
> id is assigned a low number. For example, when you add these 4
> behaviors in this order: class-x, class-y, an ajax link and a special
> stateless behavior which uses its id, the ajax link will currently get
> id 0. If you then request the id of class-y, it will get id 2 (just
> after the special one). In my current implementation, the ajax link
> will get id 2 and class-y will get 1 (using the index). I'm planning
> to change this to move behaviors to the front when a stable id is
> required. The special behavior can override this method to return
> true, in which case the id's will be 0 for link, 1 for special, 2 for
> class-x, 3 for class-y. The difference is this is that for the last 2,
> this id is not guaranteed to be stable over requests. For example,
> when class-x is removed somewhere during a request, class-y will get
> id 2 on the next request, because the array storing the behaviors is
> compacted, removing null-slots.
>
> The default implementation of the new method will simply look at
> getStatelessHint on the behavior, stateless means not a stable id. On
> ajax behaviors, this can be overridden to return true, even though the
> behavior can be stateless. The point is, that for a stateless
> behavior, this information is still stored in the component, which may
> also be stateless and not being able to store state at all. This is
> already the case in the current implementation, and will remain the
> same in my implementation. I'm trying to keep things as close to what
> it already was, but without having to store the additional
> BehaviorIdList.
>
> Emond
>
> On Thu, May 7, 2020 at 1:13 PM Sven Meier  wrote:
> >
> > Hi,
> >
> > we have a test for stateless behaviors:
> >
> > org.apache.wicket.ajax.markup.html.form.StatelessAjaxSubmitLinkTest
> >
> > We should just make sure it still works.
> >
> > Have fun
> > Sven
> >
> >
> > On 07.05.20 12:13, Andrea Del Bene wrote:
> > >
> > > On 07/05/20 10:37, Emond Papegaaij wrote:
> > >> Hi Martin,
> > >>
> > >> I know what these id's are for, and this still works as expected.
> > >> However, your claim about stable id's on stateless pages currently
> > >> does not work as you describe. The id's of behaviors is stored in the
> > >> component they are added to, also when the component is stateless. As
> > >> you said, a stateless page is discarded at the end of a request,
> > >> including the components and the recording of the stable id's. On the
> > >> next request, the page is reconstructed, but Wicket cannot guarantee
> > >> that the behavior id's are the same. For example, when you
> > >> conditionally add a behavior, it influences the id's of the behaviors
> > >> added after it. I want the documentation to reflect this, and use this
> > >> to optimize the code. IMHO there's no point in storing id's for
> > >> stateless behaviors for the next request. If you absolutely need this
> > >> guarantee, you should make your behavior stateful.
> > >>
> > >> One difference between my implementation and the current one is that
> > >> behaviors with stable id's are currently moved to the front.
> > >
> > > Hi Emond,
> > >
> > > I don't perfectly understand what you mean with 'moved to the front'.
> > > Could please explain it?
> > > To be clear about stateless beha

Re: Stable behavior ids

[Emond Papegaaij]

Hi Sven and Andrea,

Sven:
All tests still pass, I've also updated the ImmutableBehaviorIdsTest
with some additional checks. However, the tests I've seen so far are
not very exhaustive on this part. Many of them also pass with a bit of
luck :)

Andrea:
What I mean with 'moved to the front' is that a behavior with a stable
id is assigned a low number. For example, when you add these 4
behaviors in this order: class-x, class-y, an ajax link and a special
stateless behavior which uses its id, the ajax link will currently get
id 0. If you then request the id of class-y, it will get id 2 (just
after the special one). In my current implementation, the ajax link
will get id 2 and class-y will get 1 (using the index). I'm planning
to change this to move behaviors to the front when a stable id is
required. The special behavior can override this method to return
true, in which case the id's will be 0 for link, 1 for special, 2 for
class-x, 3 for class-y. The difference is this is that for the last 2,
this id is not guaranteed to be stable over requests. For example,
when class-x is removed somewhere during a request, class-y will get
id 2 on the next request, because the array storing the behaviors is
compacted, removing null-slots.

The default implementation of the new method will simply look at
getStatelessHint on the behavior, stateless means not a stable id. On
ajax behaviors, this can be overridden to return true, even though the
behavior can be stateless. The point is, that for a stateless
behavior, this information is still stored in the component, which may
also be stateless and not being able to store state at all. This is
already the case in the current implementation, and will remain the
same in my implementation. I'm trying to keep things as close to what
it already was, but without having to store the additional
BehaviorIdList.

Emond

On Thu, May 7, 2020 at 1:13 PM Sven Meier  wrote:
>
> Hi,
>
> we have a test for stateless behaviors:
>
> org.apache.wicket.ajax.markup.html.form.StatelessAjaxSubmitLinkTest
>
> We should just make sure it still works.
>
> Have fun
> Sven
>
>
> On 07.05.20 12:13, Andrea Del Bene wrote:
> >
> > On 07/05/20 10:37, Emond Papegaaij wrote:
> >> Hi Martin,
> >>
> >> I know what these id's are for, and this still works as expected.
> >> However, your claim about stable id's on stateless pages currently
> >> does not work as you describe. The id's of behaviors is stored in the
> >> component they are added to, also when the component is stateless. As
> >> you said, a stateless page is discarded at the end of a request,
> >> including the components and the recording of the stable id's. On the
> >> next request, the page is reconstructed, but Wicket cannot guarantee
> >> that the behavior id's are the same. For example, when you
> >> conditionally add a behavior, it influences the id's of the behaviors
> >> added after it. I want the documentation to reflect this, and use this
> >> to optimize the code. IMHO there's no point in storing id's for
> >> stateless behaviors for the next request. If you absolutely need this
> >> guarantee, you should make your behavior stateful.
> >>
> >> One difference between my implementation and the current one is that
> >> behaviors with stable id's are currently moved to the front.
> >
> > Hi Emond,
> >
> > I don't perfectly understand what you mean with 'moved to the front'.
> > Could please explain it?
> > To be clear about stateless behavior and ids, actually we can have a
> > "predictable" id for them if we avoid things like conditional adding,
> > etc... In short we can have stable ids for stateless behaviors but the
> > responsibility for them is up to the developer and not to the
> > framework. This is critical to make complex stateless components (for
> > example AJAX links) properly work. I guess your PR preserve this
> > condition. And yes, I agree there's no need for storing stateless
> > behaviors ids.
> >
> > Andrea.
> >> This
> >> makes the id's a bit more stable. I'm planning to do something
> >> similar, via a new method on Behavior. This should all be API
> >> compatible. I hope this clarifies my intent.
> >>
> >> Emond
> >>
> >> On Thu, May 7, 2020 at 9:23 AM Martin Grigorov 
> >> wrote:
> >>> Hi Emond,
> >>>
> >>> The behavior id is something internal to Wicket.
> >>> It is used *by* Wicket to find the requested behavior in a Component.
> >>> For example if a Component has more than one Ajax behaviors (yes, Ajax
> >>> behaviors could be stateless too since 7.4.0. 

Re: Stable behavior ids

[Emond Papegaaij]

Hi Martin,

I know what these id's are for, and this still works as expected.
However, your claim about stable id's on stateless pages currently
does not work as you describe. The id's of behaviors is stored in the
component they are added to, also when the component is stateless. As
you said, a stateless page is discarded at the end of a request,
including the components and the recording of the stable id's. On the
next request, the page is reconstructed, but Wicket cannot guarantee
that the behavior id's are the same. For example, when you
conditionally add a behavior, it influences the id's of the behaviors
added after it. I want the documentation to reflect this, and use this
to optimize the code. IMHO there's no point in storing id's for
stateless behaviors for the next request. If you absolutely need this
guarantee, you should make your behavior stateful.

One difference between my implementation and the current one is that
behaviors with stable id's are currently moved to the front. This
makes the id's a bit more stable. I'm planning to do something
similar, via a new method on Behavior. This should all be API
compatible. I hope this clarifies my intent.

Emond

On Thu, May 7, 2020 at 9:23 AM Martin Grigorov  wrote:
>
> Hi Emond,
>
> The behavior id is something internal to Wicket.
> It is used *by* Wicket to find the requested behavior in a Component.
> For example if a Component has more than one Ajax behaviors (yes, Ajax
> behaviors could be stateless too since 7.4.0. Before that there was a
> project in WicketStuff) it uses the id (extracted from the special
> parameter in the url) to find which behavior exactly should be invoked.
> In case of stateful page the ids are stored with page and later
> deserialized.
> In case of stateless page (with stateless Ajax behaviors) the whole page is
> discarded at the end of request 1 but at request 2 a new page is created
> from scratch with all its components and their behaviors. Here the id
> *must* be the same as in request 1, otherwise Wicket may execute another
> behavior's onRequest(). So, the ids must be stable in case of stateless as
> well.
>
>
>
> On Wed, May 6, 2020 at 9:28 PM Emond Papegaaij 
> wrote:
>
> > Hi,
> >
> > While running, I came up with a solution for which only a minor change
> > to the contract of the method is needed: ids for stateless behaviors
> > will be stable within a single requests, but can change over requests.
> > I think this is reasonable, given the way stateless components work.
> >
> > I would like to change the documentation to read:
> > Gets a stable id for the specified behavior. The id remains stable
> > from the point this method is first called for the behavior until the
> > behavior has been removed from the component. For {@linkplain
> > Behavior#getStatelessHint(Component) stateful} behaviors, this stable
> > id is retained over requests. For stateless behaviors, the id can
> > change between requests.
> >
> > Emond
> >
> > On Wed, May 6, 2020 at 5:54 PM Emond Papegaaij
> >  wrote:
> > >
> > > Hi Andrea,
> > >
> > > Stateful is fine, stateless is not. A component cannot keep a stable
> > > id when it's stateless. I'm trying out a change that forbids
> > > getBehaviorId() for stateless behaviors, and I'm hitting a few tests
> > > with stateless ajax. I don't see how this is supposed to work anyway.
> > > We request the component to store the id of a certain behavior, but it
> > > must do so in a stateless way. IMHO that's impossible. The component
> > > will be discarded, along with its state and the stored id at the end
> > > of the request. No way of guaranteeing that the same component with
> > > the same behavior at the same index will exist at the next request.
> > >
> > > This brings me back to my suggested change in the documentation: only
> > > stateful behaviors have guaranteed stable ids. You can request the id
> > > of a stateless behavior, but (in my current implementation) it may
> > > change when you remove behaviors from the component.
> > >
> > > Emond
> > >
> > > On Wed, May 6, 2020 at 5:41 PM Andrea Del Bene 
> > wrote:
> > > >
> > > >
> > > > On 06/05/20 16:52, Emond Papegaaij wrote:
> > > > > Hi all,
> > > > >
> > > > > During my refactoring of the component state (WICKET-6774) I noticed
> > > > > that behavior ids are currently stored in a very inefficient way: an
> > > > > ArrayList is added to Component data to store references to behaviors
> > > > > with a stable id. On my branch I have

Re: Stable behavior ids

[Emond Papegaaij]

Hi,

While running, I came up with a solution for which only a minor change
to the contract of the method is needed: ids for stateless behaviors
will be stable within a single requests, but can change over requests.
I think this is reasonable, given the way stateless components work.

I would like to change the documentation to read:
Gets a stable id for the specified behavior. The id remains stable
from the point this method is first called for the behavior until the
behavior has been removed from the component. For {@linkplain
Behavior#getStatelessHint(Component) stateful} behaviors, this stable
id is retained over requests. For stateless behaviors, the id can
change between requests.

Emond

On Wed, May 6, 2020 at 5:54 PM Emond Papegaaij
 wrote:
>
> Hi Andrea,
>
> Stateful is fine, stateless is not. A component cannot keep a stable
> id when it's stateless. I'm trying out a change that forbids
> getBehaviorId() for stateless behaviors, and I'm hitting a few tests
> with stateless ajax. I don't see how this is supposed to work anyway.
> We request the component to store the id of a certain behavior, but it
> must do so in a stateless way. IMHO that's impossible. The component
> will be discarded, along with its state and the stored id at the end
> of the request. No way of guaranteeing that the same component with
> the same behavior at the same index will exist at the next request.
>
> This brings me back to my suggested change in the documentation: only
> stateful behaviors have guaranteed stable ids. You can request the id
> of a stateless behavior, but (in my current implementation) it may
> change when you remove behaviors from the component.
>
> Emond
>
> On Wed, May 6, 2020 at 5:41 PM Andrea Del Bene  wrote:
> >
> >
> > On 06/05/20 16:52, Emond Papegaaij wrote:
> > > Hi all,
> > >
> > > During my refactoring of the component state (WICKET-6774) I noticed
> > > that behavior ids are currently stored in a very inefficient way: an
> > > ArrayList is added to Component data to store references to behaviors
> > > with a stable id. On my branch I have eliminated this ArrayList,
> > > greatly reducing the size of components with stateful behaviors (such
> > > as AjaxLink).
> > >
> > > A behavior gets a stable id when it is stateful to be able to render
> > > this id in an URL. However, at the moment, it also gets a stable id
> > > when Component.getBehaviorId is called for that particular behavior.
> > > This is also documented in the method's javadoc. Do we really need
> > > this last part? It complicates the code a lot. In our code base nor in
> > > Wicket can I find a single place where this is actually used.
> >
> > Actually I see that Component.getBehaviorId is used in
> > AbstractAjaxTimerBehavior.getTimerId() and
> > AbstractDefaultAjaxBehavior.onBind() which are however stateful behaviors.
> >
> > > I would like to suggest a change in the javadoc to state that stable
> > > ids are only guaranteed for stateful behaviors and change this in
> > > Wicket 9. The actual change in the implementation is not yet finished
> > > and does not need to ship in 9.0.0, but feel I cannot change the
> > > contract of a method in a minor release.
> > >
> > > Best regards,
> > > Emond

Re: Stable behavior ids

[Emond Papegaaij]

Hi Andrea,

Stateful is fine, stateless is not. A component cannot keep a stable
id when it's stateless. I'm trying out a change that forbids
getBehaviorId() for stateless behaviors, and I'm hitting a few tests
with stateless ajax. I don't see how this is supposed to work anyway.
We request the component to store the id of a certain behavior, but it
must do so in a stateless way. IMHO that's impossible. The component
will be discarded, along with its state and the stored id at the end
of the request. No way of guaranteeing that the same component with
the same behavior at the same index will exist at the next request.

This brings me back to my suggested change in the documentation: only
stateful behaviors have guaranteed stable ids. You can request the id
of a stateless behavior, but (in my current implementation) it may
change when you remove behaviors from the component.

Emond

On Wed, May 6, 2020 at 5:41 PM Andrea Del Bene  wrote:
>
>
> On 06/05/20 16:52, Emond Papegaaij wrote:
> > Hi all,
> >
> > During my refactoring of the component state (WICKET-6774) I noticed
> > that behavior ids are currently stored in a very inefficient way: an
> > ArrayList is added to Component data to store references to behaviors
> > with a stable id. On my branch I have eliminated this ArrayList,
> > greatly reducing the size of components with stateful behaviors (such
> > as AjaxLink).
> >
> > A behavior gets a stable id when it is stateful to be able to render
> > this id in an URL. However, at the moment, it also gets a stable id
> > when Component.getBehaviorId is called for that particular behavior.
> > This is also documented in the method's javadoc. Do we really need
> > this last part? It complicates the code a lot. In our code base nor in
> > Wicket can I find a single place where this is actually used.
>
> Actually I see that Component.getBehaviorId is used in
> AbstractAjaxTimerBehavior.getTimerId() and
> AbstractDefaultAjaxBehavior.onBind() which are however stateful behaviors.
>
> > I would like to suggest a change in the javadoc to state that stable
> > ids are only guaranteed for stateful behaviors and change this in
> > Wicket 9. The actual change in the implementation is not yet finished
> > and does not need to ship in 9.0.0, but feel I cannot change the
> > contract of a method in a minor release.
> >
> > Best regards,
> > Emond

Stable behavior ids

[Emond Papegaaij]

Hi all,

During my refactoring of the component state (WICKET-6774) I noticed
that behavior ids are currently stored in a very inefficient way: an
ArrayList is added to Component data to store references to behaviors
with a stable id. On my branch I have eliminated this ArrayList,
greatly reducing the size of components with stateful behaviors (such
as AjaxLink).

A behavior gets a stable id when it is stateful to be able to render
this id in an URL. However, at the moment, it also gets a stable id
when Component.getBehaviorId is called for that particular behavior.
This is also documented in the method's javadoc. Do we really need
this last part? It complicates the code a lot. In our code base nor in
Wicket can I find a single place where this is actually used.

I would like to suggest a change in the javadoc to state that stable
ids are only guaranteed for stateful behaviors and change this in
Wicket 9. The actual change in the implementation is not yet finished
and does not need to ship in 9.0.0, but feel I cannot change the
contract of a method in a minor release.

Best regards,
Emond

Re: Time to release 9.0.0 ?

[Emond Papegaaij]

Fine with me, +1 to release then

Op do 30 apr. 2020 14:33 schreef Martin Grigorov :

> On Thu, Apr 30, 2020 at 2:19 PM Emond Papegaaij  >
> wrote:
>
> > +0 to release
> >
> > The rewrite I'm currently doing is API compatible. I'm nearly finished
> > though, so if we can wait one more day, I should be able to get it all
> > working.
> >
>
> If it is API compatible then it can be added in 9.0.1
> I really do not want to add such changes in the last moment.
> Better add it once 9.0.0 is released and we can test it before 9.0.1.
>
>
> > Emond
> >
> > On Thu, Apr 30, 2020 at 12:07 PM Sven Meier  wrote:
> > >
> > > +1 we have to cut it somewhere
> > >
> > > Sven
> > >
> > >
> > > On 30.04.20 11:57, Andrea Del Bene wrote:
> > > > +1 to release. The current state of 9.x is very stable and IMHO it
> > > > shouldn't be delayed for major developments or refactoring.
> > > >
> > > > On 30/04/20 10:04, Tobias Soloschenko wrote:
> > > >> +1 - lets release
> > > >>
> > > >> kind regards
> > > >>
> > > >> Tobias
> > > >>
> > > >>> Am 30.04.2020 um 09:43 schrieb Maxim Solodovnik <
> > solomax...@gmail.com>:
> > > >>>
> > > >>> +1
> > > >>> let's release final version :)
> > > >>>
> > > >>>> On Thu, 30 Apr 2020 at 14:40, Martin Grigorov
> > > >>>>  wrote:
> > > >>>>
> > > >>>> Hi team,
> > > >>>>
> > > >>>> Few weeks have passed since Wicket 9.0.0-M5 and there are no
> > > >>>> stopper issues
> > > >>>> being reported.
> > > >>>> Let's release 9.0.0!
> > > >>>>
> > > >>>> I see few of you discuss refactoring some pretty critical area
> (from
> > > >>>> performance PoV) of Wicket - the Component state, and suggesting
> > some
> > > >>>> bigger refactoring. I'd like this refactoring to be left for a
> later
> > > >>>> release. If there are no API breaks it could be 9.0.1 but if there
> > > >>>> will API
> > > >>>> breaks then it will have to wait for Wicket 10.
> > > >>>>
> > > >>>> WDYT ?
> > > >>>>
> > > >>>> Martin
> > > >>>
> > > >>>
> > > >>> --
> > > >>> Best regards,
> > > >>> Maxim
> >
>

Re: Time to release 9.0.0 ?

[Emond Papegaaij]

+0 to release

The rewrite I'm currently doing is API compatible. I'm nearly finished
though, so if we can wait one more day, I should be able to get it all
working.

Emond

On Thu, Apr 30, 2020 at 12:07 PM Sven Meier  wrote:
>
> +1 we have to cut it somewhere
>
> Sven
>
>
> On 30.04.20 11:57, Andrea Del Bene wrote:
> > +1 to release. The current state of 9.x is very stable and IMHO it
> > shouldn't be delayed for major developments or refactoring.
> >
> > On 30/04/20 10:04, Tobias Soloschenko wrote:
> >> +1 - lets release
> >>
> >> kind regards
> >>
> >> Tobias
> >>
> >>> Am 30.04.2020 um 09:43 schrieb Maxim Solodovnik :
> >>>
> >>> +1
> >>> let's release final version :)
> >>>
>  On Thu, 30 Apr 2020 at 14:40, Martin Grigorov
>   wrote:
> 
>  Hi team,
> 
>  Few weeks have passed since Wicket 9.0.0-M5 and there are no
>  stopper issues
>  being reported.
>  Let's release 9.0.0!
> 
>  I see few of you discuss refactoring some pretty critical area (from
>  performance PoV) of Wicket - the Component state, and suggesting some
>  bigger refactoring. I'd like this refactoring to be left for a later
>  release. If there are no API breaks it could be 9.0.1 but if there
>  will API
>  breaks then it will have to wait for Wicket 10.
> 
>  WDYT ?
> 
>  Martin
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Maxim

Re: CSP regression

[Emond Papegaaij]

Hi Maxim,

Are you sure? I just tried the examples and CSS resources do have
nonces. Maybe you're seeing the same errors as I when opening the dev
tools? Somehow Chrome is unable to load the css resources in the dev
tools when the dev tools are opened after loading the page. After a
refresh, it's fine again.

Emond

On Tue, Mar 24, 2020 at 8:53 AM Maxim Solodovnik  wrote:
>
> Hello All,
>
> just found regression with CSP
> nonce for CSS resources seems to be not added, which results security errors
> Can it be caused by latest code optimizations?
>
> --
> WBR
> Maxim aka solomax

Re: WICKET-6725 styling of hidden elements: no vote yet

[Emond Papegaaij]

>>>
> > > >>>>>>> 1.
> > > >>>>>>>
> > > >>
> > > https://github.com/apache/wicket/blob/10d10a92dda2e5834508f52d7807fe361f20fbea/wicket-core/src/main/java/org/apache/wicket/Component.java#L2370
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> On Thu, Mar 12, 2020 at 4:35 PM Sven Meier 
> > > wrote:
> > > >>>>>>>
> > > >>>>>>>> Hi all,
> > > >>>>>>>>
> > > >>>>>>>> I've looked at all responses and most arguments in favor of a
> > > >> "core.css"
> > > >>>>>>>> boil down to:
> > > >>>>>>>>
> > > >>>>>>>> > `hidden` attribute doesn't work (even `display: flex` 
> > > >>>>>>>> breaks
> > > >> it)
> > > >>>>>>>> > Using the hidden attribute puts the responsibility with the
> > > >> developer
> > > >>>>>>>> > where this should be on the framework. The hidden attribute
> > > >> just
> > > >>>>>>>> doesn't work.
> > > >>>>>>>>
> > > >>>>>>>> > When something as simple as using flex or display:block on 
> > > >>>>>>>> a
> > > >> div breaks
> > > >>>>>>>> > the hidden attribute [1] we should not depend on it 
> > > >>>>>>>> working.
> > > >>>>>>>>
> > > >>>>>>>> Sorry, but I don't share that assessment: 'hidden' works just
> > > fine!
> > > >>>>>>>> Every browser supports it and it has a strong semantic meaning we
> > > >> can
> > > >>>>>>>> utilize.
> > > >>>>>>>>
> > > >>>>>>>> If you (or your web designer) decides to style hidden elements as
> > > >>>>>>>> floating, static, flex, pink or with marquee ... feel free to do
> > > so.
> > > >>>>>>>>
> > > >>>>>>> No. The web designer styles the element when it is supposed to be
> > > >> visible.
> > > >>>>>>> But then when some condition is met Wicket may render it as a
> > > >> placeholder
> > > >>>>>>> for Ajax requests and then this element will be rendered.
> > > >>>>>>> It does not have text content but the CSS rules will be still
> > > >> applied and
> > > >>>>>>> the web designer will have to add more rules for the cases when
> > > >> 'hidden' is
> > > >>>>>>> there.
> > > >>>>>>> Most probably something like:
> > > >>>>>>> div[hidden] {
> > > >>>>>>>   display:none;
> > > >>>>>>> }
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>> Wicket doesn't need to ship a CSS file to fix anything here.
> > > >>>>>>>> Note that the way we are hiding components in Wicket never 
> > > >>>>>>>> exposes
> > > >> any
> > > >>>>>>>> sensible information anyways. This topic is just about layout and
> > > >>>>>>>> styling and that is completely in the responsibility of your
> > > >> developer
> > > >>>>>>>> ...  and works out-of-the-box if you don't break it!
> > > >>>>>>>>
> > > >>>>>>> What about the cases when the children need to be invisible ?
> > > >>>>>>> .wicket--hidden-fields
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>> >Wicket ... has been dependent on its own styles, spread out
> > > >> through
> > > >>>>>>>> our code in odd ways
> > > >>>>>>>> > I consider not having a wicket stylesheet file a bug, not a
> > > >> feature
> > > >>>>>>>> I couldn't disagree more. These "odd ways" is one of many cool
> > > >> features
> > > >>>>>>>> of Wicket named "components". BTW we Wicket devs have never been
> > > >> very
> > > >>>>>>>> successful in crafting CSS anyways, we shouldn't start with this
> > > >> now :P.
> > > >>>>>>> We don't really start.
> > > >>>>>>> We do not mandate styling. We just hide whatever is supposed to be
> > > >> hidden.
> > > >>>>>>> Nothing more.
> > > >>>>>>>
> > > >>>>>>> As agreed (?!) earlier .wicket--color-red should be just a marker
> > > CSS
> > > >>>>>>> class. The content should be provided by the application. Just 
> > > >>>>>>> like
> > > >>>>>>> FeedbackPanel's CSS classes. I will remove it now!
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>> I'll start a vote soon.
> > > >>>>>>>>
> > > >>>>>>>> Sidenote : This doesn't mean I'm against the CSP feature in
> > > general!
> > > >>>>>>>> After some iterations we arrived at a very cool solution (with
> > > some
> > > >>>>>>>> minor detail questions remaining).
> > > >>>>>>>>
> > > >>>>>>>> Have fun
> > > >>>>>>>> Sven
> > > >>>>>>>>
> > > >>>>>>>> On 27.02.20 22:18, Emond Papegaaij wrote:
> > > >>>>>>>>> Hi Andrew,
> > > >>>>>>>>>
> > > >>>>>>>>> I thought of this solution as well and it will work. The major
> > > >>>>>>>>> advantage is that the styling is only added when it is actually
> > > >> used.
> > > >>>>>>>>> But it requires significantly more work to build and is a lot
> > > more
> > > >>>>>>>>> complex than the current solution. For this, we need some place
> > > to
> > > >>>>>>>>> accumulate element styling, like we do for JS event handlers.
> > > This
> > > >>>>>>>>> then needs to be rendered in the response.
> > > >>>>>>>>>
> > > >>>>>>>>> The most complex part is ajax updates. These might change some 
> > > >>>>>>>>> of
> > > >> the
> > > >>>>>>>>> styling. Simply replacing the style element will not work,
> > > because
> > > >> in
> > > >>>>>>>>> an ajax request only the added components are rendered.
> > > Rendering a
> > > >>>>>>>>> style element per component will work, but is far from ideal.
> > > This
> > > >> is
> > > >>>>>>>>> why I went for the easy solution.
> > > >>>>>>>>>
> > > >>>>>>>>> Emond
> > > >>>>>>>>>
> > > >>>>>>>>> On Thu, Feb 27, 2020 at 10:08 PM Andrew Kondratev <
> > > >> and...@kondratev.pro>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>> Just as a brainstorm. Not sure if it's a good idea.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Wicket potentially can add nounced style to the document with
> > > >> hidden
> > > >>>>>>>>>> elements hidden by id.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Imagine generated HTML has components like these
> > > >>>>>>>>>> 
> > > >>>>>>>>>>  > > >>>>>>>>>> class="wupb-border"> > > >>>>>>>>>> class="wupb-foreground">
> > > >>>>>>>>>> 
> > > >>>>>>>>>> 
> > > >>>>>>>>>>
> > > >>>>>>>>>> #ida and #id9 must be hidden, so in the page header we add
> > > >> something
> > > >>>>>>>> like
> > > >>>>>>>>>> this
> > > >>>>>>>>>>
> > > >>>>>>>>>> 
> > > >>>>>>>>>> #ida, #id9 {display: none;}
> > > >>>>>>>>>> 
> > > >>>>>>>>>>
> > > >>>>>>>>>> Even if the  wupb-progressBar  has display: flex, the #ida will
> > > >> win.
> > > >>>>>>>> Will
> > > >>>>>>>>>> win even over  #id8 .wupb-progressBar {display: fles}
> > > >>>>>>>>>>
> > > >>>>>>>>>> !important can potentially be added.
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> чт, 27 февр. 2020 г. в 23:56, Ernesto Reinaldo Barreiro <
> > > >>>>>>>> reier...@gmail.com
> > > >>>>>>>>>>> :
> > > >>>>>>>>>>> Hi,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
> > > >>>>>>>> an.delb...@gmail.com>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> > > >>>>>>>>>>>> reier...@gmail.com> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> Hi,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Right now I have no enough knowledge to vote in this 
> > > >>>>>>>>>>>>> feature.
> > > >> One
> > > >>>>>>>>>>> thing I
> > > >>>>>>>>>>>>> didn't like, and I already mentioned it before, is some of 
> > > >>>>>>>>>>>>> us
> > > >> were
> > > >>>>>>>>>>>> waiting
> > > >>>>>>>>>>>>> for 9.x to be released some time ago (at least a few months
> > > >> ago I
> > > >>>>>>>> was
> > > >>>>>>>>>>>>> preparing some branch of our application and ported it to
> > > 9.x,
> > > >> after
> > > >>>>>>>>>>>> asking
> > > >>>>>>>>>>>>> about release plans) and all of the sudden this feature is
> > > >>>>>>>> introduced
> > > >>>>>>>>>>> and
> > > >>>>>>>>>>>>> all sub-frameworks depending on Wicket will have to be
> > > adapted.
> > > >>>>>>>>>>>> In which way sub-frameworks should be affected? I mean, as 
> > > >>>>>>>>>>>> far
> > > >> as I
> > > >>>>>>>>>>>> understand it, if we disable CSP blocking configuration
> > > >> everything
> > > >>>>>>>> should
> > > >>>>>>>>>>>> work "the old way", and that's why I would prefer to keep CSP
> > > >>>>>>>> disabled by
> > > >>>>>>>>>>>> default.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>> Well if something is supported at core level then if 
> > > >>>>>>>>>>> associated
> > > >>>>>>>> projects
> > > >>>>>>>>>>> want to comply with this new feature, which might be ideal,
> > > then
> > > >>>>>>>> they will
> > > >>>>>>>>>>> have to be adapted (or not?). I'm not talking about not
> > > >> releasing the
> > > >>>>>>>> new
> > > >>>>>>>>>>> feature. I'm talking about not releasing as part of 9.x, as it
> > > >> was
> > > >>>>>>>> said to
> > > >>>>>>>>>>> be almost ready for release a few months ago, and deffer it to
> > > >> 10.x
> > > >>>>>>>> (and
> > > >>>>>>>>>>> try to release it soon).
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> --
> > > >>>>>>>>>>> Regards - Ernesto Reinaldo Barreiro
> > > >>>>>>>>>>>
> > > >>>
> > >
>
>
>
> --
> WBR
> Maxim aka solomax

Re: [wicket] branch master updated: WICKET-6727: only render CSP on RenderPageRequestHandler

[Emond Papegaaij]

Yes, you are right. Martin beat me in fixing it :) The file had some
formatting issues, so I pressed Ctrl-Shift-F, forgot about the
license.

Emond

On Fri, Mar 13, 2020 at 10:03 AM Maxim Solodovnik  wrote:
>
> Hello Edmond,
>
> It seems you accidentally re-format license header ...
>
> On Fri, 13 Mar 2020 at 15:44,  wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > papegaaij pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/wicket.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >  new 1619809  WICKET-6727: only render CSP on RenderPageRequestHandler
> > 1619809 is described below
> >
> > commit 16198099d8a965f17c85d2de7a6dce36b000ec26
> > Author: Emond Papegaaij 
> > AuthorDate: Fri Mar 13 09:44:36 2020 +0100
> >
> > WICKET-6727: only render CSP on RenderPageRequestHandler
> > ---
> >  .../apache/wicket/csp/CSPRequestCycleListener.java |  8 +--
> >  .../apache/wicket/examples/csp/NonceDemoPage.html  |  1 +
> >  .../apache/wicket/examples/csp/NonceDemoPage.java  | 71 
> > --
> >  3 files changed, 45 insertions(+), 35 deletions(-)
> >
> > diff --git 
> > a/wicket-core/src/main/java/org/apache/wicket/csp/CSPRequestCycleListener.java
> >  
> > b/wicket-core/src/main/java/org/apache/wicket/csp/CSPRequestCycleListener.java
> > index f0acc52..3250174 100644
> > --- 
> > a/wicket-core/src/main/java/org/apache/wicket/csp/CSPRequestCycleListener.java
> > +++ 
> > b/wicket-core/src/main/java/org/apache/wicket/csp/CSPRequestCycleListener.java
> > @@ -16,8 +16,8 @@
> >   */
> >  package org.apache.wicket.csp;
> >
> > -import 
> > org.apache.wicket.core.request.handler.BufferedResponseRequestHandler;
> >  import org.apache.wicket.core.request.handler.IPageClassRequestHandler;
> > +import org.apache.wicket.core.request.handler.RenderPageRequestHandler;
> >  import org.apache.wicket.request.IRequestHandler;
> >  import org.apache.wicket.request.IRequestHandlerDelegate;
> >  import org.apache.wicket.request.cycle.IRequestCycleListener;
> > @@ -81,11 +81,11 @@ public class CSPRequestCycleListener implements 
> > IRequestCycleListener
> > {
> > return 
> > mustProtect(((IRequestHandlerDelegate)handler).getDelegateHandler());
> > }
> > -   if (handler instanceof IPageClassRequestHandler)
> > +   if (handler instanceof RenderPageRequestHandler)
> > {
> > -   return 
> > settings.mustProtectPageRequest((IPageClassRequestHandler)handler);
> > +   return 
> > settings.mustProtectPageRequest((RenderPageRequestHandler)handler);
> > }
> > -   return !(handler instanceof BufferedResponseRequestHandler);
> > +   return false;
> > }
> >
> >  }
> > diff --git 
> > a/wicket-examples/src/main/java/org/apache/wicket/examples/csp/NonceDemoPage.html
> >  
> > b/wicket-examples/src/main/java/org/apache/wicket/examples/csp/NonceDemoPage.html
> > index 32549a7..d22b416 100644
> > --- 
> > a/wicket-examples/src/main/java/org/apache/wicket/examples/csp/NonceDemoPage.html
> > +++ 
> > b/wicket-examples/src/main/java/org/apache/wicket/examples/csp/NonceDemoPage.html
> > @@ -13,6 +13,7 @@
> >  
> >  
> >  Click a button above to replace this 
> > text
> > +This text will stay black even though 
> > color:red is added by the button above
> >> wicket:id="clickMeCount">
> >  
> >  This delayed 
> > shown text should be green and bold
> > diff --git 
> > a/wicket-examples/src/main/java/org/apache/wicket/examples/csp/NonceDemoPage.java
> >  
> > b/wicket-examples/src/main/java/org/apache/wicket/examples/csp/NonceDemoPage.java
> > index dce8079..4fe81b0 100644
> > --- 
> > a/wicket-examples/src/main/java/org/apache/wicket/examples/csp/NonceDemoPage.java
> > +++ 
> > b/wicket-examples/src/main/java/org/apache/wicket/examples/csp/NonceDemoPage.java
> > @@ -1,21 +1,16 @@
> >  /*
> > - * Licensed to the Apache Software Foundation (ASF) under one or more
> > - * contributor license agreements.  See the NOTICE file distributed with
> > - * this work for additional information regarding copyright ownership.
> > - * The ASF licenses this file to You under the Apache License, Version 2.0
> > - * (

Re: CSPRequestCycleListener headers

[Emond Papegaaij]

I've changed the code. From what I can see, the header is now only set
once per request. It could be there some exceptions to this, for
example when the request is restarted during rendering. IMHO that's
not a big issue, because the header is still added only once.

I've also added a demo-case to the CSP example that shows that CSP
protection still works in ajax requests.

Best regards,
Emond

On Fri, Mar 13, 2020 at 9:18 AM Emond Papegaaij
 wrote:
>
> Hi Sven,
>
> I've reread the spec a bit more precise last night. I think we can
> change the code to only set the header on a RenderPageRequestHandler.
> The CSP is taken from the page and applies to all resources loaded by
> that page. The only exceptions are child-contexts: iframes, objects
> and js-workers. For iframes, Wicket will render a new page and thus
> set the CSP. This only leaves objects and js-workers, which IMHO are
> quite rare. I'm not sure if the child-context will inherit the CSP
> from the page if it's not set. I couldn't find this in the spec.
>
> The reason to use a header is that it is the recommended method of
> delivery for the CSP. The meta tag has some problems, for example when
> resources show up before the tag.
>
> I'll give the above a try and see if it works.
>
> Best regards,
> Emond
>
> On Thu, Mar 12, 2020 at 9:40 PM Sven Meier  wrote:
> >
> > Hi Emond,
> >
> > for me setting the appropriate headers is part of rendering.
> >
> > I've just tried setting HTTP CSP headers from
> > CSPNonceHeaderResponseDecorator, and that almost works (with minor
> > changes to HtmlHeaderContainer, which currently doesn't allow setting of
> > headers during rendering).
> >
> > Before you took over, CSPNonceHeaderResponseDecorator wrote the CSP
> > headers in http-equiv  tags.
> > What was your reason to change this to HTTP headers in the first place?
> >
> > Regards
> > Sven
> >
> >
> > On 12.03.20 14:02, Emond Papegaaij wrote:
> > > Hi Sven,
> > >
> > > Yes, you might be right. When rendering another page, normally the
> > > header will be overridden when the second handler is resolved.
> > > However, this will not happen when the page is not protected
> > > (protectedPageFilter). Do you see a solution for this? Maybe recording
> > > the desired action in the RequestCycle per handler, so the last
> > > handler will always override the previous one? The action can then be
> > > performed in onEndRequest. It would be nice if we had some tests for
> > > this, but I'm not that experienced in writing tests with WicketTester
> > > :)
> > >
> > > Setting the header on a resource usually doesn't make sense, but
> > > doesn't hurt either. I haven't found a clear explanation of how CSP
> > > values interact across requests. For example, for js you can use
> > > strict-dynamic, but this doesn't apply to CSS, which breaks CSS loaded
> > > via js.
> > >
> > > Best regards,
> > > Emond
> > >
> > > On Thu, Mar 12, 2020 at 12:28 PM Sven Meier  wrote:
> > >> Hi Emond,
> > >>
> > >> it seems to me the CSPRequestCycleListener might add CSP headers
> > >> prematurely.
> > >>
> > >> What if a request comes in for one page and another page is rendered in
> > >> response?
> > >> The listener will already add the headers when the request handler is
> > >> resolved for the former page.
> > >>
> > >> What if the page streams back a resource? Setting the headers doesn't
> > >> make sense then, does it?
> > >>
> > >> Sven
> > >>

Re: Why jakarta.enterprise.cdi-api has "provided" scope ?

[Emond Papegaaij]

Looking at the examples, I think the packaging currently is wrong. The
examples package weld (cdi implementation), but rely on a provided
cdi-api. The cdi-api should simply be added as a compile dependency to
the examples.

Emond

On Fri, Mar 13, 2020 at 2:59 AM Maxim Solodovnik  wrote:
>
> Maybe this dependency can be added to dependencies of jetty-maven-plugin ?
>
> On Thu, 12 Mar 2020 at 23:23, Martin Grigorov  wrote:
> >
> > On Thu, Mar 12, 2020, 16:41 Martijn Dashorst 
> > wrote:
> >
> > > Because it is, just like the servlet-api, a specification that is provided
> > > by the container. When your container does not supply that specification,
> > > you have to override the scope yourself and supply the API that way. E.G.
> > > Wildfly supplies that API, as does Glassfish, etc.
> > >
> > > The examples could override the scope, but not sure if that is the correct
> > > answer for all deployments.
> > >
> >
> > Which deployments do we want to support for the examples?
> > Since a while "mvn jetty:run" does not work because of CDI. Now Tomcat too.
> > I suggest to either add this dependency or remove the CDI example.
> >
> >
> > > Martijn
> > >
> > >
> > > On Thu, Mar 12, 2020 at 3:17 PM Martin Grigorov 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Does anyone know why jakarta.enterprise:jakarta.enterprise.cdi-api
> > > > dependency [1] has provided
> > > > scope in dependency management ?
> > > > I'm hitting NoClassDefFoundError
> > > > for javax.enterprise.inject.spi.BeanManager while deploying
> > > > wicket-examples.war in Tomcat.
> > > >
> > > >
> > > > 1.
> > > >
> > > >
> > > https://github.com/apache/wicket/blob/1245ee2998930f3b9169ca8afa4018d49e2346e4/pom.xml#L221-L226
> > > >
> > >
> > >
> > > --
> > > Become a Wicket expert, learn from the best: http://wicketinaction.com
> > >
>
>
>
> --
> WBR
> Maxim aka solomax

Re: CSPRequestCycleListener headers

[Emond Papegaaij]

Hi Sven,

I've reread the spec a bit more precise last night. I think we can
change the code to only set the header on a RenderPageRequestHandler.
The CSP is taken from the page and applies to all resources loaded by
that page. The only exceptions are child-contexts: iframes, objects
and js-workers. For iframes, Wicket will render a new page and thus
set the CSP. This only leaves objects and js-workers, which IMHO are
quite rare. I'm not sure if the child-context will inherit the CSP
from the page if it's not set. I couldn't find this in the spec.

The reason to use a header is that it is the recommended method of
delivery for the CSP. The meta tag has some problems, for example when
resources show up before the tag.

I'll give the above a try and see if it works.

Best regards,
Emond

On Thu, Mar 12, 2020 at 9:40 PM Sven Meier  wrote:
>
> Hi Emond,
>
> for me setting the appropriate headers is part of rendering.
>
> I've just tried setting HTTP CSP headers from
> CSPNonceHeaderResponseDecorator, and that almost works (with minor
> changes to HtmlHeaderContainer, which currently doesn't allow setting of
> headers during rendering).
>
> Before you took over, CSPNonceHeaderResponseDecorator wrote the CSP
> headers in http-equiv  tags.
> What was your reason to change this to HTTP headers in the first place?
>
> Regards
> Sven
>
>
> On 12.03.20 14:02, Emond Papegaaij wrote:
> > Hi Sven,
> >
> > Yes, you might be right. When rendering another page, normally the
> > header will be overridden when the second handler is resolved.
> > However, this will not happen when the page is not protected
> > (protectedPageFilter). Do you see a solution for this? Maybe recording
> > the desired action in the RequestCycle per handler, so the last
> > handler will always override the previous one? The action can then be
> > performed in onEndRequest. It would be nice if we had some tests for
> > this, but I'm not that experienced in writing tests with WicketTester
> > :)
> >
> > Setting the header on a resource usually doesn't make sense, but
> > doesn't hurt either. I haven't found a clear explanation of how CSP
> > values interact across requests. For example, for js you can use
> > strict-dynamic, but this doesn't apply to CSS, which breaks CSS loaded
> > via js.
> >
> > Best regards,
> > Emond
> >
> > On Thu, Mar 12, 2020 at 12:28 PM Sven Meier  wrote:
> >> Hi Emond,
> >>
> >> it seems to me the CSPRequestCycleListener might add CSP headers
> >> prematurely.
> >>
> >> What if a request comes in for one page and another page is rendered in
> >> response?
> >> The listener will already add the headers when the request handler is
> >> resolved for the former page.
> >>
> >> What if the page streams back a resource? Setting the headers doesn't
> >> make sense then, does it?
> >>
> >> Sven
> >>

Re: CSPRequestCycleListener headers

[Emond Papegaaij]

Hi Sven,

Yes, you might be right. When rendering another page, normally the
header will be overridden when the second handler is resolved.
However, this will not happen when the page is not protected
(protectedPageFilter). Do you see a solution for this? Maybe recording
the desired action in the RequestCycle per handler, so the last
handler will always override the previous one? The action can then be
performed in onEndRequest. It would be nice if we had some tests for
this, but I'm not that experienced in writing tests with WicketTester
:)

Setting the header on a resource usually doesn't make sense, but
doesn't hurt either. I haven't found a clear explanation of how CSP
values interact across requests. For example, for js you can use
strict-dynamic, but this doesn't apply to CSS, which breaks CSS loaded
via js.

Best regards,
Emond

On Thu, Mar 12, 2020 at 12:28 PM Sven Meier  wrote:
>
> Hi Emond,
>
> it seems to me the CSPRequestCycleListener might add CSP headers
> prematurely.
>
> What if a request comes in for one page and another page is rendered in
> response?
> The listener will already add the headers when the request handler is
> resolved for the former page.
>
> What if the page streams back a resource? Setting the headers doesn't
> make sense then, does it?
>
> Sven
>

Re: [VOTE] Release Apache Wicket 9.0.0-M5

[Emond Papegaaij]

Hi,

Agreed, but first, the documentation needs to be updated with the new
API. I like most of the changes, except for the new method name for
'getContentSecurityPolicySettings()'. IMHO it's too long and everyone
calls it CSP. I'd rather stick with 'getCspSettings()'. The
documentation in 'ContentSecurityPolicySettings' is already missing
'Policy'.

Best regards,
Emond

On Thu, Mar 12, 2020 at 8:16 AM Martin Grigorov  wrote:
>
> Hi,
>
> Sven just made some API breaking changes with
> https://gitbox.apache.org/repos/asf?p=wicket.git;h=88e8d36, for good!
> If we want the next release to be the final one then I suggest to cancel
> this vote and start over with the new change.
>
> Martin
>
> On Tue, Mar 10, 2020 at 10:50 PM Andrea Del Bene 
> wrote:
>
> > This is a vote to release Apache Wicket 9.0.0-M5
> >
> > 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.0.0-M5
> > [ ] No, don't release Apache Wicket 9.0.0-M5, because ...
> >
> > Distributions, changelog, keys and signatures can be found at:
> >
> >  https://dist.apache.org/repos/dist/dev/wicket/9.0.0-M5
> >
> > Staging repository:
> >
> > https://repository.apache.org/content/repositories/orgapachewicket-1137/
> >
> > 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.0.0-M5
> >  Release tag: rel/wicket-9.0.0-M5
> >
> >
> > 
> >
> >  The signatures for the source release artefacts:
> >
> >
> > Signature for apache-wicket-9.0.0-M5.zip:
> >
> >  -BEGIN PGP SIGNATURE-
> >
> > iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAl5n/CoACgkQh48B+qjT
> > VuHd2RAAijpTFLBY5tr9GOjZPk0y//Kog/8IYi9dJjkOtJtFky7UhNzlmFVx7Yz7
> > hbc5ecLeeXz3oLZHkECjKda5086aopXzFzsS8jLQM1/yqZ4jD2zd1E7evw+Kxj+v
> > cOi6+XxV8m508R7qs8pob9rs5Z/wfDocEOvVBM4SNxFCmFxENUvwImgEq89Vg2pQ
> > iMjFK2zUk4L82cc1hEN3+GKfe1LvnlDJIp2ebP+ntlBr8Nrc7MR/jOrJxSRr+wBp
> > /U6y9jEVSuR5rrN4KKFvSLDfGOdOvug6JVhzVFJ6lKjqSKPNQ4Ml+ZWe2cEdu/qD
> > VYEn4kaioVX539424HugXQK1Z4jvNA0NJVmvWuYOsZYQeRGlccOzAsgXuYUNFllR
> > UmCw1mpFLz0OMSfFdv125gj4MxSOsl+H5eY4LJuZWBfk/6BXRBDINJo4kjaq7tq1
> > GLfVoHB5dvrDp3R9WsFzGQJA4InrF8w+/m08p1haRiny0Vqch4s/zTG82nrp9bPR
> > Iyrt97SAWquXeMwRXqdA68cBvB5UjTkbdI6BtP7pNMGtklaV2R9vbdU18opIJf0K
> > ANzjxROr+DkgEcmthLIKlkErKr+UfeAZU84lRMfaD4QlWFB4jmwW+BEBiCMUSia2
> > 8IHaOJ8OBMXuBD7dK9dnpm6FoOY8qCYGAwBPzM5l2bzj+50s9a0=
> > =qrHX
> > -END PGP SIGNATURE-
> >
> > Signature for apache-wicket-9.0.0-M5.tar.gz:
> >
> >  -BEGIN PGP SIGNATURE-
> >
> > iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAl5n/CkACgkQh48B+qjT
> > VuHvRA//ekwcb/9Lb1q1g33chXIpXAxXQJe/mOdX2rDPQUQIN2Diw8V2a9ZuFdFb
> > 7AUKXfMHBk9zOZO7HKWI1FBUp0UW9VC8p4ut+5ssBWjEaF/FKxzh/rG4J7vG9Tul
> > oD6KlAE4h7dx/lERbpKZy9Vs/Po65+oIypf3sD+iVFms7I0jxiE/81P8kMSEuD2S
> > l4pzXnKmMkuzfSkTJLOak6K6Rho8a+rsvWzr/NjG3yJ23M04Oi589Eft66MEMZFw
> > N8VgWRuBBIQkIzIlCmLu1xTbk/j95Qnt5lgCs2E4gCVfH0qlmsTroFVCjDW97WEX
> > /Iq7Dk0XUjMP7u9d+JXceLObFVi8/rng803M260h2WbRC0zbSq78RSdDk1fNQWlM
> > 5OXvS2Q0dp73+gn1VBc3lt/7TzUeIzq2aQlG3GsOBTH3ZU+G8HCaGmIL7b4Ge27J
> > rtxLG6bnBIEXmr96cDXPDqdIuthMCIHB1DcitHPDCyHISXXCC+1ZJXcLACi/dgVF
> > trbjJJFpaVYQeNLFLUYZZZzvCUFClAfE47ieSRmWUIjMNn2Ob6EslYHqK7qxlbzE
> > eUFSkhpfzU31RGXoaEwTJLe8uweIJ/lWouy8PajsiMGmVHeWjorMn37UTLoZxIKo
> > uUHpAZoFp1DHYPqOWPPxrymHctYEMAtSfbmLSV590qaCIYr3fiw=
> > =UkVf
> > -END PGP SIGNATURE-
> >
> > 
> >
> >  CHANGELOG for 9.0.0-M5:
> >
> > ** Bug
> >
> >  * [WICKET-6745] - CSP: inline JS in server and client time response
> > filters
> >  * [WICKET-6746] - HttpsMapper cannot deal with resources over
> > websockets
> >  * [WICKET-6752] - Some dependencies contain CVEs
> >  * [WICKET-6753] - res/modal.js using aria-labelledby where it
> > should be using aria-label
> >  * [WICKET-6754] - Iteration stops with nested containers
> >
> > ** New Feature
> >
> >  * [WICKET-6727] - Configurable CSP
> >  * [WICKET-6729] - allow adding IHeaderResponseDecorator without
> > replacing all others
> >  * [WICKET-6730] - Global access to secure random data
> >
> > ** Improvement
> >
> >  * [WICKET-6724] - CSP: Inline Javascript in AjaxLink
> >  * [WICKET-6725] - CSP: display:none in Component.renderPlaceholderTag
> >  * [WICKET-6726] - CSP: inline styling and js in Form submitbutton
> > handling
> >  * [WICKET-6731] - CSP: inline JS in SubmitLink
> >  * [WICKET-6732] - CSP: 

Re: CSP and UI libraries

[Emond Papegaaij]

Hi Sebastien,

Unfortunately, not all libraries work with a strict CSP (Wicket used
to be one of those :) ). For such a library, you might want to roll a
less strict CSP via an IInitializer. From what I see in the link sent
by Maxim, you'll need to add 'unsafe-eval' for Kendo:
getCsp().blocking().add(CSPDirective.SCRIPT_SRC,
CSPDirectiveSrcValue.UNSAFE_EVAL);

Best regards,
Emond

On Fri, Feb 28, 2020 at 4:05 AM Sebastien Briquet  wrote:
>
> Thank you very much for letting me know!
> I didn't exactly know what to expect until I would put my hands in it, but
> now I'm a little bit worried, haha !
>
> Best regards,
> Sebastien

Re: WICKET-6725 styling of hidden elements: no vote yet

[Emond Papegaaij]

Hi Andrew,

I thought of this solution as well and it will work. The major
advantage is that the styling is only added when it is actually used.
But it requires significantly more work to build and is a lot more
complex than the current solution. For this, we need some place to
accumulate element styling, like we do for JS event handlers. This
then needs to be rendered in the response.

The most complex part is ajax updates. These might change some of the
styling. Simply replacing the style element will not work, because in
an ajax request only the added components are rendered. Rendering a
style element per component will work, but is far from ideal. This is
why I went for the easy solution.

Emond

On Thu, Feb 27, 2020 at 10:08 PM Andrew Kondratev  wrote:
>
> Just as a brainstorm. Not sure if it's a good idea.
>
> Wicket potentially can add nounced style to the document with hidden
> elements hidden by id.
>
> Imagine generated HTML has components like these
> 
>  class="wupb-border"> class="wupb-foreground">
> 
> 
>
> #ida and #id9 must be hidden, so in the page header we add something like
> this
>
> 
> #ida, #id9 {display: none;}
> 
>
> Even if the  wupb-progressBar  has display: flex, the #ida will win. Will
> win even over  #id8 .wupb-progressBar {display: fles}
>
> !important can potentially be added.
>
>
> чт, 27 февр. 2020 г. в 23:56, Ernesto Reinaldo Barreiro  >:
>
> > Hi,
> >
> > On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene 
> > wrote:
> >
> > > On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> > > reier...@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Right now I have no enough knowledge to vote in this feature. One
> > thing I
> > > > didn't like, and I already mentioned it before, is some of us were
> > > waiting
> > > > for 9.x to be released some time ago (at least a few months ago I was
> > > > preparing some branch of our application and ported it to 9.x, after
> > > asking
> > > > about release plans) and all of the sudden this feature is introduced
> > and
> > > > all sub-frameworks depending on Wicket will have to be adapted.
> > >
> > >
> > > In which way sub-frameworks should be affected? I mean, as far as I
> > > understand it, if we disable CSP blocking configuration everything should
> > > work "the old way", and that's why I would prefer to keep CSP disabled by
> > > default.
> > >
> >
> > Well if something is supported at core level then if associated projects
> > want to comply with this new feature, which might be ideal,  then they will
> > have to be adapted (or not?). I'm not talking about not releasing the new
> > feature. I'm talking about not releasing as part of 9.x, as it was said to
> > be almost ready for release a few months ago, and deffer it to 10.x (and
> > try to release it soon).
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
> >

Re: WICKET-6725 styling of hidden elements: no vote yet

[Emond Papegaaij]

On Thu, Feb 27, 2020 at 11:56 AM Ernesto Reinaldo Barreiro
 wrote:
> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene 
> > In which way sub-frameworks should be affected? I mean, as far as I
> > understand it, if we disable CSP blocking configuration everything should
> > work "the old way", and that's why I would prefer to keep CSP disabled by
> > default.
> >
>
> Well if something is supported at core level then if associated projects
> want to comply with this new feature, which might be ideal,  then they will
> have to be adapted (or not?). I'm not talking about not releasing the new
> feature. I'm talking about not releasing as part of 9.x, as it was said to
> be almost ready for release a few months ago, and deffer it to 10.x (and
> try to release it soon).

As I've explained in the other thread, it is very likely that not much
needs to be done in additional frameworks. Also, when a framework is
not yet compliant with CSP, the user can temporarily disable CSP or
switch to a less strict version. As explained in the user guide, this
is just one line of code.

The changes made to the core of Wicket (removing inline styling and
js) were absolutely necessary to be able to support a strict CSP via
Wicket or any other way. This clearly is a wish of our users (and a
personal wish as well, because our application also needs it). Also I
think this is truly is a very unique feature. I don't think any
framework offers such a strict CSP out of the box with so less effort
from the user.

Best regards,
Emond

Re: CSP and UI libraries

[Emond Papegaaij]

Hi Martin and Sebastien,

I see no need for checking if CSP is enabled or not. It is not hard to
write your code to comply to even the strictest CSP. If it works with
the strict CSP, it will also work when CSP is disabled or with a less
strict CSP. Simply follow the few rules explained in the user guide.
Note that if your library needs to check if a nonce is required, this
is already supported, see
ContentSecurityPolicyEnforcer.isNonceEnabled().

Our application uses WiQuery and several other frameworks, and I only
had to make minor changes to make this application fully compliant
with the strict CSP. No changes were required to WiQuery. A small
change is required to the ChartJS library we use
(https://github.com/haster/java-chartjs) because ChartJS tries to
insert a stylesheet into the head. This stylesheet has to be rendered
via Wicket to get the nonce.

Best regards,
Emond

On Thu, Feb 27, 2020 at 2:00 PM Sebastien Briquet  wrote:
>
> Hi Martin,
>
> Actually that's a good point! I will try to upgrade Wicket jQuery UI to
> wicket 9/CSP to see how it behaves...
>
> Thanks and best regards,
> Sebastien

Re: WICKET-6725 styling of hidden elements: no vote yet

[Emond Papegaaij]

On Wed, Feb 26, 2020 at 10:53 AM Martin Grigorov  wrote:
> I am also not big fan of CSP but users ask for it and I see no other way
> but to move all inline styles in such .css resource

IMHO CSP is one of the changes to the web application ecosystem that
Wicket will need an answer on to stay relevant in the upcoming years.
Web application development is changing at a very rapid pace and
Wicket will need to incorporate those changes or face becoming
obsolete.

> On Tue, Feb 25, 2020 at 10:54 PM Sven Meier  wrote:
> > - it's a kitchen-sink for left-over styles (see .wicket--color-red)
>
> I agree that for this one Wicket can just add the CSS class (e.g.
> wicket-feedback-indicator) on the HTML element and let the application
> provide the CSS rules for it

I'm ok with that. I only added that styling to be compatible with the
old behavior, which was broken in my opinion anyway.

> >
< cut use hidden attribute >
> >
> I don't agree here.
> If each and every developer should make sure that Wicket's placeholder tags
> should stay invisible then the framework does not do its job.
> Often when we see that something is too common we actually add it to the
> framework. Here you ask to do the reverse - remove the support and ask the
> developers to deal with it.
> The article you linked to explains it well that "hidden" attribute does not
> really work. CSS libraries which provide reset rules like div { display:
> block; } will make the life of the developer miserable.

I totally agree with Martin. Using the hidden attribute puts the
responsibility with the developer where this should be on the
framework. The hidden attribute just doesn't work.

> An idea:
> if CSP is disabled then Wicket can deliver the content of wicket-core.css
> as inline CSS, i.e. .
> This will keep the number of http requests the same as before.

This already is an option now and doesn't depend on CSP being enabled
or not. As long as the style element is rendered with a nonce, it will
work. We can make the header contribution a bit more flexible with the
following options:
* inline wicket-core.css (or another stylesheet)
* resource reference to wicket-core.css (or another stylesheet)
* no core stylesheet at all

Best regards,
Emond

Re: buildbot failure in on wicket-master

[Emond Papegaaij]

I don't what happened here, but I'm pretty sure that I didn't break
this with a simple CSS change. The test runs fine on my machine. Did
something change in the infra?

Emond

On Mon, Feb 10, 2020 at 9:46 PM  wrote:
>
> The Buildbot has detected a new failure on builder wicket-master while 
> building wicket. Full details are available at:
> https://ci.apache.org/builders/wicket-master/builds/1245
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: bb_slave6_ubuntu
>
> Build Reason: The SingleBranchScheduler scheduler named 
> 'on-wicket-master-commit' triggered this build
> Build Source Stamp: [branch master] 4d8d8503524dd46c087a398f061685ab310e7856
> Blamelist: Emond Papegaaij 
>
> BUILD FAILED: failed compile
>
> Sincerely,
>  -The Buildbot
>
>
>

Re: Form submit via Javascript and event handlers

[Emond Papegaaij]

I've fixed the commit message, thanks for the feedback.

Emond

On Thu, Feb 6, 2020 at 1:05 PM Martin Grigorov  wrote:
>
> Looks good!
>
> One nit: the commit message mentions twice
> 'should*Trigger*JavaScriptSubmitEvent'
> while the latter should be 'should*Invoke*JavaScriptFormOnsubmit'
> You can fix it in 'csp' branch before merging to master
>
> On Wed, Feb 5, 2020 at 11:22 PM Emond Papegaaij 
> wrote:
>
> > This is what I have in mind:
> >
> > https://github.com/apache/wicket/commit/b54938053a5bda2f4577966779d580e828f16e47
> >
> > I think this is better than the old situation because this triggers
> > any submit handlers on the form (or any parent element via bubbling)
> > not just the onsubmit attribute. It is a change in behavior though and
> > might break existing applications.
> >
> > Emond
> >
> > On Wed, Feb 5, 2020 at 10:01 PM Emond Papegaaij
> >  wrote:
> > >
> > > On Wed, Feb 5, 2020 at 9:57 PM Emond Papegaaij
> > >  wrote:
> > > > While fixing the CSP violations in the examples, I noticed a strange
> > > > situation in SubmitLink example:
> > > >
> > http://examples8x.wicket.apache.org/compref/wicket/bookmarkable/org.apache.wicket.examples.compref.SubmitLinkPage
> > > >
> > > > In this example, the internal submit link immediately submits the
> > > > form, while the external submit link shows a confirmation. This
> > > > confirmation is specified via an onsubmit on the form in the markup.
> > > > The JS for the external link explicitly checks onsubmit and calls
> > > > this, while the internal link does not check the onsubmit attribute. I
> > > > think these should match, and I would like to replace the f.submit()
> > > > call with a proper submit event trigger via Wicket.Event.fire(f,
> > > > 'submit').
> > > >
> > > > Does anyone know why this discrepancy exists, or is it merely an
> > oversight?
> > >
> > > Doh, I can answer this myself, it's controlled via
> > > shouldInvokeJavaScriptFormOnsubmit. Unfortunately, that does not work
> > > with a strict CSP. What about changing this method to control the
> > > switch between 'f.submit()' and 'Wicket.Event.fire(f, 'submit')'? The
> > > first will not trigger any event bindings, the second will. For this,
> > > the name of the method should be adjusted accordingly.
> > >
> > > Best regards,
> > > Emond
> >

Re: Form submit via Javascript and event handlers

[Emond Papegaaij]

This is what I have in mind:
https://github.com/apache/wicket/commit/b54938053a5bda2f4577966779d580e828f16e47

I think this is better than the old situation because this triggers
any submit handlers on the form (or any parent element via bubbling)
not just the onsubmit attribute. It is a change in behavior though and
might break existing applications.

Emond

On Wed, Feb 5, 2020 at 10:01 PM Emond Papegaaij
 wrote:
>
> On Wed, Feb 5, 2020 at 9:57 PM Emond Papegaaij
>  wrote:
> > While fixing the CSP violations in the examples, I noticed a strange
> > situation in SubmitLink example:
> > http://examples8x.wicket.apache.org/compref/wicket/bookmarkable/org.apache.wicket.examples.compref.SubmitLinkPage
> >
> > In this example, the internal submit link immediately submits the
> > form, while the external submit link shows a confirmation. This
> > confirmation is specified via an onsubmit on the form in the markup.
> > The JS for the external link explicitly checks onsubmit and calls
> > this, while the internal link does not check the onsubmit attribute. I
> > think these should match, and I would like to replace the f.submit()
> > call with a proper submit event trigger via Wicket.Event.fire(f,
> > 'submit').
> >
> > Does anyone know why this discrepancy exists, or is it merely an oversight?
>
> Doh, I can answer this myself, it's controlled via
> shouldInvokeJavaScriptFormOnsubmit. Unfortunately, that does not work
> with a strict CSP. What about changing this method to control the
> switch between 'f.submit()' and 'Wicket.Event.fire(f, 'submit')'? The
> first will not trigger any event bindings, the second will. For this,
> the name of the method should be adjusted accordingly.
>
> Best regards,
> Emond

Re: Form submit via Javascript and event handlers

[Emond Papegaaij]

On Wed, Feb 5, 2020 at 9:57 PM Emond Papegaaij
 wrote:
> While fixing the CSP violations in the examples, I noticed a strange
> situation in SubmitLink example:
> http://examples8x.wicket.apache.org/compref/wicket/bookmarkable/org.apache.wicket.examples.compref.SubmitLinkPage
>
> In this example, the internal submit link immediately submits the
> form, while the external submit link shows a confirmation. This
> confirmation is specified via an onsubmit on the form in the markup.
> The JS for the external link explicitly checks onsubmit and calls
> this, while the internal link does not check the onsubmit attribute. I
> think these should match, and I would like to replace the f.submit()
> call with a proper submit event trigger via Wicket.Event.fire(f,
> 'submit').
>
> Does anyone know why this discrepancy exists, or is it merely an oversight?

Doh, I can answer this myself, it's controlled via
shouldInvokeJavaScriptFormOnsubmit. Unfortunately, that does not work
with a strict CSP. What about changing this method to control the
switch between 'f.submit()' and 'Wicket.Event.fire(f, 'submit')'? The
first will not trigger any event bindings, the second will. For this,
the name of the method should be adjusted accordingly.

Best regards,
Emond

Form submit via Javascript and event handlers

[Emond Papegaaij]

Hi,

While fixing the CSP violations in the examples, I noticed a strange
situation in SubmitLink example:
http://examples8x.wicket.apache.org/compref/wicket/bookmarkable/org.apache.wicket.examples.compref.SubmitLinkPage

In this example, the internal submit link immediately submits the
form, while the external submit link shows a confirmation. This
confirmation is specified via an onsubmit on the form in the markup.
The JS for the external link explicitly checks onsubmit and calls
this, while the internal link does not check the onsubmit attribute. I
think these should match, and I would like to replace the f.submit()
call with a proper submit event trigger via Wicket.Event.fire(f,
'submit').

Does anyone know why this discrepancy exists, or is it merely an oversight?

Best regards,
Emond

Re: [jira] [Created] (WICKET-6745) CSP: inline JS in server and clienttime response filters

[Emond Papegaaij]

Hi Martin,

I like the idea of the 'Server-Timing' headers. I didn't know this feature yet.

However, these response filters also measure at the client side. The
time is recorded at the start of the head and again just after body. I
highly doubt this way of measuring gives a good indication of client
side performance. Chrome DevTools provides way more details in its
Performance tab. It's this client side time measurement that's
problematic. The filters render script tags directly into the
response, which makes it hard to add the nonce when needed for the
CSP.

What about deprecating the current filters and writing a new one that
just adds the Server-Timing header?

Emond

On Tue, Feb 4, 2020 at 9:28 PM Martin Grigorov  wrote:
>
> On Tue, Feb 4, 2020 at 9:51 PM Martin Grigorov  wrote:
>
> > Hi,
> >
> > "window.defaultStatus"  could be easily replaced with console.log()
> >
> > Those are usually used in DEV mode. I think it is fine to preserve them.
> >
> > As a last resort we can render the value as a response header.
> > I remember Chromium has handling for some special response header and puts
> > its value in Dev Tools > Performance tab. I don't recall the name of the
> > header at the moment.
> >
>
> https://ma.ttias.be/server-timings-chrome-devtools/
>
>
> >
> > On Tue, Feb 4, 2020 at 9:39 PM Emond Papegaaij 
> > wrote:
> >
> >> Hi all,
> >>
> >> Do you agree on this one? I see no use for these classes anymore, as
> >> support for window.defaultStatus has been dropped by all major
> >> browsers. They also log server time, but we have other and better
> >> solutions for that.
> >>
> >> Best regards,
> >> Emond
> >>
> >> On Tue, Feb 4, 2020 at 8:37 PM Emond Papegaaij (Jira) 
> >> wrote:
> >> >
> >> > Emond Papegaaij created WICKET-6745:
> >> > ---
> >> >
> >> >  Summary: CSP: inline JS in server and clienttime response
> >> filters
> >> >  Key: WICKET-6745
> >> >  URL: https://issues.apache.org/jira/browse/WICKET-6745
> >> >  Project: Wicket
> >> >   Issue Type: Bug
> >> >   Components: wicket-core, wicket-examples
> >> > Affects Versions: 9.0.0-M4
> >> > Reporter: Emond Papegaaij
> >> >
> >> >
> >> > {{ServerAndClientTimeFilter}}, {{AjaxServerAndClientTimeFilter}} and
> >> {{ServerHostNameAndTimeFilter}} all render inline script tags. Because
> >> these tags are rendered in a non-standard way, the nonce is not added,
> >> violating the CSP.
> >> >
> >> > These filters all put status information in {{window.defaultStatus}}.
> >> This property has been deprecated for years and support has been removed in
> >> most (if not all) browsers. My suggestion is to deprecate these classes in
> >> core and remove the one in examples. In the deprecated version, there is no
> >> need to fix the CSP violation.
> >> >
> >> >
> >> >
> >> > --
> >> > This message was sent by Atlassian Jira
> >> > (v8.3.4#803005)
> >>
> >

Re: [jira] [Created] (WICKET-6745) CSP: inline JS in server and clienttime response filters

[Emond Papegaaij]

Hi all,

Do you agree on this one? I see no use for these classes anymore, as
support for window.defaultStatus has been dropped by all major
browsers. They also log server time, but we have other and better
solutions for that.

Best regards,
Emond

On Tue, Feb 4, 2020 at 8:37 PM Emond Papegaaij (Jira)  wrote:
>
> Emond Papegaaij created WICKET-6745:
> ---
>
>  Summary: CSP: inline JS in server and clienttime response filters
>  Key: WICKET-6745
>  URL: https://issues.apache.org/jira/browse/WICKET-6745
>  Project: Wicket
>   Issue Type: Bug
>   Components: wicket-core, wicket-examples
> Affects Versions: 9.0.0-M4
>     Reporter: Emond Papegaaij
>
>
> {{ServerAndClientTimeFilter}}, {{AjaxServerAndClientTimeFilter}} and 
> {{ServerHostNameAndTimeFilter}} all render inline script tags. Because these 
> tags are rendered in a non-standard way, the nonce is not added, violating 
> the CSP.
>
> These filters all put status information in {{window.defaultStatus}}. This 
> property has been deprecated for years and support has been removed in most 
> (if not all) browsers. My suggestion is to deprecate these classes in core 
> and remove the one in examples. In the deprecated version, there is no need 
> to fix the CSP violation.
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.3.4#803005)

Re: [wicket] branch csp updated: WICKET-6725: fixed special Form placeholder rendering

[Emond Papegaaij]

Hi Martin,

You are right, the commit message could have used a bit more
explanation. As you can see at Github, the change was intentional.
Unfortunately there seems to be no testcase covering this piece of
code, but IMHO it was broken and is fixed now. From what I can see,
the only difference between the method in Form and in Component should
be that the tag name must be changed to div when the form is nested.
The check for getOutputMarkupId is bogus, a placeholder always has a
markup id. The code for getAjaxRegionMarkupId seemed appropriate. The
code was also missing the data attribute. I assumed we simply forgot
to keep this method up to date while we changed its
super-implementation. Please correct me if I'm wrong.

Emond

On Wed, Jan 29, 2020 at 9:12 AM Martin Grigorov  wrote:
>
> On Tue, Jan 28, 2020 at 10:19 PM  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > papegaaij pushed a commit to branch csp
> > in repository https://gitbox.apache.org/repos/asf/wicket.git
> >
> >
> > The following commit(s) were added to refs/heads/csp by this push:
> >  new fb290e8  WICKET-6725: fixed special Form placeholder rendering
> > fb290e8 is described below
> >
> > commit fb290e818a278eb69f4fa64d77514d8f3ee3068c
> > Author: Emond Papegaaij 
> > AuthorDate: Tue Jan 28 21:18:50 2020 +0100
> >
> > WICKET-6725: fixed special Form placeholder rendering
> > ---
> >  .../main/java/org/apache/wicket/markup/html/form/Form.java| 11
> > +++
> >  1 file changed, 3 insertions(+), 8 deletions(-)
> >
> > diff --git
> > a/wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java
> > b/wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java
> > index a39160a..2ffc52b 100644
> > ---
> > a/wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java
> > +++
> > b/wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java
> > @@ -1698,14 +1698,9 @@ public class Form extends WebMarkupContainer
> > else
> > {
> > // rewrite inner form tag as div
> > -   response.write(" > -   if (getOutputMarkupId())
> > -   {
> > -   response.write(" id=\"");
> > -   response.write(getMarkupId());
> > -   response.write("\"");
> > -   }
> > -   response.write(">");
> > +   response.write(
> > +   String.format(" > data-wicket-placeholder=\"\">",
> > +   getAjaxRegionMarkupId(),
> > getString(CssUtils.key(Component.class, "hidden";
> >
>
> Why did you replace the usage of getOutputMarkupId()+getMarkupId()
> with getAjaxRegionMarkupId() ?
> Please use better commit messages! It is not clear whether you wanted to
> actually make this change or broke it unintentionally.
>
>
> > }
> > }
> >
> >
> >

Re: [wicket] branch csp updated: WICKET-6731: move inline onclick to event handler

[Emond Papegaaij]

Isn't renderHead always called before rendering the component itself?
getMarkupId() already causes setOutputMarkupId(true). When the head
isn't always rendered before the component itself, then you are right.

Emond

On Fri, Jan 24, 2020 at 3:13 PM Martin Grigorov  wrote:
>
> On Fri, Jan 24, 2020 at 3:50 PM  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > papegaaij pushed a commit to branch csp
> > in repository https://gitbox.apache.org/repos/asf/wicket.git
> >
> >
> > The following commit(s) were added to refs/heads/csp by this push:
> >  new 9ad2079  WICKET-6731: move inline onclick to event handler
> > 9ad2079 is described below
> >
> > commit 9ad20795847e146db5a536f90bc734f47386cc11
> > Author: Emond Papegaaij 
> > AuthorDate: Fri Jan 24 14:50:02 2020 +0100
> >
> > WICKET-6731: move inline onclick to event handler
> > ---
> >  .../apache/wicket/markup/html/form/SubmitLink.java| 19
> > ---
> >  1 file changed, 16 insertions(+), 3 deletions(-)
> >
> > diff --git
> > a/wicket-core/src/main/java/org/apache/wicket/markup/html/form/SubmitLink.java
> > b/wicket-core/src/main/java/org/apache/wicket/markup/html/form/SubmitLink.java
> > index 30cbe8b..d8c9426 100644
> > ---
> > a/wicket-core/src/main/java/org/apache/wicket/markup/html/form/SubmitLink.java
> > +++
> > b/wicket-core/src/main/java/org/apache/wicket/markup/html/form/SubmitLink.java
> > @@ -17,7 +17,10 @@
> >  package org.apache.wicket.markup.html.form;
> >
> >  import org.apache.wicket.markup.ComponentTag;
> > +import org.apache.wicket.markup.head.IHeaderResponse;
> > +import org.apache.wicket.markup.head.OnDomReadyHeaderItem;
> >  import org.apache.wicket.model.IModel;
> > +import org.apache.wicket.util.string.AppendingStringBuffer;
> >
> >  /**
> >   * A link which can be used exactly like a Button to submit a Form. The
> > onclick of the link will use
> > @@ -165,21 +168,31 @@ public class SubmitLink extends AbstractSubmitLink
> > if (tag.getName().equalsIgnoreCase("a") ||
> > tag.getName().equalsIgnoreCase("link")
> > || tag.getName().equalsIgnoreCase("area"))
> > {
> > -   tag.put("href", "javascript:;");
> > +   tag.put("href", "#");
> > }
> > else if (tag.getName().equalsIgnoreCase("button"))
> > {
> > // WICKET-5597 prevent default submit
> > tag.put("type", "button");
> > }
> > -
> > -   tag.put("onclick", getTriggerJavaScript());
> > }
> > else
> > {
> > disableLink(tag);
> > }
> > }
> > +
> > +   @Override
> > +   public void renderHead(IHeaderResponse response)
> > +   {
> > +   super.renderHead(response);
> > +
> > +   if (isEnabledInHierarchy())
> > +   {
> > +
> >  response.render(OnDomReadyHeaderItem.forScript("Wicket.Event.add('" +
> > getMarkupId()
> > +   + "', 'click', function(event) { " +
> > getTriggerJavaScript() + " });"));
> > +   }
> > +   }
> >
>
> I think we need to add setOutputMarkupId(true) in the constructor
>
>
> >
> > /**
> >  * Controls whether or not clicking on this link will invoke
> > form's javascript onsubmit handler.
> >
> >

Re: CSP in Wicket 9

[Emond Papegaaij]

In my opinion marketing is very important, but I think it is more
important to have this option enabled on as many applications as
possible. Enabling this by default will give this a much wider reach
than just having it available. Most importantly, it will be enabled on
new applications, guiding the developer into making a more secure
application. If it is not enabled by default, I doubt many developers
will enable it on their new application. For that you have to look
into the guide, see that it's available and then enable it.

For existing applications, I think many will either disable it or at
least configure CSP to be less strict. But still, if this triggers
just a few to make their application work with CSP, I'd consider that
a win.

IMHO as developers of a popular web framework it is our duty to work
on a secure internet and push these features actively.

Emond

On Tue, Jan 21, 2020 at 3:07 PM Andrea Del Bene  wrote:
>
> I agree with the marketable value of CSP but I don't think it will lose
> appeal if we make it disabled by default. As I said, I agree to eventually
> enable it by default, but I don't think the time is ripe yet.
>
> On Tue, Jan 21, 2020 at 2:27 PM Martijn Dashorst 
> wrote:
>
> > Not sure if enabling it by default is a bad thing when you can, as per
> > migration guide, disable it with one statement in your
> > WebApplication#init().
> >
> > Also, when looking at marketable features, having CSP, and enabled by
> > default, is something that publications will take notice of. Just like
> > being Jakarta EE prepared:
> >
> > "Deliver Secure Future Proof Web Applications with Apache Wicket 9
> >
> > Apache Wicket 9 delivers Content Security Policy (CSP) protection
> > out-of-the-box, protecting web applications against a variety of web
> > based attack vectors. CSP is a cross-browser technology that prevents
> > several attacks on web applications by limiting the 
> >
> > With the adoption of the Jakarta EE standards, Apache Wicket 9 is one
> > of the first Java frameworks prepared for the new future of enterprise
> > Java. 
> > "
> >
> > Martijn
> >
> > On Tue, Jan 21, 2020 at 2:00 PM Andrea Del Bene 
> > wrote:
> > >
> > > IMHO forcing users to adopt a new potential breaking feature is a
> > > mistake. We should wait for a wider interest in CSP to enable it by
> > > default. Don't get me wrong, I'm not underestimating the importance of
> > > this feature which is a fantastic tool to ensure security. Nonetheless,
> > > I believe that forcing users to comply with it will only have the effect
> > > of upsetting them.
> > >
> > > On 1/21/20 1:27 PM, Emond Papegaaij wrote:
> > > > On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov 
> > wrote:
> > > >> On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij <
> > emond.papega...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> I've discussed this with our unit manager, and got permission to
> > > >>> donate our CSP code to Wicket. I think a strong, out of the box CSP
> > is
> > > >>> a killer feature to have for Wicket 9. Not many frameworks can match
> > > >>> this. For this, I would like to continue working on the following
> > > >>> parts:
> > > >>> * Remove all inline styling and JS from Wicket. I will need some help
> > > >>> with this, especially the Form related code.
> > > >>> * Make sure all examples work find with a strong CSP enabled
> > > >>> * Add the CSP code to Wicket and provide several presets (strong,
> > > >>> unsafeJsAndStyling, reportOnly, disabled)
> > > >>> * Enable CSP with the strong preset by default
> > > >>>
> > > >> I think this will break all applications which migrate from earlier
> > version.
> > > >> I like that Wicket will be more secure by default but
> > > >> 1) most people do not really care about CSP (yet)
> > > >> 2) last time when I tested CSP it was behaving differently on
> > different
> > > >> browsers. I hope it is better now since only Firefox is not based on
> > > >> Chromium. According to https://caniuse.com/#search=csp IE11 might be
> > > >> problematic.
> > > >>
> > > >> Whatever we choose as default we should document how to switch it on
> > and
> > > >> off.
> > > >> The user guide needs to be updated!
> > > >>
> > > > Yes, enabling a stri

Re: CSP in Wicket 9

[Emond Papegaaij]

We are not forcing uses to comply with a strict CSP when we enable it
by default. It's just a setting, which can be turned off with a single
line of code that will be put in the migration guide. Enabling this by
default will however protect new applications out of the box and raise
the awareness of this feature. Our examples can serve as a guide on
how to use this.

Emond

On Tue, Jan 21, 2020 at 2:00 PM Andrea Del Bene  wrote:
>
> IMHO forcing users to adopt a new potential breaking feature is a
> mistake. We should wait for a wider interest in CSP to enable it by
> default. Don't get me wrong, I'm not underestimating the importance of
> this feature which is a fantastic tool to ensure security. Nonetheless,
> I believe that forcing users to comply with it will only have the effect
> of upsetting them.
>
> On 1/21/20 1:27 PM, Emond Papegaaij wrote:
> > On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov  
> > wrote:
> >> On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij 
> >> 
> >> wrote:
> >>
> >>> I've discussed this with our unit manager, and got permission to
> >>> donate our CSP code to Wicket. I think a strong, out of the box CSP is
> >>> a killer feature to have for Wicket 9. Not many frameworks can match
> >>> this. For this, I would like to continue working on the following
> >>> parts:
> >>> * Remove all inline styling and JS from Wicket. I will need some help
> >>> with this, especially the Form related code.
> >>> * Make sure all examples work find with a strong CSP enabled
> >>> * Add the CSP code to Wicket and provide several presets (strong,
> >>> unsafeJsAndStyling, reportOnly, disabled)
> >>> * Enable CSP with the strong preset by default
> >>>
> >> I think this will break all applications which migrate from earlier 
> >> version.
> >> I like that Wicket will be more secure by default but
> >> 1) most people do not really care about CSP (yet)
> >> 2) last time when I tested CSP it was behaving differently on different
> >> browsers. I hope it is better now since only Firefox is not based on
> >> Chromium. According to https://caniuse.com/#search=csp IE11 might be
> >> problematic.
> >>
> >> Whatever we choose as default we should document how to switch it on and
> >> off.
> >> The user guide needs to be updated!
> >>
> > Yes, enabling a strict CSP will probably break all existing
> > applications on upgrade. But the upgrade will do that anyway (I had to
> > fix quite a few compilation errors to get my app starting again). We
> > do have to document this in the migration guide. Switching to an
> > unsafe CSP or disabling it entirely is just one line of code. That's a
> > lot less work than fixing the compilation errors. I hope enabling CSP
> > by default will make more people aware of this browser feature. At
> > Topicus we intent to fix our applications to work with the strict CSP,
> > probably not directly after migrating to 9, but Wicket 9 is a good
> > push in this direction.
> >
> > It is true that support is lacking for some browsers. A browser that
> > does not support CSP at all (like IE11) is not hindered by it either.
> > It becomes more problematic when a browser does not support the
> > directives used (like strict-dynamic). This might cause issues and we
> > need to test that and change the CSP to make sure it works in those
> > browsers as well. IMHO as a framework it is our job to set an example
> > and show how we think this is done best. When a user thinks the gained
> > security is not worth the pain, he/she can disable it and hope for the
> > best.
> >
> > Best regards,
> > Emond
> >
> >>> I've already started the work on the 'csp' branch. On this branch,
> >>> I've also migrated all but the servlet API to the jakarta namespace.
> >>>
> >>> Best regards,
> >>> Emond
> >>>
> >>> On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij
> >>>  wrote:
> >>>> Searching through our Jira, I've found WICKET-6687, filed by Andrew.
> >>>> He already pinpointed several places that break with a strict CSP
> >>>> enabled. I'm going to convert that bug into a task (we do not have
> >>>> epic) and create new bugs for all issues in that ticket. That should
> >>>> make it easier to track progress.
> >>>>
> >>>> Best regards,
> >>>> Emond
> >>>>
> >>>> On Sat, Jan 11, 2020 at 10:31 P

Re: CSP in Wicket 9

[Emond Papegaaij]

On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov  wrote:
>
> On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij 
> wrote:
>
> > I've discussed this with our unit manager, and got permission to
> > donate our CSP code to Wicket. I think a strong, out of the box CSP is
> > a killer feature to have for Wicket 9. Not many frameworks can match
> > this. For this, I would like to continue working on the following
> > parts:
> > * Remove all inline styling and JS from Wicket. I will need some help
> > with this, especially the Form related code.
> > * Make sure all examples work find with a strong CSP enabled
> > * Add the CSP code to Wicket and provide several presets (strong,
> > unsafeJsAndStyling, reportOnly, disabled)
> > * Enable CSP with the strong preset by default
> >
>
> I think this will break all applications which migrate from earlier version.
> I like that Wicket will be more secure by default but
> 1) most people do not really care about CSP (yet)
> 2) last time when I tested CSP it was behaving differently on different
> browsers. I hope it is better now since only Firefox is not based on
> Chromium. According to https://caniuse.com/#search=csp IE11 might be
> problematic.
>
> Whatever we choose as default we should document how to switch it on and
> off.
> The user guide needs to be updated!
>
Yes, enabling a strict CSP will probably break all existing
applications on upgrade. But the upgrade will do that anyway (I had to
fix quite a few compilation errors to get my app starting again). We
do have to document this in the migration guide. Switching to an
unsafe CSP or disabling it entirely is just one line of code. That's a
lot less work than fixing the compilation errors. I hope enabling CSP
by default will make more people aware of this browser feature. At
Topicus we intent to fix our applications to work with the strict CSP,
probably not directly after migrating to 9, but Wicket 9 is a good
push in this direction.

It is true that support is lacking for some browsers. A browser that
does not support CSP at all (like IE11) is not hindered by it either.
It becomes more problematic when a browser does not support the
directives used (like strict-dynamic). This might cause issues and we
need to test that and change the CSP to make sure it works in those
browsers as well. IMHO as a framework it is our job to set an example
and show how we think this is done best. When a user thinks the gained
security is not worth the pain, he/she can disable it and hope for the
best.

Best regards,
Emond

> >
> > I've already started the work on the 'csp' branch. On this branch,
> > I've also migrated all but the servlet API to the jakarta namespace.
> >
> > Best regards,
> > Emond
> >
> > On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij
> >  wrote:
> > >
> > > Searching through our Jira, I've found WICKET-6687, filed by Andrew.
> > > He already pinpointed several places that break with a strict CSP
> > > enabled. I'm going to convert that bug into a task (we do not have
> > > epic) and create new bugs for all issues in that ticket. That should
> > > make it easier to track progress.
> > >
> > > Best regards,
> > > Emond
> > >
> > > On Sat, Jan 11, 2020 at 10:31 PM Emond Papegaaij
> > >  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > For the past few days I've been experimenting with the new CSP
> > > > features in Wicket 9. I really want to thank Andrew, Sven and Martin
> > > > for the great work you guys did in making this possible. I'm getting
> > > > very close to running my application with a very tight and secure CSP.
> > > > Unfortunately, some parts of Wicket still use inline styling and
> > > > scripting. So far I've found the following two issues:
> > > >
> > > > * hidden components with setOutputMarkupPlaceholderTag(true) have
> > display:none
> > > > * Forms render inline styling and javascript in some cases to improve
> > > > submit handling
> > > >
> > > > I think we should try to fix these before Wicket 9 is released. I will
> > > > continue to debug our application to see if there are more places.
> > > >
> > > > At Topicus we wrote a IRequestCycleListener that applies the CSP
> > > > automatically to every request via HTTP headers. The API makes it easy
> > > > to configure the CSP. I've added support for the nonce as well. It
> > > > uses a new nonce for every request, which should be more secure than a
> > > > nonce bound to a session. I'll discuss with my employee next week if
> > > > we can donate this code to Wicket.
> > > >
> > > > Best regards,
> > > > Emond
> >

Re: [wicket] branch csp updated: WICKET-6730: central SecureRandom setting

[Emond Papegaaij]

> > +   random = SecureRandom.getInstanceStrong();
> >
>
> Since we have now CryptingPageStore it is possible that an application
> store some pages with algo X.
> If the application is clustered and rolling upgrade is done with a new
> version of JDK it is possible that the new best strong algo is now Y.
> In this case the application won't be able to decrypt the old pages.

The implementation of the random source does not matter for encryption
and decryption of pages. The only thing that matters is that the
random source provides secure random data for the keys.

> > +public interface ISecureRandomSupplier
>
> nit: no need of `public` in interfaces

I know, but I don't like it when an interface is not public. I never
understood why the public keyword is optional for interfaces anyway.
All interfaces in the JDK are public as well.

I've pushed a commit with the other improvements. I don't know why I
used WicketTester as superclass, it did work :)

Best regards,
Emond

Re: [wicket] branch csp updated: WICKET-6725: replace display:none by wicket--hidden css class

[Emond Papegaaij]

Hi all,

The CSP branch started to get a bit of a mess with work on different
parts of Wicket combined in one branch. I've reworked the commits, put
some of them on master, and split the rest on 2 branches:
csp-display-none and csp-configurable. Those are for reviewing the
code. I'll open a pull request when it's done. The csp branch is just
for me, as I need a branch with all work combined to test our
application and to see the effects of my changes. This branch will
remain a mess and will not be merged to master.

Best regards,
Emond

Re: [wicket] branch csp updated: WICKET-6725: replace display:none by wicket--hidden css class

[Emond Papegaaij]

> > IMHO we have to decide first whether we want to use the "hidden" attribute.
> > I'm not sure about the pros and cons at the moment.
> >
> > Depending on that decision (NO) we'll have to write CSS classes anyway
> > or (YES) we might want to add them additionally.
> > In the latter case I'm not sure we need a CSS file at all, just to
> > contain "display: none".
> >
>
> Right!
> This is how this discussion started (question 1): if we use 'hidden'
> attribute for this case then there is no need of CSS file.
> For the other cases/tickets we can decide separately.

I disagree on this point. We use display: flex quite a lot in our
application. This will render the hidden attribute useless. The hidden
attribute without additional styling will break our application (and
therefore probably others as well). Whatever we do, we should make
sure the tags stay hidden in most cases (we can't protect against very
specific styling with !important).

I'm ok with [data-wicket-placeholder][hidden] as a rule, but I don't
see the benefit over class="wicket--hidden".

Also, we keep on focusing on this particular use case, but there are
others. How about this in Form:
style="width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hidden".
I'm not sure this can be replaced by hidden, maybe it can.

Best regards,
Emond

> >
> > Thanks
> > Sven
> >
> >
> > On 15.01.20 18:52, Martin Grigorov wrote:
> > > On Wed, Jan 15, 2020, 19:29 Sven Meier  wrote:
> > >
> > >> I disagree, "hidden" has the perfect semantic for what we're doing with
> > >> placeholders or other s.
> > >>
> > > How about such CSS rule:
> > >
> > > [data-wicket-placeholder][hidden]
> > > {
> > >display : none !important;
> > > }
> > >
> > > ?
> > >
> > >
> > >> Sven
> > >>
> > >>
> > >> On 15.01.20 11:44, Emond Papegaaij wrote:
> > >>>>> According to my tests
> > >>>>> textarea with hidden attribute works the same way as `display: none`
> > >>>>> (latest Chrome, FF, Chromium)
> > >>>>>
> > >>> Maxim and Andrew: Yes, the display: none is very important. (That's
> > >>> why it even has !important). The hidden attribute has the lowest
> > >>> priority possible. Any matching CSS rule will override it's behavior.
> > >>> For example, if you have this html:
> > >>> 
> > >>> li { display: list-item; }
> > >>> This will be visible
> > >>> 
> > >>> The li is visible, even though it has the hidden attribute. This is
> > >>> not what we want. Keep in mind that this is about components with
> > >>> isVisible() == false. The only reason we render something is because a
> > >>> placeholder is needed for Ajax updates.
> > >>>
> > >>>> Additionally, I think we should not use just
> > >>>> [hidden] {
> > >>>> ...
> > >>>> }
> > >>>>
> > >>>> in wicker-core.css because this will affect *all* elements in the
> > page.
> > >> And
> > >>>> the applications may not want Wicket styling for their own hidden
> > >> elements.
> > >>>> The CSS rule should be namespaced with "wicket-something", like
> > >>>> wicket-xyz[hidden] {...}
> > >>> I totally agree with Martin here. hidden already has semantics, we
> > >>> shouldn't tamper with that. Adding 'display: none!important' to hidden
> > >>> breaks the behavior described above.
> > >>>
> > >>>>> So I would vote for using `hidden="hidden"` for placeholders and
> > >> preserving
> > >>>>> `data-wicket-placeholder`
> > >>>>> (due to hidden can be used in regular markup while
> > >>>>> `data-wicket-placeholder` is clear way to determine the placeholders)
> > >>> The data-wicket-placeholder is indeed needed. All placeholders are
> > >>> hidden, but not all hidden elements are placeholders. As stated above,
> > >>> I'd vote against using the hidden attribute. We need something with a
> > >>> wicket namespace here. We can have the CSS match
> > >>> [data-wicket-placeholder], but I'm not a big fan of matching data
> > >>> attributes in CSS.
> > >>>

Re: [wicket] branch csp updated: WICKET-6725: replace display:none by wicket--hidden css class

[Emond Papegaaij]

> > According to my tests
> > textarea with hidden attribute works the same way as `display: none`
> > (latest Chrome, FF, Chromium)
> >

Maxim and Andrew: Yes, the display: none is very important. (That's
why it even has !important). The hidden attribute has the lowest
priority possible. Any matching CSS rule will override it's behavior.
For example, if you have this html:

li { display: list-item; }
This will be visible

The li is visible, even though it has the hidden attribute. This is
not what we want. Keep in mind that this is about components with
isVisible() == false. The only reason we render something is because a
placeholder is needed for Ajax updates.

> Additionally, I think we should not use just
> [hidden] {
> ...
> }
>
> in wicker-core.css because this will affect *all* elements in the page. And
> the applications may not want Wicket styling for their own hidden elements.
> The CSS rule should be namespaced with "wicket-something", like
> wicket-xyz[hidden] {...}

I totally agree with Martin here. hidden already has semantics, we
shouldn't tamper with that. Adding 'display: none!important' to hidden
breaks the behavior described above.

> > So I would vote for using `hidden="hidden"` for placeholders and preserving
> > `data-wicket-placeholder`
> > (due to hidden can be used in regular markup while
> > `data-wicket-placeholder` is clear way to determine the placeholders)

The data-wicket-placeholder is indeed needed. All placeholders are
hidden, but not all hidden elements are placeholders. As stated above,
I'd vote against using the hidden attribute. We need something with a
wicket namespace here. We can have the CSS match
[data-wicket-placeholder], but I'm not a big fan of matching data
attributes in CSS.

Best regards,
Emond

> >
> > On Wed, 15 Jan 2020 at 04:55, Andrew Kondratev 
> > wrote:
> >
> > > Hi Everyone!
> > >
> > > Is this "none !important" actually needed? Elements with hidden attribute
> > > are hidden by themselves, except the cases when they have some display
> > > overrides (see
> > >
> > https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/hidden
> > > ).
> > > If developer/user does override he or she could take care of this by
> > > himself.
> > >
> > > If the only style in core css is this wicket--hidden the whole css is,
> > > probably unnecessary.
> > >
> > > ср, 15 янв. 2020 г. в 10:38, Sven Meier :
> > >
> > > > Hi Edmond,
> > > >
> > > > then I'll ask again:
> > > >
> > > > Why not render a "hidden" attribute and style it in the core css:
> > > >
> > > > |[hidden] { display: none !important}|
> > > >
> > > > We could get rid of the "data-wicket-placeholder" attribute as well,
> > and
> > > > let wicket-ajax check on the "hidden" attribute instead.
> > > >
> > > > Sven
> > > >
> > > > On 14.01.20 21:06, Emond Papegaaij wrote:
> > > > >>   >Using the hidden attribute is no option either,
> > > > >>   >because it is overridden by any css that sets display.
> > > > >>
> > > > >> why is that a no-option, hidden elements can be styled too:
> > > > > Dropping the styling altogether will force our users to package their
> > > > > own styling for artifacts generated by Wicket. These styles are not
> > to
> > > > > make your application look nice, but to make certain Wicket internals
> > > > > work as expected. In the case of wicket--hidden, not much else can be
> > > > > done than use 'display:none'. In the case of the Form parts, more
> > > > > elaborate styling is need to keep the extra fields hidden without
> > > > > using display:none. Why put the burden on the user of Wicket when we
> > > > > can package those styling ourselves? I can put the registration of
> > the
> > > > > IHeaderContributor in a protected method in WebApplication. That way
> > > > > you can change the behavior in a subclass. You can already change the
> > > > > stylesheet if you need to.
> > > > >
> > > > >> Do you mean FormComponentFeedbackBorder's "color:red;" style?
> > > > >> I wouldn't want that to be located in a 'kitchen-sink' CSS file in
> > the
> > > > >> future.
> > > > > Yes, that's the styling I meant. There are more examples. IMHO those
> > > >

Re: [wicket] branch csp updated: WICKET-6725: replace display:none by wicket--hidden css class

[Emond Papegaaij]

>  >Using the hidden attribute is no option either,
>  >because it is overridden by any css that sets display.
>
> why is that a no-option, hidden elements can be styled too:

Dropping the styling altogether will force our users to package their
own styling for artifacts generated by Wicket. These styles are not to
make your application look nice, but to make certain Wicket internals
work as expected. In the case of wicket--hidden, not much else can be
done than use 'display:none'. In the case of the Form parts, more
elaborate styling is need to keep the extra fields hidden without
using display:none. Why put the burden on the user of Wicket when we
can package those styling ourselves? I can put the registration of the
IHeaderContributor in a protected method in WebApplication. That way
you can change the behavior in a subclass. You can already change the
stylesheet if you need to.

> Do you mean FormComponentFeedbackBorder's "color:red;" style?
> I wouldn't want that to be located in a 'kitchen-sink' CSS file in the
> future.

Yes, that's the styling I meant. There are more examples. IMHO those
are typical candidates for CSS classes, but without styling packaged
with Wicket (like with FeedbackPanel). The styling is not going to
match the users application anyway. Who would want to use red as a
color for a border? Even for me, being colorblind, that color is way
too saturated.

Best regards,
Emond

>
> Have fun
> Sven||
> ||
>
>
> On 14.01.20 20:31, Emond Papegaaij wrote:
> > Hi,
> >
> > Sven, we do need styling to hide components.
> > Component.renderPlaceholderTag renders an empty tag for whatever it
> > reads from your markup. That fact that it is empty, does not mean it
> > is invisible. For example, in my application I had empty list-items
> > (li) popping up all over the place. Using the hidden attribute is no
> > option either, because it is overridden by any css that sets display.
> > We need something that takes precedence over most styling and hides
> > the component for sure.
> >
> > Maxim, I didn't know about the application wide IHeaderContributors.
> > I'll give that a try, it seems cleaner to me than overriding
> > renderHead in Page.
> >
> > About the contents of the stylesheet, it will probably not contain
> > much styling, but it will be more than just wicket--hidden. For
> > example, the styling for the form submit handling markup needs to go
> > there as well. I also found some other places with inline styling,
> > like FormComponentFeedbackBorder. We need to decide what to do with
> > those as well.
> >
> > Best regards,
> > Emond
> >
> > On Tue, Jan 14, 2020 at 7:19 PM Sven Meier  wrote:
> >> Hi Maxim,
> >>
> >> an empty div with hidden inputs does not take any space.
> >>
> >> Try it with wicket-examples.
> >>
> >> Have fun
> >> Sven
> >>
> >> Am 14. Januar 2020 18:07:23 MEZ schrieb Maxim Solodovnik 
> >> :
> >>> I thought the main idea is to keep placeholder for any element both
> >>> invisible and "take no space"
> >>> hidden attribute might work instead of `display: none`
> >>> The latter also hides all descendants [1], so I guess it should be
> >>> preferable
> >>>
> >>> [1] https://developer.mozilla.org/en-US/docs/Web/CSS/display
> >>>
> >>> On Wed, 15 Jan 2020 at 00:01, Sven Meier  wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> do we really need this CSS?
> >>>>
> >>>> AFAIK the 'hidden' markup from Form and Component placeholders do not
> >>>> need any styling actually, they look fine without it.
> >>>> We should add a CSS class to the markup of course, but leave its
> >>> styling
> >>>> to each project.
> >>>>
> >>>> Cases in wicket-examples (UploadProgressBar, deprecated ModalWindow
> >>> and
> >>>> AjaxIndicatorAppender) could switch to a different solution (e.g.
> >>> their
> >>>> own CSS).
> >>>>
> >>>> If wicket-base.css contains ".wicket--hidden" only, the effort isn't
> >>>> worth it IMHO.
> >>>>
> >>>> Sven
> >>>>
> >>>>
> >>>> On 14.01.20 16:23, Maxim Solodovnik wrote:
> >>>>> For example it can be added as
> >>>>> `Application.get().getHeaderContributorListeners()`
> >>>>>
> >>>>> On Tue, 14 Jan 2020 at 16:03, Maxim Solodovni

Re: [wicket] branch csp updated: WICKET-6725: replace display:none by wicket--hidden css class

[Emond Papegaaij]

Hi,

Sven, we do need styling to hide components.
Component.renderPlaceholderTag renders an empty tag for whatever it
reads from your markup. That fact that it is empty, does not mean it
is invisible. For example, in my application I had empty list-items
(li) popping up all over the place. Using the hidden attribute is no
option either, because it is overridden by any css that sets display.
We need something that takes precedence over most styling and hides
the component for sure.

Maxim, I didn't know about the application wide IHeaderContributors.
I'll give that a try, it seems cleaner to me than overriding
renderHead in Page.

About the contents of the stylesheet, it will probably not contain
much styling, but it will be more than just wicket--hidden. For
example, the styling for the form submit handling markup needs to go
there as well. I also found some other places with inline styling,
like FormComponentFeedbackBorder. We need to decide what to do with
those as well.

Best regards,
Emond

On Tue, Jan 14, 2020 at 7:19 PM Sven Meier  wrote:
>
> Hi Maxim,
>
> an empty div with hidden inputs does not take any space.
>
> Try it with wicket-examples.
>
> Have fun
> Sven
>
> Am 14. Januar 2020 18:07:23 MEZ schrieb Maxim Solodovnik 
> :
> >I thought the main idea is to keep placeholder for any element both
> >invisible and "take no space"
> >hidden attribute might work instead of `display: none`
> >The latter also hides all descendants [1], so I guess it should be
> >preferable
> >
> >[1] https://developer.mozilla.org/en-US/docs/Web/CSS/display
> >
> >On Wed, 15 Jan 2020 at 00:01, Sven Meier  wrote:
> >
> >> Hi,
> >>
> >> do we really need this CSS?
> >>
> >> AFAIK the 'hidden' markup from Form and Component placeholders do not
> >> need any styling actually, they look fine without it.
> >> We should add a CSS class to the markup of course, but leave its
> >styling
> >> to each project.
> >>
> >> Cases in wicket-examples (UploadProgressBar, deprecated ModalWindow
> >and
> >> AjaxIndicatorAppender) could switch to a different solution (e.g.
> >their
> >> own CSS).
> >>
> >> If wicket-base.css contains ".wicket--hidden" only, the effort isn't
> >> worth it IMHO.
> >>
> >> Sven
> >>
> >>
> >> On 14.01.20 16:23, Maxim Solodovnik wrote:
> >> > For example it can be added as
> >> > `Application.get().getHeaderContributorListeners()`
> >> >
> >> > On Tue, 14 Jan 2020 at 16:03, Maxim Solodovnik
> >
> >> wrote:
> >> >
> >> >> `!important` is not the silver bullet (as well as inline style)
> >> >>
> >> >> `renderHead` is not as important as `onConfigure`, so I believe it
> >> >> shouldn't be made mandatory
> >> >> Maybe there is some `hackish` way to inject this css only once for
> >any
> >> >> component hierarchy?
> >> >>
> >> >> On Tue, 14 Jan 2020 at 15:55, Emond Papegaaij <
> >> emond.papega...@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> Rendering components without a page will indeed require you to
> >include
> >> >>> the core css file yourself. I think that's better than adding the
> >css
> >> >>> file with every component, as that will impose a massive
> >overhead.
> >> >>> I've renamed the css file to wicket-core.css as suggested by
> >Martin.
> >> >>> The idea is to collect all styling used with wicket-core in this
> >css
> >> >>> file. I do not like the idea to use a behavior for adding the
> >> >>> stylesheet, as that will increase the size of every page. Maybe a
> >> >>> temporary behavior can be used, but that will need to be re-added
> >on
> >> >>> every render then. Maybe, we can add a check to super.renderHead,
> >like
> >> >>> we do with onConfgure and onInitialize?
> >> >>>
> >> >>> Using the hidden attribute is not a good idea, for the same
> >reason as
> >> >>> I chose to use !important in the css file: any matching css rule
> >that
> >> >>> is more specify will otherwise override the visibility and cause
> >the
> >> >>> component to be visible anyway (like display: flex).
> >> >>>
> >> >>> Best regards,
> >> >>> Emond
> >> >>>
> >> >>> 

Re: CSP in Wicket 9

[Emond Papegaaij]

I've discussed this with our unit manager, and got permission to
donate our CSP code to Wicket. I think a strong, out of the box CSP is
a killer feature to have for Wicket 9. Not many frameworks can match
this. For this, I would like to continue working on the following
parts:
* Remove all inline styling and JS from Wicket. I will need some help
with this, especially the Form related code.
* Make sure all examples work find with a strong CSP enabled
* Add the CSP code to Wicket and provide several presets (strong,
unsafeJsAndStyling, reportOnly, disabled)
* Enable CSP with the strong preset by default

I've already started the work on the 'csp' branch. On this branch,
I've also migrated all but the servlet API to the jakarta namespace.

Best regards,
Emond

On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij
 wrote:
>
> Searching through our Jira, I've found WICKET-6687, filed by Andrew.
> He already pinpointed several places that break with a strict CSP
> enabled. I'm going to convert that bug into a task (we do not have
> epic) and create new bugs for all issues in that ticket. That should
> make it easier to track progress.
>
> Best regards,
> Emond
>
> On Sat, Jan 11, 2020 at 10:31 PM Emond Papegaaij
>  wrote:
> >
> > Hi all,
> >
> > For the past few days I've been experimenting with the new CSP
> > features in Wicket 9. I really want to thank Andrew, Sven and Martin
> > for the great work you guys did in making this possible. I'm getting
> > very close to running my application with a very tight and secure CSP.
> > Unfortunately, some parts of Wicket still use inline styling and
> > scripting. So far I've found the following two issues:
> >
> > * hidden components with setOutputMarkupPlaceholderTag(true) have 
> > display:none
> > * Forms render inline styling and javascript in some cases to improve
> > submit handling
> >
> > I think we should try to fix these before Wicket 9 is released. I will
> > continue to debug our application to see if there are more places.
> >
> > At Topicus we wrote a IRequestCycleListener that applies the CSP
> > automatically to every request via HTTP headers. The API makes it easy
> > to configure the CSP. I've added support for the nonce as well. It
> > uses a new nonce for every request, which should be more secure than a
> > nonce bound to a session. I'll discuss with my employee next week if
> > we can donate this code to Wicket.
> >
> > Best regards,
> > Emond

Re: CSP in Wicket 9

[Emond Papegaaij]

Searching through our Jira, I've found WICKET-6687, filed by Andrew.
He already pinpointed several places that break with a strict CSP
enabled. I'm going to convert that bug into a task (we do not have
epic) and create new bugs for all issues in that ticket. That should
make it easier to track progress.

Best regards,
Emond

On Sat, Jan 11, 2020 at 10:31 PM Emond Papegaaij
 wrote:
>
> Hi all,
>
> For the past few days I've been experimenting with the new CSP
> features in Wicket 9. I really want to thank Andrew, Sven and Martin
> for the great work you guys did in making this possible. I'm getting
> very close to running my application with a very tight and secure CSP.
> Unfortunately, some parts of Wicket still use inline styling and
> scripting. So far I've found the following two issues:
>
> * hidden components with setOutputMarkupPlaceholderTag(true) have display:none
> * Forms render inline styling and javascript in some cases to improve
> submit handling
>
> I think we should try to fix these before Wicket 9 is released. I will
> continue to debug our application to see if there are more places.
>
> At Topicus we wrote a IRequestCycleListener that applies the CSP
> automatically to every request via HTTP headers. The API makes it easy
> to configure the CSP. I've added support for the nonce as well. It
> uses a new nonce for every request, which should be more secure than a
> nonce bound to a session. I'll discuss with my employee next week if
> we can donate this code to Wicket.
>
> Best regards,
> Emond

CSP in Wicket 9

[Emond Papegaaij]

Hi all,

For the past few days I've been experimenting with the new CSP
features in Wicket 9. I really want to thank Andrew, Sven and Martin
for the great work you guys did in making this possible. I'm getting
very close to running my application with a very tight and secure CSP.
Unfortunately, some parts of Wicket still use inline styling and
scripting. So far I've found the following two issues:

* hidden components with setOutputMarkupPlaceholderTag(true) have display:none
* Forms render inline styling and javascript in some cases to improve
submit handling

I think we should try to fix these before Wicket 9 is released. I will
continue to debug our application to see if there are more places.

At Topicus we wrote a IRequestCycleListener that applies the CSP
automatically to every request via HTTP headers. The API makes it easy
to configure the CSP. I've added support for the nonce as well. It
uses a new nonce for every request, which should be more secure than a
nonce bound to a session. I'll discuss with my employee next week if
we can donate this code to Wicket.

Best regards,
Emond

Re: Jakarta EE 8 vs Java EE 8 APIs

[Emond Papegaaij]

I've prepared a branch 'jakarta-api' with the migration to Jakarta,
Servlet 4 and Jetty 10.0.0-alpha1. Most of the examples work fine,
however I get an NPE on the websocket upgrade:

Caused by: java.lang.NullPointerException
at 
org.eclipse.jetty.websocket.javax.common.JavaxWebSocketSession.getUserPrincipal(JavaxWebSocketSession.java:511)
at 
org.apache.wicket.protocol.ws.javax.JavaxUpgradeHttpRequest.(JavaxUpgradeHttpRequest.java:77)
at 
org.apache.wicket.protocol.ws.javax.JavaxWebSocketProcessor.(JavaxWebSocketProcessor.java:46)
at 
org.apache.wicket.protocol.ws.javax.WicketEndpoint.onOpen(WicketEndpoint.java:65)
at 
org.eclipse.jetty.websocket.javax.common.JavaxWebSocketFrameHandler.onOpen(JavaxWebSocketFrameHandler.java:197)

On Fri, Jan 10, 2020 at 3:32 PM Martin Grigorov  wrote:
>
> On Fri, Jan 10, 2020 at 4:03 PM Emond Papegaaij 
> wrote:
>
> > I tend to agree with Martijn here. The Jakarta APIs are the future. It
> > is unfortunate that the last stable version of Jetty is 4 years old
> > now and they have not been able to produce a new version in the past 2
> > years. Maybe us moving to servlet 4 will give them a bit more
> > incentive to pick op the pace.
> >
>
> I am -0.
> I don't see the urge for this change
>
>
> >
> > For the examples, it should not be that hard to use a jetty 10 milestone.
> >
> > Emond
> >
> > On Fri, Jan 10, 2020 at 2:41 PM Jeroen Steenbeeke
> >  wrote:
> > >
> > > Most of my Wicket applications (i.e. the ones I don't get paid to write)
> > > run on Jetty 9.4, Java 11 and Wicket 8.
> > >
> > > Jetty 10 is, as indicated on the site I linked, still in alpha and marked
> > > as unstable, and has no official Docker image yet.
> > >
> > > Right now there is nothing blocking me from adopting Wicket 9,
> > introducing
> > > servlet 4.0 would mean I cannot upgrade until Jetty stabilizes.
> > >
> > > - Jeroen
> > >
> > > Op vr 10 jan. 2020 om 14:29 schreef Martijn Dashorst <
> > > martijn.dasho...@gmail.com>:
> > >
> > > > On Fri, Jan 10, 2020 at 2:09 PM Jeroen Steenbeeke
> > > >  wrote:
> > > > >
> > > > > Jetty is still on 3.1:
> > > > >
> > > > >
> > > >
> > https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
> > > >
> > > > Well, Emond was talking about the major application/servlet containers
> > > > :-D...
> > > >
> > > > As we are targeting Java 11 with Wicket 9, perhaps 'ignoring' Jetty <=
> > > > 9.x and aiming for Jetty 10 might not be *that* a big issue?
> > > >
> > > > Martijn
> > > >
> > > >
> > > > >
> > > > > Op vr 10 jan. 2020 om 14:05 schreef Emond Papegaaij <
> > > > > emond.papega...@gmail.com>:
> > > > >
> > > > > > It turns out Wicket 9 is still on servlet 3.1, which is
> > pre-Jakarta.
> > > > > > Any objections against raising this to 4.0? AFAIK all major
> > > > > > application/servlet containers have versions with support for 4.0.
> > > > > >
> > > > > > Best regards,
> > > > > > Emond
> > > > > >
> > > > > > On Fri, Jan 10, 2020 at 1:04 PM Martijn Dashorst
> > > > > >  wrote:
> > > > > > >
> > > > > > > Just the maven coordinates.
> > > > > > >
> > > > > > > As for expected problems: probably folks have to update their
> > poms to
> > > > > > > use the jakarta variants, but mostly they shouldn't bite if they
> > use
> > > > > > > the provided scope.
> > > > > > >
> > > > > > > For benefits:
> > > > > > > - the Jakarta group-id is the future, all servers will move to
> > that
> > > > > > > maven coordinate
> > > > > > > - the licensing is now uniform (Eclipse) instead of whatever the
> > spec
> > > > > > > lead thought was good
> > > > > > > - marketing: "Wicket has moved to use the Jakarta EE Maven
> > artifacts,
> > > > > > > embracing the future of Java Enterprise software development"
> > > > > > > - hopefully the naming of the GAV will remain sane, instead of
> > each
> > > > > > > spec lead using a different naming scheme (even across versions)
> >

Re: Jakarta EE 8 vs Java EE 8 APIs

[Emond Papegaaij]

I tend to agree with Martijn here. The Jakarta APIs are the future. It
is unfortunate that the last stable version of Jetty is 4 years old
now and they have not been able to produce a new version in the past 2
years. Maybe us moving to servlet 4 will give them a bit more
incentive to pick op the pace.

For the examples, it should not be that hard to use a jetty 10 milestone.

Emond

On Fri, Jan 10, 2020 at 2:41 PM Jeroen Steenbeeke
 wrote:
>
> Most of my Wicket applications (i.e. the ones I don't get paid to write)
> run on Jetty 9.4, Java 11 and Wicket 8.
>
> Jetty 10 is, as indicated on the site I linked, still in alpha and marked
> as unstable, and has no official Docker image yet.
>
> Right now there is nothing blocking me from adopting Wicket 9, introducing
> servlet 4.0 would mean I cannot upgrade until Jetty stabilizes.
>
> - Jeroen
>
> Op vr 10 jan. 2020 om 14:29 schreef Martijn Dashorst <
> martijn.dasho...@gmail.com>:
>
> > On Fri, Jan 10, 2020 at 2:09 PM Jeroen Steenbeeke
> >  wrote:
> > >
> > > Jetty is still on 3.1:
> > >
> > >
> > https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
> >
> > Well, Emond was talking about the major application/servlet containers
> > :-D...
> >
> > As we are targeting Java 11 with Wicket 9, perhaps 'ignoring' Jetty <=
> > 9.x and aiming for Jetty 10 might not be *that* a big issue?
> >
> > Martijn
> >
> >
> > >
> > > Op vr 10 jan. 2020 om 14:05 schreef Emond Papegaaij <
> > > emond.papega...@gmail.com>:
> > >
> > > > It turns out Wicket 9 is still on servlet 3.1, which is pre-Jakarta.
> > > > Any objections against raising this to 4.0? AFAIK all major
> > > > application/servlet containers have versions with support for 4.0.
> > > >
> > > > Best regards,
> > > > Emond
> > > >
> > > > On Fri, Jan 10, 2020 at 1:04 PM Martijn Dashorst
> > > >  wrote:
> > > > >
> > > > > Just the maven coordinates.
> > > > >
> > > > > As for expected problems: probably folks have to update their poms to
> > > > > use the jakarta variants, but mostly they shouldn't bite if they use
> > > > > the provided scope.
> > > > >
> > > > > For benefits:
> > > > > - the Jakarta group-id is the future, all servers will move to that
> > > > > maven coordinate
> > > > > - the licensing is now uniform (Eclipse) instead of whatever the spec
> > > > > lead thought was good
> > > > > - marketing: "Wicket has moved to use the Jakarta EE Maven artifacts,
> > > > > embracing the future of Java Enterprise software development"
> > > > > - hopefully the naming of the GAV will remain sane, instead of each
> > > > > spec lead using a different naming scheme (even across versions)
> > > > >
> > > > > Martijn
> > > > >
> > > > > On Fri, Jan 10, 2020 at 12:03 PM Martin Grigorov <
> > mgrigo...@apache.org>
> > > > wrote:
> > > > > >
> > > > > > Hi Emond,
> > > > > >
> > > > > > If it is just about different Maven coordinates then it is OK.
> > > > > > For the change javax.servlet -> jakarta.servlet it is too soon.
> > > > > >
> > > > > > On Fri, Jan 10, 2020 at 12:40 PM Emond Papegaaij <
> > > > emond.papega...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > While building our application against Wicket 9, I noticed Wicket
> > > > > > > still uses the Java EE 8 APIs. I would like to change these to
> > the
> > > > > > > Jakarta versions. The APIs themselves are completely identical,
> > it is
> > > > > > > just the maven coordinate that changes. They do however come
> > with a
> > > > > > > better license (Eclipse). What do you think?
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Emond
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Become a Wicket expert, learn from the best:
> > http://wicketinaction.com
> > > >
> > >
> > >
> > > --
> > > Jeroen Steenbeeke
> >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> >
>
>
> --
> Jeroen Steenbeeke

Re: Jakarta EE 8 vs Java EE 8 APIs

[Emond Papegaaij]

It turns out Wicket 9 is still on servlet 3.1, which is pre-Jakarta.
Any objections against raising this to 4.0? AFAIK all major
application/servlet containers have versions with support for 4.0.

Best regards,
Emond

On Fri, Jan 10, 2020 at 1:04 PM Martijn Dashorst
 wrote:
>
> Just the maven coordinates.
>
> As for expected problems: probably folks have to update their poms to
> use the jakarta variants, but mostly they shouldn't bite if they use
> the provided scope.
>
> For benefits:
> - the Jakarta group-id is the future, all servers will move to that
> maven coordinate
> - the licensing is now uniform (Eclipse) instead of whatever the spec
> lead thought was good
> - marketing: "Wicket has moved to use the Jakarta EE Maven artifacts,
> embracing the future of Java Enterprise software development"
> - hopefully the naming of the GAV will remain sane, instead of each
> spec lead using a different naming scheme (even across versions)
>
> Martijn
>
> On Fri, Jan 10, 2020 at 12:03 PM Martin Grigorov  wrote:
> >
> > Hi Emond,
> >
> > If it is just about different Maven coordinates then it is OK.
> > For the change javax.servlet -> jakarta.servlet it is too soon.
> >
> > On Fri, Jan 10, 2020 at 12:40 PM Emond Papegaaij 
> > wrote:
> >
> > > Hi all,
> > >
> > > While building our application against Wicket 9, I noticed Wicket
> > > still uses the Java EE 8 APIs. I would like to change these to the
> > > Jakarta versions. The APIs themselves are completely identical, it is
> > > just the maven coordinate that changes. They do however come with a
> > > better license (Eclipse). What do you think?
> > >
> > > Best regards,
> > > Emond
> > >
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com

Jakarta EE 8 vs Java EE 8 APIs

[Emond Papegaaij]

Hi all,

While building our application against Wicket 9, I noticed Wicket
still uses the Java EE 8 APIs. I would like to change these to the
Jakarta versions. The APIs themselves are completely identical, it is
just the maven coordinate that changes. They do however come with a
better license (Eclipse). What do you think?

Best regards,
Emond

Re: Building with JDK 14 ea

[Emond Papegaaij]

Indeed, the build does not fail, it barfs various nasty errors and
ends with 'BUILD SUCCESS' :) It does however not build the javadoc.
I've filed https://issues.apache.org/jira/browse/MJAVADOC-633

Best regards,
Emond

On Fri, Jan 10, 2020 at 10:19 AM Martin Grigorov  wrote:
>
> On Fri, Jan 10, 2020 at 11:12 AM Martin Grigorov 
> wrote:
>
> >
> >
> > On Fri, Jan 10, 2020 at 11:02 AM Martin Grigorov 
> > wrote:
> >
> >>
> >>
> >> On Fri, Jan 10, 2020 at 10:58 AM Maxim Solodovnik 
> >> wrote:
> >>
> >>> `clean package` sounds more reasonable to me :)
> >>>
> >>
> >> agreed, but let's change that only once we have a fix/workaround for the
> >> problem
> >>
> >
> > it seems it does not break the build, so it is OK to make this change now
> > I will do it
> >
>
> Done!
>
>
> >
> >
> >>
> >>
> >>>
> >>> On Fri, 10 Jan 2020 at 15:57, Maxim Solodovnik 
> >>> wrote:
> >>>
> >>> > `fast` profile skips javadoc 
> >>> >
> >>> > On Fri, 10 Jan 2020 at 15:56, Martin Grigorov 
> >>> > wrote:
> >>> >
> >>> >> Hi Emond,
> >>> >>
> >>> >> Locally while testing new JDK builds I always use: mvn14 clean install
> >>> >> -Pfast,java14
> >>> >> mvn14 script just exports JAVA_HOME=$JAVA_14_HOME and calls mvn
> >>> >> and I don't remember having issues with javadoc since a long time.
> >>> >>
> >>> >> On Fri, Jan 10, 2020 at 10:45 AM Emond Papegaaij <
> >>> >> emond.papega...@gmail.com>
> >>> >> wrote:
> >>> >>
> >>> >> > Hi all,
> >>> >> >
> >>> >> > I just noticed a problem with building Wicket on JDK 14, which is
> >>> not
> >>> >> > detected by our current build setup. On JDK 13+, javadoc fails with:
> >>> >> >
> >>> >> > [ERROR] MavenReportException: Error while generating Javadoc:
> >>> >> > Exit code: 1 - javadoc: error - invalid flag:
> >>> --no-module-directories
> >>> >> >
> >>> >> > Command line was: /usr/lib/jvm/java-14-openjdk-amd64/bin/javadoc
> >>> >> > -J-Xmx256m -J-Xms128m --no-module-directories @options @packages
> >>> >> >
> >>> >> > Shouldn't our build detect such issues? At the moment we run 'mvn
> >>> >> > clean test'. Maybe we should run 'mvn clean package' instead? I'll
> >>> >> > submit a bug report on maven-javadoc-plugin later today. It seems
> >>> the
> >>> >> > maintainers are not yet aware of this issue.
> >>> >> >
> >>> >> > Best regards,
> >>> >> > Emond
> >>> >> >
> >>> >>
> >>> >
> >>> >
> >>> > --
> >>> > WBR
> >>> > Maxim aka solomax
> >>> >
> >>>
> >>>
> >>> --
> >>> WBR
> >>> Maxim aka solomax
> >>>
> >>

ChainingModel.getChainedModel in 9

[Emond Papegaaij]

Hi all,

With the Wicket 9 release coming closer, I decided to give our code
base a try. Most of the compilation problems were easy to fix, but I'm
missing ChaningModel.getChainedModel(). This method was deleted with
the removal of the IChainingModel interface (which I do not need).
Without this method there is no way to access the target. Does anyone
have objections to reintroduce this method and also make getTarget()
public? The latter I do not specifically need, but it seems strange to
only give access to the target when it's a model.

Best regards,
Emond

Re: wicket-ajax.js cleanup

[Emond Papegaaij]

On vrijdag 3 mei 2019 17:16:02 CEST Sven Meier wrote:
> JS Tests are not built each time, so npm is not a requirement to build
> Wicket. I'd like to keep it that way.

With the frontend-maven-plugin it isn't required to have it installed on your 
system. The plugin will download node and npm as part of the build. It works 
on all operating systems. The only problem I have with npm is the package-
lock.json that keeps changing.

Emond

Re: wicket-ajax.js cleanup

[Emond Papegaaij]

Hi,

We use the frontend-maven-plugin, which automatically downloads and installs 
node as part of your maven build. It works quite ok.

Emond

On vrijdag 3 mei 2019 11:56:14 CEST Andrew Kondratev wrote:
> Thank you. I understand these concerns.
> 
> Speaking about performance concern, if node is available on machine and
> modules are installed it takes less than 3 seconds to build on my laptop
> from 2013, incomparable with entire wicket build time. However, with node
> installation and modules installation it, indeed, takes a while and I also
> don't want everyone who building wicket to rely on these unnecessary steps.
> 
> I can suggest one of these two options, to reduce pain from TS
> transpilation:
> 1. Keep a transpiled JS file with DON'T EDIT disclaimer in the repository
> (it's quite a typical approach for JS libraries, they quite often have
> 'dist' directory right in the repo);
> 2. Create a separate repository/project and publish an artifact into the
> maven;
> 
> Testwise I don't see any problem at all, even if source-maps are SUDDENLY
> not available: generally reading transpiled TS is not like reading
> transpiled Kotlin, the resulting JS is almost the same as the original TC
> just without types and some goodies. There's no problem to spot a place in
> the source code by looking at javascript at all. We all use minified
> javascript in prod and it's not a big deal.
> 
> пт, 3 мая 2019 г. в 18:45, Martin Grigorov :
> > On Fri, May 3, 2019 at 9:32 AM Sven Meier  wrote:
> > > Hi,
> > > 
> > > 
> > > 
> > > yes, we could get rid of some crufty code here.
> > > 
> > > 
> > > 
> > > But before you put too much effort into this:
> > > 
> > > Do we really want to blow up our build with npm/typescript just to
> > > generate ~3000 lines of code?
> > > 
> > > I doubt that it's worth it. The code is very stable and well tested
> > 
> > anyway.
> > 
> > 
> > My main concern is whether it will be still easy to debug the JS code.
> > If everything is fine with the sourcemaps then it should be OK, but in my
> > experience very often something breaks in this area and the browsers
> > cannot
> > properly map the JS to the original TS code and one have to deal with the
> > auto-generated code.
> > 
> > > Sometimes I'm working on machines where I can't even use/install npm.
> > > 
> > > 
> > > 
> > > 
> > > Sven
> > > 
> > > > On 02.05.2019 at 22:56,wrote:
> > > >  Hi Sven! Do you mean removing entire wicket-ajax-jquery-debug.js and
> > > 
> > > making Wicket.Log to simply use console instead? пт, 3 мая 2019 г. в
> > 
> > 01:16,
> > 
> > > Andrea Del Bene :  >  I'm +1 for all these proposed improvements.  >   >
> > > On 5/2/19 11:55 AM, Sven Meier wrote:  >   >   >   >   >   >  Indeed
> > > (stupid phones), see my follow up.  >   >   >   >   >   >   >   > 
> > > Thanks
> > > 
> > > >   >   >   >  Sven  >   >   >   >   >   >   >   >   >   >   >   >   >
> > > >   >   >   >  
> > >  >   >   >   >   >   >>   >   >>  On 02.05.2019 at 11:53, wrote:  >   >>
> > >  >   >>   >   >>  
> > >  >   >>   >   >>  Hi Sven, I have the feeling you pressed the Send
> > >  >   >>   >   >>  button
> > > 
> > > before  >  finishing your email. On Thu, May 2, 2019 at 12:42 PM Sven
> > 
> > Meier
> > 
> > > wrote:  >   >   >   >  Hi all,  >   >   >   >  before starting a larger
> > > effort on our JS  >  code, we could do some smaller  >  cleanups.  >   >
> > > 
> > >  >   >  - remove Ajax  >  debug mode  >  Last time when I suggested this
> > > 
> > > someone from the community  >  expressed concern that the most useful
> > > functionality in it is that it  >  blinks when there is an error.  >   >

Re: Maven enforcer breakage...

[Emond Papegaaij]

This is not something we can fix in Wicket. Dependency management is not 
transitive over dependencies. Wicket already manages commons-io at version 
2.5. To fix this error, you'll need to manage the version of commons-io 
yourself.

Best regards,
Emond Papegaaij

On donderdag 24 januari 2019 12:35:38 CET nino martinez wael wrote:
> Sorry for the short mail, just saw this.. Should I create a task / bug for
> it in jira?
> 
>   Dependency convergence error for commons-io:commons-io:2.2 paths to
> dependency are:
> +-dk.netdesign.ccadmin:ccadmin-frontend:3.0.0-SNAPSHOT
>   +-com.giffing.wicket.spring.boot.starter:wicket-spring-boot-starter:2.1.5
> +-org.apache.wicket:wicket-core:8.2.0
>   +-org.apache.wicket:wicket-util:8.2.0
> +-commons-fileupload:commons-fileupload:1.3.3
>   +-commons-io:commons-io:2.2
> and
> +-dk.netdesign.ccadmin:ccadmin-frontend:3.0.0-SNAPSHOT
>   +-com.giffing.wicket.spring.boot.starter:wicket-spring-boot-starter:2.1.5
> +-org.apache.wicket:wicket-core:8.2.0
>   +-org.apache.wicket:wicket-util:8.2.0
> +-commons-io:commons-io:2.5

Re: [VOTE] Release Apache Wicket 7.11.0

[Emond Papegaaij]

As Wicket 7 is supposed to be built with jdk7, why not simply add the profile 
but not enable it by default when on jdk8? If you want build with jdk8 (or 
higher), you can enable the profile on the command line.

Best regards,
Emond

On maandag 26 november 2018 10:43:55 CET Maxim Solodovnik wrote:
> Hello Andrea,
> 
> "extend the existing java8 profile activating it by default if our default
> JDK is 1.8 or higher" will break toolchains build,
> Here are the logs
> https://ci.apache.org/builders/wicket-branch-7.x/builds/500/steps/compile/lo
> gs/stdio (I
> already tried it)
> 
> On Mon, 26 Nov 2018 at 16:40, Andrea Del Bene  wrote:
> > Hi all,
> > 
> > following the discussion about the issues related to the building of
> > 7.11.0
> > candidate, I suggest to do the following actions:
> > 
> > -cancel this vote
> > -remove the flag '--allow-script-in-comments' from JavaDoc plugin
> > configuration
> > -extend the existing java8 profile activating it by default if our default
> > JDK is 1.8 or higher (with expresion '[1.8,)'). I now this solution won't
> > work for all 1.8 versions out there, but it should with most recent
> > versions of it. Honestly I can't find a better solution to make everybody
> > happy. This solution will NOT work only if somebody is using an outdated
> > version of JDK 1.8 as default JDK, but it should be ok in all the other
> > cases.
> > -...any suggestions?
> > 
> > 
> > 
> > On Mon, Nov 26, 2018 at 10:09 AM Maxim Solodovnik 
> > 
> > wrote:
> > > The error is something like:
> > > "Invalid parameter --allow-script-in-comments" and javadoc will fail
> > > 
> > > It looks like java8 profile is activated, I was sure it shouldn't since
> > > java7 was selected using toolchains ...
> > > 
> > > On Mon, 26 Nov 2018 at 15:54, Andrea Del Bene 
> > > 
> > > wrote:
> > > > Hi Maxim
> > > > 
> > > > On Mon, Nov 26, 2018 at 4:29 AM Maxim Solodovnik  > > > 
> > > > wrote:
> > > > > Hello Andrea,
> > > > > 
> > > > > according to my tests this is not working if toolchains plugin is
> > 
> > being
> > 
> > > > > used, i.e.:
> > > > > 1) java8 is set on the machine as default
> > > > > 2) -Pbuildbot is used to activate java7 build
> > > > > Result: java8 profile will be activated
> > > >  
> > > >  that's quite strange. Do you remember which error did you get with
> > 
> > this
> > 
> > > > combination? I've searched through old mails but I didn't find it.
> > > 
> > > Anyway,
> > > 
> > > > flag '--allow-script-in-comments' is supported in JDK 8 only starting
> > > 
> > > from
> > > 
> > > > u121:
> > https://www.oracle.com/technetwork/java/javase/8u121-relnotes-3315208.html
> > 
> > > > > On Mon, 26 Nov 2018 at 04:22, Andrea Del Bene 
> > > > > 
> > > > > wrote:
> > > > > > I see that Maxim has already addressed this problem with
> > 
> > WICKET-6615,
> > 
> > > > or
> > > > 
> > > > > > at least he partially did it. We should use a profile  which is
> > > > > > automatically activated when the JDK used to run Maven is >= 1.8 .
> > > > > > 
> > > > > > Something like this:
> > > > > >   
> > > > > >   
> > > > > >  java8
> > > > > >  
> > > > > >  
> > > > > >  [1.8,)
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > > 
> > > > > > org.apache.maven.plugins
> > > > > > maven-javadoc-plugin
> > > > > > 
> > > > > >  
> > > > > > 
> > > > > > --allow-script-in-comments
> > > > > > 
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > > 
> > > > > > A similar solution is described here:
> > https://stackoverflow.com/questions/15886209/maven-is-not-working-in-java-> 
> > > 8-when-javadoc-tags-are-incomplete> 
> > > > > > WDYT?
> > > > > > 
> > > > > > > For me the build of
> > 
> > https://dist.apache.org/repos/dist/dev/wicket/7.11.0/apache-wicket-7.11.0.
> > tar.gz> 
> > > > > > > fails with:
> > > > > > > 
> > > > > > > [INFO]
> > > 
> > > 
> > > 
> > > > > > > [INFO] BUILD FAILURE
> > > > > > > [INFO]
> > > 
> > > 
> > > 
> > > > > > > [INFO] Total time:  11.773 s
> > > > > > > [INFO] Finished at: 2018-11-25T20:44:37+02:00
> > > > > > > [INFO]
> > > 
> > > 
> > > 
> > > > > > > [ERROR] Failed to execute goal
> > > > > > > 

Re: [VOTE] Release Apache Wicket 8.1.0

[Emond Papegaaij]

Agreed, that's why I did not vote yet

+1 to release. Checked the source for release errors and checked the hashes. 
Also did a build locally and it was fine (except for jetty:run).

Emond

On woensdag 12 september 2018 12:19:38 CEST Andrea Del Bene wrote:
> It's an issue with maven-jetty-plugin:
> https://stackoverflow.com/questions/44848409/cdi-invalid-bean-archive-scanni
> ng-in-jetty-not-in-tomcat. It should affect 8.0.0 as well, I will check it.
> IMHO is not a blocking issue.
> 
> On Wed, Sep 12, 2018 at 10:20 AM Emond Papegaaij
> 
> wrote:
> > Hi,
> > 
> > I'm trying to test the examples, but all I get is '503 Service
> > Unavailable'
> > and several stacktraces in the terminal:
> > 
> > java.lang.IllegalStateException: WELD-ENV-33: Invalid bean archive
> > scanning result - found multiple results with the same reference: /home/
> > papegaaij/tmp/apache-wicket-8.1.0/wicket-examples/target/classes
> > 
> > at
> > 
> > org.jboss.weld.environment.deployment.discovery.AbstractDiscoveryStrategy.
> > performDiscovery
> > 
> > (AbstractDiscoveryStrategy.java:96)
> > 
> > at
> > 
> > org.jboss.weld.environment.servlet.WeldServletLifecycle.createDeployment
> > (WeldServletLifecycle.java:311)
> > 
> > at org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize
> > 
> > (WeldServletLifecycle.java:163)
> > 
> > at org.jboss.weld.environment.servlet.EnhancedListener.onStartup
> > 
> > (EnhancedListener.java:61)
> > 
> > at org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup
> > 
> > (ContainerInitializer.java:140)
> > 
> > at
> > 
> > org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart
> > (ServletContainerInitializersStarter.java:64)
> > 
> > at org.eclipse.jetty.util.component.AbstractLifeCycle.start
> > 
> > (AbstractLifeCycle.java:68)
> > 
> > at org.eclipse.jetty.servlet.ServletContextHandler.startContext
> > 
> > (ServletContextHandler.java:355)
> > 
> > at org.eclipse.jetty.webapp.WebAppContext.startWebapp
> > 
> > (WebAppContext.java:
> > 1497)
> > 
> > at org.eclipse.jetty.maven.plugin.JettyWebAppContext.startWebapp
> > 
> > (JettyWebAppContext.java:360)
> > 
> > at org.eclipse.jetty.webapp.WebAppContext.startContext
> > 
> > (WebAppContext.java:1459)
> > 
> > at org.eclipse.jetty.server.handler.ContextHandler.doStart
> > 
> > (ContextHandler.java:847)
> > 
> > at org.eclipse.jetty.servlet.ServletContextHandler.doStart
> > 
> > (ServletContextHandler.java:287)
> > 
> > at org.eclipse.jetty.webapp.WebAppContext.doStart
> > 
> > (WebAppContext.java:545)
> > 
> > at org.eclipse.jetty.maven.plugin.JettyWebAppContext.doStart
> > 
> > (JettyWebAppContext.java:428)
> > 
> > at org.eclipse.jetty.util.component.AbstractLifeCycle.start
> > 
> > (AbstractLifeCycle.java:68)
> > 
> > at org.eclipse.jetty.util.component.ContainerLifeCycle.start
> > 
> > (ContainerLifeCycle.java:138)
> > 
> > at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart
> > 
> > (ContainerLifeCycle.java:117)
> > 
> > at org.eclipse.jetty.server.handler.AbstractHandler.doStart
> > 
> > (AbstractHandler.java:113)
> > 
> > at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart
> > 
> > (ContextHandlerCollection.java:168)
> > 
> > at org.eclipse.jetty.util.component.AbstractLifeCycle.start
> > 
> > (AbstractLifeCycle.java:68)
> > 
> > at org.eclipse.jetty.util.component.ContainerLifeCycle.start
> > 
> > (ContainerLifeCycle.java:138)
> > 
> > at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart
> > 
> > (ContainerLifeCycle.java:117)
> > 
> > at org.eclipse.jetty.server.handler.AbstractHandler.doStart
> > 
> > (AbstractHandler.java:113)
> > 
> > at org.eclipse.jetty.util.component.AbstractLifeCycle.start
> > 
> > (AbstractLifeCycle.java:68)
> > 
> > at org.eclipse.jetty.util.component.ContainerLifeCycle.start
> > 
> > (ContainerLifeCycle.java:138)
> > 
> > at org.eclipse.jetty.server.Server.start (Server.java:416)
> > at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart
> > 
> > (ContainerLifeCycle.java:108)
> > 
> > at org.eclipse.jetty.server.handler.AbstractHandler.do

Re: [VOTE] Release Apache Wicket 8.1.0

[Emond Papegaaij]

Hi,

I'm trying to test the examples, but all I get is '503 Service Unavailable' 
and several stacktraces in the terminal:

java.lang.IllegalStateException: WELD-ENV-33: Invalid bean archive 
scanning result - found multiple results with the same reference: /home/
papegaaij/tmp/apache-wicket-8.1.0/wicket-examples/target/classes
at 
org.jboss.weld.environment.deployment.discovery.AbstractDiscoveryStrategy.performDiscovery
 
(AbstractDiscoveryStrategy.java:96)
at 
org.jboss.weld.environment.servlet.WeldServletLifecycle.createDeployment 
(WeldServletLifecycle.java:311)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize 
(WeldServletLifecycle.java:163)
at org.jboss.weld.environment.servlet.EnhancedListener.onStartup 
(EnhancedListener.java:61)
at org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup 
(ContainerInitializer.java:140)
at 
org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart 
(ServletContainerInitializersStarter.java:64)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start 
(AbstractLifeCycle.java:68)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext 
(ServletContextHandler.java:355)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp (WebAppContext.java:
1497)
at org.eclipse.jetty.maven.plugin.JettyWebAppContext.startWebapp 
(JettyWebAppContext.java:360)
at org.eclipse.jetty.webapp.WebAppContext.startContext 
(WebAppContext.java:1459)
at org.eclipse.jetty.server.handler.ContextHandler.doStart 
(ContextHandler.java:847)
at org.eclipse.jetty.servlet.ServletContextHandler.doStart 
(ServletContextHandler.java:287)
at org.eclipse.jetty.webapp.WebAppContext.doStart (WebAppContext.java:545)
at org.eclipse.jetty.maven.plugin.JettyWebAppContext.doStart 
(JettyWebAppContext.java:428)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start 
(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start 
(ContainerLifeCycle.java:138)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart 
(ContainerLifeCycle.java:117)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart 
(AbstractHandler.java:113)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart 
(ContextHandlerCollection.java:168)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start 
(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start 
(ContainerLifeCycle.java:138)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart 
(ContainerLifeCycle.java:117)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart 
(AbstractHandler.java:113)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start 
(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start 
(ContainerLifeCycle.java:138)
at org.eclipse.jetty.server.Server.start (Server.java:416)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart 
(ContainerLifeCycle.java:108)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart 
(AbstractHandler.java:113)
at org.eclipse.jetty.server.Server.doStart (Server.java:383)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start 
(AbstractLifeCycle.java:68)
at org.eclipse.jetty.maven.plugin.AbstractJettyMojo.startJetty 
(AbstractJettyMojo.java:477)
at org.eclipse.jetty.maven.plugin.AbstractJettyMojo.execute 
(AbstractJettyMojo.java:343)
at org.eclipse.jetty.maven.plugin.JettyRunMojo.execute (JettyRunMojo.java:
169)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 
(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at 

Re: [GitHub] wicket pull request #283: Wicket-6563 page store implementation

[Emond Papegaaij]

On maandag 9 juli 2018 21:21:42 CEST Sven Meier wrote:
> Hi Emond,
> 
> many thanks for your first feedback.
> 
>  > this is an enormous amount of code to review so this will take some time
> 
> Actually its mostly the old code squeezed into new classes. But we can
> take all the time we want to work on it.

Well, you did lose over 1100 lines of code somewhere. I guess it was all trash 
:)
 
>  > I would recommend changing the code to using AES/CBC/PKCS5Padding with
> 
> Sure, my first try was just using what popped up first in a Google
> search :P.
> It was just a nice opportunity to show how the new store chain is
> capable of adding encryption without much hassle.
> 
> I've changed the crypt implementation now, I hope it performs better
> that way.

This new implementation is much better. However, I would keep the SecureRandom 
out of the user session. Constructing a SecureRandom is very expensive wrt 
system entropy. Constructing one for every session will deplete your system 
entropy in minutes on systems with heavy traffic. I would change the ICrypter 
interface to take the SecureRandom as parameter to encrypt and add a init 
method (which takes SecureRandom as well) to generate the key. That way you 
can store the SecureRandom in CryptingPageStore.

Btw, this will also close WICKET-6559

Emond

Re: [GitHub] wicket pull request #283: Wicket-6563 page store implementation

[Emond Papegaaij]

Hi Sven,

Thanks for the work you have put into this. However, this is an enormous 
amount of code to review so this will take some time. I'll try to get this 
done this week, but I can't promise anything.

For now, I can at least comment on CryptingPageStore.java. The ciphers used by 
this store are both obsolete and not applicable to this use case. It currently 
uses a Password Based Encryption (PBE) and a very insecure one (single DES). I 
would recommend changing the code to using AES/CBC/PKCS5Padding with a 
generated key:

SecureRandom rnd = SecureRandom.getInstance("SHA1PRNG", "SUN");
KeyGenerator keyGen = KeyGenerator.getInstance("AES");
keyGen.init(256, rnd);
SecretKey key = keyGen.generateKey();

This key is serializable and can be stored in the session directly. Make sure 
that rnd is a SecureRandom with a strong algorithm, and very importantly: it 
must be reused. Due to application specific demands on this SecureRandom (such 
as automatic reseeding), I think users must be able to provide their own. To 
encrypt a page, use:

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, key, rnd);
AlgorithmParameters params = cipher.getParameters();
byte[] iv = params.getParameterSpec(IvParameterSpec.class).getIV();
byte[] ciphertext = cipher.doFinal(plainpagebytes);
byte[] result = Bytes.concat(iv, ciphertext);

Use the same SecureRandom for the cipher.init. This will be used to generate 
the IV.  To decrypt the page, use:

byte[] iv = new byte[16];
byte[] ciphertext = new byte[cipherInput.length - 16];
System.arraycopy(cipherInput, 0, iv, 0, iv.length);
System.arraycopy(cipherInput, 16, ciphertext, 0, ciphertext.length);

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.DECRYPT_MODE, key, new IvParameterSpec(iv));
byte[] plainpagebytes = cipher.doFinal(ciphertext);

This should give a much stronger and faster algorithm than using 
PBEWithMD5AndDES.

Best regards,
Emond

On maandag 9 juli 2018 16:45:43 CEST svenmeier wrote:
> GitHub user svenmeier opened a pull request:
> 
> https://github.com/apache/wicket/pull/283
> 
> Wicket-6563 page store implementation
> 
> Basically I propose to
> *unify IPageStore with IDateStore
> *allow all IPageStore implementations to use Request/Session data (see
> DiskPageStore, GroupingPageStore and CryptingPageStore) as needed *cut down
> PageStoreManager to a very simple manager with a chain of stores, each
> offering different solutions.
> 
> I appreciate your feedback.
> 
> You can merge this pull request into a Git repository by running:
> 
> $ git pull https://github.com/apache/wicket WICKET-6563
> 
> Alternatively you can review and apply these changes as the patch at:
> 
> https://github.com/apache/wicket/pull/283.patch
> 
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
> 
> This closes #283
> 
> 
> commit bcf76f517310ac5d27a2092595c3a925c3973067
> Author: Sven Meier 
> Date:   2018-06-25T15:19:41Z
> 
> WICKET-6563 new IPageStore implementation
> 
> commit a3604f7c359f9bbd2df03d57831c3f0d838ef521
> Author: Sven Meier 
> Date:   2018-07-03T18:18:10Z
> 
> WICKET-6563 allow passing of SerializedPage
> 
> between page stores
> 
> commit ad1f9b88ce8412e2b8eec5de72073b9688deb3bb
> Author: Sven Meier 
> Date:   2018-07-03T21:52:10Z
> 
> WICKET-6563 javadoc and test
> 
> for SerializingPageStore; keep page type in serializedpage
> 
> commit 2f70db06d3aa7f1ee07c96e1287507fe0021f18e
> Author: Sven Meier 
> Date:   2018-07-05T18:09:49Z
> 
> WICKET-6563 crypt page store
> 
> commit 7e9c7e5166fda6692163c9551dc56d3177acfe6d
> Author: Sven Meier 
> Date:   2018-07-07T18:37:54Z
> 
> WICKET-6563 IPageContext set synchronization
> 
> prevent multiple threads from settings data into IPageContext
> concurrently
> 
> commit fd7b26bac6f72d5ebc647f490263c41f169faec1
> Author: Sven Meier 
> Date:   2018-07-09T08:54:57Z
> 
> WICKET-6563 improved test
> 
> 
> 
> 
> ---

Re: buildbot failure in on wicket-master

[Emond Papegaaij]

This error still persists and I have no idea why. Locally the build is fine.

I've removed some more references to the old datetime module, including the 
NOTICE about the bsd license. The userguide still mentions the tomcat and 
jetty9 modules for native-websockets. I think that part should be removed, 
right? AFAIK we now only support SSR356 compliant containers.

Best regards,
Emond

On vrijdag 18 mei 2018 13:35:42 CEST Emond Papegaaij wrote:
> I highly doubt my commit caused this failure:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin: 3.6.2:compile
> (default-compile) on project wicket-util: Fatal error compiling: Error
> creating file with javac arguments: No such file or directory -> [Help 1]
> 
> Emond
> 
> On vrijdag 18 mei 2018 13:23:31 CEST build...@apache.org wrote:
> > The Buildbot has detected a new failure on builder wicket-master while
> > building wicket. Full details are available at:
> > https://ci.apache.org/builders/wicket-master/builds/933
> > 
> > Buildbot URL: https://ci.apache.org/
> > 
> > Buildslave for this Build: bb_slave1_ubuntu
> > 
> > Build Reason: The SingleBranchScheduler scheduler named
> > 'on-wicket-master-commit' triggered this build Build Source Stamp: [branch
> > master] 024153133f79ef0bdd4ddbf0605c092fc9977e44 Blamelist: Emond
> > Papegaaij
> > <emond.papega...@topicus.nl>
> > 
> > BUILD FAILED: failed compile
> > 
> > Sincerely,
> > 
> >  -The Buildbot

Re: [VOTE] Release Apache Wicket 8.0.0

[Emond Papegaaij]

+1

Tested our application with the complete test suite
Checked signatures and hashes

I did notice some misplaced managed dependencies in the root pom for projects 
that no longer exist, but that should not stop the release.

Best regards,
Emond

On donderdag 17 mei 2018 22:30:20 CEST Pedro Santos wrote:
> +1
> 
> cheers
> 
> Pedro Santos
> 
> On Thu, May 17, 2018 at 4:33 PM, Andrea Del Bene 
> 
> wrote:
> > +1 tested my main app
> > 
> > On Thu, May 17, 2018, 4:46 AM Maxim Solodovnik 
> > 
> > wrote:
> > > +1
> > > 
> > > Tested
> > > 1) signatures
> > > 2) build from sources
> > > 3) our main application
> > > 
> > > On Thu, May 17, 2018 at 3:39 AM, Tobias Soloschenko <
> > > 
> > > tobiassolosche...@googlemail.com> wrote:
> > > > +1
> > > > 
> > > > kind regards
> > > > 
> > > > Tobias
> > > > 
> > > > > Am 16.05.2018 um 22:01 schrieb Andrea Del Bene  > > > > 
> > > > > 
> > > > > This is a vote to release Apache Wicket 8.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 8.0.0
> > > > > [ ] No, don't release Apache Wicket 8.0.0, because ...
> > > > > 
> > > > > Distributions, changelog, keys and signatures can be found at:
> > > > > https://dist.apache.org/repos/dist/dev/wicket/8.0.0
> > > > > 
> > > > > Staging repository:
> > > https://repository.apache.org/content/repositories/orgapachewicket-1110
> > > 
> > > > > 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.0.0
> > > > > Release tag: rel/wicket-8.0.0
> > > 
> > > 
> > > 
> > > > > The signatures for the source release artefacts:
> > > > > Signature for apache-wicket-8.0.0.zip:
> > > > > -BEGIN PGP SIGNATURE-
> > > > > 
> > > > > iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAlr8jGsACgkQh48B+qjT
> > > > > VuHk1xAAnJ2iPogwXIc1ieWjPatVvWGB258zYmrOtuhgwil5ThWF/Fx3PrNfhUVQ
> > > > > l1oiFSvRftuJm7YKIKZyg2sMQjosVx1o8ELOHxyvZWlyycycfjdggQCkEGIdP3Ot
> > > > > oNHu2aIqbO1fwFPiXzQUPP5cYYw7/5AXcBYOanasjYbtPDtmcrQlKo6NJZOyxjF+
> > > > > Oi2/J+yC0RGa0NaYGsrWvi0ZgYNbyA2XinnpWm0FOiyCtNv86/tWPUoJUNnx2t2k
> > > > > nEwgrcmpJAer3o85xFhO/KXG/Ibd9Fa62GcFi9H13lD/A4XoZ169xVaeujMTSCVR
> > > > > JIcCFmUuibnCd75MLqoWHwu8cGkxMQ5xgBvgp2AUAflki/iv2Uw4enF0+GV/1mCq
> > > > > Age/HHiTtBif7vGQ6yHCak7woLnCucMgVHulT3HIXgLbDu5PIpVGbJtJvB0PgOiM
> > > > > vOthGtisMrwQujj3m432ONG0aAAHEWvfmIdyXVZhRa3vwQ8JxwM6HeNYdpsbVezW
> > > > > gTinuMktBnmZzJeTEqXYxnC5AOfARAsx/GY45aSaSLZobloau2b+CpaHP3MVkDr6
> > > > > 44BjpoCffpDF90iFh6UEfwF3zGR8CkWLWxU4LHaQDXqWQ5dLCoQ/Dj7sJYE5ylgm
> > > > > QujE4mkLFcFPRO+wsKK503lfYOjz0Ud9wf43Q2m/DNiRqkbEeMM=
> > > > > =b1+3
> > > > > -END PGP SIGNATURE-
> > > > > 
> > > > > Signature for apache-wicket-8.0.0.tar.gz:
> > > > > -BEGIN PGP SIGNATURE-
> > > > > 
> > > > > iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAlr8jGsACgkQh48B+qjT
> > > > > VuHbxQ//UpfnaQUxkEUzUp04lZ7nMrh/RblfvhQOHRD+EXo/2CgbyMXSkzZV6oLd
> > > > > APF6QTEoSJnxvuH7x1wlTUeleJ3VQw3+3pPh/6AcsoQ9KnN///rGtIL8YDDrP6FD
> > > > > L5MPw8l9g2z73dioVv/OCRJD1Q6DjG/uiB0yYD+BpAWAvsZX5L22tBKl0Bsho3IV
> > > > > nc/xPI91NPXkv0Jouxfa6VMbjvCNBYRFoYQP2OSmoVOmyflRAeINysSmdQoyaLXD
> > > > > Q22CTRQCxmANb/5r3jN7cmCQIOMTDMQqmgvJKqbOYwgi0SPPYBCRBy07394uWXNu
> > > > > 3yo6yPu0dtdLH33pbk7yBpS6aY3JAs9RuHuJ++a5N10veEqbhh0sNHy7tlRkGhWa
> > > > > sHNSY0ez3wqnL2rYEI6FALWGGyXEAgYr1yqkZiLLxm1YLW08PQO46Zv5ybf5vtky
> > > > > MLYK+zYNKK8MQiMWsU6QjmVrWNl1/upfAyJSCLskFMpZ5hPwBn+3jXc0kFjT26MB
> > > > > WCcbaJhDWgo0XMIyZPO54ELeKzz4FTuwQtViIkLUC4KLX4Abxza5DPAS2KPOBviY
> > > > > FBm/LdFTte1WN/YU0qKwEvYuRqt7mEXyUbQuVT27R6kRfWoXF/dTJCrjbLv5g8ze
> > > > > cqwRxMPaZgKMSKpBlOnwWS5l6q1jN8FSFLdunm9Hdnn06aQbrdI=
> > > > > =OAcW
> > > > > -END PGP SIGNATURE-
> > > 
> > > 
> > > 
> > > > > CHANGELOG for 8.0.0:
> > > > > ** Bug
> > > > > 
> > > > > * [WICKET-6473] - Double slash break 404page
> > > > > * [WICKET-6525] - SubmitLink.onSubmit not invoked when using
> > > > 
> > > > GET-method
> > > > 
> > > > > * [WICKET-6528] - Component part of Page check in
> > > 
> > > AjaxRequestHandler
> > > 
> > > > breaks applications
> > > > 
> > > > > * [WICKET-6533] - Error while parsing xml using AjaxButton
> > > > > * 

Re: [DISCUSSION] Wicket 8 Release

[Emond Papegaaij]

I think the issue is related to the very old version of cdi-unit and weld that 
are being used. cdi-1.1 is the current implementation. If we want to drop one, 
wich should drop the wicket-cdi artifact (which is for cdi-1.0). In any case, 
we can upgrade to cdi-1.2 I guess, but we should also upgrade cdi-unit and 
weld-se-core. Unfortunately I don't have the time to do that at the moment.

Emond

On maandag 16 april 2018 11:40:08 CEST Andrea Del Bene wrote:
> It's not an answer to your question, but I've create a sort of
> "proof-of-concept" for Wicket 9 (branch wicket9 of Apache repo). I've
> successfully built a 9.0.0-SNAPSHOT version axing module wicket-cdi-1.1
> which had the same cast exception reported here for Spring:
> https://github.com/spring-projects/spring-boot/issues/7565. I've also
> removed testing/wicket-arquillian as it depends on jconsole.jar which
> seems to be not part anymore of the jdk (but i might be wrong).
> 
> PS: In any case, I don't even know if cdi-1.1 ca be used with Java > 8
> 
> Andrea.
> 
> On 16/04/2018 10:37, Martijn Dashorst wrote:
> > On Sun, Apr 15, 2018 at 12:25 PM, Andrea Del Bene  
wrote:
> >> I've also tried to build master branch with Java 9 and I've found the
> >> following issues:
> >> 
> >> wicket-util: it seems that java 9 has changed date formats to be closer
> >> to
> >> the Unicode standard: https://www.infoq.com/news/2017/02/java9-cldr-ldml.
> >> This breaks some unit tests
> >> wicket-extentions: import  javax.annotation.Resource is not used and not
> >> available in the new jdk
> >> wicket-cdi-1.1: there are some cast exceptions during tests execution. At
> >> the moment I can't be more specific.
> >> 
> >> I've created a branch for Wicket with java 9 here:
> >> https://github.com/bitstorm/wicket/tree/wicket9. I've solved the issues
> >> for
> >> wicket-util and wicket-extentions
> > 
> > How can we make it such that Wicket 8 builds on all Java 8-10?
> > 
> > Martijn

Re: [DISCUSSION] Wicket 8 Release

[Emond Papegaaij]

On dinsdag 10 april 2018 14:22:21 CEST Martijn Dashorst wrote:
> On Tue, Apr 10, 2018 at 2:09 PM, Maxim Solodovnik  
wrote:
> > Current version is Java 10 (non LTS)
> > Maybe we can release 8.0.0 and add this to Wicket 9 ?
> 
> The issue is that you can't upgrade to Java 11 when you are running
> CGLIB due to its use of sun.misc.Unsafe.
> 
> This will cause problems. I'd rather ensure we have a good path
> forward, and Java 11 is in september. We can't break API in 8.x so we
> are stuck with CGLIB apis we expose.

We can still keep the CGLIB API and add a Byte Buddy variant. This would not 
break compatibility for everyone running on 8.x. For users running on 11.x it 
would break at runtime, but that will happen anyway.

IMHO this is not a blocker for a 8.0.0 release, but it should be fixed soon. 
Also note that this will also break 6.x and 7.x, so we will need the same fix 
for those versions.

Best regards,
Emond

Re: [jira] [Updated] (WICKET-6530) Race-condition in session invalidation

[Emond Papegaaij]

Great! My mail client is having trouble keeping up with all the mai :)

On dinsdag 6 februari 2018 13:55:49 CET Martin Grigorov wrote:
> Yes, I also noticed.
> Fixed!
> 
> Martin Grigorov
> Wicket Training and Consulting
> Looking for a remote position with Wicket ? Contact me!
> https://twitter.com/mtgrigorov
> 
> 
> On Tue, Feb 6, 2018 at 1:52 PM, Emond Papegaaij <emond.papega...@topicus.nl>
> wrote:
> > On dinsdag 6 februari 2018 13:49:03 CET Martin Grigorov (JIRA) wrote:
> > > Martin Grigorov updated WICKET-6530:
> > > 
> > > 
> > > Fix Version/s: (was: 6.29.0)
> > > 
> > >(was: 7.10.0)
> > >(was: 8.0.0)
> > >
> > >8.0.0-M9
> > 
> > Your bulk update removed all additional versions on this issue and some
> > others.
> > 
> > Best regards,
> > Emond

Re: [jira] [Updated] (WICKET-6530) Race-condition in session invalidation

[Emond Papegaaij]

On dinsdag 6 februari 2018 13:49:03 CET Martin Grigorov (JIRA) wrote:
> Martin Grigorov updated WICKET-6530:
> 
> Fix Version/s: (was: 6.29.0)
>(was: 7.10.0)
>(was: 8.0.0)
>8.0.0-M9

Your bulk update removed all additional versions on this issue and some 
others.

Best regards,
Emond

Re: Quick start and https/TLS/SSL

[Emond Papegaaij]

-1

I agree, application servers, such as WildFly provide similar solutions. By 
default WildFly will generate a self-signed certificate for the https/h2 
listener.

Emond

On dinsdag 16 januari 2018 05:10:32 CET Maxim Solodovnik wrote:
> -1
> 
> I believe it's good to have HTTPS configuration ready for the tests.
> It is impossible to provide non-self-signed, so IMO security warning
> is OK here
> 
> On Mon, Jan 15, 2018 at 3:42 AM, Martin Grigorov  
wrote:
> > -1
> > 
> > The current setup makes it easier to debug HTTPS related issues.
> > I, personally, do not want to deal with openssl, keytool and
> > jetty-https.xml just to debug an issue in HttpsMapper or related code.
> > 
> > A user can use http://localhost if (s)he doesn't want to accept self
> > signed
> > certs.
> > 
> > My 2c.
> > 
> > On Sun, Jan 14, 2018 at 8:16 PM, Martijn Dashorst <
> > 
> > martijn.dasho...@gmail.com> wrote:
> >> The quick start uses a self signed certificate that gives errors in
> >> browsers and requires folks to accept the certificate in their trust
> >> chain.
> >> 
> >> I suggest we remove the secure layer part from our quickstart just to
> >> make sure we don't train our users to accept any certificate. WDYT?
> >> 
> >> Martijn

Re: buildbot failure in on wicket-branch-7.x

[Emond Papegaaij]

I'm pretty sure that I did not cause this error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:
2.10.4:aggregate (default-cli) on project wicket-parent: An error has occurred 
in JavaDocs report generation: 
[ERROR] Java HotSpot(TM) 64-Bit Server VM warning: INFO: 
os::commit_memory(0xf558, 58720256, 0) failed; error='Cannot 
allocate memory' (errno=12)
[ERROR] #
[ERROR] # There is insufficient memory for the Java Runtime Environment to 
continue.
[ERROR] # Native memory allocation (malloc) failed to allocate 58720256 bytes 
for committing reserved memory.
[ERROR] # An error report file with more information is saved as:
[ERROR] # /home/buildslave/slave/wicket-branch-7.x/build/target/site/apidocs/
hs_err_pid6527.log

On dinsdag 19 december 2017 14:41:10 CET build...@apache.org wrote:
> The Buildbot has detected a new failure on builder wicket-branch-7.x while
> building wicket. Full details are available at:
> https://ci.apache.org/builders/wicket-branch-7.x/builds/461
> 
> Buildbot URL: https://ci.apache.org/
> 
> Buildslave for this Build: bb_slave1_ubuntu
> 
> Build Reason: The SingleBranchScheduler scheduler named
> 'on-wicket-branch-7.x-commit' triggered this build Build Source Stamp:
> [branch wicket-7.x] a352fe2befbbf6ce60c1d9617df34f54fa7190ac Blamelist:
> Emond Papegaaij <papega...@apache.org>
> 
> BUILD FAILED: failed compile
> 
> Sincerely,
>  -The Buildbot

Re: File upload "too large" error managing

[Emond Papegaaij]

Hi,

I've seen the error you describe before. It happened to me when a file-
submitting ajax call fails when using a Content-Security-Policy. The problem 
is that an error is returned to the browser (in my case Chrome), which renders 
an error page inside the iframe used to submit files via ajax. This error page 
is not from the same origin as your application (localhost:9080), therefore 
access is blocked for wicket-ajax. It took me a while to figure this out and I 
suspect something similar is happening to you.

Best regards,
Emond

On vrijdag 29 september 2017 07:48:44 CEST Andrea Patricelli wrote:
> Hi Sven,
> 
> Yes I confirm that the size taken into consideration is the form's one.
> In fact I'm using tomcat as container with default max file size set to 52
> MB, ⁣while my form max size is only 4 MB.
> And I get that error uploading a 16 MB file (for example).
> 
> Best regards,
> Andrea
> 
> Il giorno 28 set 2017, 23:42, alle ore 23:42, Sven Meier  
ha scritto:
> >Hi,
> >
> >I can reproduce your finding with Chrome and Jetty:
> >
> >Jetty has a default form submit limit of 20 bytes which is hit
> >before your limit is even taken into consideration. wicket-ajax seems
> >not to be able to get hold on the response.
> >
> >If I use Firefox instead of Chrome, wicket-ajax's
> >handleMultipartComplete() is never called at all :/.
> >
> >What's your container's upload limit? Can you confirm that you get a
> >correct error message, when you upload a file bigger than your form's
> >max size, but smaller than your containers limit?
> >
> >Regards
> >Sven
> >
> >Am 28.09.2017 um 15:10 schrieb Andrea Patricelli:
> >> Hi all,
> >> 
> >> I've a Multipart form defined in this way:
> >> 
> >> Form uploadForm = new StatelessForm<>("uploadForm");
> >> uploadForm.setMultiPart(true);
> >> uploadForm.setMaxSize(Bytes.megabytes(4));
> >> 
> >> Like you can see I defined a maximum file size to avoid upload of too
> >> 
> >> large files.
> >> 
> >> My problem is:
> >> 
> >> When I upload a *too large* file nothing happens, there are no Java
> >> exceptions and all seems ok, while, instead on JavaScript console I
> >
> >get:
> >> Wicket.Ajax:  Cannot read Ajax response for multipart form submit:
> >> SecurityError: Blocked a frame with origin "http://localhost:9080;
> >> from accessing a cross-origin frame.
> >> 
> >> ...
> >> 
> >> wicket-ajax-jquery-debug-ver-1506594798000.js:1 Wicket.Ajax:
> >> Wicket.Ajax.Call.failure: Error while parsing response: No XML
> >> response in the IFrame document
> >> 
> >> Is there a way to have the evidence of this failure in Java code? In
> >> order to show a feedback panel when file is too large?
> >> 
> >> Best regards,
> >> Andrea

Re: [VOTE] Release Apache Wicket 7.8.1 take 2

[Emond Papegaaij]

I've checked the source and noticed wicket/testing/wicket-arquillian/pom.xml 
has version 7.8.0. What do we want to do with that? We've released artifacts 
with version 7.0.0, 7.1.0, 7.2.0, 7.7.0, 7.8.0 and 8.0.0 for this module. It 
seems the version has been off before. The binary tar.gz does not contain this 
module.

I did not see anything else wrong in the diff, so I'm +1 to continue the 
release without this artifact.

Emond

On dinsdag 5 september 2017 22:17:47 CEST Andrea Del Bene wrote:
> This is a vote to release Apache Wicket 7.8.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 7.8.1
> [ ] No, don't release Apache Wicket 7.8.1, because ...
> 
> Distributions, changelog, keys and signatures can be found at:
> 
>  https://dist.apache.org/repos/dist/dev/wicket/7.8.1
> 
> Staging repository:
> 
>  https://repository.apache.org/content/repositories/orgapachewicket-1100
> 
> 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-7.8.1
>  Release tag: rel/wicket-7.8.1
> 
> 
> 
> 
>  The signatures for the source release artefacts:
> 
> 
> Signature for apache-wicket-7.8.1.zip:
> 
>  -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQIcBAABAgAGBQJZrwPJAAoJEAzCjx+CMhBVibwQAIzHKnHWsIaKG9xHS1DzvtL5
> quCvZALeEn/wYQ0xoqXkd9L2hZyMyMzbSX5TUZvYC1ZpLDQJLFuhLg4Lgs76iv79
> XKgRTGLkepjTqwlqp89xFkuDNy/ezzEHei5VoTIMgxYx+CnbF9T/Dc+ZVrg9zScj
> AlK9AYEF6+WKdH8Hf9vP8LNmLoJ5pwbiICF6wkDV5Yikl3d6dMK3nsvCUzyv2qFp
> TEqu8xocTokApFiHRXhIZ6Jnov+z1O3O3kbptt52T39oVYl8IPLPMHHYpMvfqOO3
> 2cMelm2qCg0foQLRvH9N2ViTdb9B2TAaGmqckRGXziwG2Sa3qQJfxw30YieXGr/u
> /FydqxMu/QfMc9w7DhRwyK/0ShoYOaslvJIpCks/Fcs81cVU8Vy8+aXxL+6vVyxO
> IkRlD4F1uwlAw3WXszBGDsOQSSMiwcP5za5BpzA6pSwm9NLerJpDs/XdAUgsaKfH
> IA/3iHCqvPhOj+qTx6l9UKY1MK2uSgrIHTnmfCqUvsWrPKEJOCe+tzIJq1F0FtoJ
> kBOagJUpywx0XMfJJbzgfsp+j8eaJhOzv6hBVsgcchZhjARtl407Q5gKVMwP3vTT
> LHkSCwUwVFyHW+3gXAJJQJihCTvLN8jlL1qrl9+JOCtVl6wnkFsCSb+if8MAaJEf
> gE1AAJeFPnXO6wzqhFSG
> =oi5Z
> -END PGP SIGNATURE-
> 
> Signature for apache-wicket-7.8.1.tar.gz:
> 
>  -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQIcBAABAgAGBQJZrwPJAAoJEAzCjx+CMhBVr8QQAJGq6TWnRE+/5LIpMxbGi42S
> 2WGJF+1CaEmOAyaqVjhoOvHsbWCSx5IGR8vN6UUrWQPXbb0Nn6mulDSKL+YIhrmm
> pvi2wS5pn/wmP9w7n4PaUAxFF8Htgky9wzjeX/SHrePWrSZPTCDV57m5fVGBckve
> zM3ZWPuwZJ2wddMkoDWbTPZj08AMl3h+503leuVy7V50OoWNjYs+t09uiult2qTe
> 5mBqIDEKJBZoNYRXC0vkyYxsTAbWy9a1RqcaEcf1pprNMvLX1iwmPdTvKfnoVs4V
> gBrWuNw2tr65qs2ZkC+VfosFe5hoGqV/DVKRjDcA2SXf23P43b1BqU82JKJw/nYC
> YfSRSP4IFpuLMl0libknx5VV0sSv6/xTjju2/1BoInho16IhW8MK/vR12Xef4CSy
> 3l8tBAB5X+3zOKcQoruA9DY50Fatt49knH867fvNqa35P/AYDSDneSGf7ejYje0x
> ggcKEBa8O4JEHpSQuQfM+PdYoTetM2Kq6zCGjDUJjU8ViS14Nfoy9RU194c/EXmO
> K3zrdSPdNnzJbVFP+2D1SsQQ0vaJfOiVkVroC1pCpxAZJvXawjIO3FYWM+zzE1Mb
> S3Ey2GHhmovALGg5i7UR6/3OCz84wKRTMwxKgHwX4fFOtW/eh7q/M+lU130YqHe3
> t1PPdPAfi4Wd2UxzCizo
> =lEbE
> -END PGP SIGNATURE-
> 
> 
> 
>  CHANGELOG for 7.8.1:
> 
> 
> ** Bug
> 
>  * [WICKET-6457] - PageStore not cleared at session end
> 
> Release Notes - Wicket - Version 7.8.0
> 
> ** Bug
> 
>  * [WICKET-4324] - [wicket-ioc] LazyInitProxyFactory CGLIB proxies
> naming strategy may cause java.lang.IllegalAccessError
>  * [WICKET-6362] - HeaderItems with different PageParameters are
> treated as identical
>  * [WICKET-6366] - Autocomplete race condition makes page unresponsive
>  * [WICKET-6373] - Edge not recognized in UserAgent
>  * [WICKET-6374] - Exception caused by border extending another
> border with 
>  * [WICKET-6376] - Ajax redirects to non http(s)-urls are
> interpreted as relative
>  * [WICKET-6377] - Autolinking breaks hierarchy for nested elements
>  * [WICKET-6386] - Simplification of the code in WICKET-3347 is not
> consistent with previous behavior
>  * [WICKET-6387] - ModalWindow PageReference broken
>  * [WICKET-6393] - NestedStringResourceLoader ignores hard-coded
> default values and throws MissingResourceException
>  * [WICKET-6398] - WICKET-6204 breaks jQuery.noConflict()
>  * [WICKET-6399] - Dequeuing of Border component with nested body fails
>  * [WICKET-6400] - Object with array property fails on NPE when
> construction JSON object
> 
> ** Improvement
> 
>  * [WICKET-6372] - Consider to switch to a sans-serif typeface in
> the Wicket guide
>  * [WICKET-6385] - Allow using 

Re: [VOTE] Release Apache Wicket 7.8.1

[Emond Papegaaij]

Yes, I think that's better than trying to rush a fix for the form submit. The 
issue with the page store is quite severe and needs a fix.

Best regards,
Emond

On dinsdag 5 september 2017 13:00:54 CEST Andrea Del Bene wrote:
> If it's ok I will rebuild a new 7.8.1 starting from the 7.8.0 tag and
> applying only the fix for the page store.
> 
> On Tue, Sep 5, 2017 at 11:45 AM, Andrea Del Bene <an.delb...@gmail.com>
> 
> wrote:
> > This vote fails due to a bug WICKET-6462 discovered by Francois Meillet
> > 
> > On Tue, Sep 5, 2017 at 11:44 AM, Andrea Del Bene <an.delb...@gmail.com>
> > 
> > wrote:
> >> @Martin
> >> 
> >> I agree!
> >> 
> >> On Mon, Sep 4, 2017 at 9:55 PM, Martin Grigorov <mgrigo...@apache.org>
> >> 
> >> wrote:
> >>> -1 to release
> >>> 
> >>> but before making a new release let's add Francois' app as a test case
> >>> to
> >>> prevent regressions.
> >>> 
> >>> Martin Grigorov
> >>> Wicket Training and Consulting
> >>> https://twitter.com/mtgrigorov
> >>> 
> >>> On Mon, Sep 4, 2017 at 10:39 PM, Tobias Soloschenko <
> >>> 
> >>> tobiassolosche...@googlemail.com> wrote:
> >>> > -1 also because of the Behavior bug.
> >>> > 
> >>> > Good catch @François!
> >>> > 
> >>> > kind regards
> >>> > 
> >>> > Tobias
> >>> > 
> >>> > > Am 04.09.2017 um 21:18 schrieb Andrea Del Bene <an.delb...@gmail.com
> >>> > > 
> >>> > > 
> >>> > > Sorry to bother you, but Francois Meillet has discovered a bug that
> >>> > 
> >>> > might be serious: WICKET-6462. In short, due to this bug
> >>> > AjaxFormSubmitBehavior#onSubmit is called twice if its target form is
> >>> > removed during ajax request. Shall stop this release?
> >>> > 
> >>> > > I'm +1 to stop it as this bug might be quite annoying for some
> >>> > > users.
> >>> > > 
> >>> > > Andrea.
> >>> > > 
> >>> > >> On 01/09/2017 16:35, Sven Meier wrote:
> >>> > >> +1
> >>> > >> 
> >>> > >> Built and poked some examples.
> >>> > >> 
> >>> > >> Sven
> >>> > >> 
> >>> > >>> Am 01.09.2017 um 13:06 schrieb Emond Papegaaij:
> >>> > >>> +1
> >>> > >>> 
> >>> > >>> Reviewed all code changed between 7.8.0 and 7.8.1
> >>> > >>> 
> >>> > >>> Emond
> >>> > >>> 
> >>> > >>>> On vrijdag 1 september 2017 11:37:22 CEST Martijn Dashorst wrote:
> >>> > >>>> +1
> >>> > >>>> 
> >>> > >>>> Martijn
> >>> > >>>> 
> >>> > >>>> 
> >>> > >>>> On Wed, Aug 30, 2017 at 9:34 PM, Andrea Del Bene <
> >>> > 
> >>> > an.delb...@gmail.com>
> >>> > 
> >>> > >>>> wrote:
> >>> > >>>>> This is a vote to release Apache Wicket 7.8.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 7.8.1
> >>> > >>>>> [ ] No, don't release Apache Wicket 7.8.1, because ...
> >>> > >>>>> 
> >>> > >>>>> Distributions, changelog, keys and signatures can be found at:
> >>> > >>>>> https://dist.apache.org/repos/dist/dev/wicket/7.8.1
> >>> > >>>>> 
> >>> > >>>>> Staging repository:
> >>> > >>

Re: [VOTE] Release Apache Wicket 7.8.1

[Emond Papegaaij]

+1

Reviewed all code changed between 7.8.0 and 7.8.1

Emond

On vrijdag 1 september 2017 11:37:22 CEST Martijn Dashorst wrote:
> +1
> 
> Martijn
> 
> 
> On Wed, Aug 30, 2017 at 9:34 PM, Andrea Del Bene 
> 
> wrote:
> > This is a vote to release Apache Wicket 7.8.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 7.8.1
> > [ ] No, don't release Apache Wicket 7.8.1, because ...
> > 
> > Distributions, changelog, keys and signatures can be found at:
> > https://dist.apache.org/repos/dist/dev/wicket/7.8.1
> > 
> > Staging repository:
> > 
> > https://repository.apache.org/content/repositories/orgapachewicket-1097/
> > 
> > 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-7.8.1
> > Release tag: rel/wicket-7.8.1
> > 
> > 
> > 
> > The signatures for the source release artefacts:
> > Signature for apache-wicket-7.8.1.zip:
> > -BEGIN PGP SIGNATURE-
> > 
> > Version: GnuPG v1
> > 
> > iQIcBAABAgAGBQJZpxHBAAoJEAzCjx+CMhBV3qIP/i9f/lsYqHRl/WzZDeIkTyK4
> > AfxN0wKjUlJsmIzRzeBjYIcmSzzZtfGlp0cVOpQQQ09sbCGWeRjeN+k9AAWBAupU
> > pDwyIbAOoIhfh3DbD7NQ16+JJoat2MykyQREYIR41unR5Kk9EIRhc5pQdpdyyfVj
> > hC0lje2pDQpT2MVSGnl9mKVz/wrES5TNkv4kuZTl1lGu6as40Jw9jCx1tTB8AQnq
> > nDWUu5RFvK8hlPK1FDBHavizUJROMNBer5DvvDM+4lqOQojKEv3gzYNM6sPKuseg
> > R3jF6ke8r7lDDXBdup/OQxPl60UWkH5SUXZ4co2eZhdbQuncxc0Pi++gXrUQvXzd
> > MEy8VIoY2Af9bYOKOLOaGrOhk5qbXsHs1xB1W5FVBHQGI7RTHjTz5QCFUSymBqqQ
> > WHvyiMY1sbhvr0eNgWCzINJzytC3IVTtExg4QReN1FHYN/SQXcJmzKXhHmN6nTC2
> > BV/v2fgYFTJ1V2IGyKgRAsNtdlKpIDFZjxFkCEPqBNSXaRSlVA/9UrFu10FPjf3g
> > 1PB8bVphZipdDtyQ5nkdJxvYKcYWunuW+rAl/Mz5kqJQFVzmA7VsSjh3NixeZumW
> > xTlg99Ipfls/RbOK/NuDNj7OalFOcdU+J9JEZNnP9Vv0ZtiewA/wlqBvW5abYiGT
> > Ap2H2oQ6OgbDK8EUkJsT
> > =5vmE
> > -END PGP SIGNATURE-
> > 
> > Signature for apache-wicket-7.8.1.tar.gz:
> > -BEGIN PGP SIGNATURE-
> > 
> > Version: GnuPG v1
> > 
> > iQIcBAABAgAGBQJZpxHBAAoJEAzCjx+CMhBV+VoQAING0/AVNbAAPdpgIMPofGOs
> > 2X6yXpGp2ozz/Bew3b+CjNZYKWoIQBcvdw3F3m/mlmPeyi9SCc2U0XQLH2d3OAIU
> > wWgn3pTnp+4ceirALeyNdBjlo84vvy2Q1lataDAhznXDNjYWTcKywmIORbL6znrp
> > Ye7ZhzHeC/jljhpmVBcSAQoMBZdkZC/yDiXgRpX1xCSHFTRyxx7RB0RdhFZ/ZM1o
> > 7r9C9bhtX4CCZTJJtBUZwe3NLsTCzTt8eObH1hNe4usII7eI97OnhPJFpoFNlffP
> > ikOrorKHOsUfG7dfGD25QP9IlZoLeH6c7vIL5zFfWZXFHVNxLVLSEl4KbkTM0O4I
> > WYDTSOdDvY/VNnAyKQwrdpxxx+EGRz+pHhclDQeb5Dim3HYdf464r+DrZXWhK8pr
> > RiVlvKaKw2RarrxuGs+sq6GWEyUipYe8Z+88tdql/5R5cKmBRzye6W13X073jdT6
> > lVG6A3cslvOcWo+B41DUpLRafLTUuylOdAJYn4N8iB1psP0GLvQjZJLjIl0an/ZZ
> > vDDV8N8KW80hJM9cH+twuKGVKe+qdS6qjnh+LfO44ltyjHOgRhsXn+ElhHl3cNEq
> > ZOrW1nnH/h8jI2gTK6z9jYMzaSn2or2yj9UyvcAHlG8p10maBwmMm+F1cBHbFb3Z
> > D6VtwzZprdHqv+G7Gy1+
> > =5tsJ
> > -END PGP SIGNATURE-
> > 
> > 
> > 
> > CHANGELOG for 7.8.1:
> > ** Bug
> > 
> > * [WICKET-6429] - AbstractRequestLogger should not create new Sessions
> > * [WICKET-6455] - AjaxFormSubmitBehavior doesn't submit inner forms
> > * [WICKET-6457] - PageStore not cleared at session end

Re: Major page store issue found in 7.8.0, release a 7.8.1?

[Emond Papegaaij]

I've applied to fix to 6.x, 7.x and 8 (master). IMHO this issue warrants a 
patch-release for at least 6 (6.27.1) and 7 (7.8.1).

Best regards,
Emond

On dinsdag 29 augustus 2017 15:26:06 CEST Martijn Dashorst wrote:
> https://issues.apache.org/jira/browse/WICKET-6387
> 
> The original fix apparently introduces the behavior that our logged out
> users don't remove stale pages from the pagestore because the session is
> marked "updating"
> 
> Any site with major traffic that uses the page store will be affected by
> this. In Emond and my assessment this will necessitate a 7.8.1 fix as soon
> as possible.
> 
> Does anyone have a better suggestion than Emond proposes in WICKET-6387? (I
> owe you a beer then), and do you agree that a 7.8.1 should be rolled?
> 
> Martijn

Re: Major page store issue found in 7.8.0, release a 7.8.1?

[Emond Papegaaij]

I've created an issue to track this regression and a PR with my proposed fix:
https://github.com/apache/wicket/pull/231

Emond

On dinsdag 29 augustus 2017 15:26:06 CEST Martijn Dashorst wrote:
> https://issues.apache.org/jira/browse/WICKET-6387
> 
> The original fix apparently introduces the behavior that our logged out
> users don't remove stale pages from the pagestore because the session is
> marked "updating"
> 
> Any site with major traffic that uses the page store will be affected by
> this. In Emond and my assessment this will necessitate a 7.8.1 fix as soon
> as possible.
> 
> Does anyone have a better suggestion than Emond proposes in WICKET-6387? (I
> owe you a beer then), and do you agree that a 7.8.1 should be rolled?
> 
> Martijn

Re: wicket git commit: WICKET-6376: allow non-http(s) uris in ajax redirects

[Emond Papegaaij]

Hi Martin,

I agree, I totally forgot about the JS testsuite. Unfortunately, I'm not that 
familiar with that code and am very limited in my time at the moment. I would 
really appreciate it if you could help with this testcase.

Best regards,
Emond

On dinsdag 30 mei 2017 20:47:12 CEST Martin Grigorov wrote:
> Hi Emond,
> 
> I think it would be useful to have a new JS test for this.
> Do you like to add it or I should help ?
> 
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
> 
> On Tue, May 30, 2017 at 5:55 PM, <papega...@apache.org> wrote:
> > Repository: wicket
> > 
> > Updated Branches:
> >   refs/heads/wicket-7.x 35aacc4ef -> 6963c723f
> > 
> > WICKET-6376: allow non-http(s) uris in ajax redirects
> > 
> > 
> > Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/6963c723
> > Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/6963c723
> > Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/6963c723
> > 
> > Branch: refs/heads/wicket-7.x
> > Commit: 6963c723f1efb55d7ffdc64d2ccd8ab16718ef19
> > Parents: 35aacc4
> > Author: Emond Papegaaij <papega...@apache.org>
> > Authored: Tue May 30 17:54:56 2017 +0200
> > Committer: Emond Papegaaij <papega...@apache.org>
> > Committed: Tue May 30 17:55:32 2017 +0200
> > 
> > --
> > 
> >  .../java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js| 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > --
> > 
> > 
> > http://git-wip-us.apache.org/repos/asf/wicket/blob/
> > 6963c723/wicket-core/src/main/java/org/apache/wicket/ajax/
> > res/js/wicket-ajax-jquery.js
> > --
> > diff --git
> > a/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jqu
> > ery.js b/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/
> > wicket-ajax-jquery.js
> > index 0f25238..f0289fc 100644
> > --- a/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/
> > wicket-ajax-jquery.js
> > +++ b/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/
> > wicket-ajax-jquery.js
> > @@ -780,11 +780,10 @@
> > 
> > // A file download popup will
> > 
> > appear but the page in the browser won't change.
> > 
> > this.success(context);
> > 
> > -   var rhttp  = /^http:\/\//,  //
> > checks whether the string starts with http://
> > -   rhttps = /^https:\/\//; //
> > checks whether the string starts with https://
> > +   var withScheme  =
> > /^[a-z][a-z0-9+.-]*:\/\//;  // checks whether the string starts with a
> > scheme
> > 
> > // support/check for non-relative
> > 
> > redirectUrl like as provided and needed in a portlet context
> > -   if (redirectUrl.charAt(0) === '/'
> > 
> > || rhttp.test(redirectUrl) || rhttps.test(redirectUrl)) {
> > 
> > +   if (redirectUrl.charAt(0) === '/'
> > 
> > || withScheme.test(redirectUrl)) {
> > || 
> > context.isRedirecting =
> > 
> > true;
> > 
> > Wicket.Ajax.redirect(
> > 
> > redirectUrl);
> > 
> > }

Re: Proposal to move @FunctionalInteface from IModel

[Emond Papegaaij]

On maandag 10 april 2017 23:48:27 CEST Pedro Santos wrote:
> Hi Emond,
> 
> > Your proposal will not work because Java does not resolve functional
> > interfaces to subtypes of the target type. For example, take the Label
> > constructor:
> I know, and that is just a good thing. Take TextField for example, we don't
> want it constructed with a function as a model:
> 
> new TextField("id", Bean::getMethod())
> 
> this proposal is correctly preventing the user from assigning a read-only
> model to a component designed to write on it.

Your solution does not prevent this. Your IReadOnlyModel is a subinterface of 
IModel. Therefore it is perfectly fine to pass a IReadOnlyModel to the 
constructor of TextField. In your example, you will need to add a cast or 
assign it to a variable first:

IReadOnlyModel model = Bean::getMethod;
new TextField<>("id", model);

Also, I think this should be allowed. A disabled TextField provides a read-
only view of its model. There are a few read-only usecases in Wicket though: 
for example ListView and the choices in a dropdown select.

> > In Wicket 8 this works, because IModel is a functional interface, so Java
> > knows how to convert a method taking no arguments and returning a double
> > into a IModel by mapping that method to getObject().
> 
> Sure, and it's our job to provide good a API allowing the user to benefit
> from Java 8 features *where it does make sense*. A good set of constructors
> for a Label would include:
> 
> public Label(String id, IReadyOnlyModel model){ ... }

This would require adding additional constructors to all classes that must 
support read-only models. You cannot replace the constructors, because it is 
perfectly fine to construct a label with a read-write model. The problem is 
that the is-a relation for IReadOnlyModel is defined wrongly: a read-write 
model is a read-only model (a read-write model provides all the capabilities 
of a read-only model and more).

To get this right, IModel needs to be split into 2 super-interfaces: 
IReadOnlyModel and IWriteOnlyModel, both extending IDetachable. IModel then is 
simply a combination of IReadOnlyModel and IWriteOnlyModel. Both super-models 
can be functional interfaces and perhaps we can even support split models on 
components:

new TextField<>("id", Bean::getMethod, Bean::setMethod);

The problem however is "default model". For this to work, we need to drop the 
components default model, because you cannot know if it is IReadOnlyModel, 
IWriteOnlyModel or IModel. This includes CompoundPropertyModel. But this 
breaks the API of Wicket bigtime and the gain turned out the be very small.

Best regards,
Emond

Re: Proposal to move @FunctionalInteface from IModel

[Emond Papegaaij]

Hi Pedro,

Your proposal will not work because Java does not resolve functional 
interfaces to subtypes of the target type. For example, take the Label 
constructor:

public Label(String id, IModel model)

I would like to use this constructor as follows:

new Label("id", Math::random)

In Wicket 8 this works, because IModel is a functional interface, so Java 
knows how to convert a method taking no arguments and returning a double into 
a IModel by mapping that method to getObject().

With your proposal, this code needs to be changed to:

new Label("id", (IReadOnlyModel) Math::random)

So time ago, we tried to make IModel extend a ReadOnlyModel. In that case, it 
would work, but the change did not work out very well.

Best regards,
Emond

On vrijdag 7 april 2017 12:45:53 CEST Pedro Santos wrote:
> Hi devs,
> 
> IModel isn't an interface designed to provide a function, it's rather an
> interface designed to provide and manipulate (setObject and detach methods)
> internal state.
> 
> IMO a better alternative to benefit from Java 8 features would be to move
> the FunctionalInterface annotation to an interface that actually is
> designed to provide one function.
> 
> I propose that we add a new interface extending IModel to provide this
> functional interface, instead of to misplace it in an interface made for
> objects with internal state.
> 
> e.g.
> 
> @FunctionalInterface
> interface IReadyOnlyModel / IModelFunction / IFunction extends from IModel{
> 
> default void setObject(final T object)
> {
> throw new UnsupportedOperationException("unsuported");
> }
> 
> default void detach()
> {
> throw new UnsupportedOperationException("unsuported");
> }
> 
> }
> 
> Cheers
> 
> Pedro Santos

Re: [VOTE] Proposal to remove IDetachable from IModel hierarchy

[Emond Papegaaij]

The vote is closed with:
1x Yes, remove IDetachable from IModel
7x No, keep IModel detachable

So we can conclude that IModel will remain detachable.

Best regards,
Emond

On maandag 3 april 2017 09:38:03 CEST Emond Papegaaij wrote:
> Something went wrong sending this mail. I did write some more, but somehow
> my mail client lost it. So here's the vote again:
> 
> I think we are not going to agree on this proposal. I think it is not an
> improvement and I do not agree with you that IModel should not be
> detachable by default. So lets vote on this.
> 
> [ ] Yes, remove IDetachable from IModel
> [ ] No, keep IModel detachable
> 
> My vote:
> -1 keep IModel detachable
> 
> Best regards,
> Emond

Review WICKET-6353

[Emond Papegaaij]

Hi,

We've hit a rather nasty classloading issue during Wicket's deserialization, 
for which Martijn and I have a proposed fix. However, due to the complexity of 
classloading it's near to impossible to write a testcase for it, so we would 
really appreciate it if this could be reviewed. The change itself is not that 
big.

Best regards,
Emond