Re: Incorrect modification time in jars

> > I've just opened a PR with this change ( > https://github.com/apache/wicket/pull/758). I don't think this change > will be problematic, but as it only really influences the release builds, > it's hard to test its effect without doing an actual release. > It turned out that maven-bundle-plugin

Re: Incorrect modification time in jars

Op do 7 dec 2023 om 08:58 schreef Emond Papegaaij : > Op do 7 dec 2023 om 02:35 schreef Maxim Solodovnik : > >> File timestamps might be set to `project.build.outputTimestamp` by Maven >> This enables "reproducible builds" >> https://maven.apache.org/guides/m

Re: Incorrect modification time in jars

Op do 7 dec 2023 om 02:35 schreef Maxim Solodovnik : > File timestamps might be set to `project.build.outputTimestamp` by Maven > This enables "reproducible builds" > https://maven.apache.org/guides/mini/guide-reproducible-builds.html > > I believe Maven `project.build.outputTimestamp` property

Re: Incorrect modification time in jars

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

Re: Incorrect modification time in jars

Op wo 6 dec 2023 18:22 schreef Richard Eckart de Castilho : > > We can switch from LastModifiedResourceVersion to something else in our > > applications to work around this issue, but maybe we should consider > > tracking down this issue and release a 9.16.1. I'd expect we are not the > > only

Incorrect modification time in jars

Hi, With the upgrade to wicket 9.16.0 we've seen some issues with the new 'Wicket.Event.requestSubmit' method that was added to wicket-ajax-jquery. It turns out that a cached version of the resource was used, and this seems to be caused by an incorrect version string in the url. The filename is

Re: Wicket 9.x versions are NOT backward compatible

Op wo 30 aug 2023 om 17:20 schreef Maxim Solodovnik : > Hello Emond, > > On Fri, 25 Aug 2023 at 14:38, Emond Papegaaij > wrote: > > > > Op vr 25 aug 2023 om 07:02 schreef Maxim Solodovnik < > solomax...@gmail.com>: > > > > > So if (for wha

Re: Wicket 9.x versions are NOT backward compatible

Op vr 25 aug 2023 om 07:02 schreef Maxim Solodovnik : > So if (for whatever reason) we do have > wicket-core 9.8.0+ AND wicket-util 9.7.0- > > In class path WebApplication will fail to start with > java.lang.NoSuchMethodError > This is perfectly fine. Semver only is about Wicket as a whole, so

Re: Time for Wicket M1?

Op do 9 feb. 2023 om 08:32 schreef Martin Grigorov : > On Thu, Feb 9, 2023 at 9:16 AM Emond Papegaaij > wrote: > > > Op do 9 feb. 2023 om 07:47 schreef Martin Grigorov >: > > > > > Please update > > > > > > https://cwiki.apache.org

Re: Time for Wicket M1?

Op do 9 feb. 2023 om 07:47 schreef Martin Grigorov : > Please update > https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0 > that the Component Queueing is gone > > Before releasing M1 I think we need to: > 1) update all dependencies to their latest stable version > 2)

Re: [ANNOUNCE] Apache Wicket 9.9.1 released

I had issues with the git repo on Friday. Git fetch told me the repository did not exist. I'm using https://gitbox.apache.org/repos/asf/wicket.git . After some time it was working again. Maybe this is related? Emond On Sat, Apr 9, 2022 at 12:01 PM Andrea Del Bene wrote: > For some reason I

Re: @jakarta.inject.Inject + not required

CDI uses javax.enterprise.inject.Instance to inject optional beans. I don't particular like this solution, but it works. The downside is that it depends on the CDI API. Best regards, Emond On Wed, Jun 2, 2021 at 10:41 AM Martin Grigorov wrote: > > On Wed, Jun 2, 2021 at 11:31 AM Sven Meier

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

Hi, I agree the mail spams the list a bit and it makes sense to send it somewhere else, but doesn't it belong in commits@w.a.o? Best regards, Emond On Mon, May 31, 2021 at 5:25 PM Martin Grigorov wrote: > > Hi, > > Some people complain that there is too much email traffic on dev@ due to > the

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

Description: A DNS proxy and possible amplification attack vulnerability in WebClientInfo of Apache Wicket allows an attacker to trigger arbitrary DNS lookups from the server when the X-Forwarded-For header is not properly sanitized. This DNS lookup can be engineered to overload an internal DNS

