Re: Could not lock page exception improvement

[Martijn Dashorst]

Merged to master. I'll create a separate PR for 9.x

Martijn


On Thu, May 9, 2024 at 3:19 PM Martijn Dashorst 
wrote:

>
>
> On Tue, May 7, 2024 at 1:30 PM Martin Grigorov 
> wrote:
>
>> Hi,
>>
>> On Tue, May 7, 2024 at 2:20 PM Martijn Dashorst <
>> martijn.dasho...@gmail.com>
>> wrote:
>>
>> > Hi!
>> >
>> > I was looking at our exception reporting in our application(s), and
>> noticed
>> > that when the CouldNotLockPageException is thrown, it only logs the
>> stack
>> > elements of the request that keeps the lock.
>> >
>>
>> "... of the request that keeps the lock"
>> Isn't that the important stacktrace ?
>> I.e. it does not log the stacktrace of the current request but of the one
>> that keeps the lock, i.e. hangs.
>>
>
> Yes, and I want that in the cause of the CouldNotLockPageException, not
> just in the log.
>
> See https://github.com/apache/wicket/pull/861 for the implementation
>
> Martijn
>
> <http://wicketinaction.com>
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Could not lock page exception improvement

[Martijn Dashorst]

On Tue, May 7, 2024 at 1:30 PM Martin Grigorov  wrote:

> Hi,
>
> On Tue, May 7, 2024 at 2:20 PM Martijn Dashorst <
> martijn.dasho...@gmail.com>
> wrote:
>
> > Hi!
> >
> > I was looking at our exception reporting in our application(s), and
> noticed
> > that when the CouldNotLockPageException is thrown, it only logs the stack
> > elements of the request that keeps the lock.
> >
>
> "... of the request that keeps the lock"
> Isn't that the important stacktrace ?
> I.e. it does not log the stacktrace of the current request but of the one
> that keeps the lock, i.e. hangs.
>

Yes, and I want that in the cause of the CouldNotLockPageException, not
just in the log.

See https://github.com/apache/wicket/pull/861 for the implementation

Martijn

<http://wicketinaction.com>

Could not lock page exception improvement

[Martijn Dashorst]

Hi!

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

What I'd like to do is to construct an exception and fill that exception's
stack trace elements with the stack of the lock keeping request, and
setting that as the cause of the CouldNotLockPageException.

While this is a bit esoteric in nature, I think it is functionally correct
in that the page that keeps the lock is actually the cause of the CNLPE.

This would make debugging the occurrences of the CNLPE a bit better, as the
exception itself is not informative, and you're actually interested in the
cause. So this would alleviate the need to peruse the logs of one's
application, and you can just look in the reported exception itself.

WDYT?

Martijn

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

[Martijn Dashorst]

Thanks Martin!

It appears we now have to wait for the projects.a.o website to update
itself :-)

Martijn


On Wed, Sep 6, 2023 at 8:44 AM Martin Grigorov  wrote:

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


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

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

[Martijn Dashorst]

On Wed, Sep 6, 2023 at 8:18 AM Martin Grigorov  wrote:

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

Yes, otherwise jekyll will not use the file as a template.

Martijn

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

[Martijn Dashorst]

There was some rumblings that a lot of projects don't have a DOAP file
(which is processed by https://projects.apache.org) and when I looked at
our description on projects.a.o it noted:

6.19.0 (2015-02-02): Latest Stable Release

Which is AFAIK incorrect :-D

It appears that the DOAP registration points to the SVN repository of our
site publishing thing, which hasn't been in use since at last 2 February
2015, 8 years ago.

This should be fixed in the projects.a.o administration to point to our
DOAP file that's published on the website (
https://wicket.apache.org/doap.rdf), and I think the SCM location should
also be changed from subversion to something git like.

The projects.a.o site: https://projects.apache.org/project.html?wicket

Any takers?

Martijn

Re: Release Wicket 10.0.0-M1?

[Martijn Dashorst]

Is commons-fileupload still necessary with the addition of multipart
support?

https://www.baeldung.com/upload-file-servlet

I assume we require servlet 3.0 at the minimum?

Martijn


On Sat, Dec 17, 2022 at 1:56 AM Maxim Solodovnik 
wrote:

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


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Apache Committers

[Martijn Dashorst]

This is because you don't have 2fa enabled on your account. This is ASF
policy, since 2016 or so, but they were unable to enforce it at that time.
Now they can validate and are cleaning up the committers group.

Martijn

On Fri, Dec 9, 2022 at 7:57 PM Tobias Soloschenko
 wrote:

> Hey everyone,
>
> I just received the same message.
>
> kind regards
>
> Tobias
>
> > Am 09.12.2022 um 19:08 schrieb Andrea Del Bene :
> >
> > That's weird, and honestly I don't know who might responsible for this
> . I
> > will try to investigate further.
> >
> >> On Fri, Dec 9, 2022 at 6:32 PM Michael Mosmann 
> wrote:
> >>
> >> Hi,
> >>
> >> I got this message today:
> >>
> >>> You’ve been removed from the "Apache Committers" team on the "The
> >>> Apache Software Foundation" organization.
> >>>
> >>> Cheers & Octocats,
> >>> GitHub Support
> >>
> >> I guess this is not a spam message... and as my last commit is long ago
> >> this is the right step to do:)
> >>
> >> so have fun and nice pre christmas day:) (still reading wicket related
> >> mailing lists)
> >>
> >>
> >> Michael Mosmann:)
> >>
> >
> >
> > --
> > Andrea Del Bene.
> > Apache Wicket committer.
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Time for 9.12.0?

[Martijn Dashorst]

IIUC sfl4j 2.0.0 API is the same as 1.7.x API, so from a Wicket perspective
it doesn't matter if we ship with 2.0.0 or 1.7.x, right?

If that is the case, I suggest we fall back to 1.7.x, and note that one can
easily upgrade to 2.0.0 without issue if someone so desires.

This will keep it working for most folks, yet give an upgrade path for
those that wish so. It is harder to convince someone to downgrade from 2.0
to 1.7 than to upgrade to 2.0 from 1.7.

But this is my .02 (which is even worth less with the current exchange
rates).

Martijn



On Wed, Sep 14, 2022 at 9:15 AM Martin Grigorov 
wrote:

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


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Build failed in Jenkins: Wicket » Wicket 9.x (Draft) #157

[Martijn Dashorst]

The build fails for some reason I am unable to discern, nor does it seem
related to my change. The 9.x branch builds perfectly locally, so I assume
this is a flaky build of the ASF jenkins server.

Martijn


On Tue, Sep 13, 2022 at 10:56 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://ci-builds.apache.org/job/Wicket/job/Wicket%209.x%20(Draft)/157/display/redirect?page=changes
> >
>
> Changes:
>
> [github] Upgrade archetype pom plugins
>
>
> --
> [...truncated 1.72 MB...]
> [INFO]
> [INFO] 6 vulnerabilities (4 high, 2 critical)
> [INFO]
> [INFO] To address issues that do not require attention, run:
> [INFO]   npm audit fix
> [INFO]
> [INFO] To address all issues, run:
> [INFO]   npm audit fix --force
> [INFO]
> [INFO] Run `npm audit` for details.
> [INFO]
> [INFO] --- frontend-maven-plugin:1.12.1:grunt (grunt build) @
> wicket-js-tests ---
> [INFO] Running 'grunt ' in <
> https://ci-builds.apache.org/job/Wicket/job/Wicket%209.x%20(Draft)/ws/testing/wicket-js-tests
> >
> [INFO] Running "jshint:core" (jshint) task
> [INFO] >> 4 files lint free.
> [INFO]
> [INFO] Running "jshint:extensions" (jshint) task
> [INFO] >> 6 files lint free.
> [INFO]
> [INFO] Running "jshint:nativeWebSocket" (jshint) task
> [INFO] >> 1 file lint free.
> [INFO]
> [INFO] Running "jshint:testsJs" (jshint) task
> [INFO] >> 8 files lint free.
> [INFO]
> [INFO] Running "jshint:gymTestsJs" (jshint) task
> [INFO] >> 12 files lint free.
> [INFO]
> [INFO] Running "jshint:grunt" (jshint) task
> [INFO] >> 1 file lint free.
> [INFO]
> [INFO] Running "connect:server" (connect) task
> [INFO] Fatal error: Port 38887 is already in use by another process.
> [WARNING] Failed to getClass for
> org.apache.maven.plugins.javadoc.AggregatorJavadocReport
> [WARNING] Failed to getClass for
> org.apache.maven.plugins.javadoc.AggregatorJavadocReport
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Wicket Parent 9.12.0-SNAPSHOT .. FAILURE [01:31
> min]
> [INFO] Wicket Util 9.12.0-SNAPSHOT  SUCCESS [01:36
> min]
> [INFO] Wicket Request 9.12.0-SNAPSHOT . SUCCESS [
> 39.795 s]
> [INFO] Wicket Core 9.12.0-SNAPSHOT  SUCCESS [06:06
> min]
> [INFO] Wicket 9.12.0-SNAPSHOT . SUCCESS [
> 11.143 s]
> [INFO] Wicket Extensions 9.12.0-SNAPSHOT .. SUCCESS [01:08
> min]
> [INFO] Wicket Development Utilities 9.12.0-SNAPSHOT ... SUCCESS [
> 36.245 s]
> [INFO] Wicket IoC common code 9.12.0-SNAPSHOT . SUCCESS [
> 47.132 s]
> [INFO] Wicket CDI 9.12.0-SNAPSHOT . SUCCESS [
> 51.910 s]
> [INFO] Wicket Spring Integration 9.12.0-SNAPSHOT .. SUCCESS [
> 39.379 s]
> [INFO] Wicket Velocity 9.12.0-SNAPSHOT  SUCCESS [
> 34.168 s]
> [INFO] Wicket Auth Roles 9.12.0-SNAPSHOT .. SUCCESS [
> 39.607 s]
> [INFO] Wicket Guice Integration 9.12.0-SNAPSHOT ... SUCCESS [
> 36.916 s]
> [INFO] Wicket JMX 9.12.0-SNAPSHOT . SUCCESS [
> 33.822 s]
> [INFO] Wicket Objects Sizeof Agent 9.12.0-SNAPSHOT  SUCCESS [
> 25.469 s]
> [INFO] Wicket Bean Validation 9.12.0-SNAPSHOT . SUCCESS [
> 38.730 s]
> [INFO] Wicket Native WebSocket Parent 9.12.0-SNAPSHOT . SUCCESS [
> 10.758 s]
> [INFO] Wicket Native WebSocket Core 9.12.0-SNAPSHOT ... SUCCESS [
> 37.424 s]
> [INFO] Wicket Native WebSocket Javax 9.12.0-SNAPSHOT .. SUCCESS [
> 37.249 s]
> [INFO] Wicket Examples 9.12.0-SNAPSHOT  SUCCESS [01:08
> min]
> [INFO] Wicket-Experimental 9.12.0-SNAPSHOT  SUCCESS [
> 9.900 s]
> [INFO] Wicket Http/2 0.23-SNAPSHOT  SUCCESS [
> 10.546 s]
> [INFO] Wicket Http/2 Core 0.23-SNAPSHOT ... SUCCESS [
> 33.179 s]
> [INFO] Wicket Http/2 Jetty 9.3+ 0.23-SNAPSHOT . SUCCESS [
> 33.061 s]
> [INFO] Wicket Http/2 Servlet 4 0.23-SNAPSHOT .. SUCCESS [
> 31.441 s]
> [INFO] Wicket Http/2 Tomcat 8.5+ 0.23-SNAPSHOT  SUCCESS [
> 35.759 s]
> [INFO] Wicket Http/2 Undertow 2+ 0.23-SNAPSHOT  SUCCESS [
> 31.727 s]
> [INFO] Wicket Metrics 0.24-SNAPSHOT ... SUCCESS [
> 31.304 s]
> [INFO] Wicket Quickstart Archetype 9.12.0-SNAPSHOT  SUCCESS [
> 26.862 s]
> [INFO] Wicket Common Tests 9.12.0-SNAPSHOT  SUCCESS [
> 10.952 s]
> [INFO] Wicket JavaScript Tests 9.12.0-SNAPSHOT  SUCCESS [01:30
> min]
> [INFO] Wicket User Guide 9.12.0-SNAPSHOT .. SUCCESS [06:19
> min]
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  36:54 min
> [INFO] Finished at: 2022-09-13T20:52:21Z
> [INFO]
> 

Re: Time for 9.12.0?

[Martijn Dashorst]

No objection from me!

Martijn 

> On 13 Sep 2022, at 13:14, Andrea Del Bene  wrote:
> 
> Looks like we have enough material to promote a new release. WDYT?
> 
> -- 
> Andrea Del Bene.
> Apache Wicket committer.

Re: Synchronization on Application.getMetaData()

[Martijn Dashorst]

It's merged into 10.x, 9.x and 8.x

Martijn


On Sun, Sep 4, 2022 at 12:17 AM Andrea Del Bene 
wrote:

>
> On 03/09/22 20:46, Martijn Dashorst wrote:
> > I've added PRs for wicket 8.x, 9.x and master. I assume we won't be
> > releasing a 7.x anytime soon, so this is just one more benefit for
> > upgrading to a newer version IMO.
> >
> > Even though this came up as a blocking hotspot, it did not show up as a
> > performance hotspot, so it will benefit all wicket applications, but it
> is
> > not detrimental.
> >
> > If there are no objections I intend to merge these changes somewhere on
> > monday.
> >
> > Martijn
>
> Ok! Thank you!
>
>
> >
> >
> > On Fri, Sep 2, 2022 at 5:43 PM Martijn Dashorst <
> martijn.dasho...@gmail.com>
> > wrote:
> >
> >> I've created this ticket for this:
> >>
> >> https://issues.apache.org/jira/browse/WICKET-7002
> >>
> >> And a PR: https://github.com/apache/wicket/pull/532
> >>
> >> Martijn
> >>
> >>
> >> On Fri, Sep 2, 2022 at 2:37 PM Martijn Dashorst <
> >> martijn.dasho...@gmail.com> wrote:
> >>
> >>> Well,
> >>>
> >>> I think that the metadata storage in Application tries to mimic a
> >>> key-value store, but does so in an esoteric way that requires
> >>> synchronization, which is unnecessary when we just use a
> ConcurrentHashMap
> >>> for the datastructure that is especially designed for this use case.
> >>> Changing the array to a ConcurrentHashMap will not increase the memory
> >>> footprint in any meaningful way, but will remove the need for
> >>> synchronization and change the algorithm for looking up a value by key
> from
> >>> O(n) to O(1) (
> >>>
> https://stackoverflow.com/questions/559839/big-o-summary-for-java-collections-framework-implementations
> >>> ).
> >>>
> >>> The change is completely encapsulated for external users (unless they
> >>> play with the internals using reflection) so this can also be
> backported to
> >>> Wicket 9, 8 and 7, up til Wicket 1.5 if we so desire (we don't but you
> get
> >>> my drift).
> >>>
> >>> I also think it is a bad idea to return the datastructure from the
> >>> setter. This would have made this optimization impossible to do in a
> >>> backwards compatible way.
> >>>
> >>> Martijn
> >>>
> >>>
> >>> On Fri, Sep 2, 2022 at 11:59 AM Andrea Del Bene 
> >>> wrote:
> >>>
> >>>> It's of course a delicate topic and it needs a full investigation, but
> >>>> looking at the code of both setMetaData and getMetaData I think we
> could
> >>>> reduce the synchronization overloading by making Application#metadata
> >>>> volatile and removing synchronized from getMetaData. In addition I
> think
> >>>> setMetaData should always return a new copy of Application#metadata to
> >>>> ensure a proper synchronization among threads, but I'm not 100% sure
> >>>> about
> >>>> this.
> >>>>
> >>>> Just some 2 cents...
> >>>>
> >>>> On Fri, Sep 2, 2022 at 8:46 AM Martijn Dashorst <
> >>>> martijn.dasho...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Heya!
> >>>>>
> >>>>> In a performance dump for a production issue I was looking through
> the
> >>>>> monitors that were in use during request processing and I noticed
> that
> >>>> a
> >>>>> lot of request threads were blocking on Application.getMetaData.
> >>>>>
> >>>>> This method is synchronized because it uses an array of metadata and
> >>>> goes
> >>>>> through that array in search of the key.
> >>>>>
> >>>>> I'm no rocket scientist, but shouldn't that metadata field just be a
> >>>>> ConcurrentHashMap so we can remove the blocking synchronization on
> the
> >>>>> application object?
> >>>>>
> >>>>> Martijn
> >>>>>
> >>>>> <http://wicketinaction.com>
> >>>>>
> >>>>
> >>>> --
> >>>> Andrea Del Bene.
> >>>> Apache Wicket committer.
> >>>>
> >>>
> >>> --
> >>> Become a Wicket expert, learn from the best: http://wicketinaction.com
> >>>
> >>
> >> --
> >> Become a Wicket expert, learn from the best: http://wicketinaction.com
> >>
> >
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Synchronization on Application.getMetaData()

[Martijn Dashorst]

I've added PRs for wicket 8.x, 9.x and master. I assume we won't be
releasing a 7.x anytime soon, so this is just one more benefit for
upgrading to a newer version IMO.

Even though this came up as a blocking hotspot, it did not show up as a
performance hotspot, so it will benefit all wicket applications, but it is
not detrimental.

If there are no objections I intend to merge these changes somewhere on
monday.

Martijn


On Fri, Sep 2, 2022 at 5:43 PM Martijn Dashorst 
wrote:

> I've created this ticket for this:
>
> https://issues.apache.org/jira/browse/WICKET-7002
>
> And a PR: https://github.com/apache/wicket/pull/532
>
> Martijn
>
>
> On Fri, Sep 2, 2022 at 2:37 PM Martijn Dashorst <
> martijn.dasho...@gmail.com> wrote:
>
>> Well,
>>
>> I think that the metadata storage in Application tries to mimic a
>> key-value store, but does so in an esoteric way that requires
>> synchronization, which is unnecessary when we just use a ConcurrentHashMap
>> for the datastructure that is especially designed for this use case.
>> Changing the array to a ConcurrentHashMap will not increase the memory
>> footprint in any meaningful way, but will remove the need for
>> synchronization and change the algorithm for looking up a value by key from
>> O(n) to O(1) (
>> https://stackoverflow.com/questions/559839/big-o-summary-for-java-collections-framework-implementations
>> ).
>>
>> The change is completely encapsulated for external users (unless they
>> play with the internals using reflection) so this can also be backported to
>> Wicket 9, 8 and 7, up til Wicket 1.5 if we so desire (we don't but you get
>> my drift).
>>
>> I also think it is a bad idea to return the datastructure from the
>> setter. This would have made this optimization impossible to do in a
>> backwards compatible way.
>>
>> Martijn
>>
>>
>> On Fri, Sep 2, 2022 at 11:59 AM Andrea Del Bene 
>> wrote:
>>
>>> It's of course a delicate topic and it needs a full investigation, but
>>> looking at the code of both setMetaData and getMetaData I think we could
>>> reduce the synchronization overloading by making Application#metadata
>>> volatile and removing synchronized from getMetaData. In addition I think
>>> setMetaData should always return a new copy of Application#metadata to
>>> ensure a proper synchronization among threads, but I'm not 100% sure
>>> about
>>> this.
>>>
>>> Just some 2 cents...
>>>
>>> On Fri, Sep 2, 2022 at 8:46 AM Martijn Dashorst <
>>> martijn.dasho...@gmail.com>
>>> wrote:
>>>
>>> > Heya!
>>> >
>>> > In a performance dump for a production issue I was looking through the
>>> > monitors that were in use during request processing and I noticed that
>>> a
>>> > lot of request threads were blocking on Application.getMetaData.
>>> >
>>> > This method is synchronized because it uses an array of metadata and
>>> goes
>>> > through that array in search of the key.
>>> >
>>> > I'm no rocket scientist, but shouldn't that metadata field just be a
>>> > ConcurrentHashMap so we can remove the blocking synchronization on the
>>> > application object?
>>> >
>>> > Martijn
>>> >
>>> > <http://wicketinaction.com>
>>> >
>>>
>>>
>>> --
>>> Andrea Del Bene.
>>> Apache Wicket committer.
>>>
>>
>>
>> --
>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Synchronization on Application.getMetaData()

[Martijn Dashorst]

I've created this ticket for this:

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

And a PR: https://github.com/apache/wicket/pull/532

Martijn


On Fri, Sep 2, 2022 at 2:37 PM Martijn Dashorst 
wrote:

> Well,
>
> I think that the metadata storage in Application tries to mimic a
> key-value store, but does so in an esoteric way that requires
> synchronization, which is unnecessary when we just use a ConcurrentHashMap
> for the datastructure that is especially designed for this use case.
> Changing the array to a ConcurrentHashMap will not increase the memory
> footprint in any meaningful way, but will remove the need for
> synchronization and change the algorithm for looking up a value by key from
> O(n) to O(1) (
> https://stackoverflow.com/questions/559839/big-o-summary-for-java-collections-framework-implementations
> ).
>
> The change is completely encapsulated for external users (unless they play
> with the internals using reflection) so this can also be backported to
> Wicket 9, 8 and 7, up til Wicket 1.5 if we so desire (we don't but you get
> my drift).
>
> I also think it is a bad idea to return the datastructure from the setter.
> This would have made this optimization impossible to do in a backwards
> compatible way.
>
> Martijn
>
>
> On Fri, Sep 2, 2022 at 11:59 AM Andrea Del Bene 
> wrote:
>
>> It's of course a delicate topic and it needs a full investigation, but
>> looking at the code of both setMetaData and getMetaData I think we could
>> reduce the synchronization overloading by making Application#metadata
>> volatile and removing synchronized from getMetaData. In addition I think
>> setMetaData should always return a new copy of Application#metadata to
>> ensure a proper synchronization among threads, but I'm not 100% sure about
>> this.
>>
>> Just some 2 cents...
>>
>> On Fri, Sep 2, 2022 at 8:46 AM Martijn Dashorst <
>> martijn.dasho...@gmail.com>
>> wrote:
>>
>> > Heya!
>> >
>> > In a performance dump for a production issue I was looking through the
>> > monitors that were in use during request processing and I noticed that a
>> > lot of request threads were blocking on Application.getMetaData.
>> >
>> > This method is synchronized because it uses an array of metadata and
>> goes
>> > through that array in search of the key.
>> >
>> > I'm no rocket scientist, but shouldn't that metadata field just be a
>> > ConcurrentHashMap so we can remove the blocking synchronization on the
>> > application object?
>> >
>> > Martijn
>> >
>> > <http://wicketinaction.com>
>> >
>>
>>
>> --
>> Andrea Del Bene.
>> Apache Wicket committer.
>>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Synchronization on Application.getMetaData()

[Martijn Dashorst]

Well,

I think that the metadata storage in Application tries to mimic a key-value
store, but does so in an esoteric way that requires synchronization, which
is unnecessary when we just use a ConcurrentHashMap for the datastructure
that is especially designed for this use case. Changing the array to a
ConcurrentHashMap will not increase the memory footprint in any meaningful
way, but will remove the need for synchronization and change the algorithm
for looking up a value by key from O(n) to O(1) (
https://stackoverflow.com/questions/559839/big-o-summary-for-java-collections-framework-implementations
).

The change is completely encapsulated for external users (unless they play
with the internals using reflection) so this can also be backported to
Wicket 9, 8 and 7, up til Wicket 1.5 if we so desire (we don't but you get
my drift).

I also think it is a bad idea to return the datastructure from the setter.
This would have made this optimization impossible to do in a backwards
compatible way.

Martijn


On Fri, Sep 2, 2022 at 11:59 AM Andrea Del Bene 
wrote:

> It's of course a delicate topic and it needs a full investigation, but
> looking at the code of both setMetaData and getMetaData I think we could
> reduce the synchronization overloading by making Application#metadata
> volatile and removing synchronized from getMetaData. In addition I think
> setMetaData should always return a new copy of Application#metadata to
> ensure a proper synchronization among threads, but I'm not 100% sure about
> this.
>
> Just some 2 cents...
>
> On Fri, Sep 2, 2022 at 8:46 AM Martijn Dashorst <
> martijn.dasho...@gmail.com>
> wrote:
>
> > Heya!
> >
> > In a performance dump for a production issue I was looking through the
> > monitors that were in use during request processing and I noticed that a
> > lot of request threads were blocking on Application.getMetaData.
> >
> > This method is synchronized because it uses an array of metadata and goes
> > through that array in search of the key.
> >
> > I'm no rocket scientist, but shouldn't that metadata field just be a
> > ConcurrentHashMap so we can remove the blocking synchronization on the
> > application object?
> >
> > Martijn
> >
> > <http://wicketinaction.com>
> >
>
>
> --
> Andrea Del Bene.
> Apache Wicket committer.
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Synchronization on Application.getMetaData()

[Martijn Dashorst]

Heya!

In a performance dump for a production issue I was looking through the
monitors that were in use during request processing and I noticed that a
lot of request threads were blocking on Application.getMetaData.

This method is synchronized because it uses an array of metadata and goes
through that array in search of the key.

I'm no rocket scientist, but shouldn't that metadata field just be a
ConcurrentHashMap so we can remove the blocking synchronization on the
application object?

Martijn

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

[Martijn Dashorst]

On Thu, Aug 11, 2022 at 4:11 PM Chris Colman
 wrote:

> On 11/08/2022 7:45 pm, Daniel Stoch wrote:
> > We have a plan to upgrade (at last ;))
> Yeehah!
> >   Wicket to a newer version (9.x), but
> > it is not quite easy for a big application
> Our app has 1034 Wicket UI classes - that's just pure Wicket UI classes
>

Mine is bigger than yours! :tongue in cheek:

Secondary education student information system:
$ git grep -l "org.apache.wicket." | wc -l
3825
Sloccount:
java:   1378972 (98.24%)

Primary education student information system:
$ git grep -l "org.apache.wicket." | wc -l
2381
Sloccount:
java:672676 (96.59%)

Shared component/model/behaviour/other utility classes framework:
$ git grep -l "org.apache.wicket." | wc -l
750
Sloccount:
java:145353 (100.00%)

All running on Wicket latest. We just migrate when there's a new version
available as soon as possible, because otherwise You Get Left Behind, and
It Gets Scarier to Upgrade and More Expensive (due to more regressions
possible--having to upgrade Java, other libraries, etc).

Martijn

Re: CI for wicketstuff

[Martijn Dashorst]

I did not find any...

Martijn


On Fri, Feb 11, 2022 at 6:49 AM Maxim Solodovnik 
wrote:

> Hello Martijn,
>
> were you able to find credentials? :)
> I can try to add my personal login/password
>
> I believe SNAPSHOTs are very useful :)
>
> On Wed, 19 Jan 2022 at 15:12, Martijn Dashorst
>  wrote:
> >
> > IIRC all our secrets are in the wicket-pmc's private repository. I'm
> trying
> > to find the coordinates but I am unable to find them.
> >
> > Martijn
> >
> >
> > On Fri, Jan 14, 2022 at 10:55 PM Martin Grigorov 
> > wrote:
> >
> > > I've merged the PR!
> > >
> > > But it failed because there are no env vars/secrets for deploying to
> > > oss.sonatype.org
> > > Travis was using
> > >
> > >
> https://github.com/wicketstuff/core/blob/b3f84bb0f49f1ebee8eec5100cb31b22176d5a4b/.travis.yml#L22-L26
> > > If anyone knows what were those credentials then please set them up at
> > > https://github.com/wicketstuff/core/settings/secrets/actions with
> names
> > > CI_DEPLOY_USERNAME and CI_DEPLOY_PASSWORD (
> > >
> > >
> https://github.com/wicketstuff/core/blob/b3f84bb0f49f1ebee8eec5100cb31b22176d5a4b/.github/workflows/ci.yml#L54-L56
> > > )
> > > Otherwise we could run just 'mvn verify'
> > >
> > > On Fri, Jan 14, 2022 at 9:51 AM Martin Grigorov 
> > > wrote:
> > >
> > > >
> > > >
> > > > On Fri, Jan 14, 2022 at 9:32 AM Maxim Solodovnik <
> solomax...@gmail.com>
> > > > wrote:
> > > >
> > > >> On Thu, 13 Jan 2022 at 10:29, Maxim Solodovnik <
> solomax...@gmail.com>
> > > >> wrote:
> > > >> >
> > > >> > I'm +1 for any solution :)
> > > >> > I can ask INFRA if we can use Jenkins :)
> > > >> >
> > > >> > On Thu, 13 Jan 2022 at 02:47, Martin Grigorov <
> mgrigo...@apache.org>
> > > >> wrote:
> > > >> > >
> > > >> > > Shall we move to Github Actions ?
> > > >>
> > > >> Are you familiar with "Github Actions"
> > > >> Maybe you can set it up and we will see how it will suit our needs
> :)
> > > >>
> > > >
> > > > No problemo! :-)
> > > >
> > > >
> > > >>
> > > >> > > TravisCI degrades day by day :-(
> > > >> > > CircleCI is also a very good alternative!
> > > >> > >
> > > >> > > On Wed, Jan 12, 2022 at 6:52 PM Maxim Solodovnik <
> > > >> solomax...@gmail.com>
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Hello All,
> > > >> > > >
> > > >> > > > Maybe you know what is the current status of CI for
> wicketstuff
> > > >> > > >
> > > >> > > > I was unable to find latest snapshot
> > > >> > > > And the job at travis-ci.com :(
> > > >> > > >
> > > >> > > > from mobile (sorry for typos ;)
> > > >> > > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Best regards,
> > > >> > Maxim
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Best regards,
> > > >> Maxim
> > > >>
> > > >
> > >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
>
>
>
> --
> Best regards,
> Maxim
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: CI for wicketstuff

[Martijn Dashorst]

IIRC all our secrets are in the wicket-pmc's private repository. I'm trying
to find the coordinates but I am unable to find them.

Martijn


On Fri, Jan 14, 2022 at 10:55 PM Martin Grigorov 
wrote:

> I've merged the PR!
>
> But it failed because there are no env vars/secrets for deploying to
> oss.sonatype.org
> Travis was using
>
> https://github.com/wicketstuff/core/blob/b3f84bb0f49f1ebee8eec5100cb31b22176d5a4b/.travis.yml#L22-L26
> If anyone knows what were those credentials then please set them up at
> https://github.com/wicketstuff/core/settings/secrets/actions with names
> CI_DEPLOY_USERNAME and CI_DEPLOY_PASSWORD (
>
> https://github.com/wicketstuff/core/blob/b3f84bb0f49f1ebee8eec5100cb31b22176d5a4b/.github/workflows/ci.yml#L54-L56
> )
> Otherwise we could run just 'mvn verify'
>
> On Fri, Jan 14, 2022 at 9:51 AM Martin Grigorov 
> wrote:
>
> >
> >
> > On Fri, Jan 14, 2022 at 9:32 AM Maxim Solodovnik 
> > wrote:
> >
> >> On Thu, 13 Jan 2022 at 10:29, Maxim Solodovnik 
> >> wrote:
> >> >
> >> > I'm +1 for any solution :)
> >> > I can ask INFRA if we can use Jenkins :)
> >> >
> >> > On Thu, 13 Jan 2022 at 02:47, Martin Grigorov 
> >> wrote:
> >> > >
> >> > > Shall we move to Github Actions ?
> >>
> >> Are you familiar with "Github Actions"
> >> Maybe you can set it up and we will see how it will suit our needs :)
> >>
> >
> > No problemo! :-)
> >
> >
> >>
> >> > > TravisCI degrades day by day :-(
> >> > > CircleCI is also a very good alternative!
> >> > >
> >> > > On Wed, Jan 12, 2022 at 6:52 PM Maxim Solodovnik <
> >> solomax...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Hello All,
> >> > > >
> >> > > > Maybe you know what is the current status of CI for wicketstuff
> >> > > >
> >> > > > I was unable to find latest snapshot
> >> > > > And the job at travis-ci.com :(
> >> > > >
> >> > > > from mobile (sorry for typos ;)
> >> > > >
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> > Maxim
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Maxim
> >>
> >
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Interesting talk for publishing refactorings

[Martijn Dashorst]

https://www.crowdcast.io/e/oct19
-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Fun poll for the Wicket twitter account

[Martijn Dashorst]

@Julien HENRY 

If you issue a return statement in a page constructor before the components
are added, what happens?

1. the page renders normally
2. exception because missing components

Now for the answer: typically 2 is correct. But that got me thinking of all
the ways you can have 1 as a result (this would be a great list for a
twitter thread)

a. the components were added in a super-class constructor
b. the components were added in a sub-class constructor
c. the components were added in an onInitialize
d. the components were added in an onConfigure
e. the components were added in an onBeforeRender
f. the components were added using a Behavior (bad choice, but possible)
g. the page is invisible
h. the container that the components were added to is invisbile
i. the components are added in an IComponentInstantiationListener
j. the wicket:id's were escaped in the markup (e.g. awicket:id="...")
k. the components are added in an onInitialize of a child component (added
before the return, adding in child's constructor would fail because parent
is not know yet)
l. a custom RequestCycle adds the missing components in handleException, or
a IRequestCycleListener, or an IRequestHandler and restarts rendering (is
that necessary?)
m. an IComponentResolver creates the missing component(s) (not 100% sure
this works)

Perhaps others can find insidious ways of adding components to a page?

I think this would be quite a nice poll on twitter.

Martijn

Rails 7 features

[Martijn Dashorst]

https://world.hey.com/dhh/rails-7-will-have-three-great-answers-to-javascript-in-2021-8d68191b

Somehow I think that a couple of these features would be a great fit for
Wicket.

But I don't know if they are easy or neigh impossible to implement.

Martijn

Re: Wicket 10 ideas

[Martijn Dashorst]

*➜  **git:(**master**)* git grep "wicket:enclosure" | wc -l

 804

*➜  **git:(**master**)* git grep "wicket:container" | wc -l

 369

0 uses of queue(

Roughly 800 pages.

Martijn


On Mon, May 17, 2021 at 11:40 AM Tobias Gierke 
wrote:

> Hi,
> > We do not use enclosures or component queueing either.
> FWIW, we heavily use both enclosures and component queueing in a very
> large Wicket application (>350 pages) - please keep those features.
>
> Cheers,
> Tobias
>
> >
> > -Matt Pavlovich
> >
> >> On Apr 24, 2021, at 3:56 PM, Francois Meillet <
> francois.meil...@gmail.com> wrote:
> >>
> >> I don't use enclosures and component queueing
> >>
> >> Kind regards,
> >> François
> >>
> >>
> >>
> >>> Le 24 avr. 2021 à 20:52, Ernesto Reinaldo Barreiro 
> a écrit :
> >>>
> >>> Hi,
> >>>
> >>> On Sat, Apr 24, 2021 at 2:13 PM Tobias Soloschenko
> >>>  tobiassolosche...@googlemail.com.invalid>> wrote:
> >>>
>  Hi everyone,
> 
>  from my side I also would prefer removing component queuing (+1),
>  enclosures I would prefer a rework and not to remove it (+0).
> 
>  In addition to Martin’s list I would add some points
> 
>  — Martin's list —
>  4) Move wicket-http2-servlet4 into core and remove wicket-http2-jetty
> /
>  wicket-http2-tomcat / wicket-http2-undertow / wicket-http2-core (I
> would
>  prefer doing it in 10 over 9)
>  5) May remove wicket-metrics (I have the feeling that this is used
> rarely
>  over other reporting frameworks)
> 
> >>> I have the impression the practice before "always" was to move things
> to
> >>> wicket-stuff once they were no longer supported as core features. E.g.
> >>> things like treetables and so on. Correct?
> >>>
> >>>
>  kind regards
> 
>  Tobias
> 
> > Am 24.04.2021 um 11:07 schrieb Korbinian Bachl <
>  korbinian.ba...@whiskyworld.de>:
> > Hi,
> >
> > we dont use queueing but we use enclosures in quite a few places.
>  Getting rid of it would mean we have to switch to markup containers
> holding
>  the content and add additonal layer of complexity and boilerplatecode
> for
>  us.
> > Beside that: can wicket 10 finally get rid of jQuery? Since IE is now
>  definitely dead I dont see any reason why this is still needed
> > Best,
> > KB
> >
> >
> > - Ursprüngliche Mail -
> >> Von: "Ernesto Reinaldo Barreiro"
> >> An: dev@wicket.apache.org
> >> Gesendet: Freitag, 23. April 2021 12:04:34
> >> Betreff: Re: Wicket 10 ideas
> >> Hi,
> >>
> >> On Fri, Apr 23, 2021 at 11:58 AM Sven Meier  wrote:
> >>
> >>> x) remove/rework enclosures and component queueing.
> >>>
> >> It would be interesting to know how many people really use queuing
> >>
> >>
> >>> Have fun
> >>> Sven
> >>>
> >>>
> >>> On 02.04.21 13:58, Martin Grigorov wrote:
>  Hi,
> 
>  Now since we have 9.3.0 released is it time to start
> thinking/working
>  on
>  Wicket 10 ?
> 
>  Here are few ideas what to break :-)
> 
>  1) Move to Servlet 5.x, i.e. jakarta.servlet.**
>  2) Use @Inject + @Named instead of @SpringBean. If everything is
>  covered
>  by @Inject we may deprecate @SpringBean in 9.x
>  3) Depending on the release date we may even bump Java to 17 (it
> is
>  going
>  to be released this September and it is going to be LTS). I expect
>  Wicket
>  10.0.0 to be released in 1-2 years from now, so by this time Java
> 17
> >>> should
>  be mainstream! :-) I know that this is too brave. Most projects
> still
>  use
>  Java 8 for some reason.
> 
>  Regards,
>  Martin
> 
> >>
> >> --
> >> Regards - Ernesto Reinaldo Barreiro
> 
> >>> --
> >>> Regards - Ernesto Reinaldo Barreiro
>
> --
> Tobias Gierke
> Software Developer
>
> Voipfuture GmbH   Wendenstr. 4   20097 Hamburg   Germany
> Phone +49 40 688 9001 64   Fax +49 40 688 9001 99
> Managing Directors   Jan Bastian   Eyal Ullert
> Commercial Court AG Hamburg   HRB 109896   VAT ID DE263738086
>
>
>

-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Flush request before detach

[Martijn Dashorst]

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

Re: Migration of jenkins.a.o to cloudbees

[Martijn Dashorst]

Good, then we're all set :D

Lot's of work done...

Martijn


On Fri, Aug 14, 2020 at 2:41 PM Andrea Del Bene 
wrote:

> Yep! We still rely on Buildbot
>
> On Fri, Aug 14, 2020 at 2:39 PM Maxim Solodovnik 
> wrote:
>
> > AFAIK wicket doesn't use Jenkins
> >
> > On Fri, 14 Aug 2020 at 19:37, Martijn Dashorst <
> martijn.dasho...@gmail.com
> > >
> > wrote:
> >
> > > Is this something we are aware of, and is this done?
> > >
> > > > Tomorrow is the deadline for migrating to ci-builds.a.o and for
> > > builds.a.o to be turned off.
> > >
> > > A script to move builds from one to the other:
> > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/INFRA/Migrating+Jenkins+jobs+from+Jenkins+to+Cloudbees
> > >
> > > Martijn
> > >
> >
> >
> > --
> > Best regards,
> > Maxim
> >
>
>
> --
> Andrea Del Bene.
> Apache Wicket committer.
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Migration of jenkins.a.o to cloudbees

[Martijn Dashorst]

Is this something we are aware of, and is this done?

> Tomorrow is the deadline for migrating to ci-builds.a.o and for
builds.a.o to be turned off.

A script to move builds from one to the other:

https://cwiki.apache.org/confluence/display/INFRA/Migrating+Jenkins+jobs+from+Jenkins+to+Cloudbees

Martijn

Re: [VOTE] Release Apache Wicket 9.0.0

[Martijn Dashorst]

Is your github page still the actual site page?

Martijn

On Tue, Jul 14, 2020 at 12:40 PM Andrea Del Bene 
wrote:

> I think we have all set and done to go ahead with the release. Maybe
> Martijn
> has something left to do on for the site.
>
> On Tue, Jul 14, 2020 at 10:37 AM Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > I'm sorry not to be able to cast a vote: I kept for a few months a branch
> > of our main application in synchrony with 9.x milestones but after so
> much
> > delay and pressure from our project I gave up. As soon as 9.0 is out, and
> > our internal schedule allows it, I will migrate our project to 9.0 and
> > provide feedback for further 9.x. releases.
> >
> > On Tue, Jul 14, 2020 at 10:24 AM Martijn Dashorst <
> > martijn.dasho...@gmail.com> wrote:
> >
> > > On Mon, Jul 13, 2020 at 10:55 AM Sven Meier  wrote:
> > >
> > > > +1
> > > >
> > > > tested examples and checked sha.
> > > >
> > > > Regarding the FilePageStore NullPointerException:
> > > > It seems UserDefinedFileAttributeView is not available on Os X.
> > > > IMHO we can fix this later.
> > > >
> > >
> > > The NPE is a result of me breaking off the build (CTRL-C) I think.
> > However,
> > > if others are able to build the package I'm fine with releasing it.
> > >
> > > Martijn
> > >
> >
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
> >
>
>
> --
> Andrea Del Bene.
> Apache Wicket committer.
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: [VOTE] Release Apache Wicket 9.0.0

[Martijn Dashorst]

On Mon, Jul 13, 2020 at 10:55 AM Sven Meier  wrote:

> +1
>
> tested examples and checked sha.
>
> Regarding the FilePageStore NullPointerException:
> It seems UserDefinedFileAttributeView is not available on Os X.
> IMHO we can fix this later.
>

The NPE is a result of me breaking off the build (CTRL-C) I think. However,
if others are able to build the package I'm fine with releasing it.

Martijn

Re: [VOTE] Release Apache Wicket 9.0.0

[Martijn Dashorst]

-0

I am unable to build the tar.gz on my mac (Mojave) as the build stalls on
FilePageStoreTest

$ java -version
openjdk version "11.0.7" 2020-04-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.7+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.7+10, mixed mode)