Re: Next release cycle.

I agree. It would have been nice to have it backported to 8, but it's not a big deal and not worth the effort of backporting all those other things. On Sun, Mar 21, 2021 at 9:18 PM Martin Grigorov wrote: > > On Sun, Mar 21, 2021, 18:47 Maxim Solodovnik wrote: > > > Let it be 9.x exclusive

Re: JDK 16 is in Rampdown Phase One

Hi, Before we go that way, please do some performance tests. We've seen very bad performance in StackWalker, especially when it is called many times over. This may have improved in more recent JDKs, but in Java 11 the overhead was so significant that a single StackWalker call in a log call would

Re: new release 9.2.0 ?

-1 to start the release now. We just discovered a (very likely) new issue with the flush before detach: https://issues.apache.org/jira/browse/WICKET-6848 We are currently checking if the changes made with WICKET-6847 fix this, but I think this is a different problem. Maybe someone with a bit more

Re: New release

Hi Andrea, Yes, WICKET-6702 is completed. I've resolved the ticket. Emond On Fri, Oct 2, 2020 at 11:59 AM Andrea Del Bene wrote: > > The changelog for 9.1.0 is exploding :-). I think we can proceed releasing > it. That said, I don't know if WICKET-6702 >

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

ild Source Stamp: [branch wicket-8.x] > bed559fdf531b15dab3ae0367873f2e27b2fcdcc > Blamelist: Emond Papegaaij ,Sven Meier > > > BUILD FAILED: failed compile > > Sincerely, > -The Buildbot > > >

Re: Flush request before detach

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

Flush request before detach

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

Re: Contribution - CSP support for Wicket

Hi Santiago, It's always nice to get some help in maintaining Wicket. Wicket has always been strong wrt security. That's one of the reasons why at Topicus we use it to power our Identity and Access Management solution called Topicus KeyHub. Just a few weeks ago I filed the following ticket

Re: Stable behavior ids

, 2020 at 11:12 PM Emond Papegaaij wrote: > > Hi Sven, > > I agree with you that this method is not very nice. It indeed complicates the > API even more and it is very hard to explain why it is needed. It however is > the most efficient implementation I could think of. > >

Re: Stable behavior ids

hat if the method returns true, but getId() is never actually called? > > IMHO this is the wrong timing to adjust the API. > > Have fun > Sven > > > On 08.05.20 07:59, Emond Papegaaij wrote: > > Hi Sven, > > > > Yes, this is all about optimization. It already

Re: Stable behavior ids

or this stable id hassle? Why can't the id be stable > when a behavior wants it? > Is this really needed for optimization? > > Thanks > Sven > > > On 07.05.20 21:04, Emond Papegaaij wrote: > > Hi all, > > > > I've updated my pull request at > > https://g

Re: Stable behavior ids

may not need it. IMHO this change makes it more clear to a developer what to expect. I would like to merge this into 9 before the release, even though strictly speaking it is not an API break. What do you think? Best regards, Emond On Thu, May 7, 2020 at 1:58 PM Emond Papegaaij wrote: > &

Re: Stable behavior ids

make sure it still works. > > Have fun > Sven > > > On 07.05.20 12:13, Andrea Del Bene wrote: > > > > On 07/05/20 10:37, Emond Papegaaij wrote: > >> Hi Martin, > >> > >> I know what these id's are for, and this still works as expected. > >> Ho

Re: Stable behavior ids

er > behavior's onRequest(). So, the ids must be stable in case of stateless as > well. > > > > On Wed, May 6, 2020 at 9:28 PM Emond Papegaaij > wrote: > > > Hi, > > > > While running, I came up with a solution for which only a minor change > > to the con

Re: Stable behavior ids

, this stable id is retained over requests. For stateless behaviors, the id can change between requests. Emond On Wed, May 6, 2020 at 5:54 PM Emond Papegaaij wrote: > > Hi Andrea, > > Stateful is fine, stateless is not. A component cannot keep a stable > id when it's stateless. I'm tryi

Re: Stable behavior ids

On Wed, May 6, 2020 at 5:41 PM Andrea Del Bene wrote: > > > On 06/05/20 16:52, Emond Papegaaij wrote: > > Hi all, > > > > During my refactoring of the component state (WICKET-6774) I noticed > > that behavior ids are currently stored in a very inefficient way: an &g

Stable behavior ids

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

Re: Time to release 9.0.0 ?

Fine with me, +1 to release then Op do 30 apr. 2020 14:33 schreef Martin Grigorov : > On Thu, Apr 30, 2020 at 2:19 PM Emond Papegaaij > > wrote: > > > +0 to release > > > > The rewrite I'm currently doing is API compatible. I'm nearly finished > > thoug

Re: Time to release 9.0.0 ?

+0 to release The rewrite I'm currently doing is API compatible. I'm nearly finished though, so if we can wait one more day, I should be able to get it all working. Emond On Thu, Apr 30, 2020 at 12:07 PM Sven Meier wrote: > > +1 we have to cut it somewhere > > Sven > > > On 30.04.20 11:57,

Re: CSP regression

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

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

34508f52d7807fe361f20fbea/wicket-core/src/main/java/org/apache/wicket/Component.java#L2370 > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> On Thu, Mar 12, 2020 at 4:35 PM Sven Meier > > > wrote: > > > >

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

e following commit(s) were added to refs/heads/master by this push: > > new 1619809 WICKET-6727: only render CSP on RenderPageRequestHandler > > 1619809 is described below > > > > commit 16198099d8a965f17c85d2de7a6dce36b000ec26 > > Author: Emond Pa

Re: CSPRequestCycleListener headers

to the CSP example that shows that CSP protection still works in ajax requests. Best regards, Emond On Fri, Mar 13, 2020 at 9:18 AM Emond Papegaaij wrote: > > Hi Sven, > > I've reread the spec a bit more precise last night. I think we can > change the code to only

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

Looking at the examples, I think the packaging currently is wrong. The examples package weld (cdi implementation), but rely on a provided cdi-api. The cdi-api should simply be added as a compile dependency to the examples. Emond On Fri, Mar 13, 2020 at 2:59 AM Maxim Solodovnik wrote: > > Maybe

Re: CSPRequestCycleListener headers

). > > Before you took over, CSPNonceHeaderResponseDecorator wrote the CSP > headers in http-equiv tags. > What was your reason to change this to HTTP headers in the first place? > > Regards > Sven > > > On 12.03.20 14:02, Emond Papegaaij wrote: > > Hi Sven, > > > > Ye

Re: CSPRequestCycleListener headers

Hi Sven, Yes, you might be right. When rendering another page, normally the header will be overridden when the second handler is resolved. However, this will not happen when the page is not protected (protectedPageFilter). Do you see a solution for this? Maybe recording the desired action in the

Re: [VOTE] Release Apache Wicket 9.0.0-M5

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

Re: CSP and UI libraries

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

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

Hi Andrew, I thought of this solution as well and it will work. The major advantage is that the styling is only added when it is actually used. But it requires significantly more work to build and is a lot more complex than the current solution. For this, we need some place to accumulate element

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

On Thu, Feb 27, 2020 at 11:56 AM Ernesto Reinaldo Barreiro wrote: > On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene > > In which way sub-frameworks should be affected? I mean, as far as I > > understand it, if we disable CSP blocking configuration everything should > > work "the old way", and

Re: CSP and UI libraries

Hi Martin and Sebastien, I see no need for checking if CSP is enabled or not. It is not hard to write your code to comply to even the strictest CSP. If it works with the strict CSP, it will also work when CSP is disabled or with a less strict CSP. Simply follow the few rules explained in the user

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

On Wed, Feb 26, 2020 at 10:53 AM Martin Grigorov wrote: > I am also not big fan of CSP but users ask for it and I see no other way > but to move all inline styles in such .css resource IMHO CSP is one of the changes to the web application ecosystem that Wicket will need an answer on to stay

Re: buildbot failure in on wicket-master

n-wicket-master-commit' triggered this build > Build Source Stamp: [branch master] 4d8d8503524dd46c087a398f061685ab310e7856 > Blamelist: Emond Papegaaij > > BUILD FAILED: failed compile > > Sincerely, > -The Buildbot > > >

Re: Form submit via Javascript and event handlers

ormOnsubmit' > You can fix it in 'csp' branch before merging to master > > On Wed, Feb 5, 2020 at 11:22 PM Emond Papegaaij > wrote: > > > This is what I have in mind: > > > > https://github.com/apache/wicket/commit/b54938053a5bda2f4577966779d580e828f16e47 > >