[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.026 s - in org.apache.wicket.stateless.StatelessComponentTest
[INFO] Running org.apache.wicket.stateless.StatelessFormTest
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.073 s - in org.apache.wicket.stateless.StatelessFormTest
[INFO] Running org.apache.wicket.stateless.StatelessPageWithFeedbackTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.029 s - in org.apache.wicket.stateless.StatelessPageWithFeedbackTest
[INFO] Running org.apache.wicket.stateless.TemporarySessionTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.011 s - in org.apache.wicket.stateless.TemporarySessionTest
[INFO] Running org.apache.wicket.stateless.StatelessDynmicLinksTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.008 s - in org.apache.wicket.stateless.StatelessDynmicLinksTest
[INFO] Running org.apache.wicket.stateless.pages.StatelessFormTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.006 s - in org.apache.wicket.stateless.pages.StatelessFormTest
[INFO] Running org.apache.wicket.stateless.pages.RefreshStatelessPageTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.003 s - in org.apache.wicket.stateless.pages.RefreshStatelessPageTest
[INFO] Running org.apache.wicket.pageStore.InSessionPageStoreTest
[INFO] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.003 s - in org.apache.wicket.pageStore.InSessionPageStoreTest
[INFO] Running org.apache.wicket.pageStore.SerializingPageStoreTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.002 s - in org.apache.wicket.pageStore.SerializingPageStoreTest
[INFO] Running org.apache.wicket.pageStore.FilePageStoreTest
Exception in thread "Wicket-AsyncPageStore-PageSavingThread"
java.lang.NullPointerException
at
org.apache.wicket.pageStore.FilePageStore.setPageType(FilePageStore.java:328)
at
org.apache.wicket.pageStore.FilePageStore.writeFile(FilePageStore.java:205)
at
org.apache.wicket.pageStore.FilePageStore.addPersistedPage(FilePageStore.java:178)
at
org.apache.wicket.pageStore.AbstractPersistentPageStore.addPage(AbstractPersistentPageStore.java:128)
at
org.apache.wicket.pageStore.AsynchronousPageStore$PageAddingRunnable.run(AsynchronousPageStore.java:278)
at java.base/java.lang.Thread.run(Thread.java:834)


On Sun, Jul 12, 2020 at 10:04 PM Andrea Del Bene 
wrote:

> +1 Tested my main application.
>
> On 12/07/20 01:05, Martin Grigorov wrote:
> > On Sat, Jul 11, 2020, 13:08 Andrea Del Bene 
> wrote:
> >
> >> I've found an issue with module wicket-objectsizeof-agent. Its pom
> >> contains a pluginManagement section that overrides the original
> >> configuration contained in the parent pom which sets the manifest entry
> >> 'Automatic-Module-Name'. Long story short, the default module name for
> >> wicket-objectsizeof-agent is 'org.apache.wicket.objectsizeof-agent'
> >> instead of 'org.apache.wicket.objectsizeof.agent' and maven javadoc
> >> plugin complains about it:
> >>
> >> [INFO] [ [1;31mERROR [m] MavenReportException: Error while generating
> >> Javadoc:
> >> [INFO] Exit code: 1 - error: cannot determine module name for
> >>
> >>
> /home/andrea/WicketBuild/wicket/target/checkout/wicket-objectsizeof-agent/target/wicket-objectsizeof-agent-9.0.0.jar
> >> [INFO]
> >> [INFO] Command line was:
> >> /usr/lib/jvm/adoptopenjdk-11-hotspot-amd64/bin/javadoc -J-Xmx256m
> >> -J-Xms128m --no-module-directories @options @packages
> >> [INFO]
> >> [INFO] Refer to the generated Javadoc files in
> >>
> '/home/andrea/WicketBuild/wicket/target/checkout/wicket-objectsizeof-agent/target/apidocs'
> >>
> >> dir.
> >> [INFO]
> >>
> >> It's a trivial problem but I'm afraid that solving it means somehow
> >> 'breaking' the current APIs contract, if we consider module's name an
> API.
> >>
> >> I think we need to restart a new vote.
> >>
> > I think the module is not usable due to this bug, so no one can depend on
> > it in JPMS.
> > IMO it is not a stopper.
> >
> >
> >> On 10/07/20 08:31, Martin Grigorov wrote:
> >>> +1 to release
> >>>
> >>> Tested:
> >>> - build from source
> >>> - browser various Wicket Examples
> >>> - the applications I use for Wicket trainings
> >>>
> >>> On Wed, Jul 8, 2020 at 1:25 PM Andrea Del Bene 
> >> wrote:
>  This is a vote to release Apache Wicket 9.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 9.0.0
>  [ ] No, 

Re: [ANNOUNCE] New Committer - Thomas Heigl

[Martijn Dashorst]

Welcome to the team!

Martijn


On Fri, May 22, 2020 at 9:08 PM Andrea Del Bene 
wrote:

> The Apache Wicket team is happy to announce that Thomas Heigl has been
> voted in as a committer on Apache Wicket and also as a PMC member of the
> project! Thomas is an active member of the Wicket community since 2011
> and lately has greatly contributed fixing bugs and providing ideas and
> pull requests to improve Wicket performance.
>
> We're looking forward to working with Thomas in the near future, so
> please join us in welcoming him to our project!
>
> Andrea Del Bene
> Apache Wicket PMC chair.
>
>

-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: ConcurrentHashSet to be removed from wicket code base

[Martijn Dashorst]

IIRC Micromap was created for serialization and memory efficiency. Has that
changed?

Martijn

On Wed, May 6, 2020 at 2:18 PM Maxim Solodovnik 
wrote:

> MicroMap can easily be replaced with Map.of(key, value)
>
> I can deprecate it for wicket9 in same PR, should I?
>
> On Wed, 6 May 2020 at 18:06, Maxim Solodovnik 
> wrote:
>
> > I would propose to remove it in Wicket9, but don't want to slow down the
> > release :)
> > Will create PR :)
> >
> > On Wed, 6 May 2020 at 17:56, Andrea Del Bene 
> wrote:
> >
> >> +1 to replace it with ConcurrentHashMap.newKeySet()
> >>
> >> On 06/05/20 12:53, Martijn Dashorst wrote:
> >> > I'd go further and deprecate it in wicket 8 as well... Since the
> >> > replacement is in Java 8.
> >> >
> >> > I would be +1 on removing it from Wicket 9 final if it came to a vote.
> >> It
> >> > is not a core class in Wicket, it was not supposed to be used widely
> >> > (mostly for our internal stuff), and would make it clear that when in
> >> > doubt: use the JDK provided one.
> >> >
> >> > Martijn
> >> >
> >> >
> >> > On Wed, May 6, 2020 at 12:36 PM Martin Grigorov  >
> >> > wrote:
> >> >
> >> >> On Wed, May 6, 2020 at 1:20 PM Maxim Solodovnik <
> solomax...@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> Hello All,
> >> >>>
> >> >>> ConcurrentHashSet can be safely removed from wicket codebase due to
> >> >>> since Java8 it is possible to use ConcurrentHashMap.newKeySet()
> >> >>>
> >> >>> Can we @deprecate in in wicket9 and remove in Wicket10?
> >> >>>
> >> >> +1
> >> >>
> >> >>
> >> >>> --
> >> >>> Best regards,
> >> >>> Maxim
> >> >>>
> >> >
> >>
> >
> >
> > --
> > Best regards,
> > Maxim
> >
>
>
> --
> Best regards,
> Maxim
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: ConcurrentHashSet to be removed from wicket code base

[Martijn Dashorst]

I'd go further and deprecate it in wicket 8 as well... Since the
replacement is in Java 8.

I would be +1 on removing it from Wicket 9 final if it came to a vote. It
is not a core class in Wicket, it was not supposed to be used widely
(mostly for our internal stuff), and would make it clear that when in
doubt: use the JDK provided one.

Martijn


On Wed, May 6, 2020 at 12:36 PM Martin Grigorov 
wrote:

> On Wed, May 6, 2020 at 1:20 PM Maxim Solodovnik 
> wrote:
>
> > Hello All,
> >
> > ConcurrentHashSet can be safely removed from wicket codebase due to
> > since Java8 it is possible to use ConcurrentHashMap.newKeySet()
> >
> > Can we @deprecate in in wicket9 and remove in Wicket10?
> >
>
> +1
>
>
> >
> > --
> > Best regards,
> > Maxim
> >
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

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

[Martijn Dashorst]

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.

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

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

[Martijn Dashorst]

On Wed, Feb 26, 2020 at 11:15 AM Emond Papegaaij 
wrote:

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

As long as the default behavior is specified in the Wicket core css file,
I'm for it. .wicket--color-red is godawful so +1 for making it meaningful.

IMO this means that we should move the styling of e.g. the feedback panel
[1] into the wicket-- fold. However, that is not something that is related
to CSP, so CSP should not be the driver (nor wait) for that.


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

AFAIR the extra request is normally not a problem as browsers multiplex
that on the HTTP/2 connection to the server, and the CSS is easily cached.
It might actually be a worse experience to inline the style than having it
as a separate resource.

Martijn

[1]
https://github.com/apache/wicket/blob/master/wicket-core/src/test/java/org/apache/wicket/markup/html/panel/FeedbackPanelTest_cssClasses_expected.html

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

[Martijn Dashorst]

On Tue, Feb 25, 2020 at 9:54 PM Sven Meier  wrote:

> [] leave as is with .wicket--hidden & wicket-core.css
>
> [] use HTML5 "hidden" attribute instead
>

While it is true that Wicket hasn't depended on a CSS file for its own use,
it has been dependent on its own styles, spread out through our code in odd
ways. The fact that we now have to own up to this by having to ship a
stylesheet file of our own after 15 years, sounds more like 15 years of
neglect and harassment of our users than an actual achievement. I consider
not having a wicket stylesheet file a bug, not a feature.

Having an actual Wicket css file means that our styles are *finally*
documented and available for our users to accommodate, rather than strewn
out through our code base and hidden in style attributes, only to be
discovered through perusing the generated markup or ample browsing through
java code. This is a great benefit: want to know what Wicket uses for
styling? Here's the file!

Furthermore, the wicket-core css file can be easily disabled if one desires
so (then you have add your own implementations of those classes to your own
css file), or overridden (e.g. wicket-bootstrap can provide its own core
css file). And we provide the default template as well...

This doesn't mean that I want us to ship a full bootstrap/material like CSS
styling with Wicket, but rather only those parts that ensure that
applications keep working.

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. Telling folks to
'just add some arbitrary css to your styling to fix this attribute so some
parts of your page remain invisible', is not a suitable substitute for
providing our own css.

Martijn

[1] https://meowni.ca/hidden.is.a.lie.html

Re: CSP in Wicket 9

[Martijn Dashorst]

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

Live examples need updating

[Martijn Dashorst]

Hi!

A coworker told me that there's no example for ModalDialog, however,
the code is available. I went to look at our live examples, and there
are no live examples (yet?) for 9.x? And the version that is deployed
for 8.x is 8.4.0-SNAPSHOT. Which seem old given that we have 8.7.0 out
and about.

Now I don't know our infrastructure to update the examples and create
a new environment for 9.x examples, but I think it would be great to
show off our live examples even for master.

http://examples8x.wicket.apache.org/index.html -> 8.4.0-SNAPSHOT

http://examples9x.wicket.apache.org/index.html -> 404

Also, I noticed that the examples all run on http... Perhaps we should
move to https for them as well?

Martijn

Re: Jakarta EE 8 vs Java EE 8 APIs

[Martijn Dashorst]

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

Re: Jakarta EE 8 vs Java EE 8 APIs

[Martijn Dashorst]

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

Re: New Wicket Team Member: Ernesto Reinaldo Barreiro!

[Martijn Dashorst]

Woop woop!!!

Welcome Ernesto!

Martijn

On Wed, Aug 21, 2019 at 11:36 AM Andrea Del Bene  wrote:
>
> The Project Management Committee (PMC) for Apache Wicket has asked Ernesto
> Reinaldo Barreiro to become a team member and we are pleased to announce
> that he has accepted.
>
> Ernesto is a long-time Wicket contributor and user and fully deserves an
> active role in shaping
> the future of the framework.
>
> Welcome Ernesto!
> --
> Andrea Del Bene.
> Apache Wicket committer.



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Jakarta EE & javax.* namespace

[Martijn Dashorst]

All,

Last week Oracle and the Eclipse Foundation shared that they were
unable to reach an amicable agreement on the use of javax.* packages
by the Jakarta EE project.

The Jakarta EE project is the continuation of the Java EE
specifications board and would be responsible for publishing the Java
EE specifications in the future. With this disagreement, they have
stated that going forward, no changes are allowed in the javax.*
namespace and that any such modifications (and additions) should go
into jakarta.*

Today this does not have any influence on us, but in the near future
this will affect us an dwe should prepare plans for how to integrate
properly in the new world. This is of course mightily dependent on how
the Jakarta Servlet group intends to go forward and what their release
schedule is.

Does anyone have insight into the Jakarta Servlet group?
(https://projects.eclipse.org/projects/ee4j.servlet)

Martijn

Re: Remove from the user guide ?

[Martijn Dashorst]

On Wed, Jan 23, 2019 at 11:52 AM Martijn Dashorst
 wrote:
>
> On Wed, Jan 23, 2019 at 4:48 AM Maxim Solodovnik  wrote:
> >
> > +1 to make it deprecated and correct the documentation
> > I'm also OK with removing it in 9.0.0, I believe there is enough time to
> > fix 9.0.0 applications :)
>
> I'd rather not remove it in 9 (nor 10+). The solution to fix this in
> applications is non-trivial, and removing the feature will break apps
> considerably and silently.

635 occurrences of 

Re: Future releases and random thoughts

[Martijn Dashorst]

Related:

https://reproducible-builds.org/docs/jvm/

Interesting reading, and makes maven builds reproducible (when using
the maven plugin)

Martijn

On Sun, Jan 20, 2019 at 8:49 PM Andrea Del Bene  wrote:
>
> Hi,
>
> I think it's time to share some ideas about future releases and
> developments. Here we go:
>
> - Wicket 8 and 7:  I see we have a decent amount of changes targeted for
> 8.3
> (https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561=12344559).
> This is not the case for version 7.x, which doesn't have yet many issues
> solved for the next version 7.11.0
> (https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561=12344758).
> Should we consider to release 8.3 and 7.11.0 or do you think we'd better
> wait for the 7.x version to reach a "critical mass" of changes?
>
> - Wicket 9: after we close "Wicket-6563 page store implementation"
> (https://github.com/apache/wicket/pull/283) I think we could consider to
> release the first milestone for Wicket 9. Sounds good to you?
>
> Speaking of future developments for Wicket 9, I've got (so far) a couple
> of nice-to-have:
>
> - Use Java modularization (project Jigsaw): we should work to fully
> embrace the new modularization framework. If I remember correctly Martin
> has done some work with automatic modules but I can't find the exact
> commit at the moment.
>
> - Dismiss utility classes Time and Duration: Wicket still heavily use a
> couple of classes from package org.apache.wicket.util.time: Time and
> Duration. These classes are virtually equivalent to java.time.Instant
> and java.time.Duration. I'm aware that this is not a trivial task and
> it's quite delicate, but I'd really like to not depend on custom code
> for tasks like time and dates that are well supported by Java. For those
> who are interested I've started to make some experiment with this task
> and the results are very encouraging as most of the changes are in-place
> replacements of the old classes with the standard entities. You can find
> the code here: https://github.com/bitstorm/wicket/tree/remove-time-utils
>
> That's all, let me know what do you think!
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Wicket site with adblocker @ MS Edge

[Martijn Dashorst]

My guess is that if a web font from same origin is blocked, JavaScript
will fail as well.

Martijn

On Tue, Jan 22, 2019 at 12:25 PM Maxim Solodovnik  wrote:
>
> Maybe something like this
>
> https://stackoverflow.com/questions/1271477/changing-body-font-size-based-on-font-family-with-jquery
>
> can be used?
>
> On Tue, 22 Jan 2019 at 17:27, Andrea Del Bene  wrote:
>
> > I've checked uBlock with Firefox and AdBlocker with Chrome, both with
> > default configs, and I see no problem. Obviously IE/Edge always behaves in
> > its own, peculiar way :-).
> >
> > On Tue, Jan 22, 2019 at 11:12 AM Martijn Dashorst <
> > martijn.dasho...@gmail.com> wrote:
> >
> > > Well, we did everything well: the fonts are hosted at Apache, not
> > > loaded from external site that tracks their usage (looking at you
> > > fonts.google.com), the SVG even embeds the font file in a data uri. If
> > > the adblocker then still blocks the font, what can we do? Introduce a
> > > 4MB PNG file? Or should the adblocker at least honor same domain
> > > requests for resources and not block data URI's?
> > >
> > > The font face used for the logo is narrow and there are no web-safe
> > > fonts that render correctly in this instance: I've tried with Arial
> > > Narrow and sans-serif as a fallback: the logo still looks badly
> > > broken.
> > >
> > > AFAIK we can't detect whether someone uses an adblocker that
> > > specifically blocks web fonts, serve them the 8GB binary images, and
> > > serve the rest of the world the 80kb SVG file.
> > >
> > > I understand the need for an adblocker, but when you use one (wrongly)
> > > you are responsible for when shit breaks.
> > >
> > > Martijn
> > >
> > >
> > > On Tue, Jan 22, 2019 at 9:46 AM Vit Rozkovec 
> > > wrote:
> > > >
> > > > HI,
> > > >
> > > > please see this screenshot:
> > > > https://screenshots.firefox.com/v4PQv7WIKAv1TiUA/null
> > > >
> > > > This is how is the site visible when you browse it with adblock that
> > > > blocks also some fonts.
> > > >
> > > > Discovered when one my colleague who is learning Wicket and uses
> > Windows
> > > > wanted to show it to someone else, not a very good first impression :)
> > > >
> > > > I think it would be good to have a default that displays ok even when
> > > > fonts are blocked, what do you think?
> > > >
> > > > Have a nice day
> > > > Vit
> > > >
> > >
> > >
> > > --
> > > Become a Wicket expert, learn from the best: http://wicketinaction.com
> > >
> >
> >
> > --
> > Andrea Del Bene.
> > Apache Wicket committer.
> >
>
>
> --
> WBR
> Maxim aka solomax



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Wicket site with adblocker @ MS Edge