Re: Form submit via Javascript and event handlers

in behavior though and might break existing applications. Emond On Wed, Feb 5, 2020 at 10:01 PM Emond Papegaaij wrote: > > On Wed, Feb 5, 2020 at 9:57 PM Emond Papegaaij > wrote: > > While fixing the CSP violations in the examples, I noticed a strange > > situation in SubmitL

Re: Form submit via Javascript and event handlers

On Wed, Feb 5, 2020 at 9:57 PM Emond Papegaaij wrote: > While fixing the CSP violations in the examples, I noticed a strange > situation in SubmitLink example: > http://examples8x.wicket.apache.org/compref/wicket/bookmarkable/org.apache.wicket.examples.compref.SubmitLinkPage > >

Form submit via Javascript and event handlers

Hi, While fixing the CSP violations in the examples, I noticed a strange situation in SubmitLink example: http://examples8x.wicket.apache.org/compref/wicket/bookmarkable/org.apache.wicket.examples.compref.SubmitLinkPage In this example, the internal submit link immediately submits the form,

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

t; > its value in Dev Tools > Performance tab. I don't recall the name of the > > header at the moment. > > > > https://ma.ttias.be/server-timings-chrome-devtools/ > > > > > > On Tue, Feb 4, 2020 at 9:39 PM Emond Papegaaij > > wrote: > > > >> Hi all,

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

Hi all, Do you agree on this one? I see no use for these classes anymore, as support for window.defaultStatus has been dropped by all major browsers. They also log server time, but we have other and better solutions for that. Best regards, Emond On Tue, Feb 4, 2020 at 8:37 PM Emond Papegaaij

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

725: fixed special Form placeholder rendering > > fb290e8 is described below > > > > commit fb290e818a278eb69f4fa64d77514d8f3ee3068c > > Author: Emond Papegaaij > > AuthorDate: Tue Jan 28 21:18:50 2020 +0100 > > > > WICKET-6725: fixed special Form pl

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

added to refs/heads/csp by this push: > > new 9ad2079 WICKET-6731: move inline onclick to event handler > > 9ad2079 is described below > > > > commit 9ad20795847e146db5a536f90bc734f47386cc11 > > Author: Emond Papegaaij > > AuthorDate: Fri J

Re: CSP in Wicket 9

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

Re: CSP in Wicket 9

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

Re: CSP in Wicket 9

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 >

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

> > + random = SecureRandom.getInstanceStrong(); > > > > Since we have now CryptingPageStore it is possible that an application > store some pages with algo X. > If the application is clustered and rolling upgrade is done with a new > version of JDK it is possible that the

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

Hi all, The CSP branch started to get a bit of a mess with work on different parts of Wicket combined in one branch. I've reworked the commits, put some of them on master, and split the rest on 2 branches: csp-display-none and csp-configurable. Those are for reviewing the code. I'll open a pull

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

t; > > How about such CSS rule: > > > > > > [data-wicket-placeholder][hidden] > > > { > > >display : none !important; > > > } > > > > > > ? > > > > > > > > >> Sven > > >> > >

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

gt; > > Hi Edmond, > > > > > > > > then I'll ask again: > > > > > > > > Why not render a "hidden" attribute and style it in the core css: > > > > > > > > |[hidden] { display: none !important}| > > > > > >

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

without styling packaged with Wicket (like with FeedbackPanel). The styling is not going to match the users application anyway. Who would want to use red as a color for a border? Even for me, being colorblind, that color is way too saturated. Best regards, Emond > > Have fun > Sven|| >

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

isteners()` > >> > > >> > On Tue, 14 Jan 2020 at 16:03, Maxim Solodovnik > > > >> wrote: > >> > > >> >> `!important` is not the silver bullet (as well as inline style) > >> >> > >> >> `renderHead` is not

Re: CSP in Wicket 9

by default I've already started the work on the 'csp' branch. On this branch, I've also migrated all but the servlet API to the jakarta namespace. Best regards, Emond On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij wrote: > > Searching through our Jira, I've found WICKET-6687, filed by

Re: CSP in Wicket 9

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

CSP in Wicket 9

Hi all, For the past few days I've been experimenting with the new CSP features in Wicket 9. I really want to thank Andrew, Sven and Martin for the great work you guys did in making this possible. I'm getting very close to running my application with a very tight and secure CSP. Unfortunately,

Re: Jakarta EE 8 vs Java EE 8 APIs

(WicketEndpoint.java:65) at org.eclipse.jetty.websocket.javax.common.JavaxWebSocketFrameHandler.onOpen(JavaxWebSocketFrameHandler.java:197) On Fri, Jan 10, 2020 at 3:32 PM Martin Grigorov wrote: > > On Fri, Jan 10, 2020 at 4:03 PM Emond Papegaaij > wrote: > > > I tend to agree

Re: Jakarta EE 8 vs Java EE 8 APIs

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

Re: Jakarta EE 8 vs Java EE 8 APIs

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

Jakarta EE 8 vs Java EE 8 APIs

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

Re: Building with JDK 14 ea

> >>> > > >>> > On Fri, 10 Jan 2020 at 15:56, Martin Grigorov > >>> > wrote: > >>> > > >>> >> Hi Emond, > >>> >> > >>> >> Locally while testing new JDK builds I always use: mvn14 clean

ChainingModel.getChainedModel in 9

Hi all, With the Wicket 9 release coming closer, I decided to give our code base a try. Most of the compilation problems were easy to fix, but I'm missing ChaningModel.getChainedModel(). This method was deleted with the removal of the IChainingModel interface (which I do not need). Without this

Re: wicket-ajax.js cleanup

On vrijdag 3 mei 2019 17:16:02 CEST Sven Meier wrote: > JS Tests are not built each time, so npm is not a requirement to build > Wicket. I'd like to keep it that way. With the frontend-maven-plugin it isn't required to have it installed on your system. The plugin will download node and npm as

Re: wicket-ajax.js cleanup

Hi, We use the frontend-maven-plugin, which automatically downloads and installs node as part of your maven build. It works quite ok. Emond On vrijdag 3 mei 2019 11:56:14 CEST Andrew Kondratev wrote: > Thank you. I understand these concerns. > > Speaking about performance concern, if node is

Re: Maven enforcer breakage...

This is not something we can fix in Wicket. Dependency management is not transitive over dependencies. Wicket already manages commons-io at version 2.5. To fix this error, you'll need to manage the version of commons-io yourself. Best regards, Emond Papegaaij On donderdag 24 januari 2019 12

Re: [VOTE] Release Apache Wicket 7.11.0

As Wicket 7 is supposed to be built with jdk7, why not simply add the profile but not enable it by default when on jdk8? If you want build with jdk8 (or higher), you can enable the profile on the command line. Best regards, Emond On maandag 26 november 2018 10:43:55 CET Maxim Solodovnik wrote:

Re: [VOTE] Release Apache Wicket 8.1.0

gin: > https://stackoverflow.com/questions/44848409/cdi-invalid-bean-archive-scanni > ng-in-jetty-not-in-tomcat. It should affect 8.0.0 as well, I will check it. > IMHO is not a blocking issue. > > On Wed, Sep 12, 2018 at 10:20 AM Emond Papegaaij > > wrote: > > H

Re: [VOTE] Release Apache Wicket 8.1.0

Hi, I'm trying to test the examples, but all I get is '503 Service Unavailable' and several stacktraces in the terminal: java.lang.IllegalStateException: WELD-ENV-33: Invalid bean archive scanning result - found multiple results with the same reference: /home/

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

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

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

Hi Sven, Thanks for the work you have put into this. However, this is an enormous amount of code to review so this will take some time. I'll try to get this done this week, but I can't promise anything. For now, I can at least comment on CryptingPageStore.java. The ciphers used by this store

Re: buildbot failure in on wicket-master

be removed, right? AFAIK we now only support SSR356 compliant containers. Best regards, Emond On vrijdag 18 mei 2018 13:35:42 CEST Emond Papegaaij wrote: > I highly doubt my commit caused this failure: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin: 3.6.

Re: [VOTE] Release Apache Wicket 8.0.0

+1 Tested our application with the complete test suite Checked signatures and hashes I did notice some misplaced managed dependencies in the root pom for projects that no longer exist, but that should not stop the release. Best regards, Emond On donderdag 17 mei 2018 22:30:20 CEST Pedro

Re: [DISCUSSION] Wicket 8 Release

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

Re: [DISCUSSION] Wicket 8 Release

On dinsdag 10 april 2018 14:22:21 CEST Martijn Dashorst wrote: > On Tue, Apr 10, 2018 at 2:09 PM, Maxim Solodovnik wrote: > > Current version is Java 10 (non LTS) > > Maybe we can release 8.0.0 and add this to Wicket 9 ? > > The issue is that you can't upgrade to Java 11

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

ontact me! > https://twitter.com/mtgrigorov > > > On Tue, Feb 6, 2018 at 1:52 PM, Emond Papegaaij <emond.papega...@topicus.nl> > wrote: > > On dinsdag 6 februari 2018 13:49:03 CET Martin Grigorov (JIRA) wrote: > > > Martin Grigorov updated WICKET-6530: > > >

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

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

Re: Quick start and https/TLS/SSL

-1 I agree, application servers, such as WildFly provide similar solutions. By default WildFly will generate a self-signed certificate for the https/h2 listener. Emond On dinsdag 16 januari 2018 05:10:32 CET Maxim Solodovnik wrote: > -1 > > I believe it's good to have HTTPS configuration

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

cheduler named > 'on-wicket-branch-7.x-commit' triggered this build Build Source Stamp: > [branch wicket-7.x] a352fe2befbbf6ce60c1d9617df34f54fa7190ac Blamelist: > Emond Papegaaij <papega...@apache.org> > > BUILD FAILED: failed compile > > Sincerely, > -The Buildbot

Re: File upload "too large" error managing

Hi, I've seen the error you describe before. It happened to me when a file- submitting ajax call fails when using a Content-Security-Policy. The problem is that an error is returned to the browser (in my case Chrome), which renders an error page inside the iframe used to submit files via ajax.

Re: [VOTE] Release Apache Wicket 7.8.1 take 2

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

Re: [VOTE] Release Apache Wicket 7.8.1

t;> > > > >>> > > Sorry to bother you, but Francois Meillet has discovered a bug that > >>> > > >>> > might be serious: WICKET-6462. In short, due to this bug > >>> > AjaxFormSubmitBehavior#onSubmit is called twice

Re: [VOTE] Release Apache Wicket 7.8.1

+1 Reviewed all code changed between 7.8.0 and 7.8.1 Emond On vrijdag 1 september 2017 11:37:22 CEST Martijn Dashorst wrote: > +1 > > Martijn > > > On Wed, Aug 30, 2017 at 9:34 PM, Andrea Del Bene > > wrote: > > This is a vote to release Apache Wicket 7.8.1 > > > >

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

I've applied to fix to 6.x, 7.x and 8 (master). IMHO this issue warrants a patch-release for at least 6 (6.27.1) and 7 (7.8.1). Best regards, Emond On dinsdag 29 augustus 2017 15:26:06 CEST Martijn Dashorst wrote: > https://issues.apache.org/jira/browse/WICKET-6387 > > The original fix

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

I've created an issue to track this regression and a PR with my proposed fix: https://github.com/apache/wicket/pull/231 Emond On dinsdag 29 augustus 2017 15:26:06 CEST Martijn Dashorst wrote: > https://issues.apache.org/jira/browse/WICKET-6387 > > The original fix apparently introduces the

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

pos/asf/wicket/repo > > Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/6963c723 > > Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/6963c723 > > Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/6963c723 > > > > Branch: refs/hea

Re: Proposal to move @FunctionalInteface from IModel

On maandag 10 april 2017 23:48:27 CEST Pedro Santos wrote: > Hi Emond, > > > Your proposal will not work because Java does not resolve functional > > interfaces to subtypes of the target type. For example, take the Label > > constructor: > I know, and that is just a good thing. Take TextField for

Re: Proposal to move @FunctionalInteface from IModel

Hi Pedro, Your proposal will not work because Java does not resolve functional interfaces to subtypes of the target type. For example, take the Label constructor: public Label(String id, IModel model) I would like to use this constructor as follows: new Label("id", Math::random) In Wicket 8

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

The vote is closed with: 1x Yes, remove IDetachable from IModel 7x No, keep IModel detachable So we can conclude that IModel will remain detachable. Best regards, Emond On maandag 3 april 2017 09:38:03 CEST Emond Papegaaij wrote: > Something went wrong sending this mail. I did write some m

Review WICKET-6353

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

  1   2   3   4   >