[Martijn Dashorst]

Well, we did everything well: the fonts are hosted at Apache, not
loaded from external site that tracks their usage (looking at you
fonts.google.com), the SVG even embeds the font file in a data uri. If
the adblocker then still blocks the font, what can we do? Introduce a
4MB PNG file? Or should the adblocker at least honor same domain
requests for resources and not block data URI's?

The font face used for the logo is narrow and there are no web-safe
fonts that render correctly in this instance: I've tried with Arial
Narrow and sans-serif as a fallback: the logo still looks badly
broken.

AFAIK we can't detect whether someone uses an adblocker that
specifically blocks web fonts, serve them the 8GB binary images, and
serve the rest of the world the 80kb SVG file.

I understand the need for an adblocker, but when you use one (wrongly)
you are responsible for when shit breaks.

Martijn


On Tue, Jan 22, 2019 at 9:46 AM Vit Rozkovec  wrote:
>
> HI,
>
> please see this screenshot:
> https://screenshots.firefox.com/v4PQv7WIKAv1TiUA/null
>
> This is how is the site visible when you browse it with adblock that
> blocks also some fonts.
>
> Discovered when one my colleague who is learning Wicket and uses Windows
> wanted to show it to someone else, not a very good first impression :)
>
> I think it would be good to have a default that displays ok even when
> fonts are blocked, what do you think?
>
> Have a nice day
> Vit
>


--
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Future releases and random thoughts

[Martijn Dashorst]

On Mon, Jan 21, 2019 at 9:25 AM Martin Grigorov  wrote:
> > Speaking of future developments for Wicket 9, I've got (so far) a couple
> > of nice-to-have:
> >
> > - Use Java modularization (project Jigsaw): we should work to fully
> > embrace the new modularization framework. If I remember correctly Martin
> > has done some work with automatic modules but I can't find the exact
> > commit at the moment.
> >
>
> I cannot find it either! Somehow it got lost!
> http://branchandbound.net/blog/java/2017/12/automatic-module-name/ - this
> article explains the required changes.
>
> But apart from this minimal change I am not sure we should go fully Jigsaw.
> Many libraries still do not support Java 9 modules -
> https://blog.frankel.ch/hard-look-state-java-modularization/
> Servlet specification is not updated to make use of Jigsaw and the web
> containers do not make use of it.

Yup, I'm not sure modularization should currently be our main focus.
When Java EE supports it, we can follow suit.

> > - Dismiss utility classes Time and Duration: Wicket still heavily use a
> > couple of classes from package org.apache.wicket.util.time: Time and
> > Duration. These classes are virtually equivalent to java.time.Instant
> > and java.time.Duration. I'm aware that this is not a trivial task and
> > it's quite delicate, but I'd really like to not depend on custom code
> > for tasks like time and dates that are well supported by Java. For those
> > who are interested I've started to make some experiment with this task
> > and the results are very encouraging as most of the changes are in-place
> > replacements of the old classes with the standard entities. You can find
> > the code here: https://github.com/bitstorm/wicket/tree/remove-time-utils
>
>
> +1 if the migratiin is easy
> The Wicket classes should stay as deprecated for the lifetime of 9.x though

I'm not directly opposed to deprecating them in 8.x (though we are at
8.3 soon, so might be a tad late for deprecation) and removing in 9.0
(or making them module private :-D)

Martijn

Re: Wicket HTML5 compliancy?

[Martijn Dashorst]

Wicket's markup strategy is garbage in, garbage out. If you don't make
your components' and pages' markup HTML5 compliant, then Wicket can't
do anything about that.

It might be that 3rd party or components from Wicket core are not
HTML5 compliant. We gladly accept patches that fix HTML5 compliancy,
and won't mess up CSS styling for our thousands of users.

So a HTML 5 validator might complain that a  can't be in a ,
but if we 'fix' that by making the  into a , to satisfy the
validator, we will break all CSS rules that assums ...

In short: in principle Wicket doesn't require, prescribe or prevent
HTML5 compliancy. It is what you make of it.

Also, we use(d) a HTML5 validator filter in our project that would
validate the markup sent to the browser on the server side. Due to the
rewrites of the HTML parser the project became stale, but I'd love to
see it updated and revitalized.

https://github.com/dashorst/wicket-stuff-markup-validator

Martijn

On Mon, Jan 21, 2019 at 10:22 AM Rob Audenaerde
 wrote:
>
> Hi all,
>
> I'm trying to answer the question for one of our clients, that is, if the
> application we made using Wicket is HTML5 compliant.
>
> I have two questions:
>
> 1. Should Wicket adhere strictly to the standard?
> 2. What do you think would be a good approach for testing this?
>
> Let me describe what I did so far:
>
> I interpreted this question for myself as: is the HTML output of Wicket
> valid HTML5?
>
> I do this by validating the HTML ouput of some pages of the application
> with the https://validator.w3.org/nu. I get a list of warnings, which might
> be solved by how Wicket generates HTML and some that might be solved by how
> we implemented some detail.
>
> I also validated a wicket-examples page, I just took the first ajax-example:
>
> https://validator.w3.org/nu/?doc=http%3A%2F%2Fexamples8x.wicket.apache.org%2Fajax%2Fautocomplete
>
> As you can see from opening this URL, there are some warnings and some
> errors
>
> I don't see any problem with the examples *working*, so browsers probably
> don't care too much, and maybe this is a bit of a non-issue.
>
> WDYT?
>
> Kind regards,
> Rob Audenaerde



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

A new chair for Apache Wicket

[Martijn Dashorst]

All,

This is mostly Apache internal, but quite notable: after almost 11
years of serving as the chair for Apache Wicket, I decided to step
down and make room for a new member of our community to be the bridge
between our project and the Apache Board.

I am happy to announce that Andrea Del Bene is now our chair and wish
him well in providing timely and correct reports to the board, and
communicating back the Board's wishes.

In our discussions on how to proceed with our chair role, we also
decided to rotate the chair each year, to make it more palatable to
serve as chair (as your commitment only is for one year ahead). Of
course, if life happens, it is quite easy to change roles midterm, but
rotating the position seems like a good idea going forward.

Good luck Andrea!

Martijn

Re: Tumblr carroussel works again...

[Martijn Dashorst]

We do have to take care to upload a new tumblr.json every now and then.

Martijn

On Mon, Jan 7, 2019 at 10:19 AM Martin Grigorov  wrote:
>
> On Mon, Jan 7, 2019 at 11:14 AM Martijn Dashorst 
> wrote:
>
> > Ah,
> >
> > Thanks for noticing that! The tumblr gives back a jsonp (var tumbl =
> >  ;), so I removed the 'var tumbl = ' bit, but neglected to remove
> > the trailing semi colon
> >
> > Should be fixed now!
> >
>
> Now it does! :-)
>
>
> >
> > Martijn
> >
> > On Mon, Jan 7, 2019 at 9:43 AM Martin Grigorov 
> > wrote:
> > >
> > > For me it does not work both in Chrome and Firefox.
> > >
> > > The debugger does not stop at
> > > $.getJSON('https://dashorst.github.io/built-with-wicket/tumblr.json
> > ',
> > > function(response) {
> > > var posts = response.posts;  // HERE
> > >
> > > otherwise the XHR response has these headers:
> > > content-encoding: gzip
> > > content-length: 7267
> > > content-type: application/json; charset=utf-8
> > > and there is a JSON body
> > >
> > > Pasting the body in https://codebeautify.org/jsonviewer said that the
> > > trailing ';' ("tags":["wicket-6","submission"]}]};) causes the
> > problem
> > >
> > > On Mon, Jan 7, 2019 at 10:32 AM Martijn Dashorst <
> > martijn.dasho...@gmail.com>
> > > wrote:
> > >
> > > > Private browser window does show the carrousel for me...
> > > >
> > > > Martijn
> > > >
> > > > Op ma 7 jan. 2019 om 08:36 schreef Martin Grigorov <
> > mgrigo...@apache.org>
> > > >
> > > > > At  https://wicket.apache.org/ section "Projects Using Apache
> > Wicket"
> > > > > still
> > > > > has no carrousel for me.
> > > > > I guess I have to accept the cookie of Tumblr but then it is not
> > really
> > > > > fixed, right ?
> > > > >
> > > > > On Mon, Jan 7, 2019 at 12:14 AM Martijn Dashorst <
> > > > > martijn.dasho...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > By hosting the json data on a non-cookie encumbered environment I
> > was
> > > > > > able to re-enable the built-with-wicket carroussel.
> > > > > >
> > > > > > Also new background picture suitable for winter :-)
> > > > > >
> > > > > > Martijn
> > > > > >
> > > > > > --
> > > > > > Become a Wicket expert, learn from the best:
> > http://wicketinaction.com
> > > > > >
> > > > >
> > > > --
> > > > Become a Wicket expert, learn from the best: http://wicketinaction.com
> > > >
> >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> >



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Tumblr carroussel works again...

[Martijn Dashorst]

Ah,

Thanks for noticing that! The tumblr gives back a jsonp (var tumbl =
 ;), so I removed the 'var tumbl = ' bit, but neglected to remove
the trailing semi colon

Should be fixed now!

Martijn

On Mon, Jan 7, 2019 at 9:43 AM Martin Grigorov  wrote:
>
> For me it does not work both in Chrome and Firefox.
>
> The debugger does not stop at
> $.getJSON('https://dashorst.github.io/built-with-wicket/tumblr.json',
> function(response) {
> var posts = response.posts;  // HERE
>
> otherwise the XHR response has these headers:
> content-encoding: gzip
> content-length: 7267
> content-type: application/json; charset=utf-8
> and there is a JSON body
>
> Pasting the body in https://codebeautify.org/jsonviewer said that the
> trailing ';' ("tags":["wicket-6","submission"]}]};) causes the problem
>
> On Mon, Jan 7, 2019 at 10:32 AM Martijn Dashorst 
> wrote:
>
> > Private browser window does show the carrousel for me...
> >
> > Martijn
> >
> > Op ma 7 jan. 2019 om 08:36 schreef Martin Grigorov 
> >
> > > At  https://wicket.apache.org/ section "Projects Using Apache Wicket"
> > > still
> > > has no carrousel for me.
> > > I guess I have to accept the cookie of Tumblr but then it is not really
> > > fixed, right ?
> > >
> > > On Mon, Jan 7, 2019 at 12:14 AM Martijn Dashorst <
> > > martijn.dasho...@gmail.com>
> > > wrote:
> > >
> > > > By hosting the json data on a non-cookie encumbered environment I was
> > > > able to re-enable the built-with-wicket carroussel.
> > > >
> > > > Also new background picture suitable for winter :-)
> > > >
> > > > Martijn
> > > >
> > > > --
> > > > Become a Wicket expert, learn from the best: http://wicketinaction.com
> > > >
> > >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> >



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Tumblr carroussel works again...

[Martijn Dashorst]

Private browser window does show the carrousel for me...

Martijn

Op ma 7 jan. 2019 om 08:36 schreef Martin Grigorov 

> At  https://wicket.apache.org/ section "Projects Using Apache Wicket"
> still
> has no carrousel for me.
> I guess I have to accept the cookie of Tumblr but then it is not really
> fixed, right ?
>
> On Mon, Jan 7, 2019 at 12:14 AM Martijn Dashorst <
> martijn.dasho...@gmail.com>
> wrote:
>
> > By hosting the json data on a non-cookie encumbered environment I was
> > able to re-enable the built-with-wicket carroussel.
> >
> > Also new background picture suitable for winter :-)
> >
> > Martijn
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> >
>
-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Tumblr carroussel works again...

[Martijn Dashorst]

By hosting the json data on a non-cookie encumbered environment I was
able to re-enable the built-with-wicket carroussel.

Also new background picture suitable for winter :-)

Martijn

-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Building an alternative for builtwithwicket.tumblr.com

[Martijn Dashorst]

All,

Since the cookie wall of tumblr now blocks showing content before
accepting their 300+ tracking cookies, I want to build an alternative.

The temporary output can be found here:

https://dashorst.github.io/built-with-wicket/

the project lives currently at https://github.com/dashorst/built-with-wicket

There's still a lot to do:

- implement the details page
- implement support for multiple images
- convert the tumblr data to this format
- make it easy for folks to submit new sites (via Google forms?)
- find a final resting place for the url... (e.g.
https://builtwithwicket.wicketstuff.org)
- ...

WDYT?

Martijn

Java 7 availability

[Martijn Dashorst]

All,

If you are in need of a Java 7 version, the Zulu 7 package is still
available for installation.

brew cask install caskroom/versions/zulu7

There're also a linux and windows installation available.

Martijn

Re: PR 341

[Martijn Dashorst]

Wicket Site gitbox migration:
https://issues.apache.org/jira/browse/INFRA-17457

Wicket gitbox migration
https://issues.apache.org/jira/browse/INFRA-17456

Martijn

On Sun, Dec 16, 2018 at 8:45 PM Martijn Dashorst
 wrote:
>
> I'll create a ticket with infra to perform the migration voluntarily.
>
> Martijn
>
> On Sun, Dec 16, 2018 at 8:45 PM Martijn Dashorst
>  wrote:
> >
> > I +1 this move as well.
> >
> > Martijn
> >
> > On Tue, Dec 11, 2018 at 8:50 AM Andrea Del Bene  
> > wrote:
> > >
> > > +1
> > >
> > > On Tue, Dec 11, 2018, 7:20 AM Martin Grigorov  > > wrote:
> > >
> > > > +1 from me too
> > > >
> > > > On Tue, Dec 11, 2018, 05:24 Maxim Solodovnik  > > > wrote:
> > > >
> > > > > +1 to migrate now :)
> > > > >
> > > > > On Tue, 11 Dec 2018 at 05:38, Martin Grigorov 
> > > > > wrote:
> > > > >
> > > > > > If we apply for Gitbox setup we will be able to close it ourselves.
> > > > > > If we don't do it now then Infra will move us to Gitbox in 2-3 
> > > > > > months
> > > > and
> > > > > > then we will be able to close it.
> > > > > > Shall we apply for Gitbox ? :-)
> > > > > >
> > > > > > On Mon, Dec 10, 2018 at 11:38 AM Maxim Solodovnik <
> > > > solomax...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I don't have rights
> > > > > > > (was unable to merge own PR via UI ...)
> > > > > > >
> > > > > > > On Mon, 10 Dec 2018 at 16:35, Andrea Del Bene 
> > > > > > > 
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I don't remember which is the status of GitHub integration with
> > > > > Apache
> > > > > > > > repository. Can anybody close PR from GitHub?
> > > > > > > >
> > > > > > > > Thank you.
> > > > > > > > --
> > > > > > > > Andrea Del Bene.
> > > > > > > > Apache Wicket committer.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > WBR
> > > > > > > Maxim aka solomax
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > WBR
> > > > > Maxim aka solomax
> > > > >
> > > >
> >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: PR 341

[Martijn Dashorst]

I +1 this move as well.

Martijn

On Tue, Dec 11, 2018 at 8:50 AM Andrea Del Bene  wrote:
>
> +1
>
> On Tue, Dec 11, 2018, 7:20 AM Martin Grigorov  wrote:
>
> > +1 from me too
> >
> > On Tue, Dec 11, 2018, 05:24 Maxim Solodovnik  >
> > > +1 to migrate now :)
> > >
> > > On Tue, 11 Dec 2018 at 05:38, Martin Grigorov 
> > > wrote:
> > >
> > > > If we apply for Gitbox setup we will be able to close it ourselves.
> > > > If we don't do it now then Infra will move us to Gitbox in 2-3 months
> > and
> > > > then we will be able to close it.
> > > > Shall we apply for Gitbox ? :-)
> > > >
> > > > On Mon, Dec 10, 2018 at 11:38 AM Maxim Solodovnik <
> > solomax...@gmail.com>
> > > > wrote:
> > > >
> > > > > I don't have rights
> > > > > (was unable to merge own PR via UI ...)
> > > > >
> > > > > On Mon, 10 Dec 2018 at 16:35, Andrea Del Bene 
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I don't remember which is the status of GitHub integration with
> > > Apache
> > > > > > repository. Can anybody close PR from GitHub?
> > > > > >
> > > > > > Thank you.
> > > > > > --
> > > > > > Andrea Del Bene.
> > > > > > Apache Wicket committer.
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > WBR
> > > > > Maxim aka solomax
> > > > >
> > > >
> > >
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
> >



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: PR 341

[Martijn Dashorst]

I'll create a ticket with infra to perform the migration voluntarily.

Martijn

On Sun, Dec 16, 2018 at 8:45 PM Martijn Dashorst
 wrote:
>
> I +1 this move as well.
>
> Martijn
>
> On Tue, Dec 11, 2018 at 8:50 AM Andrea Del Bene  wrote:
> >
> > +1
> >
> > On Tue, Dec 11, 2018, 7:20 AM Martin Grigorov  > wrote:
> >
> > > +1 from me too
> > >
> > > On Tue, Dec 11, 2018, 05:24 Maxim Solodovnik  > >
> > > > +1 to migrate now :)
> > > >
> > > > On Tue, 11 Dec 2018 at 05:38, Martin Grigorov 
> > > > wrote:
> > > >
> > > > > If we apply for Gitbox setup we will be able to close it ourselves.
> > > > > If we don't do it now then Infra will move us to Gitbox in 2-3 months
> > > and
> > > > > then we will be able to close it.
> > > > > Shall we apply for Gitbox ? :-)
> > > > >
> > > > > On Mon, Dec 10, 2018 at 11:38 AM Maxim Solodovnik <
> > > solomax...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I don't have rights
> > > > > > (was unable to merge own PR via UI ...)
> > > > > >
> > > > > > On Mon, 10 Dec 2018 at 16:35, Andrea Del Bene 
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I don't remember which is the status of GitHub integration with
> > > > Apache
> > > > > > > repository. Can anybody close PR from GitHub?
> > > > > > >
> > > > > > > Thank you.
> > > > > > > --
> > > > > > > Andrea Del Bene.
> > > > > > > Apache Wicket committer.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > WBR
> > > > > > Maxim aka solomax
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > WBR
> > > > Maxim aka solomax
> > > >
> > >
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Jetty & ab issue in quick start?

[Martijn Dashorst]

When I try to run a somewhat longer benchmark with our Quick Start
application, I get strange timeouts while running ab (or siege)

ab -n 10 -c 4 http://localhost:8080/
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd
Licensed to The Apache Software Foundation

Benchmarking localhost (be patient)
Completed 1 requests
apr_socket_recv: Operation timed out (60)
Total of 16347 requests completed

The ab runs always fail at the 16348th request (when you use
concurrency > 1 it will vary around 16348)

I've upgraded/downgraded Wicket (this is still the case with 7.0,
7.10, 8.0, 8.1 and 8.2).

I've upgraded jetty to the latest 9.4 version (9.4.14.v20181114) to no avail.

Running ab on a remote Tomcat server does end normally, so it doesn't
appear to be ab related (also siege exhibits the same behavior on the
local Jetty server).

Can anyone confirm this odd behavior?

Martijn

Wicketstuff DNS stuff

[Martijn Dashorst]

I've removed ci.wicketstuff.org from the DNS entries (no server
listening to that IP anymore)

I've started the migration from my current registrar to a new one (a
bit cheaper)

I've also updated the DNS entries to point to the correct github.io servers.

I've also enabled the force HTTPS setting on the wicketstuff.org
website in the github settings.

Martijn


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Removing the "Wicket Stuff Import Backup project"

[Martijn Dashorst]

All,

My notification center is going bonkers with security alerts for this
repository:

https://github.com/wicketstuff/wicketstuff-import-backup

According to me this repository can be removed. Any objections (a +1
means no objection to removing the repository)?

Martijn


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Tumbler down

[Martijn Dashorst]

On Tue, Jul 10, 2018 at 10:49 AM Martijn Dashorst
 wrote:
> I'm submitting a bug report. However, this might mean we need to move
> the carroussel generation to build-time (i.e. when the site gets built
> and published) rather than dynamic.

I just got a notification that the issue is passed onto the
engineering team at Tumblr. There's yet no indication that this will
be resolved or when.

Martijn

Re: Tumbler down

[Martijn Dashorst]

On Tue, Jul 10, 2018 at 10:35 AM Martin Grigorov  wrote:
>
> Then Safari must be broken :-)

It actually isn't: I accepted the GDPR cookie when I opened your
payload request. Apparently Safari remembers the cookie (while in
Emond's browser it didn't).

> The REST call is intercepted by a check for "GDPR agreed" cookie. So the
> response is a HTML page asking you to click "OK" and then you are
> redirected to the original destination.
>
> I guess Tumblr will fix it soon. It is stupid to ask for EU/GDPR consent in
> REST API calls.

I'm submitting a bug report. However, this might mean we need to move
the carroussel generation to build-time (i.e. when the site gets built
and published) rather than dynamic.

I guess they will also GDPR notice the images we link to from now on?

Martijn

Re: Tumbler down

[Martijn Dashorst]

It just works in Safari...

Martijn

On Tue, Jul 10, 2018 at 9:05 AM Tobias Soloschenko
 wrote:
>
> So may we remove the panel, but make a link to tumblr?
>
> kind regards
>
> Tobias
>
> > Am 10.07.2018 um 08:41 schrieb Martin Grigorov :
> >
> > The problem is:
> >
> > Cross-Origin Read Blocking (CORB) blocked cross-origin response
> > https://www.tumblr.com/privacy/consent?redirect=https%3A%2F%2Fbuiltwithwicket.tumblr.com%2Fapi%2Fread%2Fjson%3Fcallback%3DjQuery111304038688794901899_1531204859945%26_%3D1531204859946
> > with MIME type text/html. See
> > https://www.chromestatus.com/feature/5629709824032768 for more details
> >
> >
> > On Tue, Jul 10, 2018 at 9:24 AM Tobias Soloschenko
> >  wrote:
> >
> >> On the wicket site. I am sorry just forgot to mention this.
> >>
> >> kind regards
> >>
> >> Tobias
> >>
> >>> Am 10.07.2018 um 08:10 schrieb Martin Grigorov :
> >>>
> >>> https://builtwithwicket.tumblr.com/
> >>>
> >>> looks OK to me
> >>>
> >>> Or you mean another integration ?
> >>>
> >>> On Tue, Jul 10, 2018 at 7:57 AM Tobias Soloschenko
> >>>  wrote:
> >>>
>  Hey all,
> 
>  just noticed that the Tumbler integration doesn‘t show up any projects.
> 
>  kind regards
> 
>  Tobias
> >>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: [DISCUSSION] WICKET-6544 mobile browser detection

[Martijn Dashorst]

+1 remove it

Martijn

On Sat, Jun 23, 2018 at 3:07 PM Martin Grigorov  wrote:
>
> Then maybe we should deprecate the user agent related code in Wicket 8/9
> and drop it later ?
> ... and show the users how they can use 3rd party libs like this one for
> such needs.
>
> On Sat, Jun 23, 2018 at 3:57 PM Sven Meier  wrote:
>
> > Hi,
> >
> > my stance hasn't changed:
> >
> > I'm not in favor to add a dependency to a library which
> >
> > - updates frequently to adjust to browser developments
> > - introduces a singleton bottleneck
> > - can't be excluded from dependencies
> > - is hidden behind an age-old API Wicket API (UserAgent) ...
> > - ... which won't be sufficient to many people anyways
> >
> > .. just to save someone a single line of code passing the user agent
> > string to the library himself.
> >
> > Have fun
> > Sven
> >
> >
> > Am 22.06.2018 um 14:37 schrieb Tobias Soloschenko:
> > > I think we should turn off the gatherExtendedBrowserInformation by
> > default and give a hint that there is a synchronisation point of 0,011 ms
> > when turned on, but the detection is much more reliable with the new
> > implementation.
> > >
> > > kind regards
> > >
> > > Tobias
> > >
> > >> Am 22.06.2018 um 11:49 schrieb Maxim Solodovnik :
> > >>
> > >> Is it time to resume this discussion?
> > >> We still have PR unmerged, and don't have agreement what to do next :(
> > >>
> > >> On Tue, Apr 10, 2018 at 3:08 AM Tobias Soloschenko <
> > >> tobiassolosche...@googlemail.com> wrote:
> > >>
> > >>> :-D
> > >>>
> > >>> kind regards
> > >>>
> > >>> Tobias
> > >>>
> >  Am 09.04.2018 um 19:14 schrieb Sven Meier :
> > 
> >  bike shed :P
> > 
> >  Sven
> > 
> > 
> > > Am 09.04.2018 um 18:12 schrieb Maxim Solodovnik:
> > > This topic is more active than the release one :)
> > >
> > > On Thu, Apr 5, 2018 at 7:22 PM, Tobias Soloschenko
> > >  wrote:
> > >> -1 for dropping agent detection
> > >> +1 for adding a dependency to an external library (because of the
> > big
> > >>> pool of browsers - which might increase in future)
> > >> kind regards
> > >>
> > >> Tobias
> > >>
> > >>> Am 05.04.2018 um 13:44 schrieb Sven Meier :
> > >>>
> > >>> +0 for dropping agent detection (3)
> > >>> -1 for adding a dependency to an external library
> > >>>
> > >>> Sven
> > >>>
> > >>> Am 3. April 2018 16:34:15 MESZ schrieb Maxim Solodovnik <
> > >>> solomax...@gmail.com>:
> >  It seems the discussion is spread between this thread and the JIRA
> > 
> > >>>
> > https://issues.apache.org/jira/browse/WICKET-6544?focusedCommentId=16423835=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16423835
> >  As far as I can see we don't have consensus if this feature should
> >  1) remain as is (drop PR)
> >  2) be improved (merge PR and/or enhance detection)
> >  3) browser detection should be dropped?
> > 
> >  I would vote for option 2+ :)
> > 
> >  On Mon, Apr 2, 2018 at 5:11 AM, Martin Grigorov <
> > >>> mgrigo...@apache.org>
> >  wrote:
> > 
> > > On Thu, Mar 29, 2018 at 1:31 AM, Korbinian Bachl <
> > > korbinian.ba...@whiskyworld.de> wrote:
> > >
> > >> - Ursprüngliche Mail -
> >  even in 2009 it was considered bad:
> >  https://www.sitepoint.com/why-
> >  browser-sniffing-stinks/
> >  and in case that is not enough, read what the guy that
> > invented
> > >> modernizr
> >  has to say:
> >  http://farukat.es/journal/2011/02/499-lest-we-forget-or-
> >  how-i-learned-whats-so-bad-about-browser-sniffing/
> > 
> > 
> > >>> I do not trust anyone who says "don't do it this way" but
> > doesn't
> >  say
> > > how
> > >>> to do it!
> > >>>
> > >>> There are several of "if (isBrowserX()) {...} else {...}" in
> >  Wicket JS
> > >> code
> > >>> and they served well for the last decade.
> > >>> Since there are several other *Java* libraries for user agent
> >  detection
> > >>> this means that someone still finds them useful despite what
> >  other
> > > people
> > >>> claim.
> > >> unreliable things wont get reliably by pointing into the past
> > and
> >  then
> > >> telling that your fater did it the same way
> > >>
> > >> nowadays you would use feature detection, see:
> > >>
> > >> https://developer.mozilla.org/en-US/docs/Learn/Tools_and_
> > >> testing/Cross_browser_testing/Feature_detection
> > > Korbinian,
> > >
> > > The PR by Maxim is about the User-Agent detection at the *server*
> >  side,
> > > i.e. in the *Java* code. It reads the request header and tells

Oracle plans to dump risky Java serialization | InfoWorld

[Martijn Dashorst]

https://www.infoworld.com/article/3275924/java/oracle-plans-to-dump-risky-java-serialization.amp.html?__twitter_impression=true

Oracle plans to dump risky Java serialization
A “horrible mistake” from 1997, the Java object serialization capability for 
encoding objects has serious security issues

Paul Krill

Getty Images
Oracle plans to drop from Java its serialization feature that has been a thorn 
in the side when it comes to security. Also known as Java object serialization, 
the feature is used for encoding objects into streams of bytes. Used for 
lightweight persistence and communication via sockets or Java RMI, 
serialization also supports the reconstruction of an object graph from a 
stream. 

Removing serialization is a long-term goal and is part of Project Amber, which 
is focused on productivity-oriented Java language features, says Mark Reinhold, 
chief architect of the Java platform group at Oracle.

To replace the current serialization technology, a small serialization 
framework would be placed in the platform once records, the Java version of 
data classes, are supported. The framework could support a graph of records, 
and developers could plug in a serialization engine of their choice, supporting 
formats such as JSON or XML, enabling serialization of records in a safe way. 
But Reinhold cannot yet say which release of Java will have the records 
capability.

Serialization was a “horrible mistake” made in 1997, Reinhold says. He 
estimates that at least a third—maybe even half—of Java vulnerabilities have 
involved serialization. Serialization overall is brittle but holds the appeal 
of being easy to use in simple use cases, Reinhold says.

Recently, a filtering capability was added to Java so if serialization is being 
used on a network and untrusted serialization data streams must be accepted, 
there is a way to filter which classes can be mentioned, to provide a defense 
mechanism against serialization’s security weaknesses. Reinhold says Oracle has 
received many reports are received about application servers running on the 
network with unprotected ports taking serialization streams, which is why the 
filtering capability was developed.

Preview of new wicket site

[Martijn Dashorst]

I've uploaded my work in progress to github.

You can find it here:

http://dashorst.github.io/wicket-site/

In this draft I have opted to make a separate wicket 8 part for our
website under "/8" for the announcement and features list.

Is this something we want to expand on further? To make sub sites for
wicket 7, 8 and beyond?

This way you can have

http://wicket.apache.org/7
http://wicket.apache.org/8
http://wicket.apache.org/9

Martijn

-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Editing announcement for wicket 8

[Martijn Dashorst]

On Mon, Apr 30, 2018 at 3:37 PM, Tobias Soloschenko
 wrote:
> Hi Martijn,
>
> I have just one question - maybe I got it wrong, but does Wicket 8 run also 
> with Java 9 / 10? I thought there are some issues with those newer VMs - it 
> was also discussed on the dev mailing list - if yes we should not mention 
> Java 8+.

It currently does not build using java 9 due to test failures (where
the tests probably don't assert the correct thing). I haven't tested
whether it runs on java 9 :-)

Martijn

Editing announcement for wicket 8

[Martijn Dashorst]

I've started a document with the release announcement for wicket 8,
and will integrate it into my local website prior to pushing it.

The announcement can be found here:

https://gist.github.com/dashorst/16eb7cabf086512f16493dd15070e101

Please review for mistakes, omissions etc.

Martijn

Re: Wicket 8 site

[Martijn Dashorst]

This is what I'm working on:

https://slack-files.com/T4S1WH2J3-FADRRMU0J-40deceefd2

Martijn


On Fri, Apr 20, 2018 at 12:11 PM, Andrea Del Bene <an.delb...@gmail.com> wrote:
> Great!
>
> On Fri, Apr 20, 2018, 12:03 PM Martijn Dashorst <martijn.dasho...@gmail.com>
> wrote:
>
>> I’m working on the release front page with a design. Aiming for a spring
>> vibe with the wicket orange logo as an 8 between the Apache and wicket.
>>
>> Soon more to show
>>
>> Martijn
>> --
>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Wicket 8 site

[Martijn Dashorst]

I’m working on the release front page with a design. Aiming for a spring
vibe with the wicket orange logo as an 8 between the Apache and wicket.

Soon more to show

Martijn
-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

[DISCUSSION] Java future and Wicket

[Martijn Dashorst]

All,

With the new release schedule of Java where they will (have)
release(d) Java 9, 10 and 11 in one year, what will we do with
Wicket's dependency on Java?

Will we move with the Long Term Support versions? AFAIK this will
require us to upgrade every year to a new major version.

Or will we stay with LTS-- as our major supported Java version?

If so, how do we work with deprecated technologies that we (or our
dependencies) use when they get removed, or Wicket plain stops working
on Java 10 (or Java 11), or stops building on one such version?

In the long run, I don't think it is possible for us to align Wicket
versions with major Java versions as we could in the previous years:

- wicket 1.5 -> Java 5 (actually Wicket 1.4, but who's counting)
- wicket 6 -> Java 6
- wicket 7 -> Java 7
- wicket 8 -> Java 8

would the next major version of Wicket be 11?

- wicket 11 -> Java 11?

Martijn

Article on Java web frameworks at Infoworld

[Martijn Dashorst]

https://www.infoworld.com/article/3263767/java/15-java-frameworks-that-give-developers-a-boost.html

Re: [DISCUSSION] Wicket 8 Release

[Martijn Dashorst]

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

[Martijn Dashorst]

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.

Unfortunately CGLIB usage is not private/internal to wicket itself but
is exposed in a couple public APIs.

Of course, if we had relesed Wicket 8 with CGLIB in it, this problem
would still exist, and perhaps Wicket 8 would be a short lived
maintained version if we were forced to remove our dependency on CGLIB
(which is unclear at the moment)

Martijn

Re: [DISCUSSION] Wicket 8 Release

[Martijn Dashorst]

Ehm,

While perfect is the enemy of shipping, I came across the stuff below.

This article has a good description of the forthcoming issues with
sun.misc.Unsafe and JDK 11:

https://mydailyjava.blogspot.nl/2018/04/jdk-11-and-proxies-in-world-past.html

As we use CGLIB for our proxy generation in wicket-ioc (and hence
wicket-spring and wicket-guice), this will affect users of Wicket
running on JDK 11 in the future.

IMO we should at least make our dependency on CGLIB optional, and add
support for byte buddy or such, to remove our dependency on
sun.misc.Unsafe.

As we expose some CGLIB APIs as public in Wicket IOC, this might be a
breaking change if we opt to remove our dependency on CGLIB
completely.

I'm working on using Byte Buddy as an alternative IOC implementation.
However I don't know if I will be able to cover all use cases (not
sure how good our unit tests are).

Martijn

Re: Wicket User Guide Google URL Submission

[Martijn Dashorst]

I'm no expert on google search optimization, but I thought this is
typically done through a sitemap.xml file.

Perhaps we should add one to the wicket site (possibly generated from
the _config.yml settings)?

Martijn


On Wed, Feb 28, 2018 at 9:20 AM, Andrea Del Bene  wrote:
> well done, thank you!
>
> On Wed, Feb 28, 2018 at 8:32 AM, Tobias Soloschenko <
> tobiassolosche...@googlemail.com> wrote:
>
>> Hi everyone,
>>
>> because I noticed that our user guide 7.x and 8.x is not crawled by google
>> I added both URLs to Google Search Console.
>>
>> kind regards
>>
>> Tobias



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Wicket slack at the-asf

[Martijn Dashorst]

All,

The ASF has a slack group, so I joined using my @apache.org email. I
also created a Wicket channel over there.

It should not be used for official decision making, but as a back
channel or flushing out features it can be a great tool, similarly the
way we used irc.

https://the-asf.slack.com is the slack group.

Martijn

Re: [VOTE] Release wicket-eclipse-settings 4

[Martijn Dashorst]

+1 from me, so this vote passes, I'll press the promote button.

Martijn


On Tue, Jan 16, 2018 at 8:10 AM, Tobias Soloschenko
<tobiassolosche...@googlemail.com> wrote:
> The preferences are load via „M2E Settings 2.0.4“ plugin provided by Topicus. 
> You don’t need to import them but to install the plugin via marketplace.
>
> I just wonder where it was mentioned at our site.
>
> kind regards
>
> Tobias
>
>> Am 16.01.2018 um 05:08 schrieb Maxim Solodovnik <solomax...@gmail.com>:
>>
>> +1 via code review
>>
>> I was unable to import these settings using standard Eclipse
>> Import->Preferences dialog
>> What is the proper way of import?
>>
>>> On Mon, Jan 15, 2018 at 1:33 AM, Andrea Del Bene <an.delb...@gmail.com> 
>>> wrote:
>>> +1 to release
>>>
>>> On Jan 14, 2018 7:26 PM, "Tobias Soloschenko" <
>>> tobiassolosche...@googlemail.com> wrote:
>>>
>>>> +1 to release
>>>>
>>>> kind regards
>>>>
>>>> Tobias
>>>>
>>>>> Am 14.01.2018 um 19:12 schrieb Martijn Dashorst <
>>>> martijn.dasho...@gmail.com>:
>>>>>
>>>>> Tag: https://github.com/dashorst/wicket/releases/tag/rel%
>>>> 2Fwicket-eclipse-settings-4
>>>>>
>>>>> Staging repo:
>>>>> https://repository.apache.org/content/repositories/orgapachewicket-1104/
>>>>>
>>>>> Changes:
>>>>>
>>>>> - set javac source and target to 1.8
>>>>> - Add configuration for Maven deploy and gpg plugins.
>>>>>
>>>>> [ ] Yes release
>>>>> [ ] No don't release
>>>>>
>>>>> Martijn
>>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Quick start and https/TLS/SSL

[Martijn Dashorst]

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

[VOTE] Release wicket-eclipse-settings 4

[Martijn Dashorst]

Tag: 
https://github.com/dashorst/wicket/releases/tag/rel%2Fwicket-eclipse-settings-4

Staging repo:
https://repository.apache.org/content/repositories/orgapachewicket-1104/

Changes:

- set javac source and target to 1.8
- Add configuration for Maven deploy and gpg plugins.

[ ] Yes release
[ ] No don't release

Martijn

Re: [GitHub] wicket pull request #257: [WICKET-6518] Log4j is replaced with logback

[Martijn Dashorst]

We use SLF4J to enable folks to switch between loggers.

I'd rather see us use slf4j-jul or slf4j-simple without any config.
Moving to log4j or logback would then require anyone picking the
quickstart to add the relevant config, but not to remove things when
switching.

Quick start is just that. The less one has to remove the better. If
simple logging or jul are too slow for performance tests (that
inevitably are run against quick start) pick logback or log4j2.

Anyways, I like my bike shed green. If logback it is, then we'd better
add a line to quick start's NOTICE file (and add a NOTICE file to the
archetype resources).

Other than that: perhaps the archetype is overdue for an overhaul and
we should rather adopt a spring boot, jhipster like setup where we
generate a zip file with the required resources based on selections
(e.g. jszip [1]) and allow for either log4j, logback, slf4j-simple,
jpa, etc, straight from our page without having to install Maven, etc.

Martijn

[1] https://davidwalsh.name/javascript-zip

On Sun, Jan 14, 2018 at 12:30 PM, Maxim Solodovnik <solomax...@gmail.com> wrote:
> Thanks Martin :)
> This was exactly my point :)
>
> WBR, Maxim
> (from mobile, sorry for the typos)
>
> On Sun, Jan 14, 2018, 18:29 Martin Grigorov <mgrigo...@apache.org> wrote:
>
>> I do not see any problem here.
>> We do not distribute any non-ASL2 code or binaries!
>> The snippet in pom.xml and logback.xml are ASL2 as being part of
>> wicket-archetype-quickstart, so the user can do anything with them,
>> including replacing them with whatever (s)he finds better.
>>
>> Actually I believe Logback is far more used than Log4j in business
>> applications.
>>
>> "Promoting" JUL would be the worst we can do.
>>
>> On Sun, Jan 14, 2018 at 10:34 AM, Maxim Solodovnik <solomax...@gmail.com>
>> wrote:
>>
>> > EPL is compatible with APLv2, just need to be added to NOTICE.
>> > I mean the files we are distributing doesn't contain any binaries.
>> >
>> > Logback binaries appears only after compilation of generated
>> > quick-start  nothing illegal.
>> >
>> > Will check java util logging in the beginning of next week 
>> >
>> > On Sun, Jan 14, 2018 at 4:28 PM, Tobias Soloschenko
>> > <tobiassolosche...@googlemail.com> wrote:
>> > > What do you mean by choose any license?
>> > >
>> > > If you put in the logback xml it is required to add the logback
>> > dependency to enable the logging - logback is EPL / LGPL so it is
>> > incompatible to Apache license v2.
>> > >
>> > > So the user is required to remove everything first and add a logging
>> > with MIT or any other non-restrict license.
>> > >
>> > > To generate something with a restricted license is also not the target
>> > solution we should go for.
>> > >
>> > > What about java utils logging? SLF4J has also an adapter for this and
>> > maybe we can prevent the memory leak by this.
>> > >
>> > > kind regards
>> > >
>> > > Tobias
>> > >
>> > >> Am 14.01.2018 um 05:58 schrieb Maxim Solodovnik <solomax...@gmail.com
>> >:
>> > >>
>> > >> I would support any decision here :)
>> > >>
>> > >> From my point of view app with in-build "memory leak" shouldn't be
>> > generated.
>> > >> Generated quick-start project is being owned by the user. And he/she
>> > >> can choose any license :)
>> > >> We can add NOTICE to generated project, not sure if this is required
>> > .
>> > >>
>> > >> On Sun, Jan 14, 2018 at 11:30 AM, Tobias Soloschenko
>> > >> <tobiassolosche...@googlemail.com> wrote:
>> > >>> I would also not enforce user to take a LGPL dependency. For Log4j
>> you
>> > can use SLF4J adapter and also logback if you finally want to but you
>> don’t
>> > have to.
>> > >>>
>> > >>> +1 to revert.
>> > >>>
>> > >>> kind regards
>> > >>>
>> > >>> Tobias
>> > >>>
>> > >>>> Am 14.01.2018 um 04:45 schrieb Maxim Solodovnik <
>> solomax...@gmail.com
>> > >:
>> > >>>>
>> > >>>> Actually it is not being distributed :)
>> > >>>> It is in the pom only, It only "distributed" after final project,
>> > >>>> generated on client side, is bein

Wicket 8 & Eclipse

[Martijn Dashorst]

All,

I've imported Wicket sources into a new eclipse workspace but get lots
of compile errors. This is due to the source level being set to 1.7.

And this comes from org.apache.wicket:wicket-eclipse-settings:3

The 4-SNAPSHOT does have the correct source level. My guess is it is
time (long overdue) to release 4?

Martijn


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: [GitHub] wicket pull request #257: [WICKET-6518] Log4j is replaced with logback

[Martijn Dashorst]

Please note that logback is LGPL 2.1/EPL licensed.

LGPL 2.1 cannot be distributed with our code. EPL only as binary, and
properly attributed in the NOTICE file:

https://www.apache.org/legal/resolved.html#category-b

Martijn


On Sat, Jan 13, 2018 at 4:20 AM, solomax  wrote:
> GitHub user solomax opened a pull request:
>
> https://github.com/apache/wicket/pull/257
>
> [WICKET-6518] Log4j is replaced with logback
>
>
>
> You can merge this pull request into a Git repository by running:
>
> $ git pull https://github.com/apache/wicket WICKET-6518-quickstart-logback
>
> Alternatively you can review and apply these changes as the patch at:
>
> https://github.com/apache/wicket/pull/257.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 #257
>
> 
> commit cfd6a55fc9d613d4412a004efcc8e06d6ac1d73d
> Author: Maxim Solodovnik 
> Date:   2018-01-13T03:18:56Z
>
> [WICKET-6518] Log4j is replaced with logback
>
> 
>
>
> ---



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: 8.0.0 blockers

[Martijn Dashorst]

On Wed, Jan 10, 2018 at 2:35 PM, Andrea Del Bene <an.delb...@gmail.com> wrote:
> On Wed, Jan 10, 2018 at 1:26 PM, Martijn Dashorst <
> martijn.dasho...@gmail.com> wrote:
>
>> No technical blockers AFAIK, however, we really should do the marketing
>> right:
>>
>> - front page of website should feature 8 prominently
>> - work with Sally from PR for a press release to let the world know we
>> are not Dead Yet™
>> - have a really great announcement to give to the world about all the
>> benefits of Wicket 8
>>
>> What are the key features that necessitate upgrading to Wicket 8?
>>
>> Not blocking but really important:
>>
>> - have a story to answer "Why not just use XXX.js?"
>> - have a story to answer "Isn't Java Server Side frameworks dead?"
>> - have a story to answer "Isn't Java dead"
>>
>
> By "having a story" what would you like to have? For example could it be a
> sort of section on Wicket site (a sort of FAQ section)?

Mostly that we are on the same page and are prepared for those
inevitable questions that arise in the comments and from interested
journalists. Paul Krill used to want to do an interview with one of
the committers about the new release. If we have a canned answer now,
that will help us react in a quick way.

Martijn

Re: 8.0.0 blockers

[Martijn Dashorst]

No technical blockers AFAIK, however, we really should do the marketing right:

- front page of website should feature 8 prominently
- work with Sally from PR for a press release to let the world know we
are not Dead Yet™
- have a really great announcement to give to the world about all the
benefits of Wicket 8

What are the key features that necessitate upgrading to Wicket 8?

Not blocking but really important:

- have a story to answer "Why not just use XXX.js?"
- have a story to answer "Isn't Java Server Side frameworks dead?"
- have a story to answer "Isn't Java dead"

Have a call list for when a reporter wants to have contact about
Wicket 8 and its future (esp. related to questions above)

Other things to consider:

- prepare some articles to publish to dzone, voxxed, etc.?

Martijn

Re: WICKET-6514 and FeedbackPanel

[Martijn Dashorst]

Op do 4 jan. 2018 om 03:42 schreef Maxim Solodovnik <solomax...@gmail.com>

> I thought this API break was "by design"
> Maybe this can be documented instead?
>

FeedbackPanel should use the constructor with session messages enabled.
That is the API break, not the collector change.

Martijn


> WBR, Maxim
> (from mobile, sorry for the typos)
>
> On Thu, Jan 4, 2018, 05:22 Martijn Dashorst <martijn.dasho...@gmail.com>
> wrote:
>
> > On Wed, Jan 3, 2018 at 10:43 PM, Andrea Del Bene <an.delb...@gmail.com>
> > wrote:
> > > Hi,
> > >
> > > as a result of WICKET-6514 now FeedbackPanel doesn't show anymore
> session
> > > messages. I'm not sure if this was intentional, but I think
> > FeedbackPanel
> > > shouldn't change its behavior. Should we modify FeedbackPanel to
> restore
> > the
> > > original behavior?
> >
> > Yes. There are countless applications depending on this type of
> > messaging. This is a regression.
> >
> > Martijn
> >
>
-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: WICKET-6514 and FeedbackPanel

[Martijn Dashorst]

On Wed, Jan 3, 2018 at 10:43 PM, Andrea Del Bene  wrote:
> Hi,
>
> as a result of WICKET-6514 now FeedbackPanel doesn't show anymore session
> messages. I'm not sure if this was intentional, but I think  FeedbackPanel
> shouldn't change its behavior. Should we modify FeedbackPanel to restore the
> original behavior?

Yes. There are countless applications depending on this type of
messaging. This is a regression.

Martijn

Re: 8.0.0 blockers

[Martijn Dashorst]

I’m working on restyling the QuickStart to look like the new examples. Not
a blocker but would be awesome to include. Will work on it 2nd Jan

Martijn



Op vr 29 dec. 2017 om 20:28 schreef Korbinian Bachl <
korbinian.ba...@whiskyworld.de>

> May I also mention WICKET-6498?
>
> https://issues.apache.org/jira/browse/WICKET-6498
>
>
>
> - Ursprüngliche Mail -
> > Von: "Sven Meier" <s...@meiers.net>
> > An: dev@wicket.apache.org
> > Gesendet: Freitag, 29. Dezember 2017 16:22:47
> > Betreff: Re: 8.0.0 blockers
>
> > Not strictly necessary, but I would like to merge WICKET-6503:
> >
> > https://issues.apache.org/jira/browse/WICKET-6503
> >
> > Have fun
> > Sven
> >
> >
> > Am 29.12.2017 um 06:02 schrieb Maxim Solodovnik:
> >> Hello All,
> >>
> >> Is it time for release?
> >>
> >> There are long holidays upcoming here, so I can send more time on Wicket
> >> :)))
> >>
> >>
> >> On Thu, Nov 30, 2017 at 9:36 PM, Andrea Del Bene <an.delb...@gmail.com>
> >> wrote:
> >>
> >>> On Thu, Nov 30, 2017 at 1:07 PM, Martijn Dashorst <
> >>> martijn.dasho...@gmail.com> wrote:
> >>>
> >>>> No technical blockers AFAIK, however, we really should do the
> marketing
> >>>> right:
> >>>>
> >>>> - front page of website should feature 8 prominently
> >>>> - work with Sally from PR for a press release to let the world know we
> >>> are
> >>>> not Dead Yet™
> >>>> - have a really great announcement to give to the world about all the
> >>>> benefits of Wicket 8
> >>>>
> >>>> What are the key features that necessitate upgrading to Wicket 8?
> >>>>
> >>>> Not blocking but really important:
> >>>>
> >>>> - have a story to answer "Why not just use XXX.js?"
> >>>> - have a story to answer "Isn't Java Server Side frameworks dead?"
> >>>>
> >>> I (partially) covered these two issues in my presentation. Maybe it
> can be
> >>> helpful for further considerations:
> >>>
> >>> http://events.linuxfoundation.org/sites/events/files/slides/
> >>> Wicket_The_story_so_far_and_beyond.pdf
> >>>
> >>>
> >>>> - have a story to answer "Isn't Java dead"
> >>>>
> >>> Java will never die :-)
> >>>
> >>>
> >>>> Have a call list for when a reporter wants to have contact about
> Wicket 8
> >>>> and its future (esp. related to questions above)
> >>>>
> >>>> Other things to consider:
> >>>>
> >>>> - prepare some articles to publish to dzone, voxxed, etc.?
> >>>>
> >>> I'm preparing an article for dzone. You can find it here:
> >>>
> >>> https://www.dropbox.com/s/l9ec2plxyhe4aa2/article8.txt
> >>>
> >>> Any feedback is welcome!
> >>>
> >>>
> >>>> Martijn
> >>>>
> >>>>
> >>>> On Wed, Nov 29, 2017 at 3:32 AM, Maxim Solodovnik <
> solomax...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hello All,
> >>>>>
> >>>>> do we have any blockers for 8.0.0?
> >>>>>
> >>>>>
> >>>>> --
> >>>>> WBR
> >>>>> Maxim aka solomax
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Become a Wicket expert, learn from the best:
> http://wicketinaction.com
> >>>>
> >>
>
-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

@PMC: Request permission for a HyderabadJUG meetup for Wicket

[Martijn Dashorst]

Apparently to abide by the rules of the ComDev [1] I have to ask
permission to use the Apache Wicket name for organizing a meetup event
for the HyderabadJUG concerning Wicket.

So here it goes:

Can I, in conjunction with my co-organizers of the HyderabadJUG and
our local business partner use the Apache Wicket name to organize an
event concerning our project with one or two talks about Wicket?

[ ] +1: yes you can use the Apache Wicket™ brand for the HyderabadJUG
[ ] -1: Nope

Martijn

[1] http://community.apache.org/events/small-events.html

Wicket mention in presentation by David Schmitz

[Martijn Dashorst]

The presentation "10 Tips for failing badly at Microservices" by David
Schmitz got a mention for Wicket:

https://youtu.be/X0tjziAQfNQ?t=1588

Thanks to my esteamed coworkers Egbert and Thomas for pointing this out.

This presentation is also just a great watch btw.

Martijn

Re: 8.0.0 blockers

[Martijn Dashorst]

No technical blockers AFAIK, however, we really should do the marketing
right:

- front page of website should feature 8 prominently
- work with Sally from PR for a press release to let the world know we are
not Dead Yet™
- have a really great announcement to give to the world about all the
benefits of Wicket 8

What are the key features that necessitate upgrading to Wicket 8?

Not blocking but really important:

- have a story to answer "Why not just use XXX.js?"
- have a story to answer "Isn't Java Server Side frameworks dead?"
- have a story to answer "Isn't Java dead"

Have a call list for when a reporter wants to have contact about Wicket 8
and its future (esp. related to questions above)

Other things to consider:

- prepare some articles to publish to dzone, voxxed, etc.?

Martijn


On Wed, Nov 29, 2017 at 3:32 AM, Maxim Solodovnik 
wrote:

> Hello All,
>
> do we have any blockers for 8.0.0?
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: New wicket 8 examples look: awesome

[Martijn Dashorst]

Not quite the whole story: I made the original design for the wicket
website, but that is a far stretch for the examples.

You have done IMO awesome work applying the original design in a new
context in a very clean and simple way. The reason I never did so was that
I was constantly venturing into a complex cumbersome way.

Martijn


On Fri, Nov 24, 2017 at 10:31 AM, Andrea Del Bene <an.delb...@gmail.com>
wrote:

> Thank you! But it's actually your work, I've just applied it to examples
> :).
>
> On Fri, Nov 24, 2017 at 10:21 AM, Martijn Dashorst <
> martijn.dasho...@gmail.com> wrote:
>
> > Hey Andrea!
> >
> > Love your work on the new examples look and feel! Excellent work.
> >
> > For everyone else who hasn't seen them, cover your eyes because they'll
> get
> > blinded by the new look:
> >
> > http://examples8x.wicket.apache.org/index.html
> >
> > Martijn
> >
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

New wicket 8 examples look: awesome

[Martijn Dashorst]

Hey Andrea!

Love your work on the new examples look and feel! Excellent work.

For everyone else who hasn't seen them, cover your eyes because they'll get
blinded by the new look:

http://examples8x.wicket.apache.org/index.html

Martijn

Re: Unsubscribe+from+Apache+Wicket+Dev+list

[Martijn Dashorst]

If you send a message from the address you subscribed to to this address:
dev-unsubscr...@wicket.apache.org you'll be taken off the wicket-dev list.

Martijn

On Sat, Nov 11, 2017 at 3:56 PM, calle sollander 
wrote:

>
>


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Analyze Wicket builds with Sonar

[Martijn Dashorst]

Only if you tweak sonar config such that we don't have to rework our source
code. Sonar's defaults are awful and should not be used by any serious
developer.

I weep whenever I see someone extract a private method to get a method from
cyclomatic complexity of 8 to 6 (aka the "sweep shit under the carpet"
refactoring)

Martijn


On Fri, Nov 10, 2017 at 6:21 AM, Maxim Solodovnik 
wrote:

> Hello All,
>
> Maybe it worth to add Sonar analysis to Wicket builds?
> It is available at Apache build servers: https://builds.apache.org/
> analysis/
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Time for M8?

[Martijn Dashorst]

I say make a final milestone. Work on a press release for Wicket 8 final,
work with Sally from PR to get the press release in good shape, cut 8.0 and
release it upon the world.

Martijn


On Thu, Oct 19, 2017 at 10:14 AM, Andrea Del Bene 
wrote:

> i dare ask you... :-)
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: [VOTE] Release Apache Wicket 7.8.1

[Martijn Dashorst]

On Wed, Aug 30, 2017 at 10:12 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:

> I guess this is a release made of HEAD of 7.x. This would warrant a 7.9.0
> version rather than a 7.8.1. It also includes 2 fixes other than
> WICKET-6457. Is this what we want?
>
> If we want a 7.8.1 release just with WICKET-6457 I can invest the time
> tomorrow to roll it. Otherwise we can release this one.
>

These questions are answered: 7.x of HEAD it is :-)

Martijn

Re: [VOTE] Release Apache Wicket 7.8.1

[Martijn Dashorst]

Heya Andrea!

Thanks for rolling the release! I would've done so tomorrow at work.

I guess this is a release made of HEAD of 7.x. This would warrant a 7.9.0
version rather than a 7.8.1. It also includes 2 fixes other than
WICKET-6457. Is this what we want?

If we want a 7.8.1 release just with WICKET-6457 I can invest the time
tomorrow to roll it. Otherwise we can release this one.

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


-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

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

[Martijn Dashorst]

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: Using Gitbox

[Martijn Dashorst]

I wouldn't mind having more abilities available at github. I don't see any
downsides other than some work on our documentation and the migration.

Martijn


On Sun, Aug 13, 2017 at 1:08 PM, Martin Grigorov 
wrote:

> I haven't seen any documentation too.
> As far as I understand it this service just replaces git-wip with
> github.com,
> i.e. we will have more (all ?!) permissions at
> https://github.com/apache/wicket and we will be able to merge PRs by
> clicking buttons.
>
> https://gitbox.apache.org/setup/ - here you can link your Apache id with
> your GitHub id.
> https://gitbox.apache.org/repos/asf - here you can see which Apache
> projects already use this service.
>
> If the active Wicket devs like the idea then we need to create a ticket for
> Infra to enable GitBox for Wicket.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Aug 9, 2017 at 10:40 AM, Maxim Solodovnik 
> wrote:
>
> > I see no documentation at all :(((
> > Maybe you can share some links?
> >
> > On Mon, Aug 7, 2017 at 2:04 AM, Martin Grigorov 
> > wrote:
> >
> > > This is what Wicket uses now.
> > > It didn't happen to you because you haven't merged PRs from GitHub.
> > >
> > > See https://gitbox.apache.org. although it is not well documented yet.
> > >
> > > On Aug 6, 2017 8:33 PM, "Maxim Solodovnik" 
> wrote:
> > >
> > > > We are using git at https://git-wip-us.apache.org/repos/asf/ and it
> > > > seems to produce less emails ...
> > > >
> > > > On Sun, Aug 6, 2017 at 7:52 PM, Martin Grigorov <
> mgrigo...@apache.org>
> > > > wrote:
> > > > > Hi devs,
> > > > >
> > > > > As you may have noticed merging PRs from GitHub creates a lot of
> > email
> > > > and
> > > > > git history noise.
> > > > >
> > > > > What do you think about moving to Gitbox service offered by Apache
> > > Infra
> > > > ?
> > > > > AFAIK it gives more permissions over the repo at GitHub and the
> > > workflow
> > > > > should simlify.
> > > > >
> > > > > Martin Grigorov
> > > > > Wicket Training and Consulting
> > > > > https://twitter.com/mtgrigorov
> > > >
> > > >
> > > >
> > > > --
> > > > WBR
> > > > Maxim aka solomax
> > > >
> > >
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com