[jira] [Commented] (WICKET-7120) Improve Accessibility of AutoCompleteBehavior

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870419#comment-17870419
 ] 

ASF GitHub Bot commented on WICKET-7120:


renoth commented on PR #933:
URL: https://github.com/apache/wicket/pull/933#issuecomment-2264923458

   I created https://issues.apache.org/jira/browse/WICKET-7120 and hopefully 
fixed the compiler errors in js




> Improve Accessibility of AutoCompleteBehavior
> -
>
> Key: WICKET-7120
> URL: https://issues.apache.org/jira/browse/WICKET-7120
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-extensions
>Reporter: Johannes Renoth
>Priority: Minor
>
> AutoCompleteBehavior does not generate Markup that is read correctly by a 
> screenreader.
> This configuration will work with NVDA 2024.2 and the latest Firefox
> {code:java}
> input must have
> role="combobox"
> aria-expanded="true/false"
> autocomplete="off"
> aria-autocomplete="list"
> aria-controls=$ID
> ul must have
> role="listbox"
> id=$ID
> li must have
> role="option"
> aria-posinset: Item Position
> aria-setsize: length of List
> aria-selected: true when selected / false when not
> tabindex="-1" {code}
> This ensures that the Options are read correctly by a screenreader when 
> channing the selection via keyboard (arrow up/down)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7119) 5 unit tests are non-idempotent (passes in the first run but fails in subsequent runs in the same environment)

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17869546#comment-17869546
 ] 

ASF GitHub Bot commented on WICKET-7119:


martin-g commented on PR #929:
URL: https://github.com/apache/wicket/pull/929#issuecomment-2257619329

   Thank you, @kaiyaok2 !




> 5 unit tests are non-idempotent (passes in the first run but fails in 
> subsequent runs in the same environment)
> --
>
> Key: WICKET-7119
> URL: https://issues.apache.org/jira/browse/WICKET-7119
> Project: Wicket
>  Issue Type: Bug
>Reporter: Kaiyao Ke
>Priority: Major
>
> List of non-idempotent tests:
> org.apache.wicket.util.string.StringsTest#stripJSessionId
> org.apache.wicket.resource.FileSystemResourceReferenceTest#testFileSystemResourceReferenceWithZip
> org.apache.wicket.markup.repeater.AbstractPageableViewTest#cachedItemCount
> org.apache.wicket.ComponentOnConfigureTest#order
> org.apache.wicket.pageStore.AbstractPersistentPageStoreTest#rebindingAttributeDoesNotRemoveAllPages
> Will open a PR to fix them



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7119) 5 unit tests are non-idempotent (passes in the first run but fails in subsequent runs in the same environment)

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17869541#comment-17869541
 ] 

ASF GitHub Bot commented on WICKET-7119:


martin-g merged PR #929:
URL: https://github.com/apache/wicket/pull/929




> 5 unit tests are non-idempotent (passes in the first run but fails in 
> subsequent runs in the same environment)
> --
>
> Key: WICKET-7119
> URL: https://issues.apache.org/jira/browse/WICKET-7119
> Project: Wicket
>  Issue Type: Bug
>Reporter: Kaiyao Ke
>Priority: Major
>
> List of non-idempotent tests:
> org.apache.wicket.util.string.StringsTest#stripJSessionId
> org.apache.wicket.resource.FileSystemResourceReferenceTest#testFileSystemResourceReferenceWithZip
> org.apache.wicket.markup.repeater.AbstractPageableViewTest#cachedItemCount
> org.apache.wicket.ComponentOnConfigureTest#order
> org.apache.wicket.pageStore.AbstractPersistentPageStoreTest#rebindingAttributeDoesNotRemoveAllPages
> Will open a PR to fix them



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7119) 5 unit tests are non-idempotent (passes in the first run but fails in subsequent runs in the same environment)

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17868419#comment-17868419
 ] 

ASF GitHub Bot commented on WICKET-7119:


kaiyaok2 opened a new pull request, #929:
URL: https://github.com/apache/wicket/pull/929

   Fixes https://issues.apache.org/jira/browse/WICKET-7119
   
   # The Problem
   
   
   Some unit tests are non-idempotent, as they pass in the first run but fail 
in the second run in the same environment. A fix is necessary since unit tests 
shall be self-contained, ensuring that the state of the system under test is 
consistent at the beginning of each test. In practice, fixing non-idempotent 
tests can help proactively avoid state pollution that results in test order 
dependency (which could cause problems under test selection, prioritization or 
parallelization).
   
   
   # Reproduce
   
   
   Using the `NIOInspector` plugin that supports rerunning JUnit tests in the 
same environment. Use 
`org.apache.wicket.util.string.StringsTest#stripJSessionId` as an example:
   ```
   cd wicket-util
   mvn edu.illinois:NIOInspector:rerun 
-Dtest=org.apache.wicket.util.string.StringsTest#stripJSessionId
   
   ```
   
   
   # 5 Non-Idempotent Tests & Proposed Fix
   ## org.apache.wicket.util.string.StringsTest#stripJSessionId
   Reason: The `SESSION_ID_PARAM` field in `Strings`(see 
https://github.com/apache/wicket/blob/37c80e8c54533257c9fc5737424847a61e889b4e/wicket-util/src/main/java/org/apache/wicket/util/string/Strings.java#L74)
 contains semicolon by default, but `stripJSessionId()` resets it to 
`"jsessionid"` (see 
https://github.com/apache/wicket/blob/37c80e8c54533257c9fc5737424847a61e889b4e/wicket-util/src/test/java/org/apache/wicket/util/string/StringsTest.java#L62)
 when doing cleanup. As a result, `assertEquals(url, 
Strings.stripJSessionId(url + ";jsessionid=12345"));` will fail in the second 
test execution due to the missing semicolon.
   
   Error message of the test in the repeated run:
   ```
   org.opentest4j.AssertionFailedError: expected:  but 
was: 
at 
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at 
org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at 
org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
at 
org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
at 
org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)
at 
org.apache.wicket.util.string.StringsTest.stripJSessionId(StringsTest.java:43)
   ```
   Fix: Save the original value of the field `SESSION_ID_PARAM` before 
modifying it, and restore it to the saved value at the end of the test.
   
   
   
   ## 
org.apache.wicket.resource.FileSystemResourceReferenceTest#testFileSystemResourceReferenceWithZip
   Reason: `FileSystemAlreadyExistsException` occurs when calling 
`FileSystemResourceReference.getPath()` because the file system for the zip 
file is already mounted when the test is executed a second time. 
   
   Error message in the repeated run:
   ```
   java.nio.file.FileSystemAlreadyExistsException: null
at 
jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:104)
at 
java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:339)
at 
java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:288)
at 
org.apache.wicket.resource.FileSystemJarPathService.getPath(FileSystemJarPathService.java:75)
at 
org.apache.wicket.resource.FileSystemResourceReference.getPath(FileSystemResourceReference.java:180)
at 
org.apache.wicket.resource.FileSystemResourceReference.getPath(FileSystemResourceReference.java:204)
at 
org.apache.wicket.resource.FileSystemResourceReferenceTest.testFileSystemResourceReferenceWithZip(FileSystemResourceReferenceTest.java:58)
   ```
   Fix: Check if the file system for the zip file is already available before 
creating a new one.
   
   
   
   ## org.apache.wicket.markup.repeater.AbstractPageableViewTest#cachedItemCount
   Reason: `View.getItemCount()` calls `View.internalGetItemCount()`, which is 
dependent on the static variable `count`. The test `cachedItemCount()` resets 
`count` to 8 without resetting it, so in the second test execution 
`view.getItemCount()` would be 8 instead of 5.
   
   Error message of one of the tests in the repeated run:
   ```
   org.opentest4j.AssertionFailedError: expected: <5> but was: <8>
at 
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at 
org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at 

[jira] [Commented] (WICKET-7115) Spelling corrections, and removal of non-breaking spaces. Some doc improvements

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862510#comment-17862510
 ] 

ASF GitHub Bot commented on WICKET-7115:


jstuyts opened a new pull request, #904:
URL: https://github.com/apache/wicket/pull/904

   Clean up of text in code and documentation: spelling corrections, and 
replacement of non-breaking spaces with regular spaces. Some small improvements 
to Javadoc and example code in documentation.




> Spelling corrections, and removal of non-breaking spaces. Some doc 
> improvements
> ---
>
> Key: WICKET-7115
> URL: https://issues.apache.org/jira/browse/WICKET-7115
> Project: Wicket
>  Issue Type: Improvement
>  Components: guide, wicket-core, wicket-examples, wicket-extensions
>Affects Versions: 10.0.0
>Reporter: Johan Stuyts
>Assignee: Andrea Del Bene
>Priority: Trivial
> Fix For: 10.2.0
>
>
> There are a number of spelling mistakes in both documentation and code. And 
> non-breaking space are used where they are not needed.
> While fixing those, I also found:
>  * The documentation of `ResourceNameIterator` could be improved.
>  * A few small improvements in the example code in the documentation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7111) Greek Application i18n is broken due to wrong file name

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849828#comment-17849828
 ] 

ASF GitHub Bot commented on WICKET-7111:


martin-g commented on PR #879:
URL: https://github.com/apache/wicket/pull/879#issuecomment-2134028783

   Thank you, @mscoon !




> Greek Application i18n is broken due to wrong file name
> ---
>
> Key: WICKET-7111
> URL: https://issues.apache.org/jira/browse/WICKET-7111
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
>
> See https://lists.apache.org/thread/4rqsmgkl6y3v8674vh2ssqcs9cpxp4ok
> PR: https://github.com/apache/wicket/pull/879



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7111) Greek Application i18n is broken due to wrong file name

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849826#comment-17849826
 ] 

ASF GitHub Bot commented on WICKET-7111:


martin-g merged PR #879:
URL: https://github.com/apache/wicket/pull/879




> Greek Application i18n is broken due to wrong file name
> ---
>
> Key: WICKET-7111
> URL: https://issues.apache.org/jira/browse/WICKET-7111
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
>
> See https://lists.apache.org/thread/4rqsmgkl6y3v8674vh2ssqcs9cpxp4ok
> PR: https://github.com/apache/wicket/pull/879



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7107) CSP Header not rendered when using RedirectPolicy.AUTO_REDIRECT

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848897#comment-17848897
 ] 

ASF GitHub Bot commented on WICKET-7107:


dr0ps commented on code in PR #846:
URL: https://github.com/apache/wicket/pull/846#discussion_r1611370030


##
wicket-core/src/main/java/org/apache/wicket/csp/CSPRequestCycleListener.java:
##
@@ -39,14 +40,7 @@ public CSPRequestCycleListener(ContentSecurityPolicySettings 
settings)
}
 
@Override
-   public void onRequestHandlerResolved(RequestCycle cycle, 
IRequestHandler handler)
-   {
-   // WICKET-7028- this is needed for redirect to buffer use case.
-   protect(cycle, handler);
-   }
-
-   @Override
-   public void onRequestHandlerExecuted(RequestCycle cycle, 
IRequestHandler handler)
+   public void onUrlMapped(RequestCycle cycle, IRequestHandler handler, 
Url url)

Review Comment:
   WICKET-7040 is never going to work, I think. Due to ajax requests, 
components can be instantiated long after the original page has been created 
and long after the original CSP has been sent to the browser. Additional CPSs 
could be delivered to the client as meta tags but weakening the original CSP is 
not allowed ( https://www.w3.org/TR/CSP3/#multiple-policies ). Therefore the 
strictest possible set of policies has to be known before the page is rendered.





> CSP Header not rendered when using RedirectPolicy.AUTO_REDIRECT
> ---
>
> Key: WICKET-7107
> URL: https://issues.apache.org/jira/browse/WICKET-7107
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 9.16.0
>Reporter: Dirk Forchel
>Priority: Major
> Attachments: myproject.zip
>
>
> If we redirect to another Web Page and use the RedirectPolicy.AUTO_REDIRECT, 
> this results in the CSP directives being missing in the head of the result 
> page.
> I've attached a quickstart application to show the error. Just browse to 
> [http://localhost:8080/redirect|http://localhost:8080/redirect.] and use the 
> browser's developer console of your choice. The CSP is not included if Wicket 
> performs a RestartResponseException with a WebPage instance like this
> {code:java}
> throw new RestartResponseException(new HomePage(new PageParameters()));{code}
> If you open the home page directly 
> [http://localhost:8080/|http://localhost:8080/redirect.] the response does 
> include a CSP.
> There is an additional test for the CSPRequestCycleListener with different 
> page classes as test parameters.
> Relates to https://issues.apache.org/jira/browse/WICKET-7028



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7110) Add stack trace of lock holding thread in CouldNotLockPageException

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845973#comment-17845973
 ] 

ASF GitHub Bot commented on WICKET-7110:


dashorst merged PR #861:
URL: https://github.com/apache/wicket/pull/861




> Add stack trace of lock holding thread in CouldNotLockPageException
> ---
>
> Key: WICKET-7110
> URL: https://issues.apache.org/jira/browse/WICKET-7110
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Martijn Dashorst
>Assignee: Martijn Dashorst
>Priority: Minor
>
> Currently we only log the stack trace of the thread that keeps the lock on 
> the page when we can't claim a lock. It is beneficial to set the cause of the 
> CouldNotLockPageException to an exception that shows the stack trace elements 
> of the thread holding the lock.
> This way you can see in the monitoring what was the cause instead of having 
> to go look for the holding (e.g. slow) page in the logs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7110) Add stack trace of lock holding thread in CouldNotLockPageException

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845228#comment-17845228
 ] 

ASF GitHub Bot commented on WICKET-7110:


dashorst commented on code in PR #861:
URL: https://github.com/apache/wicket/pull/861#discussion_r1596388032


##
wicket-core/src/main/java/org/apache/wicket/page/DefaultPageLockManager.java:
##
@@ -222,3 +227,12 @@ Supplier> getLocks()
return locks;
}
 }
+
+static class PageLockedException extends Exception
+{

Review Comment:
   ️ 
   
   The exception has no reuse outside the DefaultPageLockManager, I thought 
about making it a local class, but then you get those enclosures in your stack 
traces, which I don't like. So this should get both requirements: no strange 
stack trace names and no reuse.
   





> Add stack trace of lock holding thread in CouldNotLockPageException
> ---
>
> Key: WICKET-7110
> URL: https://issues.apache.org/jira/browse/WICKET-7110
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Martijn Dashorst
>Assignee: Martijn Dashorst
>Priority: Minor
>
> Currently we only log the stack trace of the thread that keeps the lock on 
> the page when we can't claim a lock. It is beneficial to set the cause of the 
> CouldNotLockPageException to an exception that shows the stack trace elements 
> of the thread holding the lock.
> This way you can see in the monitoring what was the cause instead of having 
> to go look for the holding (e.g. slow) page in the logs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7110) Add stack trace of lock holding thread in CouldNotLockPageException

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845100#comment-17845100
 ] 

ASF GitHub Bot commented on WICKET-7110:


martin-g commented on code in PR #861:
URL: https://github.com/apache/wicket/pull/861#discussion_r1595848322


##
wicket-core/src/main/java/org/apache/wicket/page/DefaultPageLockManager.java:
##
@@ -222,3 +227,12 @@ Supplier> getLocks()
return locks;
}
 }
+
+static class PageLockedException extends Exception
+{

Review Comment:
   > this is outside the surrounding class
   
   who does this ?! :-)
   why not create its own class ? because you will need to add a license at the 
top ? :-)





> Add stack trace of lock holding thread in CouldNotLockPageException
> ---
>
> Key: WICKET-7110
> URL: https://issues.apache.org/jira/browse/WICKET-7110
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Martijn Dashorst
>Assignee: Martijn Dashorst
>Priority: Minor
>
> Currently we only log the stack trace of the thread that keeps the lock on 
> the page when we can't claim a lock. It is beneficial to set the cause of the 
> CouldNotLockPageException to an exception that shows the stack trace elements 
> of the thread holding the lock.
> This way you can see in the monitoring what was the cause instead of having 
> to go look for the holding (e.g. slow) page in the logs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7110) Add stack trace of lock holding thread in CouldNotLockPageException

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845028#comment-17845028
 ] 

ASF GitHub Bot commented on WICKET-7110:


dashorst commented on code in PR #861:
URL: https://github.com/apache/wicket/pull/861#discussion_r1595595605


##
wicket-core/src/main/java/org/apache/wicket/page/DefaultPageLockManager.java:
##
@@ -222,3 +227,12 @@ Supplier> getLocks()
return locks;
}
 }
+
+static class PageLockedException extends Exception
+{

Review Comment:
   ```suggestion
   class PageLockedException extends Exception
   {
   ```
   @martin-g this is outside the surrounding class, so it is already static. 
The compiler also complains:
   
   ```
   Error:  
/home/runner/work/wicket/wicket/wicket-core/src/main/java/org/apache/wicket/page/DefaultPageLockManager.java:[231,8]
 modifier static not allowed here
   ```
   





> Add stack trace of lock holding thread in CouldNotLockPageException
> ---
>
> Key: WICKET-7110
> URL: https://issues.apache.org/jira/browse/WICKET-7110
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Martijn Dashorst
>Assignee: Martijn Dashorst
>Priority: Minor
>
> Currently we only log the stack trace of the thread that keeps the lock on 
> the page when we can't claim a lock. It is beneficial to set the cause of the 
> CouldNotLockPageException to an exception that shows the stack trace elements 
> of the thread holding the lock.
> This way you can see in the monitoring what was the cause instead of having 
> to go look for the holding (e.g. slow) page in the logs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7110) Add stack trace of lock holding thread in CouldNotLockPageException

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844994#comment-17844994
 ] 

ASF GitHub Bot commented on WICKET-7110:


dashorst commented on code in PR #861:
URL: https://github.com/apache/wicket/pull/861#discussion_r1595497973


##
wicket-core/src/main/java/org/apache/wicket/page/DefaultPageLockManager.java:
##
@@ -222,3 +227,12 @@ Supplier> getLocks()
return locks;
}
 }
+
+class PageLockedException extends Exception
+{
+   PageLockedException(Thread previousThread, int pageId) 
+   {
+   super("This thread " + previousThread.getName() + " holds the 
lock to page " + pageId);
+   setStackTrace(previousThread.getStackTrace());

Review Comment:
   ```suggestion
super("This thread " + pageHoldingThread.getName() + " holds 
the lock to page " + pageId);
setStackTrace(pageHoldingThread.getStackTrace());
   ```





> Add stack trace of lock holding thread in CouldNotLockPageException
> ---
>
> Key: WICKET-7110
> URL: https://issues.apache.org/jira/browse/WICKET-7110
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Martijn Dashorst
>Assignee: Martijn Dashorst
>Priority: Minor
>
> Currently we only log the stack trace of the thread that keeps the lock on 
> the page when we can't claim a lock. It is beneficial to set the cause of the 
> CouldNotLockPageException to an exception that shows the stack trace elements 
> of the thread holding the lock.
> This way you can see in the monitoring what was the cause instead of having 
> to go look for the holding (e.g. slow) page in the logs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7110) Add stack trace of lock holding thread in CouldNotLockPageException

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844993#comment-17844993
 ] 

ASF GitHub Bot commented on WICKET-7110:


dashorst commented on code in PR #861:
URL: https://github.com/apache/wicket/pull/861#discussion_r1595496779


##
wicket-core/src/main/java/org/apache/wicket/page/DefaultPageLockManager.java:
##
@@ -133,9 +133,10 @@ public void lockPage(int pageId) throws 
CouldNotLockPageException
}
else
{
+   final String previousThreadName = previous != null ? 
previous.getThread().getName() : "N/A";
+   final Thread previousThread = previous != null ? 
previous.getThread() : null;

Review Comment:
   ```suggestion
final Thread previousThread = previous != null ? 
previous.getThread() : null;
final String previousThreadName = previousThread != 
null ? previousThread.getName() : "N/A";
   ```





> Add stack trace of lock holding thread in CouldNotLockPageException
> ---
>
> Key: WICKET-7110
> URL: https://issues.apache.org/jira/browse/WICKET-7110
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Martijn Dashorst
>Assignee: Martijn Dashorst
>Priority: Minor
>
> Currently we only log the stack trace of the thread that keeps the lock on 
> the page when we can't claim a lock. It is beneficial to set the cause of the 
> CouldNotLockPageException to an exception that shows the stack trace elements 
> of the thread holding the lock.
> This way you can see in the monitoring what was the cause instead of having 
> to go look for the holding (e.g. slow) page in the logs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7110) Add stack trace of lock holding thread in CouldNotLockPageException

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844988#comment-17844988
 ] 

ASF GitHub Bot commented on WICKET-7110:


martin-g commented on code in PR #861:
URL: https://github.com/apache/wicket/pull/861#discussion_r1595479754


##
wicket-core/src/main/java/org/apache/wicket/page/DefaultPageLockManager.java:
##
@@ -222,3 +227,12 @@ Supplier> getLocks()
return locks;
}
 }
+
+class PageLockedException extends Exception
+{
+   PageLockedException(Thread previousThread, int pageId) 

Review Comment:
   ```suggestion
PageLockedException(Thread pageHoldingThread, int pageId) 
   ```



##
wicket-core/src/main/java/org/apache/wicket/page/DefaultPageLockManager.java:
##
@@ -133,9 +133,10 @@ public void lockPage(int pageId) throws 
CouldNotLockPageException
}
else
{
+   final String previousThreadName = previous != null ? 
previous.getThread().getName() : "N/A";
+   final Thread previousThread = previous != null ? 
previous.getThread() : null;

Review Comment:
   nit: swap these two lines and simplify the latter to: `final String 
previousThreadName = previousThread != null ? previousThread.getName() : "N/A";`



##
wicket-core/src/main/java/org/apache/wicket/page/DefaultPageLockManager.java:
##
@@ -222,3 +227,12 @@ Supplier> getLocks()
return locks;
}
 }
+
+class PageLockedException extends Exception

Review Comment:
   ```suggestion
   static class PageLockedException extends Exception
   ```





> Add stack trace of lock holding thread in CouldNotLockPageException
> ---
>
> Key: WICKET-7110
> URL: https://issues.apache.org/jira/browse/WICKET-7110
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Martijn Dashorst
>Assignee: Martijn Dashorst
>Priority: Minor
>
> Currently we only log the stack trace of the thread that keeps the lock on 
> the page when we can't claim a lock. It is beneficial to set the cause of the 
> CouldNotLockPageException to an exception that shows the stack trace elements 
> of the thread holding the lock.
> This way you can see in the monitoring what was the cause instead of having 
> to go look for the holding (e.g. slow) page in the logs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7110) Add stack trace of lock holding thread in CouldNotLockPageException

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844982#comment-17844982
 ] 

ASF GitHub Bot commented on WICKET-7110:


dashorst opened a new pull request, #861:
URL: https://github.com/apache/wicket/pull/861

   Adds the stack trace of the thread holding the lock of a page in case of
   a timeout trying to acquire a lock. This is quite handy when trying to
   figure out what caused the CouldNotLockPageException without having to
   go sift through logs.
   




> Add stack trace of lock holding thread in CouldNotLockPageException
> ---
>
> Key: WICKET-7110
> URL: https://issues.apache.org/jira/browse/WICKET-7110
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Martijn Dashorst
>Priority: Minor
>
> Currently we only log the stack trace of the thread that keeps the lock on 
> the page when we can't claim a lock. It is beneficial to set the cause of the 
> CouldNotLockPageException to an exception that shows the stack trace elements 
> of the thread holding the lock.
> This way you can see in the monitoring what was the cause instead of having 
> to go look for the holding (e.g. slow) page in the logs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7107) CSP Header not rendered when using RedirectPolicy.AUTO_REDIRECT

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844975#comment-17844975
 ] 

ASF GitHub Bot commented on WICKET-7107:


reiern70 commented on code in PR #846:
URL: https://github.com/apache/wicket/pull/846#discussion_r1595398663


##
wicket-core/src/main/java/org/apache/wicket/csp/CSPRequestCycleListener.java:
##
@@ -39,14 +40,7 @@ public CSPRequestCycleListener(ContentSecurityPolicySettings 
settings)
}
 
@Override
-   public void onRequestHandlerResolved(RequestCycle cycle, 
IRequestHandler handler)
-   {
-   // WICKET-7028- this is needed for redirect to buffer use case.
-   protect(cycle, handler);
-   }
-
-   @Override
-   public void onRequestHandlerExecuted(RequestCycle cycle, 
IRequestHandler handler)
+   public void onUrlMapped(RequestCycle cycle, IRequestHandler handler, 
Url url)

Review Comment:
   I have tried this change with 
   
   https://issues.apache.org/jira/browse/WICKET-7028
   
   sample application and this change seems to be Ok. But to be honest I'm not 
sure this is the way we should go.  See 
   
   https://issues.apache.org/jira/browse/WICKET-7040
   
   
   
   





> CSP Header not rendered when using RedirectPolicy.AUTO_REDIRECT
> ---
>
> Key: WICKET-7107
> URL: https://issues.apache.org/jira/browse/WICKET-7107
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 9.16.0
>Reporter: Dirk Forchel
>Priority: Major
> Attachments: myproject.zip
>
>
> If we redirect to another Web Page and use the RedirectPolicy.AUTO_REDIRECT, 
> this results in the CSP directives being missing in the head of the result 
> page.
> I've attached a quickstart application to show the error. Just browse to 
> [http://localhost:8080/redirect|http://localhost:8080/redirect.] and use the 
> browser's developer console of your choice. The CSP is not included if Wicket 
> performs a RestartResponseException with a WebPage instance like this
> {code:java}
> throw new RestartResponseException(new HomePage(new PageParameters()));{code}
> If you open the home page directly 
> [http://localhost:8080/|http://localhost:8080/redirect.] the response does 
> include a CSP.
> There is an additional test for the CSPRequestCycleListener with different 
> page classes as test parameters.
> Relates to https://issues.apache.org/jira/browse/WICKET-7028



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7107) CSP Header not rendered when using RedirectPolicy.AUTO_REDIRECT

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844973#comment-17844973
 ] 

ASF GitHub Bot commented on WICKET-7107:


reiern70 commented on code in PR #846:
URL: https://github.com/apache/wicket/pull/846#discussion_r1595398663


##
wicket-core/src/main/java/org/apache/wicket/csp/CSPRequestCycleListener.java:
##
@@ -39,14 +40,7 @@ public CSPRequestCycleListener(ContentSecurityPolicySettings 
settings)
}
 
@Override
-   public void onRequestHandlerResolved(RequestCycle cycle, 
IRequestHandler handler)
-   {
-   // WICKET-7028- this is needed for redirect to buffer use case.
-   protect(cycle, handler);
-   }
-
-   @Override
-   public void onRequestHandlerExecuted(RequestCycle cycle, 
IRequestHandler handler)
+   public void onUrlMapped(RequestCycle cycle, IRequestHandler handler, 
Url url)

Review Comment:
   I have tried this with 
   
   https://issues.apache.org/jira/browse/WICKET-7028
   
   sample application and this change seems to be Ok. But to be honest I'm not 
sure this is the way we should go.  See 
   
   https://issues.apache.org/jira/browse/WICKET-7040
   
   
   
   





> CSP Header not rendered when using RedirectPolicy.AUTO_REDIRECT
> ---
>
> Key: WICKET-7107
> URL: https://issues.apache.org/jira/browse/WICKET-7107
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 9.16.0
>Reporter: Dirk Forchel
>Priority: Major
> Attachments: myproject.zip
>
>
> If we redirect to another Web Page and use the RedirectPolicy.AUTO_REDIRECT, 
> this results in the CSP directives being missing in the head of the result 
> page.
> I've attached a quickstart application to show the error. Just browse to 
> [http://localhost:8080/redirect|http://localhost:8080/redirect.] and use the 
> browser's developer console of your choice. The CSP is not included if Wicket 
> performs a RestartResponseException with a WebPage instance like this
> {code:java}
> throw new RestartResponseException(new HomePage(new PageParameters()));{code}
> If you open the home page directly 
> [http://localhost:8080/|http://localhost:8080/redirect.] the response does 
> include a CSP.
> There is an additional test for the CSPRequestCycleListener with different 
> page classes as test parameters.
> Relates to https://issues.apache.org/jira/browse/WICKET-7028



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7098) [Websockets] malformed XML is generated if runtime exceptions happen during rendering phase of a web socket push request

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844350#comment-17844350
 ] 

ASF GitHub Bot commented on WICKET-7098:


reiern70 merged PR #860:
URL: https://github.com/apache/wicket/pull/860




> [Websockets] malformed XML is generated if runtime exceptions happen during 
> rendering phase of a web socket push request
> 
>
> Key: WICKET-7098
> URL: https://issues.apache.org/jira/browse/WICKET-7098
> Project: Wicket
>  Issue Type: Improvement
>Affects Versions: 10.0.0-M2, 9.16.0
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0
>
>
> This issue is similar to
>  
> https://issues.apache.org/jira/browse/WICKET-7074
>  
> If during rendering phase of a web socket push request some runtime exception 
> happens then client will received a malformed XML: because streaming of 
> generated markup is done directly to response.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7109) Create a ready to use dropdown supporting grouping

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844346#comment-17844346
 ] 

ASF GitHub Bot commented on WICKET-7109:


reiern70 merged PR #859:
URL: https://github.com/apache/wicket/pull/859




> Create a ready to use dropdown supporting grouping
> --
>
> Key: WICKET-7109
> URL: https://issues.apache.org/jira/browse/WICKET-7109
> Project: Wicket
>  Issue Type: New Feature
>  Components: wicket
>Affects Versions: 10.0.0, 9.17.0
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0, 9.18.0
>
>
> Create a ready to use dropdown supporting grouping out of the box



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7109) Create a ready to use dropdown supporting grouping

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844337#comment-17844337
 ] 

ASF GitHub Bot commented on WICKET-7109:


reiern70 commented on PR #859:
URL: https://github.com/apache/wicket/pull/859#issuecomment-2098642563

   @martin-g Implemented all feedback + added tests




> Create a ready to use dropdown supporting grouping
> --
>
> Key: WICKET-7109
> URL: https://issues.apache.org/jira/browse/WICKET-7109
> Project: Wicket
>  Issue Type: New Feature
>  Components: wicket
>Affects Versions: 10.0.0, 9.17.0
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0, 9.18.0
>
>
> Create a ready to use dropdown supporting grouping out of the box



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7109) Create a ready to use dropdown supporting grouping

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844147#comment-17844147
 ] 

ASF GitHub Bot commented on WICKET-7109:


martin-g commented on code in PR #859:
URL: https://github.com/apache/wicket/pull/859#discussion_r1591852785


##
wicket-core/src/main/java/org/apache/wicket/markup/html/form/GroupedDropDownChoice.java:
##
@@ -0,0 +1,141 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket.markup.html.form;
+
+import java.util.List;
+import org.apache.wicket.model.IModel;
+import org.apache.wicket.util.string.AppendingStringBuffer;
+import org.apache.wicket.util.string.Strings;
+
+/**
+ * Convenience class for generating dropdown choices with option groups.
+ *
+ * @param  The model object type
+ */
+public abstract class GroupedDropDownChoice extends DropDownChoice
+{
+private static final long serialVersionUID = 1L;
+
+public GroupedDropDownChoice(String id)
+{
+super(id);
+}
+
+public GroupedDropDownChoice(String id, List choices)
+{
+super(id, choices);
+}
+
+public GroupedDropDownChoice(String id, List choices, 
IChoiceRenderer renderer)
+{
+super(id, choices, renderer);
+}
+
+public GroupedDropDownChoice(String id, IModel model, List 
choices)
+{
+super(id, model, choices);
+}
+
+public GroupedDropDownChoice(String id, IModel model, List 
choices, IChoiceRenderer renderer)
+{
+super(id, model, choices, renderer);
+}
+
+public GroupedDropDownChoice(String id, IModel> choices)
+{
+super(id, choices);
+}
+
+public GroupedDropDownChoice(String id, IModel model, IModel> choices)
+{
+super(id, model, choices);
+}
+
+public GroupedDropDownChoice(String id, IModel> choices, IChoiceRenderer renderer)
+{
+super(id, choices, renderer);
+}
+
+public GroupedDropDownChoice(String id, IModel model, IModel> choices, IChoiceRenderer renderer)
+{
+super(id, model, choices, renderer);
+}
+
+private transient T previous;
+
+private transient boolean inOptionGroup;
+
+private boolean isLast(int index)
+{
+return index - 1 == getChoices().size();
+}
+
+/**
+ * Determines if a new group has started
+ *
+ * @param previous The previous entry (it can be null)
+ * @param current  The current entry (always non-null)
+ * @return if a new group has started
+ */
+protected abstract boolean isNewGroup(T previous, T current);
+
+/**
+ * Determines if current entry belongs to no group
+ *
+ * @param current The current entry
+ * @return true is current entry belongs to no group.
+ */
+protected abstract boolean hasNoGroup(T current);
+
+/**
+ * @param current The current entry
+ * @return Returns the label for current group.
+ */
+protected abstract String getGroupLabel(T current);

Review Comment:
   ```suggestion
   protected abstract IModel getGroupLabel(T current);
   ```
   This way it would be possible to calculate it lazily, e.g. for i18n.



##
wicket-core/src/main/java/org/apache/wicket/markup/html/form/GroupedDropDownChoice.java:
##
@@ -0,0 +1,141 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket.markup.html.form;

[jira] [Commented] (WICKET-7098) [Websockets] malformed XML is generated if runtime exceptions happen during rendering phase of a web socket push request

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843808#comment-17843808
 ] 

ASF GitHub Bot commented on WICKET-7098:


reiern70 opened a new pull request, #860:
URL: https://github.com/apache/wicket/pull/860

   … happen during rendering phase of a web socket push request: writing to a 
buffer allows to generate a proper XML as request's buffer will not be polluted




> [Websockets] malformed XML is generated if runtime exceptions happen during 
> rendering phase of a web socket push request
> 
>
> Key: WICKET-7098
> URL: https://issues.apache.org/jira/browse/WICKET-7098
> Project: Wicket
>  Issue Type: Improvement
>Affects Versions: 10.0.0-M2, 9.16.0
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0
>
>
> This issue is similar to
>  
> https://issues.apache.org/jira/browse/WICKET-7074
>  
> If during rendering phase of a web socket push request some runtime exception 
> happens then client will received a malformed XML: because streaming of 
> generated markup is done directly to response.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7109) Create a ready to use dropdown supporting grouping

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843760#comment-17843760
 ] 

ASF GitHub Bot commented on WICKET-7109:


reiern70 opened a new pull request, #859:
URL: https://github.com/apache/wicket/pull/859

   [Screencast from 2024-05-06 
09-26-47.webm](https://github.com/apache/wicket/assets/462655/197ed293-7d78-4a30-96a5-526138aa6b9b)
   




> Create a ready to use dropdown supporting grouping
> --
>
> Key: WICKET-7109
> URL: https://issues.apache.org/jira/browse/WICKET-7109
> Project: Wicket
>  Issue Type: New Feature
>  Components: wicket
>Affects Versions: 10.0.0, 9.17.0
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0, 9.18.0
>
>
> Create a ready to use dropdown supporting grouping out of the box



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7107) CSP Header not rendered when using RedirectPolicy.AUTO_REDIRECT

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840956#comment-17840956
 ] 

ASF GitHub Bot commented on WICKET-7107:


dr0ps commented on PR #846:
URL: https://github.com/apache/wicket/pull/846#issuecomment-2078090021

   I replaced CSPRequestCycleListener#onRequestHandlerResolved and 
CSPRequestCycleListener#onRequestHandlerExecuted with onUrlMapped which fixes 
the tests. Is the a good idea?




> CSP Header not rendered when using RedirectPolicy.AUTO_REDIRECT
> ---
>
> Key: WICKET-7107
> URL: https://issues.apache.org/jira/browse/WICKET-7107
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 9.16.0
>Reporter: Dirk Forchel
>Priority: Major
> Attachments: myproject.zip
>
>
> If we redirect to another Web Page and use the RedirectPolicy.AUTO_REDIRECT, 
> this results in the CSP directives being missing in the head of the result 
> page.
> I've attached a quickstart application to show the error. Just browse to 
> [http://localhost:8080/redirect|http://localhost:8080/redirect.] and use the 
> browser's developer console of your choice. The CSP is not included if Wicket 
> performs a RestartResponseException with a WebPage instance like this
> {code:java}
> throw new RestartResponseException(new HomePage(new PageParameters()));{code}
> If you open the home page directly 
> [http://localhost:8080/|http://localhost:8080/redirect.] the response does 
> include a CSP.
> There is an additional test for the CSPRequestCycleListener with different 
> page classes as test parameters.
> Relates to https://issues.apache.org/jira/browse/WICKET-7028



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7107) CSP Header not rendered when using RedirectPolicy.AUTO_REDIRECT

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840952#comment-17840952
 ] 

ASF GitHub Bot commented on WICKET-7107:


dr0ps commented on PR #846:
URL: https://github.com/apache/wicket/pull/846#issuecomment-2078081010

   ResetResponseException$ResponseResettingDecorator#respond(RequestCycle) 
calls reset() on the response object. The current implementation in 
BaseWicketTester$WicketTesterServletWebResponse does nothing which is not 
representative of the implementation in BufferedWebResponse or 
ServletWebResponse. I therefore added the clearing of cookies and headers which 
makes the tests fail.
   As the ResetResponseException then continues to call 
IRequestHandler#respond(RequestCycle) the onRequestHandlerResolved and 
onRequestHandlerExecuted in CSPRequestCycleListener will not be called. 
Therefore the CSP values are missing.




> CSP Header not rendered when using RedirectPolicy.AUTO_REDIRECT
> ---
>
> Key: WICKET-7107
> URL: https://issues.apache.org/jira/browse/WICKET-7107
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 9.16.0
>Reporter: Dirk Forchel
>Priority: Major
> Attachments: myproject.zip
>
>
> If we redirect to another Web Page and use the RedirectPolicy.AUTO_REDIRECT, 
> this results in the CSP directives being missing in the head of the result 
> page.
> I've attached a quickstart application to show the error. Just browse to 
> [http://localhost:8080/redirect|http://localhost:8080/redirect.] and use the 
> browser's developer console of your choice. The CSP is not included if Wicket 
> performs a RestartResponseException with a WebPage instance like this
> {code:java}
> throw new RestartResponseException(new HomePage(new PageParameters()));{code}
> If you open the home page directly 
> [http://localhost:8080/|http://localhost:8080/redirect.] the response does 
> include a CSP.
> There is an additional test for the CSPRequestCycleListener with different 
> page classes as test parameters.
> Relates to https://issues.apache.org/jira/browse/WICKET-7028



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7107) CSP Header not rendered when using RedirectPolicy.AUTO_REDIRECT

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840817#comment-17840817
 ] 

ASF GitHub Bot commented on WICKET-7107:


dr0ps opened a new pull request, #846:
URL: https://github.com/apache/wicket/pull/846

   WICKET-7107 seems to not be an issue in Wicket core but rather a shortcoming 
of BaseWicketTester. WicketTesterServletWebResponse does implement 
IMetaDataBufferingWebResponse but fails to buffer header data. Headers are 
therefore lost in some cases. I took the provided test from WICKET-7107 and 
reduced it to the minimum required to demonstrate the issue. I also added the 
header buffering to BaseWicketTester#WicketTesterServletWebResponse. 
   I believe that this is an improvement but it ultimately falls short of 
actually testing wicket core functionality. It only tests the test 
infrastructure.




> CSP Header not rendered when using RedirectPolicy.AUTO_REDIRECT
> ---
>
> Key: WICKET-7107
> URL: https://issues.apache.org/jira/browse/WICKET-7107
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 9.16.0
>Reporter: Dirk Forchel
>Priority: Major
> Attachments: myproject.zip
>
>
> If we redirect to another Web Page and use the RedirectPolicy.AUTO_REDIRECT, 
> this results in the CSP directives being missing in the head of the result 
> page.
> I've attached a Quickstart with the use-case (see RedirectPage.java) and an 
> additional Test for the CSPRequestCycleListener with different page classes 
> as test parameters.
> Relates to https://issues.apache.org/jira/browse/WICKET-7028



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7103) Enhance ModalDialog API

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837544#comment-17837544
 ] 

ASF GitHub Bot commented on WICKET-7103:


martin-g merged PR #833:
URL: https://github.com/apache/wicket/pull/833




> Enhance ModalDialog API
> ---
>
> Key: WICKET-7103
> URL: https://issues.apache.org/jira/browse/WICKET-7103
> Project: Wicket
>  Issue Type: Improvement
>  Components: ModalDialog
>Reporter: Johannes Renoth
>Priority: Major
>
> At the moment it is impossible to change the AjaxRequestAttributes of the 
> CloseBehavior in ModalDialog. Sometimes it is warranted to change the Ajax 
> Channel or the Queue Type. For this reason an API should be provided.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7103) Enhance ModalDialog API

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837546#comment-17837546
 ] 

ASF GitHub Bot commented on WICKET-7103:


martin-g commented on PR #833:
URL: https://github.com/apache/wicket/pull/833#issuecomment-2058416854

   Thank you, @renoth !




> Enhance ModalDialog API
> ---
>
> Key: WICKET-7103
> URL: https://issues.apache.org/jira/browse/WICKET-7103
> Project: Wicket
>  Issue Type: Improvement
>  Components: ModalDialog
>Reporter: Johannes Renoth
>Priority: Major
>
> At the moment it is impossible to change the AjaxRequestAttributes of the 
> CloseBehavior in ModalDialog. Sometimes it is warranted to change the Ajax 
> Channel or the Queue Type. For this reason an API should be provided.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7103) Enhance ModalDialog API

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837415#comment-17837415
 ] 

ASF GitHub Bot commented on WICKET-7103:


renoth commented on PR #833:
URL: https://github.com/apache/wicket/pull/833#issuecomment-2057654969

   sorry forgot the license, should work now :)




> Enhance ModalDialog API
> ---
>
> Key: WICKET-7103
> URL: https://issues.apache.org/jira/browse/WICKET-7103
> Project: Wicket
>  Issue Type: Improvement
>  Components: ModalDialog
>Reporter: Johannes Renoth
>Priority: Major
>
> At the moment it is impossible to change the AjaxRequestAttributes of the 
> CloseBehavior in ModalDialog. Sometimes it is warranted to change the Ajax 
> Channel or the Queue Type. For this reason an API should be provided.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7103) Enhance ModalDialog API

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837187#comment-17837187
 ] 

ASF GitHub Bot commented on WICKET-7103:


martin-g commented on PR #833:
URL: https://github.com/apache/wicket/pull/833#issuecomment-2056588341

   ```
   
   org.apache.wicket.util.license.JavaLicenseHeaderHandler failed. The 
following files(1) didn't have correct license header:
   NONE 
/home/runner/work/wicket/wicket/wicket-extensions/src/test/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalDialogTest.java
   ```




> Enhance ModalDialog API
> ---
>
> Key: WICKET-7103
> URL: https://issues.apache.org/jira/browse/WICKET-7103
> Project: Wicket
>  Issue Type: Improvement
>  Components: ModalDialog
>Reporter: Johannes Renoth
>Priority: Major
>
> At the moment it is impossible to change the AjaxRequestAttributes of the 
> CloseBehavior in ModalDialog. Sometimes it is warranted to change the Ajax 
> Channel or the Queue Type. For this reason an API should be provided.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7103) Enhance ModalDialog API

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837105#comment-17837105
 ] 

ASF GitHub Bot commented on WICKET-7103:


martin-g commented on PR #833:
URL: https://github.com/apache/wicket/pull/833#issuecomment-2055998352

   Please rebase your branch to latest wicket:master.
   I could do it too but I don't want to force-push to your master...




> Enhance ModalDialog API
> ---
>
> Key: WICKET-7103
> URL: https://issues.apache.org/jira/browse/WICKET-7103
> Project: Wicket
>  Issue Type: Improvement
>  Components: ModalDialog
>Reporter: Johannes Renoth
>Priority: Major
>
> At the moment it is impossible to change the AjaxRequestAttributes of the 
> CloseBehavior in ModalDialog. Sometimes it is warranted to change the Ajax 
> Channel or the Queue Type. For this reason an API should be provided.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7103) Enhance ModalDialog API

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836513#comment-17836513
 ] 

ASF GitHub Bot commented on WICKET-7103:


renoth opened a new pull request, #833:
URL: https://github.com/apache/wicket/pull/833

   see https://issues.apache.org/jira/browse/WICKET-7103




> Enhance ModalDialog API
> ---
>
> Key: WICKET-7103
> URL: https://issues.apache.org/jira/browse/WICKET-7103
> Project: Wicket
>  Issue Type: Improvement
>  Components: ModalDialog
>Reporter: Johannes Renoth
>Priority: Major
>
> At the moment it is impossible to change the AjaxRequestAttributes of the 
> CloseBehavior in ModalDialog. Sometimes it is warranted to change the Ajax 
> Channel or the Queue Type. For this reason an API should be provided.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7102) Error in LiveSessionsPage

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835779#comment-17835779
 ] 

ASF GitHub Bot commented on WICKET-7102:


reiern70 merged PR #832:
URL: https://github.com/apache/wicket/pull/832




> Error in LiveSessionsPage
> -
>
> Key: WICKET-7102
> URL: https://issues.apache.org/jira/browse/WICKET-7102
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 9.16.0, 10.0.0
>Reporter: Johannes Renoth
>Priority: Major
> Attachments: image-2024-04-09-13-51-48-038.png
>
>
> {code:java}
> Description: java.lang.IllegalArgumentException: 'bytes' cannot be negative: 
> -1
>   Message: 'bytes' cannot be negative: -1
>   
>   org.apache.wicket.util.lang.Bytes.(Bytes.java:111)
>   
>   org.apache.wicket.util.lang.Bytes.bytes(Bytes.java:124)
>   
>   
> org.apache.wicket.devutils.inspector.LiveSessionsPage$7.populateItem(LiveSessionsPage.java:163)
>   
>   
> org.apache.wicket.markup.html.list.ListView.onPopulate(ListView.java:523)
>   
>   
> org.apache.wicket.markup.repeater.AbstractRepeater.onBeforeRender(AbstractRepeater.java:124)
>   
>   
> org.apache.wicket.Component.beforeRender(Component.java:949)
>   
>   
> org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1759)
>   
>   
> org.apache.wicket.Component.onBeforeRender(Component.java:3832)
>   
>   org.apache.wicket.Page.onBeforeRender(Page.java:789)
>   
>   
> org.apache.wicket.devutils.DevUtilsPage.onBeforeRender(DevUtilsPage.java:76)
>   
>   
> org.apache.wicket.Component.beforeRender(Component.java:949)
>   
>   org.apache.wicket.Page.renderPage(Page.java:991)
>   
>   
> org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:124)
>   
>   
> org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:195)
>   
>   
> org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:202)
>   
>   
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:910)
>   
>   
> org.apache.wicket.request.RequestHandlerExecutor.execute(RequestHandlerExecutor.java:63)
>   
>   
> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:294)
>   
>   
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:255)
>   
>   
> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:277)
>{code}
> Probably caused by this code in AbstractRequestLogger
> !image-2024-04-09-13-51-48-038.png!
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7102) Error in LiveSessionsPage

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835365#comment-17835365
 ] 

ASF GitHub Bot commented on WICKET-7102:


renoth opened a new pull request, #832:
URL: https://github.com/apache/wicket/pull/832

   Fix Error when Bytes Constructor is called with -1




> Error in LiveSessionsPage
> -
>
> Key: WICKET-7102
> URL: https://issues.apache.org/jira/browse/WICKET-7102
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 9.16.0, 10.0.0
>Reporter: Johannes Renoth
>Priority: Major
> Attachments: image-2024-04-09-13-51-48-038.png
>
>
> {code:java}
> Description: java.lang.IllegalArgumentException: 'bytes' cannot be negative: 
> -1
>   Message: 'bytes' cannot be negative: -1
>   
>   org.apache.wicket.util.lang.Bytes.(Bytes.java:111)
>   
>   org.apache.wicket.util.lang.Bytes.bytes(Bytes.java:124)
>   
>   
> org.apache.wicket.devutils.inspector.LiveSessionsPage$7.populateItem(LiveSessionsPage.java:163)
>   
>   
> org.apache.wicket.markup.html.list.ListView.onPopulate(ListView.java:523)
>   
>   
> org.apache.wicket.markup.repeater.AbstractRepeater.onBeforeRender(AbstractRepeater.java:124)
>   
>   
> org.apache.wicket.Component.beforeRender(Component.java:949)
>   
>   
> org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1759)
>   
>   
> org.apache.wicket.Component.onBeforeRender(Component.java:3832)
>   
>   org.apache.wicket.Page.onBeforeRender(Page.java:789)
>   
>   
> org.apache.wicket.devutils.DevUtilsPage.onBeforeRender(DevUtilsPage.java:76)
>   
>   
> org.apache.wicket.Component.beforeRender(Component.java:949)
>   
>   org.apache.wicket.Page.renderPage(Page.java:991)
>   
>   
> org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:124)
>   
>   
> org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:195)
>   
>   
> org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:202)
>   
>   
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:910)
>   
>   
> org.apache.wicket.request.RequestHandlerExecutor.execute(RequestHandlerExecutor.java:63)
>   
>   
> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:294)
>   
>   
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:255)
>   
>   
> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:277)
>{code}
> Probably caused by this code in AbstractRequestLogger
> !image-2024-04-09-13-51-48-038.png!
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) auto-label is not automatically updated when related form component is updated.

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832189#comment-17832189
 ] 

ASF GitHub Bot commented on WICKET-7101:


reiern70 merged PR #824:
URL: https://github.com/apache/wicket/pull/824




> auto-label is not automatically updated when related form component is 
> updated.
> ---
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0, 9.18.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/pull/812]
>  
> This PR introduces:
>  * a new tag *wicket:auto='true|false'* that allows to set some auto label as 
> updatable always that form component is updated (via AJAX or web socket 
> request).
>  * a new boolean flag on markup-settings that allows to set this new behavior 
> as application default. By default, the flag is set to false thus that 
> applications keep existing behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) auto-label is not automatically updated when related form component is updated.

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831978#comment-17831978
 ] 

ASF GitHub Bot commented on WICKET-7101:


martin-g commented on code in PR #824:
URL: https://github.com/apache/wicket/pull/824#discussion_r1543560596


##
wicket-core/src/main/resources/META-INF/wicket.xsd:
##
@@ -102,6 +103,15 @@


 
+   
+   
+   Can be used in HTML  
to indicate the label will be automatically updated

Review Comment:
   ```suggestion
The attribute can be used in HTML 
 to indicate the label will be automatically updated
   ```





> auto-label is not automatically updated when related form component is 
> updated.
> ---
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0, 9.18.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/pull/812]
>  
> This PR introduces:
>  * a new tag *wicket:auto='true|false'* that allows to set some auto label as 
> updatable always that form component is updated (via AJAX or web socket 
> request).
>  * a new boolean flag on markup-settings that allows to set this new behavior 
> as application default. By default, the flag is set to false thus that 
> applications keep existing behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) auto-label is not automatically updated when related form component is updated.

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831981#comment-17831981
 ] 

ASF GitHub Bot commented on WICKET-7101:


martin-g commented on code in PR #824:
URL: https://github.com/apache/wicket/pull/824#discussion_r1543730258


##
wicket-core/src/main/resources/META-INF/wicket.xsd:
##
@@ -102,6 +103,15 @@


 
+   
+   
+   Can be used in HTML  
to indicate the label will be automatically updated

Review Comment:
   I updated the suggestion





> auto-label is not automatically updated when related form component is 
> updated.
> ---
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0, 9.18.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/pull/812]
>  
> This PR introduces:
>  * a new tag *wicket:auto='true|false'* that allows to set some auto label as 
> updatable always that form component is updated (via AJAX or web socket 
> request).
>  * a new boolean flag on markup-settings that allows to set this new behavior 
> as application default. By default, the flag is set to false thus that 
> applications keep existing behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) auto-label is not automatically updated when related form component is updated.

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831970#comment-17831970
 ] 

ASF GitHub Bot commented on WICKET-7101:


reiern70 commented on code in PR #824:
URL: https://github.com/apache/wicket/pull/824#discussion_r1543633486


##
wicket-core/src/main/resources/META-INF/wicket.xsd:
##
@@ -102,6 +103,15 @@


 
+   
+   
+   Can be used in HTML  
to indicate the label will be automatically updated

Review Comment:
   ![Screenshot from 2024-03-28 
15-48-36](https://github.com/apache/wicket/assets/462655/4a241206-3341-4b76-8fae-655a1efc913f)
   





> auto-label is not automatically updated when related form component is 
> updated.
> ---
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0, 9.18.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/pull/812]
>  
> This PR introduces:
>  * a new tag *wicket:auto='true|false'* that allows to set some auto label as 
> updatable always that form component is updated (via AJAX or web socket 
> request).
>  * a new boolean flag on markup-settings that allows to set this new behavior 
> as application default. By default, the flag is set to false thus that 
> applications keep existing behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) auto-label is not automatically updated when related form component is updated.

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831969#comment-17831969
 ] 

ASF GitHub Bot commented on WICKET-7101:


reiern70 commented on code in PR #824:
URL: https://github.com/apache/wicket/pull/824#discussion_r1543631596


##
wicket-core/src/main/resources/META-INF/wicket.xsd:
##
@@ -102,6 +103,15 @@


 
+   
+   
+   Can be used in HTML  
to indicate the label will be automatically updated

Review Comment:
   Hum... other elements use CDATA
   
   ![Uploading image.png…]()
   
   Maybe change all of them too?





> auto-label is not automatically updated when related form component is 
> updated.
> ---
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0, 9.18.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/pull/812]
>  
> This PR introduces:
>  * a new tag *wicket:auto='true|false'* that allows to set some auto label as 
> updatable always that form component is updated (via AJAX or web socket 
> request).
>  * a new boolean flag on markup-settings that allows to set this new behavior 
> as application default. By default, the flag is set to false thus that 
> applications keep existing behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) auto-label is not automatically updated when related form component is updated.

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831949#comment-17831949
 ] 

ASF GitHub Bot commented on WICKET-7101:


martin-g commented on code in PR #824:
URL: https://github.com/apache/wicket/pull/824#discussion_r1543560596


##
wicket-core/src/main/resources/META-INF/wicket.xsd:
##
@@ -102,6 +103,15 @@


 
+   
+   
+   Can be used in HTML  
to indicate the label will be automatically updated

Review Comment:
   ```suggestion
The attribute can be used in HTML 
label to indicate the label will be automatically updated
   ```





> auto-label is not automatically updated when related form component is 
> updated.
> ---
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0, 9.18.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/pull/812]
>  
> This PR introduces:
>  * a new tag *wicket:auto='true|false'* that allows to set some auto label as 
> updatable always that form component is updated (via AJAX or web socket 
> request).
>  * a new boolean flag on markup-settings that allows to set this new behavior 
> as application default. By default, the flag is set to false thus that 
> applications keep existing behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) auto-label is not automatically updated when related form component is updated.

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831946#comment-17831946
 ] 

ASF GitHub Bot commented on WICKET-7101:


reiern70 opened a new pull request, #824:
URL: https://github.com/apache/wicket/pull/824

   (no comment)




> auto-label is not automatically updated when related form component is 
> updated.
> ---
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0, 9.18.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/pull/812]
>  
> This PR introduces:
>  * a new tag *wicket:auto='true|false'* that allows to set some auto label as 
> updatable always that form component is updated (via AJAX or web socket 
> request).
>  * a new boolean flag on markup-settings that allows to set this new behavior 
> as application default. By default, the flag is set to false thus that 
> applications keep existing behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) auto-label is not automatically updated when related form component is updated.

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831931#comment-17831931
 ] 

ASF GitHub Bot commented on WICKET-7101:


martin-g commented on PR #812:
URL: https://github.com/apache/wicket/pull/812#issuecomment-2025892576

   Just edit the adoc files. Maven does the rest.
   One more thing - please update wicket.xsd too
   
   On Thu, 28 Mar 2024 at 20:06, Ernesto Reinaldo Barreiro <
   ***@***.***> wrote:
   
   > It would be nice to update the guide too.
   >
   > Do we have any documentation on how to update the guide?
   >
   > —
   > Reply to this email directly, view it on GitHub
   > , or
   > unsubscribe
   > 

   > .
   > You are receiving this because your review was requested.Message ID:
   > ***@***.***>
   >
   




> auto-label is not automatically updated when related form component is 
> updated.
> ---
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0, 9.18.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/pull/812]
>  
> This PR introduces:
>  * a new tag *wicket:auto='true|false'* that allows to set some auto label as 
> updatable always that form component is updated (via AJAX or web socket 
> request).
>  * a new boolean flag on markup-settings that allows to set this new behavior 
> as application default. By default, the flag is set to false thus that 
> applications keep existing behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) auto-label is not automatically updated when related form component is updated.

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831918#comment-17831918
 ] 

ASF GitHub Bot commented on WICKET-7101:


reiern70 commented on PR #812:
URL: https://github.com/apache/wicket/pull/812#issuecomment-2025817087

   > It would be nice to update the guide too.
   
   Do we have any documentation on how to update the guide?




> auto-label is not automatically updated when related form component is 
> updated.
> ---
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0, 9.18.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/pull/812]
>  
> This PR introduces:
>  * a new tag *wicket:auto='true|false'* that allows to set some auto label as 
> updatable always that form component is updated (via AJAX or web socket 
> request).
>  * a new boolean flag on markup-settings that allows to set this new behavior 
> as application default. By default, the flag is set to false thus that 
> applications keep existing behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) auto-label is not automatically updated when related form component is updated.

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831916#comment-17831916
 ] 

ASF GitHub Bot commented on WICKET-7101:


reiern70 commented on code in PR #812:
URL: https://github.com/apache/wicket/pull/812#discussion_r1543387516


##
wicket-core/src/main/java/org/apache/wicket/ajax/form/AjaxFormComponentUpdatingBehavior.java:
##
@@ -157,7 +158,7 @@ protected final void onEvent(final AjaxRequestTarget target)
{
onError(target, e);
}
-   formComponent.updateAutoLabels(target);
+   
formComponent.updateAutoLabels((IPartialPageRequestHandler)target, false);

Review Comment:
   Not really.





> auto-label is not automatically updated when related form component is 
> updated.
> ---
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 10.1.0, 9.18.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/pull/812]
>  
> This PR introduces:
>  * a new tag *wicket:auto='true|false'* that allows to set some auto label as 
> updatable always that form component is updated (via AJAX or web socket 
> request).
>  * a new boolean flag on markup-settings that allows to set this new behavior 
> as application default. By default, the flag is set to false thus that 
> applications keep existing behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) auto-label is not automatically updated when related form component is updated.

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831071#comment-17831071
 ] 

ASF GitHub Bot commented on WICKET-7101:


martin-g commented on code in PR #812:
URL: https://github.com/apache/wicket/pull/812#discussion_r1540068379


##
wicket-core/src/main/java/org/apache/wicket/markup/html/form/FormComponent.java:
##
@@ -1558,9 +1566,9 @@ public final IValidatable newValidatable()
 * Updates auto label css classes such as error/required during ajax 
updates when the labels may
 * not be directly repainted in the response.
 * 
-* @param target
+* @param target The {@link IPartialPageRequestHandler}

Review Comment:
   Please add `@param auto ...` too



##
wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java:
##
@@ -873,7 +874,7 @@ else if (hasError())
@Override
public void component(FormComponent 
component, IVisit visit)
{
-   component.updateAutoLabels(target);
+   
component.updateAutoLabels((IPartialPageRequestHandler)target, false);

Review Comment:
   Is the casting needed ?



##
wicket-core/src/main/java/org/apache/wicket/markup/html/form/FormComponent.java:
##
@@ -1570,9 +1578,30 @@ public final void updateAutoLabels(AjaxRequestTarget 
target)
return;
}
 
+   if (auto)
+   {
+   if (marker.isAuto())
+   {
+   marker.updateFrom(this, target);
+   return;
+   } else {
+   return;
+   }

Review Comment:
   This can be simplified to 
   ```
   if (!marker.isAuto())
   {
 return;
   }
   marker.updateFrom(this, target); 
   ```
   
   Maybe even more.



##
wicket-core/src/main/java/org/apache/wicket/ajax/form/AjaxFormComponentUpdatingBehavior.java:
##
@@ -157,7 +158,7 @@ protected final void onEvent(final AjaxRequestTarget target)
{
onError(target, e);
}
-   formComponent.updateAutoLabels(target);
+   
formComponent.updateAutoLabels((IPartialPageRequestHandler)target, false);

Review Comment:
   Is the casting really needed here ?





> auto-label is not automatically updated when related form component is 
> updated.
> ---
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 9.17.0, 10.1.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/pull/812]
>  
> This PR introduces:
>  * a new tag *wicket:auto='true|false'* that allows to set some auto label as 
> updatable always that form component is updated (via AJAX or web socket 
> request).
>  * a new boolean flag on markup-settings that allows to set this new behavior 
> as application default. By default, the flag is set to false thus that 
> applications keep existing behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) auto-label is not automatically updated when related form component is updated.

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831067#comment-17831067
 ] 

ASF GitHub Bot commented on WICKET-7101:


reiern70 merged PR #812:
URL: https://github.com/apache/wicket/pull/812




> auto-label is not automatically updated when related form component is 
> updated.
> ---
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 9.17.0, 10.1.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/pull/812]
>  
> This PR introduces:
>  * a new tag *wicket:auto='true|false'* that allows to set some auto label as 
> updatable always that form component is updated (via AJAX or web socket 
> request).
>  * a new boolean flag on markup-settings that allows to set this new behavior 
> as application default. By default, the flag is set to false thus that 
> applications keep existing behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) auto-label is not automatically updated when related form component is updated.

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830517#comment-17830517
 ] 

ASF GitHub Bot commented on WICKET-7101:


reiern70 commented on PR #812:
URL: https://github.com/apache/wicket/pull/812#issuecomment-2018153079

   > Maybe another possibility is to add an application setting toggling this 
behavior (and set it to disabled by default). This, way existing applications 
will not break.
   
   Added some application setting allowing to toggle on and off the feature




> auto-label is not automatically updated when related form component is 
> updated.
> ---
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Assignee: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 9.17.0, 10.1.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/pull/812]
>  
> This PR introduces:
>  * a new tag *wicket:auto='true|false'* that allows to set some auto label as 
> updatable always that form component is updated (via AJAX or web socket 
> request).
>  * a new boolean flag on markup-settings that allows to set this new behavior 
> as application default. By default, the flag is set to false thus that 
> applications keep existing behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) autolabel detection of isValid is faulty

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828948#comment-17828948
 ] 

ASF GitHub Bot commented on WICKET-7101:


reiern70 commented on PR #812:
URL: https://github.com/apache/wicket/pull/812#issuecomment-2009573146

   Maybe another possibility is to add an application setting toggling this 
behavior (and set it to disabled by default). This, way existing applications 
will not break.




> autolabel detection of isValid is faulty
> 
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 9.17.0, 10.1.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/commit/ef50d9f506c88ab5d235ea7825175f231b4dc3b2]
>  
> I can't at the moment create PRs as I lost my github access somehow. Can 
> someone please review that commit?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) autolabel detection of isValid is faulty

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828565#comment-17828565
 ] 

ASF GitHub Bot commented on WICKET-7101:


reiern70 commented on code in PR #812:
URL: https://github.com/apache/wicket/pull/812#discussion_r1531440581


##
wicket-core/src/main/java/org/apache/wicket/markup/html/form/FormComponent.java:
##
@@ -301,6 +302,13 @@ private String getLabel()
}
}
 
+   @Override
+   protected void onBeforeRender()
+   {
+   // WICKET-7101 update related auto-label
+   
getRequestCycle().find(IPartialPageRequestHandler.class).ifPresent(handler -> 
updateAutoLabels(handler, true));

Review Comment:
   This will only succeed if the label have the `wicket:auto="true"` attribute.





> autolabel detection of isValid is faulty
> 
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 9.17.0, 10.1.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/commit/ef50d9f506c88ab5d235ea7825175f231b4dc3b2]
>  
> I can't at the moment create PRs as I lost my github access somehow. Can 
> someone please review that commit?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) autolabel detection of isValid is faulty

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828564#comment-17828564
 ] 

ASF GitHub Bot commented on WICKET-7101:


reiern70 commented on code in PR #812:
URL: https://github.com/apache/wicket/pull/812#discussion_r1531439695


##
wicket-core/src/test/java/org/apache/wicket/markup/html/form/AutoLabelTest.java:
##
@@ -163,22 +167,80 @@ class MyTestPage2 extends TestPage
 
}
 
+   // WICKET-7101
+   @Test
+   void labelTagClassesAreUpdatedWhenRelatedFormComponentIsUpdated()
+   {
+   class MyAjaxTestPage extends TestPage
+   {
+   private static final long serialVersionUID = 1L;
+
+   // we define a label that is auto-synchronized with 
component
+   MyAjaxTestPage()
+   {
+   super("field");

Review Comment:
   This introduces a new attribute wicket:auto="true" that essentially say 
label is always repainted when component is re-rendered this way label is 
always up to date.
   
   If not set label behaves as before. Thus, this change should be backward 
compatible.





> autolabel detection of isValid is faulty
> 
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 9.17.0, 10.1.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/commit/ef50d9f506c88ab5d235ea7825175f231b4dc3b2]
>  
> I can't at the moment create PRs as I lost my github access somehow. Can 
> someone please review that commit?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7101) autolabel detection of isValid is faulty

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828563#comment-17828563
 ] 

ASF GitHub Bot commented on WICKET-7101:


reiern70 opened a new pull request, #812:
URL: https://github.com/apache/wicket/pull/812

   The label associated with form component should always be rendered when the 
form component is rendered via AJAX. This way we ensure the state of the label 
is consistent with form component's state. This introduces a new wicket 
attribute wicket:auto that controls that auto-label is bound to form component.
   
   




> autolabel detection of isValid is faulty
> 
>
> Key: WICKET-7101
> URL: https://issues.apache.org/jira/browse/WICKET-7101
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Ernesto Reinaldo Barreiro
>Priority: Major
> Fix For: 9.17.0, 10.1.0
>
>
> Auto-labels are somewhat disconnected from FormComponent they are bound to in 
> the sense that:
>  
>  * You can modify the form component (e.g. if it is required) and update that 
> component via AJAX and
>  * Autolabel will stay with a stale state: i.e. still with the required CSS 
> class
> This should be fixed with 
>  
> [https://github.com/apache/wicket/commit/ef50d9f506c88ab5d235ea7825175f231b4dc3b2]
>  
> I can't at the moment create PRs as I lost my github access somehow. Can 
> someone please review that commit?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7093) Add support for missing CSP directives

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824676#comment-17824676
 ] 

ASF GitHub Bot commented on WICKET-7093:


martin-g commented on PR #801:
URL: https://github.com/apache/wicket/pull/801#issuecomment-1985327630

   Thank you, @kaczorek89 !




> Add support for missing CSP directives
> --
>
> Key: WICKET-7093
> URL: https://issues.apache.org/jira/browse/WICKET-7093
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 9.16.0
>Reporter: Martin Tzvetanov Grigorov
>Priority: Minor
>
> A user at StackOverflow reported that the CSP directive `form-action` is not 
> supported: 
> https://stackoverflow.com/questions/77768942/missing-form-action-csp-directive-in-cspdirective
> Looking at 
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/form-action
>  and 
> https://github.com/apache/wicket/blob/c4a77c4ee7b7ec1dd5d071ed6e1e41a9946d6758/wicket-core/src/main/java/org/apache/wicket/csp/CSPDirective.java#L36-L48
>  I think there are few more that are listed in the CSPDirective enum.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7093) Add support for missing CSP directives

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824673#comment-17824673
 ] 

ASF GitHub Bot commented on WICKET-7093:


martin-g merged PR #801:
URL: https://github.com/apache/wicket/pull/801




> Add support for missing CSP directives
> --
>
> Key: WICKET-7093
> URL: https://issues.apache.org/jira/browse/WICKET-7093
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 9.16.0
>Reporter: Martin Tzvetanov Grigorov
>Priority: Minor
>
> A user at StackOverflow reported that the CSP directive `form-action` is not 
> supported: 
> https://stackoverflow.com/questions/77768942/missing-form-action-csp-directive-in-cspdirective
> Looking at 
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/form-action
>  and 
> https://github.com/apache/wicket/blob/c4a77c4ee7b7ec1dd5d071ed6e1e41a9946d6758/wicket-core/src/main/java/org/apache/wicket/csp/CSPDirective.java#L36-L48
>  I think there are few more that are listed in the CSPDirective enum.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-6890) Render debug setting 'outputMarkupContainerClassName` as an attribute

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823295#comment-17823295
 ] 

ASF GitHub Bot commented on WICKET-6890:


theigl merged PR #781:
URL: https://github.com/apache/wicket/pull/781




> Render debug setting 'outputMarkupContainerClassName` as an attribute
> -
>
> Key: WICKET-6890
> URL: https://issues.apache.org/jira/browse/WICKET-6890
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0-M1
>
>
> As discussed at [https://markmail.org/message/uoxxlnbz56ex7vuk] when 
> org.apache.wicket.settings.DebugSettings#isOutputMarkupContainerClassName() 
> returns true then the MarkupContainer class name should be rendered as an 
> attribute of the component tag instead of as an HTML comment because an HTML 
> comment may break a CSS rule, e.g. by appearing between two sibling HTML 
> elements
> {code:java}
> p + p {color: red;} {code}
>  
> The CSS rule above will change the text color of any paragraph that follows 
> another paragraph. But if an HTML comment appears between them then the rule 
> won't apply.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-6890) Render debug setting 'outputMarkupContainerClassName` as an attribute

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823107#comment-17823107
 ] 

ASF GitHub Bot commented on WICKET-6890:


theigl commented on PR #781:
URL: https://github.com/apache/wicket/pull/781#issuecomment-1976159472

   > @theigl Do you need help here ?
   
   Thanks a lot for asking @martin-g! I just found the time to continue working 
on this.
   
   I improved the JavaDoc some more and added a method to set the strategy to 
the JMX bean.




> Render debug setting 'outputMarkupContainerClassName` as an attribute
> -
>
> Key: WICKET-6890
> URL: https://issues.apache.org/jira/browse/WICKET-6890
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0-M1
>
>
> As discussed at [https://markmail.org/message/uoxxlnbz56ex7vuk] when 
> org.apache.wicket.settings.DebugSettings#isOutputMarkupContainerClassName() 
> returns true then the MarkupContainer class name should be rendered as an 
> attribute of the component tag instead of as an HTML comment because an HTML 
> comment may break a CSS rule, e.g. by appearing between two sibling HTML 
> elements
> {code:java}
> p + p {color: red;} {code}
>  
> The CSS rule above will change the text color of any paragraph that follows 
> another paragraph. But if an HTML comment appears between them then the rule 
> won't apply.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-6890) Render debug setting 'outputMarkupContainerClassName` as an attribute

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823106#comment-17823106
 ] 

ASF GitHub Bot commented on WICKET-6890:


theigl commented on code in PR #781:
URL: https://github.com/apache/wicket/pull/781#discussion_r1510879670


##
wicket-jmx/src/main/java/org/apache/wicket/jmx/DebugSettingsMBean.java:
##
@@ -71,6 +71,8 @@ public interface DebugSettingsMBean
 * Enables wrapping output of markup container in html comments that 
contain markup container's
 * class name. (Useful for determining which part of page belongs to 
which markup file).
 * 
+* //TODO WICKET-6890 JMX Probably does not work with enum, What do we 
do here?

Review Comment:
   I went the "enum name as a String" way.





> Render debug setting 'outputMarkupContainerClassName` as an attribute
> -
>
> Key: WICKET-6890
> URL: https://issues.apache.org/jira/browse/WICKET-6890
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0-M1
>
>
> As discussed at [https://markmail.org/message/uoxxlnbz56ex7vuk] when 
> org.apache.wicket.settings.DebugSettings#isOutputMarkupContainerClassName() 
> returns true then the MarkupContainer class name should be rendered as an 
> attribute of the component tag instead of as an HTML comment because an HTML 
> comment may break a CSS rule, e.g. by appearing between two sibling HTML 
> elements
> {code:java}
> p + p {color: red;} {code}
>  
> The CSS rule above will change the text color of any paragraph that follows 
> another paragraph. But if an HTML comment appears between them then the rule 
> won't apply.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-6890) Render debug setting 'outputMarkupContainerClassName` as an attribute

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823066#comment-17823066
 ] 

ASF GitHub Bot commented on WICKET-6890:


martin-g commented on PR #781:
URL: https://github.com/apache/wicket/pull/781#issuecomment-1975949311

   @theigl Do you need help here ?




> Render debug setting 'outputMarkupContainerClassName` as an attribute
> -
>
> Key: WICKET-6890
> URL: https://issues.apache.org/jira/browse/WICKET-6890
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0-M1
>
>
> As discussed at [https://markmail.org/message/uoxxlnbz56ex7vuk] when 
> org.apache.wicket.settings.DebugSettings#isOutputMarkupContainerClassName() 
> returns true then the MarkupContainer class name should be rendered as an 
> attribute of the component tag instead of as an HTML comment because an HTML 
> comment may break a CSS rule, e.g. by appearing between two sibling HTML 
> elements
> {code:java}
> p + p {color: red;} {code}
>  
> The CSS rule above will change the text color of any paragraph that follows 
> another paragraph. But if an HTML comment appears between them then the rule 
> won't apply.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-6890) Render debug setting 'outputMarkupContainerClassName` as an attribute

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821557#comment-17821557
 ] 

ASF GitHub Bot commented on WICKET-6890:


martin-g commented on code in PR #781:
URL: https://github.com/apache/wicket/pull/781#discussion_r1505527158


##
wicket-core/src/main/java/org/apache/wicket/settings/DebugSettings.java:
##
@@ -173,10 +187,24 @@ public DebugSettings 
setLinePreciseReportingOnNewComponentEnabled(boolean enable
 *
 * @param enable
 * @return {@code this} object for chaining
+* @deprecated use {@link 
#setOutputMarkupContainerClassNameStrategy(ClassOutputStrategy)} instead
 */
+   @Deprecated(forRemoval = true)
public DebugSettings setOutputMarkupContainerClassName(boolean enable)
{
-   outputMarkupContainerClassName = enable;
+   outputMarkupContainerClassNameStrategy = enable ? 
ClassOutputStrategy.HTML_COMMENT : ClassOutputStrategy.NONE;
+   return this;
+   }
+
+   /**
+* Sets the strategy for outputting the class of a markup

Review Comment:
   ```suggestion
 * Sets the strategy for outputting the Java class name of a markup
   ```





> Render debug setting 'outputMarkupContainerClassName` as an attribute
> -
>
> Key: WICKET-6890
> URL: https://issues.apache.org/jira/browse/WICKET-6890
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0-M1
>
>
> As discussed at [https://markmail.org/message/uoxxlnbz56ex7vuk] when 
> org.apache.wicket.settings.DebugSettings#isOutputMarkupContainerClassName() 
> returns true then the MarkupContainer class name should be rendered as an 
> attribute of the component tag instead of as an HTML comment because an HTML 
> comment may break a CSS rule, e.g. by appearing between two sibling HTML 
> elements
> {code:java}
> p + p {color: red;} {code}
>  
> The CSS rule above will change the text color of any paragraph that follows 
> another paragraph. But if an HTML comment appears between them then the rule 
> won't apply.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-6890) Render debug setting 'outputMarkupContainerClassName` as an attribute

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816033#comment-17816033
 ] 

ASF GitHub Bot commented on WICKET-6890:


martin-g commented on code in PR #781:
URL: https://github.com/apache/wicket/pull/781#discussion_r1484220117


##
wicket-core/src/main/java/org/apache/wicket/Page.java:
##
@@ -827,9 +827,10 @@ public void component(final Component component, final 
IVisit visit)
getSession().getPageManager().touchPage(this);
}
 
+   //TODO WICKET-6890 What about TAG_ATTRIBUTE?

Review Comment:
   This is the `END`, so there is nothing to do for `TAG_ATTRIBUTE` and `NONE`



##
wicket-core/src/main/java/org/apache/wicket/settings/DebugSettings.java:
##
@@ -173,10 +185,24 @@ public DebugSettings 
setLinePreciseReportingOnNewComponentEnabled(boolean enable
 *
 * @param enable
 * @return {@code this} object for chaining
+* @deprecated use {@link 
#setOutputMarkupContainerClassNameStrategy(ClassOutputStrategy)} instead
 */
+   @Deprecated(forRemoval = true)
public DebugSettings setOutputMarkupContainerClassName(boolean enable)
{
-   outputMarkupContainerClassName = enable;
+   outputMarkupContainerClassNameStrategy = enable ? 
ClassOutputStrategy.HTML_COMMENT : ClassOutputStrategy.NONE;
+   return this;
+   }
+
+   /**
+* Sets the strategy for outputting the class of a markup
+* 
+* @param stategy
+* @return {@code this} object for chaining
+*/
+   public DebugSettings 
setOutputMarkupContainerClassNameStrategy(ClassOutputStrategy stategy) 

Review Comment:
   ```suggestion
public DebugSettings 
setOutputMarkupContainerClassNameStrategy(ClassOutputStrategy strategy) 
   ```



##
wicket-jmx/src/main/java/org/apache/wicket/jmx/DebugSettingsMBean.java:
##
@@ -71,6 +71,8 @@ public interface DebugSettingsMBean
 * Enables wrapping output of markup container in html comments that 
contain markup container's
 * class name. (Useful for determining which part of page belongs to 
which markup file).
 * 
+* //TODO WICKET-6890 JMX Probably does not work with enum, What do we 
do here?

Review Comment:
   One way is to use the enum name as a String.
   Another way is to use MXBean instead of MBean.



##
wicket-core/src/main/java/org/apache/wicket/Page.java:
##
@@ -827,9 +827,10 @@ public void component(final Component component, final 
IVisit visit)
getSession().getPageManager().touchPage(this);
}
 
+   //TODO WICKET-6890 What about TAG_ATTRIBUTE?
if 
(getApplication().getDebugSettings().isOutputMarkupContainerClassName())
{
-   String className = Classes.name(getClass());
+   final String className = Classes.name(getClass());
getResponse().write(" Render debug setting 'outputMarkupContainerClassName` as an attribute
> -
>
> Key: WICKET-6890
> URL: https://issues.apache.org/jira/browse/WICKET-6890
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0-M1
>
>
> As discussed at [https://markmail.org/message/uoxxlnbz56ex7vuk] when 
> org.apache.wicket.settings.DebugSettings#isOutputMarkupContainerClassName() 
> returns true then the MarkupContainer class name should be rendered as an 
> attribute of the component tag instead of as an HTML comment because an HTML 
> comment may break a CSS rule, e.g. by appearing between two sibling HTML 
> elements
> {code:java}
> p + p {color: red;} {code}
>  
> The CSS rule above will change the text color of any paragraph that follows 
> another paragraph. But if an HTML comment appears between them then the rule 
> won't apply.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-6890) Render debug setting 'outputMarkupContainerClassName` as an attribute

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816002#comment-17816002
 ] 

ASF GitHub Bot commented on WICKET-6890:


theigl commented on code in PR #781:
URL: https://github.com/apache/wicket/pull/781#discussion_r1484137664


##
wicket-jmx/src/main/java/org/apache/wicket/jmx/DebugSettingsMBean.java:
##
@@ -71,6 +71,8 @@ public interface DebugSettingsMBean
 * Enables wrapping output of markup container in html comments that 
contain markup container's
 * class name. (Useful for determining which part of page belongs to 
which markup file).
 * 
+* //TODO WICKET-6890 JMX Probably does not work with enum, What do we 
do here?

Review Comment:
   @martin-g: Any idea what we should do about the JMX bean? Looking at all 
available beans, enums have been carefully avoided.





> Render debug setting 'outputMarkupContainerClassName` as an attribute
> -
>
> Key: WICKET-6890
> URL: https://issues.apache.org/jira/browse/WICKET-6890
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0-M1
>
>
> As discussed at [https://markmail.org/message/uoxxlnbz56ex7vuk] when 
> org.apache.wicket.settings.DebugSettings#isOutputMarkupContainerClassName() 
> returns true then the MarkupContainer class name should be rendered as an 
> attribute of the component tag instead of as an HTML comment because an HTML 
> comment may break a CSS rule, e.g. by appearing between two sibling HTML 
> elements
> {code:java}
> p + p {color: red;} {code}
>  
> The CSS rule above will change the text color of any paragraph that follows 
> another paragraph. But if an HTML comment appears between them then the rule 
> won't apply.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-6890) Render debug setting 'outputMarkupContainerClassName` as an attribute

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816001#comment-17816001
 ] 

ASF GitHub Bot commented on WICKET-6890:


theigl commented on code in PR #781:
URL: https://github.com/apache/wicket/pull/781#discussion_r1484134849


##
wicket-core/src/main/java/org/apache/wicket/Page.java:
##
@@ -827,9 +827,10 @@ public void component(final Component component, final 
IVisit visit)
getSession().getPageManager().touchPage(this);
}
 
+   //TODO WICKET-6890 What about TAG_ATTRIBUTE?
if 
(getApplication().getDebugSettings().isOutputMarkupContainerClassName())
{
-   String className = Classes.name(getClass());
+   final String className = Classes.name(getClass());
getResponse().write(" Render debug setting 'outputMarkupContainerClassName` as an attribute
> -
>
> Key: WICKET-6890
> URL: https://issues.apache.org/jira/browse/WICKET-6890
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0-M1
>
>
> As discussed at [https://markmail.org/message/uoxxlnbz56ex7vuk] when 
> org.apache.wicket.settings.DebugSettings#isOutputMarkupContainerClassName() 
> returns true then the MarkupContainer class name should be rendered as an 
> attribute of the component tag instead of as an HTML comment because an HTML 
> comment may break a CSS rule, e.g. by appearing between two sibling HTML 
> elements
> {code:java}
> p + p {color: red;} {code}
>  
> The CSS rule above will change the text color of any paragraph that follows 
> another paragraph. But if an HTML comment appears between them then the rule 
> won't apply.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-6890) Render debug setting 'outputMarkupContainerClassName` as an attribute

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816000#comment-17816000
 ] 

ASF GitHub Bot commented on WICKET-6890:


theigl opened a new pull request, #781:
URL: https://github.com/apache/wicket/pull/781

   This PR introduces a strategy for outputting a container's class name for 
debugging purposes.
   
   Up until 8bbf158ebc4d12f3b317c0d607200441c0767162, 
`ClassNameStrategy.HTML_COMMENT` was the default strategy. Since then  
`ClassNameStrategy.TAG_ATTRIBUTE` has become the default and only option.
   
   For applications that strip Wicket tags during development, this means that 
there is currently no more debug output.




> Render debug setting 'outputMarkupContainerClassName` as an attribute
> -
>
> Key: WICKET-6890
> URL: https://issues.apache.org/jira/browse/WICKET-6890
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0-M1
>
>
> As discussed at [https://markmail.org/message/uoxxlnbz56ex7vuk] when 
> org.apache.wicket.settings.DebugSettings#isOutputMarkupContainerClassName() 
> returns true then the MarkupContainer class name should be rendered as an 
> attribute of the component tag instead of as an HTML comment because an HTML 
> comment may break a CSS rule, e.g. by appearing between two sibling HTML 
> elements
> {code:java}
> p + p {color: red;} {code}
>  
> The CSS rule above will change the text color of any paragraph that follows 
> another paragraph. But if an HTML comment appears between them then the rule 
> won't apply.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7029) Add migration recipes to Wicket 10

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809848#comment-17809848
 ] 

ASF GitHub Bot commented on WICKET-7029:


timtebeek commented on PR #773:
URL: https://github.com/apache/wicket/pull/773#issuecomment-1905652184

   You're welcome! Wishing all the best with the release and seeing folks 
upgrade. :)




> Add migration recipes to Wicket 10
> --
>
> Key: WICKET-7029
> URL: https://issues.apache.org/jira/browse/WICKET-7029
> Project: Wicket
>  Issue Type: New Feature
>Affects Versions: 10.0.0-M1
>Reporter: Tim te Beek
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
>  Labels: migration
> Fix For: 10.0.0-M1
>
>
> The [Migration to Wicket 
> 10.0|https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0]
>  guide contains a number of breaking changes, that users will have to adopt. 
> Examples include merging `wicket-http2` into `wicket-core`, and the 
> associated package change of `PushHeaderItem` to 
> `org.apache.wicket.markup.head.http2`. And while understandably necessary, 
> these nonetheless can be a hurdle for users to adopt.
> To help users adopt Wicket 10 and the associated upgrade to Java 17 and 
> Servlet 5+ I propose to add a module containing [OpenRewrite migration 
> recipes|https://docs.openrewrite.org/]. For those unfamiliar: OpenRewrite 
> allows you to define migration steps either through Yaml or with Java 
> visitors, and compose these steps to achieve larger migrations. Such 
> migrations have been [applied to Wicket 
> before,|https://github.com/apache/wicket/pull/546] but they can also be 
> defined and distributed for Apache Wicket users.
> As a recent example, migration recipes have been [added to Axon 
> Framework|https://developer.axoniq.io/w/upgrading-to-axon-framework-4.7-automated].
>  In practice that comes down to the following code changes, which also 
> include instructions on their use: 
> [https://github.com/AxonFramework/AxonFramework/pull/2597/files]
> Wicket 10 migration recipes can include a number of existing recipes that 
> help modernize applications:
>  # [Use lambdas where 
> possible|https://docs.openrewrite.org/reference/recipes/java/cleanup/uselambdaforfunctionalinterface]
>  # [Migrate to Jakarta EE 
> 9|https://docs.openrewrite.org/reference/recipes/java/migrate/jakarta/javaxmigrationtojakarta]
>  # [Migrate to Java 
> 17|https://docs.openrewrite.org/reference/recipes/java/migrate/upgradetojava17]
> The Wicket 10 specific recipes can reuse common building blocks such as 
> ChangeType to adopt package name changes, and RemoveDependency to remove 
> `wicket-http2`.
> Technically this wouldn't have to be very difficult initially, even more so 
> when the goal is to assist a migration rather than to achieve a complete 
> migration. The Axon Framework migration can serve as a template, and I'm 
> happy to provide guidance.
> Would this be something worth adding to Apache Wicket?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7029) Add migration recipes to Wicket 10

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809840#comment-17809840
 ] 

ASF GitHub Bot commented on WICKET-7029:


martin-g commented on PR #773:
URL: https://github.com/apache/wicket/pull/773#issuecomment-1905631649

   Thank you, @timtebeek !




> Add migration recipes to Wicket 10
> --
>
> Key: WICKET-7029
> URL: https://issues.apache.org/jira/browse/WICKET-7029
> Project: Wicket
>  Issue Type: New Feature
>Affects Versions: 10.0.0-M1
>Reporter: Tim te Beek
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
>  Labels: migration
> Fix For: 10.0.0-M1
>
>
> The [Migration to Wicket 
> 10.0|https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0]
>  guide contains a number of breaking changes, that users will have to adopt. 
> Examples include merging `wicket-http2` into `wicket-core`, and the 
> associated package change of `PushHeaderItem` to 
> `org.apache.wicket.markup.head.http2`. And while understandably necessary, 
> these nonetheless can be a hurdle for users to adopt.
> To help users adopt Wicket 10 and the associated upgrade to Java 17 and 
> Servlet 5+ I propose to add a module containing [OpenRewrite migration 
> recipes|https://docs.openrewrite.org/]. For those unfamiliar: OpenRewrite 
> allows you to define migration steps either through Yaml or with Java 
> visitors, and compose these steps to achieve larger migrations. Such 
> migrations have been [applied to Wicket 
> before,|https://github.com/apache/wicket/pull/546] but they can also be 
> defined and distributed for Apache Wicket users.
> As a recent example, migration recipes have been [added to Axon 
> Framework|https://developer.axoniq.io/w/upgrading-to-axon-framework-4.7-automated].
>  In practice that comes down to the following code changes, which also 
> include instructions on their use: 
> [https://github.com/AxonFramework/AxonFramework/pull/2597/files]
> Wicket 10 migration recipes can include a number of existing recipes that 
> help modernize applications:
>  # [Use lambdas where 
> possible|https://docs.openrewrite.org/reference/recipes/java/cleanup/uselambdaforfunctionalinterface]
>  # [Migrate to Jakarta EE 
> 9|https://docs.openrewrite.org/reference/recipes/java/migrate/jakarta/javaxmigrationtojakarta]
>  # [Migrate to Java 
> 17|https://docs.openrewrite.org/reference/recipes/java/migrate/upgradetojava17]
> The Wicket 10 specific recipes can reuse common building blocks such as 
> ChangeType to adopt package name changes, and RemoveDependency to remove 
> `wicket-http2`.
> Technically this wouldn't have to be very difficult initially, even more so 
> when the goal is to assist a migration rather than to achieve a complete 
> migration. The Axon Framework migration can serve as a template, and I'm 
> happy to provide guidance.
> Would this be something worth adding to Apache Wicket?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7029) Add migration recipes to Wicket 10

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809815#comment-17809815
 ] 

ASF GitHub Bot commented on WICKET-7029:


martin-g commented on code in PR #773:
URL: https://github.com/apache/wicket/pull/773#discussion_r1462938679


##
wicket-migration/src/main/resources/META-INF/rewrite/wicket.yml:
##
@@ -16,6 +16,11 @@ description: Migrates Wicket 9.x to Wicket 10.x, as well as 
Java 17 and Jakarta.
 recipeList:
   - org.openrewrite.java.migrate.UpgradeToJava17
   - org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta
+  - org.openrewrite.java.dependencies.AddDependency:
+  groupId: org.apache.wicket
+  artifactId: wicket-tester
+  version: 10.x
+  onlyIfUsing: org.apache.wicket.util.tester.*

Review Comment:
   Nice!





> Add migration recipes to Wicket 10
> --
>
> Key: WICKET-7029
> URL: https://issues.apache.org/jira/browse/WICKET-7029
> Project: Wicket
>  Issue Type: New Feature
>Affects Versions: 10.0.0-M1
>Reporter: Tim te Beek
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
>  Labels: migration
> Fix For: 10.0.0-M1
>
>
> The [Migration to Wicket 
> 10.0|https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0]
>  guide contains a number of breaking changes, that users will have to adopt. 
> Examples include merging `wicket-http2` into `wicket-core`, and the 
> associated package change of `PushHeaderItem` to 
> `org.apache.wicket.markup.head.http2`. And while understandably necessary, 
> these nonetheless can be a hurdle for users to adopt.
> To help users adopt Wicket 10 and the associated upgrade to Java 17 and 
> Servlet 5+ I propose to add a module containing [OpenRewrite migration 
> recipes|https://docs.openrewrite.org/]. For those unfamiliar: OpenRewrite 
> allows you to define migration steps either through Yaml or with Java 
> visitors, and compose these steps to achieve larger migrations. Such 
> migrations have been [applied to Wicket 
> before,|https://github.com/apache/wicket/pull/546] but they can also be 
> defined and distributed for Apache Wicket users.
> As a recent example, migration recipes have been [added to Axon 
> Framework|https://developer.axoniq.io/w/upgrading-to-axon-framework-4.7-automated].
>  In practice that comes down to the following code changes, which also 
> include instructions on their use: 
> [https://github.com/AxonFramework/AxonFramework/pull/2597/files]
> Wicket 10 migration recipes can include a number of existing recipes that 
> help modernize applications:
>  # [Use lambdas where 
> possible|https://docs.openrewrite.org/reference/recipes/java/cleanup/uselambdaforfunctionalinterface]
>  # [Migrate to Jakarta EE 
> 9|https://docs.openrewrite.org/reference/recipes/java/migrate/jakarta/javaxmigrationtojakarta]
>  # [Migrate to Java 
> 17|https://docs.openrewrite.org/reference/recipes/java/migrate/upgradetojava17]
> The Wicket 10 specific recipes can reuse common building blocks such as 
> ChangeType to adopt package name changes, and RemoveDependency to remove 
> `wicket-http2`.
> Technically this wouldn't have to be very difficult initially, even more so 
> when the goal is to assist a migration rather than to achieve a complete 
> migration. The Axon Framework migration can serve as a template, and I'm 
> happy to provide guidance.
> Would this be something worth adding to Apache Wicket?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7029) Add migration recipes to Wicket 10

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809807#comment-17809807
 ] 

ASF GitHub Bot commented on WICKET-7029:


timtebeek opened a new pull request, #773:
URL: https://github.com/apache/wicket/pull/773

   Adds the new dependency that was added as part of WICKET-7072
   - https://issues.apache.org/jira/browse/WICKET-7072
   - https://issues.apache.org/jira/browse/WICKET-7029
   
   




> Add migration recipes to Wicket 10
> --
>
> Key: WICKET-7029
> URL: https://issues.apache.org/jira/browse/WICKET-7029
> Project: Wicket
>  Issue Type: New Feature
>Affects Versions: 10.0.0-M1
>Reporter: Tim te Beek
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
>  Labels: migration
> Fix For: 10.0.0-M1
>
>
> The [Migration to Wicket 
> 10.0|https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0]
>  guide contains a number of breaking changes, that users will have to adopt. 
> Examples include merging `wicket-http2` into `wicket-core`, and the 
> associated package change of `PushHeaderItem` to 
> `org.apache.wicket.markup.head.http2`. And while understandably necessary, 
> these nonetheless can be a hurdle for users to adopt.
> To help users adopt Wicket 10 and the associated upgrade to Java 17 and 
> Servlet 5+ I propose to add a module containing [OpenRewrite migration 
> recipes|https://docs.openrewrite.org/]. For those unfamiliar: OpenRewrite 
> allows you to define migration steps either through Yaml or with Java 
> visitors, and compose these steps to achieve larger migrations. Such 
> migrations have been [applied to Wicket 
> before,|https://github.com/apache/wicket/pull/546] but they can also be 
> defined and distributed for Apache Wicket users.
> As a recent example, migration recipes have been [added to Axon 
> Framework|https://developer.axoniq.io/w/upgrading-to-axon-framework-4.7-automated].
>  In practice that comes down to the following code changes, which also 
> include instructions on their use: 
> [https://github.com/AxonFramework/AxonFramework/pull/2597/files]
> Wicket 10 migration recipes can include a number of existing recipes that 
> help modernize applications:
>  # [Use lambdas where 
> possible|https://docs.openrewrite.org/reference/recipes/java/cleanup/uselambdaforfunctionalinterface]
>  # [Migrate to Jakarta EE 
> 9|https://docs.openrewrite.org/reference/recipes/java/migrate/jakarta/javaxmigrationtojakarta]
>  # [Migrate to Java 
> 17|https://docs.openrewrite.org/reference/recipes/java/migrate/upgradetojava17]
> The Wicket 10 specific recipes can reuse common building blocks such as 
> ChangeType to adopt package name changes, and RemoveDependency to remove 
> `wicket-http2`.
> Technically this wouldn't have to be very difficult initially, even more so 
> when the goal is to assist a migration rather than to achieve a complete 
> migration. The Axon Framework migration can serve as a template, and I'm 
> happy to provide guidance.
> Would this be something worth adding to Apache Wicket?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7096) stylesheets referenced via automatic linking miss nonce attribute

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808082#comment-17808082
 ] 

ASF GitHub Bot commented on WICKET-7096:


martin-g commented on PR #768:
URL: https://github.com/apache/wicket/pull/768#issuecomment-1898013549

   Thank you, @sebthom !




> stylesheets referenced via automatic linking miss nonce attribute
> -
>
> Key: WICKET-7096
> URL: https://issues.apache.org/jira/browse/WICKET-7096
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 10.0.0-M2
>Reporter: Sebastian T
>Priority: Major
>
> I am running a Wicket App with:
> {code:java}
> getCspSettings().blocking();
> getMarkupSettings().setAutomaticLinking(true);
> {code}
> I have a base.css file in the same folder as the Wicket page and add it to 
> html like this:
> {code:html}
> 
> {code}
> This is rendered by wicket to
> {code:html}
>  href="./wicket/resource/com.example.MyPage/base-ver-1705259207805.css" 
> type="text/css" data-wicket-path="html___autolink__-1754779463"/>
> {code}
> This result in:
> {noformat}
> Content-Security-Policy: The page’s settings blocked the loading of a 
> resource at 
> http://localhost:8080/wicket/resource/com.example.MyPage/base-ver-1705259207805.css
>  (“style-src”).
> {noformat}
> -
> If I however add the stylesheet programmatically like this:
> {code:java}
> public void renderHead(final IHeaderResponse response) {
>   super.renderHead(response);
>   response.render(CssHeaderItem.forReference(new 
> CssResourceReference(MyPage.class, "base.css")));
> }
> {code}
> the required nonce is added as expected:
> {code:html}
>  href="./wicket/resource/com.example.MyPage/base-ver-1705259207805.css" 
> type="text/css" nonce="Fkg6q7ZOaX_uLN6aFESVwZVM" />
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7096) stylesheets referenced via automatic linking miss nonce attribute

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808078#comment-17808078
 ] 

ASF GitHub Bot commented on WICKET-7096:


martin-g merged PR #768:
URL: https://github.com/apache/wicket/pull/768




> stylesheets referenced via automatic linking miss nonce attribute
> -
>
> Key: WICKET-7096
> URL: https://issues.apache.org/jira/browse/WICKET-7096
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 10.0.0-M2
>Reporter: Sebastian T
>Priority: Major
>
> I am running a Wicket App with:
> {code:java}
> getCspSettings().blocking();
> getMarkupSettings().setAutomaticLinking(true);
> {code}
> I have a base.css file in the same folder as the Wicket page and add it to 
> html like this:
> {code:html}
> 
> {code}
> This is rendered by wicket to
> {code:html}
>  href="./wicket/resource/com.example.MyPage/base-ver-1705259207805.css" 
> type="text/css" data-wicket-path="html___autolink__-1754779463"/>
> {code}
> This result in:
> {noformat}
> Content-Security-Policy: The page’s settings blocked the loading of a 
> resource at 
> http://localhost:8080/wicket/resource/com.example.MyPage/base-ver-1705259207805.css
>  (“style-src”).
> {noformat}
> -
> If I however add the stylesheet programmatically like this:
> {code:java}
> public void renderHead(final IHeaderResponse response) {
>   super.renderHead(response);
>   response.render(CssHeaderItem.forReference(new 
> CssResourceReference(MyPage.class, "base.css")));
> }
> {code}
> the required nonce is added as expected:
> {code:html}
>  href="./wicket/resource/com.example.MyPage/base-ver-1705259207805.css" 
> type="text/css" nonce="Fkg6q7ZOaX_uLN6aFESVwZVM" />
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7096) stylesheets referenced via automatic linking miss nonce attribute

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807796#comment-17807796
 ] 

ASF GitHub Bot commented on WICKET-7096:


sebthom commented on PR #768:
URL: https://github.com/apache/wicket/pull/768#issuecomment-1896128614

   > It would be nice to add a test case too
   
   done




> stylesheets referenced via automatic linking miss nonce attribute
> -
>
> Key: WICKET-7096
> URL: https://issues.apache.org/jira/browse/WICKET-7096
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 10.0.0-M2
>Reporter: Sebastian T
>Priority: Major
>
> I am running a Wicket App with:
> {code:java}
> getCspSettings().blocking();
> getMarkupSettings().setAutomaticLinking(true);
> {code}
> I have a base.css file in the same folder as the Wicket page and add it to 
> html like this:
> {code:html}
> 
> {code}
> This is rendered by wicket to
> {code:html}
>  href="./wicket/resource/com.example.MyPage/base-ver-1705259207805.css" 
> type="text/css" data-wicket-path="html___autolink__-1754779463"/>
> {code}
> This result in:
> {noformat}
> Content-Security-Policy: The page’s settings blocked the loading of a 
> resource at 
> http://localhost:8080/wicket/resource/com.example.MyPage/base-ver-1705259207805.css
>  (“style-src”).
> {noformat}
> -
> If I however add the stylesheet programmatically like this:
> {code:java}
> public void renderHead(final IHeaderResponse response) {
>   super.renderHead(response);
>   response.render(CssHeaderItem.forReference(new 
> CssResourceReference(MyPage.class, "base.css")));
> }
> {code}
> the required nonce is added as expected:
> {code:html}
>  href="./wicket/resource/com.example.MyPage/base-ver-1705259207805.css" 
> type="text/css" nonce="Fkg6q7ZOaX_uLN6aFESVwZVM" />
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7096) stylesheets referenced via automatic linking miss nonce attribute

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806980#comment-17806980
 ] 

ASF GitHub Bot commented on WICKET-7096:


sebthom opened a new pull request, #768:
URL: https://github.com/apache/wicket/pull/768

   (no comment)




> stylesheets referenced via automatic linking miss nonce attribute
> -
>
> Key: WICKET-7096
> URL: https://issues.apache.org/jira/browse/WICKET-7096
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 10.0.0-M2
>Reporter: Sebastian T
>Priority: Major
>
> I am running a Wicket App with:
> {code:java}
> getCspSettings().blocking();
> getMarkupSettings().setAutomaticLinking(true);
> {code}
> I have a base.css file in the same folder as the Wicket page and add it to 
> html like this:
> {code:html}
> 
> {code}
> This is rendered by wicket to
> {code:html}
>  href="./wicket/resource/com.example.MyPage/base-ver-1705259207805.css" 
> type="text/css" data-wicket-path="html___autolink__-1754779463"/>
> {code}
> This result in:
> {noformat}
> Content-Security-Policy: The page’s settings blocked the loading of a 
> resource at 
> http://localhost:8080/wicket/resource/com.example.MyPage/base-ver-1705259207805.css
>  (“style-src”).
> {noformat}
> -
> If I however add the stylesheet programmatically like this:
> {code:java}
> public void renderHead(final IHeaderResponse response) {
>   super.renderHead(response);
>   response.render(CssHeaderItem.forReference(new 
> CssResourceReference(MyPage.class, "base.css")));
> }
> {code}
> the required nonce is added as expected:
> {code:html}
>  href="./wicket/resource/com.example.MyPage/base-ver-1705259207805.css" 
> type="text/css" nonce="Fkg6q7ZOaX_uLN6aFESVwZVM" />
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805259#comment-17805259
 ] 

ASF GitHub Bot commented on WICKET-7090:


papegaaij commented on PR #758:
URL: https://github.com/apache/wicket/pull/758#issuecomment-1885441134

   Thank you @mattrpav 




> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
> Fix For: 10.0.0-M3
>
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805247#comment-17805247
 ] 

ASF GitHub Bot commented on WICKET-7090:


mattrpav commented on PR #758:
URL: https://github.com/apache/wicket/pull/758#issuecomment-1885366546

   @martin-g @papegaaij I'll test the v10 release in OSGi and report any 
issues. Thanks.




> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
> Fix For: 10.0.0-M3
>
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805027#comment-17805027
 ] 

ASF GitHub Bot commented on WICKET-7090:


papegaaij merged PR #758:
URL: https://github.com/apache/wicket/pull/758




> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805002#comment-17805002
 ] 

ASF GitHub Bot commented on WICKET-7090:


papegaaij commented on PR #758:
URL: https://github.com/apache/wicket/pull/758#issuecomment-1884342352

   @martin-g are you ok with merging this change?




> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7094) Make all CSP schemes configurable

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804180#comment-17804180
 ] 

ASF GitHub Bot commented on WICKET-7094:


martin-g commented on PR #761:
URL: https://github.com/apache/wicket/pull/761#issuecomment-1880600390

   Thank you for the contribution, @renoth !




> Make all CSP schemes configurable
> -
>
> Key: WICKET-7094
> URL: https://issues.apache.org/jira/browse/WICKET-7094
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Johannes Renoth
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
> Fix For: 10.0.0-M3, 9.17.0
>
>
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#scheme-source]
> knows more than data and https. These should be made accepted by 
> FixedCSPValue#{color:#00627a}checkValidityForSrc{color}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7094) Make all CSP schemes configurable

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804176#comment-17804176
 ] 

ASF GitHub Bot commented on WICKET-7094:


martin-g merged PR #761:
URL: https://github.com/apache/wicket/pull/761




> Make all CSP schemes configurable
> -
>
> Key: WICKET-7094
> URL: https://issues.apache.org/jira/browse/WICKET-7094
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Johannes Renoth
>Priority: Minor
>
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#scheme-source]
> knows more than data and https. These should be made accepted by 
> FixedCSPValue#{color:#00627a}checkValidityForSrc{color}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803498#comment-17803498
 ] 

ASF GitHub Bot commented on WICKET-7090:


papegaaij commented on code in PR #758:
URL: https://github.com/apache/wicket/pull/758#discussion_r1442722644


##
pom.xml:
##
@@ -129,6 +129,8 @@

UTF-8

UTF-8
 
+   
2024-01-01T00:00:00Z

Review Comment:
   Yes, the maven-release-plugin should update this field automatically during 
a release. We do need to verify this at the next release though.





> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803496#comment-17803496
 ] 

ASF GitHub Bot commented on WICKET-7090:


papegaaij commented on code in PR #758:
URL: https://github.com/apache/wicket/pull/758#discussion_r1442721690


##
wicket-auth-roles/pom.xml:
##
@@ -24,7 +24,7 @@
../pom.xml

wicket-auth-roles
-   bundle
+   jar

Review Comment:
   @mattrpav This change is to get correct timestamps on files (also called 
entries) in the jar files. The maven-bundle-plugin does not set these 
timestamps at all, causing them to revert to the jar-epoch (02-01-1980). The 
maven-jar-plugin honors `project.build.outputTimestamp`. If it also gives us 
reproducible builds, that's a bonus but not the reason for this change.
   
   We do however not want to break OSGi support. However, none of the Wicket 
core developers uses OSGi, so this is very hard for us to test. With this 
change, the produced jars *should* still be valid OSGi bundles, but we have no 
good way to verify this. It be really great of you could check this.
   
   As far as I know OSGi, the only thing that makes a normal jar an OSGi bundle 
is a set of entries in the MANIFEST.MF. These all seem unaffected by this 
change (I compared before and after), so I think the change is correct. But 
maybe you can point to something else that must be in place for an OSGi bundle?





> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803381#comment-17803381
 ] 

ASF GitHub Bot commented on WICKET-7090:


solomax commented on code in PR #758:
URL: https://github.com/apache/wicket/pull/758#discussion_r1442445764


##
pom.xml:
##
@@ -129,6 +129,8 @@

UTF-8

UTF-8
 
+   
2024-01-01T00:00:00Z

Review Comment:
   Maven-release-plugin updates this field during release .





> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803304#comment-17803304
 ] 

ASF GitHub Bot commented on WICKET-7090:


mattrpav commented on code in PR #758:
URL: https://github.com/apache/wicket/pull/758#discussion_r1442183475


##
pom.xml:
##
@@ -129,6 +129,8 @@

UTF-8

UTF-8
 
+   
2024-01-01T00:00:00Z

Review Comment:
   Using a static value seems difficult to manage. I suggest looking at using 
the git commit timestamp. This would be automatic, it would change with ever 
commit and ensure reproducible builds get the same timestamp when rebuilt from 
any commit.





> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803305#comment-17803305
 ] 

ASF GitHub Bot commented on WICKET-7090:


mattrpav commented on code in PR #758:
URL: https://github.com/apache/wicket/pull/758#discussion_r1442183475


##
pom.xml:
##
@@ -129,6 +129,8 @@

UTF-8

UTF-8
 
+   
2024-01-01T00:00:00Z

Review Comment:
   Using a static value seems difficult to manage. I suggest looking at using 
the git commit timestamp. 
   
   Benefits:
   1. Automatically changes
   2. Changes with every commit
   3. Ensures reproducible builds get the same timestamp when rebuilt from any 
commit.





> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803303#comment-17803303
 ] 

ASF GitHub Bot commented on WICKET-7090:


mattrpav commented on code in PR #758:
URL: https://github.com/apache/wicket/pull/758#discussion_r1442182676


##
wicket-auth-roles/pom.xml:
##
@@ -24,7 +24,7 @@
../pom.xml

wicket-auth-roles
-   bundle
+   jar

Review Comment:
   @papegaaij the bundle plugin can add any field to the MANIFEST.MF. What 
field are you looking for in the MANIFEST.MF?





> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803202#comment-17803202
 ] 

ASF GitHub Bot commented on WICKET-7090:


papegaaij commented on code in PR #758:
URL: https://github.com/apache/wicket/pull/758#discussion_r1441863155


##
wicket-auth-roles/pom.xml:
##
@@ -24,7 +24,7 @@
../pom.xml

wicket-auth-roles
-   bundle
+   jar

Review Comment:
   @mattrpav the bundle plugin is activated by binding one of its goals to the 
maven execution phase (in this case `manifest` in `process-classes`). This will 
generate the MANIFEST.MF, which will then be used by the maven-jar-plugin. I 
can see the correct MANIFEST.MF in the produced jar.
   
   The problem with the maven-bundle-plugin is that it generates jars without 
timestamps on its entries. This is valid (and considered reproducible), but 
very inconvenient. There is no way to change this when using packaging 
`bundle`. I think the produced jars are fine. They do contain the correct 
MANIFEST.MF. However, we do not use OSGi, so I have no way of testing it.





> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803178#comment-17803178
 ] 

ASF GitHub Bot commented on WICKET-7090:


mattrpav commented on code in PR #758:
URL: https://github.com/apache/wicket/pull/758#discussion_r1441793638


##
wicket-auth-roles/pom.xml:
##
@@ -24,7 +24,7 @@
../pom.xml

wicket-auth-roles
-   bundle
+   jar

Review Comment:
   Yes, type should be ‘bundle’ to activate the bundle plugin when generating 
the jar. 
   
   ActiveMQ had changes to support reproducible builds and maintained the 
bundle plugin. 
   
   I recommend we should know exactly what is the miss or change needed to 
support reproducible builds, and not just change the project type to jar. 





> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803070#comment-17803070
 ] 

ASF GitHub Bot commented on WICKET-7090:


papegaaij commented on PR #758:
URL: https://github.com/apache/wicket/pull/758#issuecomment-1876994695

   > In addition: one of the commits uses `TKH-7090` instead of `WICKET-7090`
   
   Doh, TKH is the prefix we use for Topicus KeyHub :) I've fixed the commit.




> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803067#comment-17803067
 ] 

ASF GitHub Bot commented on WICKET-7090:


papegaaij commented on code in PR #758:
URL: https://github.com/apache/wicket/pull/758#discussion_r1441675290


##
wicket-auth-roles/pom.xml:
##
@@ -24,7 +24,7 @@
../pom.xml

wicket-auth-roles
-   bundle
+   jar

Review Comment:
   As far as I know, it shouldn't. A jar is an OSGi bundle, when it's manifest 
contains OSGi related information, but it's still a jar. The documentation for 
the maven-bundle-plugin even describes this setup as a valid solution: 
https://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#_adding_osgi_metadata_to_existing_projects_without_changing_the_packaging_type





> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802998#comment-17802998
 ] 

ASF GitHub Bot commented on WICKET-7090:


martin-g commented on PR #758:
URL: https://github.com/apache/wicket/pull/758#issuecomment-1876964895

   In addition: one of the commits uses `TKH-7090` instead of `WICKET-7090`




> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802997#comment-17802997
 ] 

ASF GitHub Bot commented on WICKET-7090:


martin-g commented on code in PR #758:
URL: https://github.com/apache/wicket/pull/758#discussion_r1441652353


##
wicket-auth-roles/pom.xml:
##
@@ -24,7 +24,7 @@
../pom.xml

wicket-auth-roles
-   bundle
+   jar

Review Comment:
   Does this break the OSGi support ?!
   CC @mattrpav 





> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802890#comment-17802890
 ] 

ASF GitHub Bot commented on WICKET-7090:


papegaaij commented on PR #758:
URL: https://github.com/apache/wicket/pull/758#issuecomment-1876851753

   Ok, unfortunately, this does not seem to give the desired effect. The files 
in the jars still don't have timestamps.




> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802886#comment-17802886
 ] 

ASF GitHub Bot commented on WICKET-7090:


papegaaij opened a new pull request, #758:
URL: https://github.com/apache/wicket/pull/758

   In addition to reprocible builds, this should also result in timestamps 
being set on files in jars.




> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
>  Issue Type: Bug
>  Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0, 
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a 
> last modification timestamp. This can cause issues if 
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}. 
> The browser may be using an older version of the resource, even if a newer 
> version is available. This strategy is normally only used in development 
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last 
> modification timestamp to fixed time during the release, as git doesn't track 
> this. A suggestion is to use  the project.build.outputTimestamp property: 
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7089) Set cookie SameSite only if the container supports it

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798457#comment-17798457
 ] 

ASF GitHub Bot commented on WICKET-7089:


martin-g merged PR #749:
URL: https://github.com/apache/wicket/pull/749




> Set cookie SameSite only if the container supports it
> -
>
> Key: WICKET-7089
> URL: https://issues.apache.org/jira/browse/WICKET-7089
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 10.0.0-M2
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0-M3
>
>
> [https://lists.apache.org/thread/nwnhygmwoodbmx8f5j0rtm5wgy21p5kr]
>  
> {code:java}
> Hi,
> in parent pom.xml you are referencing
> 6.0.0
> but here you state that Servlet 5+ is required:
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0#MigrationtoWicket10.0-Wicket10requiresServlet5+
> I've been bitten by this today when users couldn't sign in the app as 
> CookieUtils.initializeCookie uses 6.0.0 api, start of the stacktrace:
> java.lang.NoSuchMethodError: 'void 
> jakarta.servlet.http.Cookie.setAttribute(java.lang.String, 
> java.lang.String)'
>      at 
> org.apache.wicket.util.cookies.CookieUtils.initializeCookie(CookieUtils.java:341)
>      at 
> org.apache.wicket.util.cookies.CookieUtils.save(CookieUtils.java:294)
>      at 
> org.apache.wicket.util.cookies.CookieUtils.save(CookieUtils.java:168)
>      at 
> org.apache.wicket.authentication.strategy.DefaultAuthenticationStrategy.save(DefaultAuthenticationStrategy.java:148)
> Cookie.setAttribute is not present in 5.0.0 jservlet-api.
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7089) Set cookie SameSite only if the container supports it

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798459#comment-17798459
 ] 

ASF GitHub Bot commented on WICKET-7089:


martin-g commented on PR #749:
URL: https://github.com/apache/wicket/pull/749#issuecomment-1862226321

   Thank you, @vrozkovec !




> Set cookie SameSite only if the container supports it
> -
>
> Key: WICKET-7089
> URL: https://issues.apache.org/jira/browse/WICKET-7089
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 10.0.0-M2
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0-M3
>
>
> [https://lists.apache.org/thread/nwnhygmwoodbmx8f5j0rtm5wgy21p5kr]
>  
> {code:java}
> Hi,
> in parent pom.xml you are referencing
> 6.0.0
> but here you state that Servlet 5+ is required:
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0#MigrationtoWicket10.0-Wicket10requiresServlet5+
> I've been bitten by this today when users couldn't sign in the app as 
> CookieUtils.initializeCookie uses 6.0.0 api, start of the stacktrace:
> java.lang.NoSuchMethodError: 'void 
> jakarta.servlet.http.Cookie.setAttribute(java.lang.String, 
> java.lang.String)'
>      at 
> org.apache.wicket.util.cookies.CookieUtils.initializeCookie(CookieUtils.java:341)
>      at 
> org.apache.wicket.util.cookies.CookieUtils.save(CookieUtils.java:294)
>      at 
> org.apache.wicket.util.cookies.CookieUtils.save(CookieUtils.java:168)
>      at 
> org.apache.wicket.authentication.strategy.DefaultAuthenticationStrategy.save(DefaultAuthenticationStrategy.java:148)
> Cookie.setAttribute is not present in 5.0.0 jservlet-api.
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7089) Set cookie SameSite only if the container supports it

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798064#comment-17798064
 ] 

ASF GitHub Bot commented on WICKET-7089:


vrozkovec commented on PR #749:
URL: https://github.com/apache/wicket/pull/749#issuecomment-1859867560

   Done




> Set cookie SameSite only if the container supports it
> -
>
> Key: WICKET-7089
> URL: https://issues.apache.org/jira/browse/WICKET-7089
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 10.0.0-M2
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0-M3
>
>
> [https://lists.apache.org/thread/nwnhygmwoodbmx8f5j0rtm5wgy21p5kr]
>  
> {code:java}
> Hi,
> in parent pom.xml you are referencing
> 6.0.0
> but here you state that Servlet 5+ is required:
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0#MigrationtoWicket10.0-Wicket10requiresServlet5+
> I've been bitten by this today when users couldn't sign in the app as 
> CookieUtils.initializeCookie uses 6.0.0 api, start of the stacktrace:
> java.lang.NoSuchMethodError: 'void 
> jakarta.servlet.http.Cookie.setAttribute(java.lang.String, 
> java.lang.String)'
>      at 
> org.apache.wicket.util.cookies.CookieUtils.initializeCookie(CookieUtils.java:341)
>      at 
> org.apache.wicket.util.cookies.CookieUtils.save(CookieUtils.java:294)
>      at 
> org.apache.wicket.util.cookies.CookieUtils.save(CookieUtils.java:168)
>      at 
> org.apache.wicket.authentication.strategy.DefaultAuthenticationStrategy.save(DefaultAuthenticationStrategy.java:148)
> Cookie.setAttribute is not present in 5.0.0 jservlet-api.
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7089) Set cookie SameSite only if the container supports it

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798038#comment-17798038
 ] 

ASF GitHub Bot commented on WICKET-7089:


martin-g commented on PR #749:
URL: https://github.com/apache/wicket/pull/749#issuecomment-1859691170

   Please update the commit message to start with `WICKET-7089`




> Set cookie SameSite only if the container supports it
> -
>
> Key: WICKET-7089
> URL: https://issues.apache.org/jira/browse/WICKET-7089
> Project: Wicket
>  Issue Type: Sub-task
>  Components: wicket
>Affects Versions: 10.0.0-M2
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0-M3
>
>
> [https://lists.apache.org/thread/nwnhygmwoodbmx8f5j0rtm5wgy21p5kr]
>  
> {code:java}
> Hi,
> in parent pom.xml you are referencing
> 6.0.0
> but here you state that Servlet 5+ is required:
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0#MigrationtoWicket10.0-Wicket10requiresServlet5+
> I've been bitten by this today when users couldn't sign in the app as 
> CookieUtils.initializeCookie uses 6.0.0 api, start of the stacktrace:
> java.lang.NoSuchMethodError: 'void 
> jakarta.servlet.http.Cookie.setAttribute(java.lang.String, 
> java.lang.String)'
>      at 
> org.apache.wicket.util.cookies.CookieUtils.initializeCookie(CookieUtils.java:341)
>      at 
> org.apache.wicket.util.cookies.CookieUtils.save(CookieUtils.java:294)
>      at 
> org.apache.wicket.util.cookies.CookieUtils.save(CookieUtils.java:168)
>      at 
> org.apache.wicket.authentication.strategy.DefaultAuthenticationStrategy.save(DefaultAuthenticationStrategy.java:148)
> Cookie.setAttribute is not present in 5.0.0 jservlet-api.
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7088) Improve test reliability by resolving nondeterministic order of Set and Map

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792931#comment-17792931
 ] 

ASF GitHub Bot commented on WICKET-7088:


MyEnthusiastic commented on PR #707:
URL: https://github.com/apache/wicket/pull/707#issuecomment-1838953146

   My pleasure! 




> Improve test reliability by resolving nondeterministic order of Set and Map
> ---
>
> Key: WICKET-7088
> URL: https://issues.apache.org/jira/browse/WICKET-7088
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Affects Versions: 10.0.0-M2, 9.16.0
> Environment: Reproduce
> This error can be reproduced with the NondexTool with the following command 
> (you can try that without modifying the pom, but feel free to use the plugin 
> to protect your project and make it safer  ), and this kind problem is 
> widely documented in International Dataset of Flaky Tests (IDoFT)
> mvn edu.illinois:nondex-maven-plugin:2.1.7-SNAPSHOT:nondex -pl 
> ./wicket-core-tests -DnondexRuns=10 
> -Dtest=org.apache.wicket.markup.html.form.CollectionFormComponentTest#getSetUnmodifiableSet
> Most similar Similar issues
> FasterXML/jackson-jaxrs-providers#154
> https://github.com/FasterXML/jackson-annotations/pull/194/files
>Reporter: huiyang chi
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
>  Labels: pull-request-available
> Fix For: 10.0.0-M3
>
>
> The related PR had been approved  : 
> [https://github.com/apache/wicket/pull/707] :):):)
> h1. Problem
> In the test getSetUnmodifiableSet and getSetNullList, we use a set to 
> intitialize our choice, and assume it will have the order with 
> getDefaultModelObjectAsString to be [A, B], but this is not necessary true 
> according to [Oracle's official 
> document|https://docs.oracle.com/javase/8/docs/api/java/util/HashSet.html#:~:text=It%20makes%20no%20guarantees%20as%20to%20the%20iteration%20order%20of%20the%20set%3B%20in%20particular]
>  
> For the test renderAjaxAttributes, we create the Json string from the 
> AjaxRequestAttributes and assume the order of the fields in tests which is 
> not true because it serialize from extraParameters which was a HashMap, which 
> did not guarantee any order and will cause non-deterministic when we change 
> the environments like JDK version. Also the LinkedHashMap is designed with 
> specification to guarantee the order to resolve this kind of problem
> h1. Solution
> Use LinkedHashMap
> This problem had encountered and solved in wicket the same way before :
> [wicket/wicket-core/src/main/java/org/apache/wicket/ajax/json/README|https://github.com/apache/wicket/blob/b243eca31ab4a0ab78159fd2ccf7337a38b94840/wicket-core/src/main/java/org/apache/wicket/ajax/json/README#L4-L6]
> Lines 4 to 6 in 
> [b243eca|https://github.com/apache/wicket/commit/b243eca31ab4a0ab78159fd2ccf7337a38b94840]
> ||IMPORTANT: JSONObject#map field is manually changed to LinkedHashMap (from 
> HashMap) to keep||
> ||the order of the ajax attributes consistent for WicketTester based unit 
> tests||
>  
>  
> h1. Affected Tests
>  
> [INFO] 
> org.apache.wicket.markup.html.form.CollectionFormComponentTest#getSetUnmodifiableSet
> [INFO] 
> org.apache.wicket.markup.html.form.CollectionFormComponentTest#getSetNullSet
> [INFO] 
> org.apache.wicket.ajax.AbstractDefaultAjaxBehaviorTest#renderAjaxAttributes
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithConverted
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithExplicit
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithAll
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithContext
> [INFO] org.apache.wicket.ajax.AjaxCallbackFunctionTest#testJQueryUIEvent
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithResolved
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testDefaultCallbackFunction



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7088) Improve test reliability by resolving nondeterministic order of Set and Map

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792688#comment-17792688
 ] 

ASF GitHub Bot commented on WICKET-7088:


martin-g commented on PR #707:
URL: https://github.com/apache/wicket/pull/707#issuecomment-1837988520

   Thank you, @MyEnthusiastic !




> Improve test reliability by resolving nondeterministic order of Set and Map
> ---
>
> Key: WICKET-7088
> URL: https://issues.apache.org/jira/browse/WICKET-7088
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Affects Versions: 10.0.0-M2, 9.16.0
> Environment: Reproduce
> This error can be reproduced with the NondexTool with the following command 
> (you can try that without modifying the pom, but feel free to use the plugin 
> to protect your project and make it safer  ), and this kind problem is 
> widely documented in International Dataset of Flaky Tests (IDoFT)
> mvn edu.illinois:nondex-maven-plugin:2.1.7-SNAPSHOT:nondex -pl 
> ./wicket-core-tests -DnondexRuns=10 
> -Dtest=org.apache.wicket.markup.html.form.CollectionFormComponentTest#getSetUnmodifiableSet
> Most similar Similar issues
> FasterXML/jackson-jaxrs-providers#154
> https://github.com/FasterXML/jackson-annotations/pull/194/files
>Reporter: huiyang chi
>Priority: Major
>  Labels: pull-request-available
>
> The related PR had been approved  : 
> [https://github.com/apache/wicket/pull/707] :):):)
> h1. Problem
> In the test getSetUnmodifiableSet and getSetNullList, we use a set to 
> intitialize our choice, and assume it will have the order with 
> getDefaultModelObjectAsString to be [A, B], but this is not necessary true 
> according to [Oracle's official 
> document|https://docs.oracle.com/javase/8/docs/api/java/util/HashSet.html#:~:text=It%20makes%20no%20guarantees%20as%20to%20the%20iteration%20order%20of%20the%20set%3B%20in%20particular]
>  
> For the test renderAjaxAttributes, we create the Json string from the 
> AjaxRequestAttributes and assume the order of the fields in tests which is 
> not true because it serialize from extraParameters which was a HashMap, which 
> did not guarantee any order and will cause non-deterministic when we change 
> the environments like JDK version. Also the LinkedHashMap is designed with 
> specification to guarantee the order to resolve this kind of problem
> h1. Solution
> Use LinkedHashMap
> This problem had encountered and solved in wicket the same way before :
> [wicket/wicket-core/src/main/java/org/apache/wicket/ajax/json/README|https://github.com/apache/wicket/blob/b243eca31ab4a0ab78159fd2ccf7337a38b94840/wicket-core/src/main/java/org/apache/wicket/ajax/json/README#L4-L6]
> Lines 4 to 6 in 
> [b243eca|https://github.com/apache/wicket/commit/b243eca31ab4a0ab78159fd2ccf7337a38b94840]
> ||IMPORTANT: JSONObject#map field is manually changed to LinkedHashMap (from 
> HashMap) to keep||
> ||the order of the ajax attributes consistent for WicketTester based unit 
> tests||
>  
>  
> h1. Affected Tests
>  
> [INFO] 
> org.apache.wicket.markup.html.form.CollectionFormComponentTest#getSetUnmodifiableSet
> [INFO] 
> org.apache.wicket.markup.html.form.CollectionFormComponentTest#getSetNullSet
> [INFO] 
> org.apache.wicket.ajax.AbstractDefaultAjaxBehaviorTest#renderAjaxAttributes
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithConverted
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithExplicit
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithAll
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithContext
> [INFO] org.apache.wicket.ajax.AjaxCallbackFunctionTest#testJQueryUIEvent
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithResolved
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testDefaultCallbackFunction



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7088) Improve test reliability by resolving nondeterministic order of Set and Map

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792687#comment-17792687
 ] 

ASF GitHub Bot commented on WICKET-7088:


martin-g merged PR #707:
URL: https://github.com/apache/wicket/pull/707




> Improve test reliability by resolving nondeterministic order of Set and Map
> ---
>
> Key: WICKET-7088
> URL: https://issues.apache.org/jira/browse/WICKET-7088
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Affects Versions: 10.0.0-M2, 9.16.0
> Environment: Reproduce
> This error can be reproduced with the NondexTool with the following command 
> (you can try that without modifying the pom, but feel free to use the plugin 
> to protect your project and make it safer  ), and this kind problem is 
> widely documented in International Dataset of Flaky Tests (IDoFT)
> mvn edu.illinois:nondex-maven-plugin:2.1.7-SNAPSHOT:nondex -pl 
> ./wicket-core-tests -DnondexRuns=10 
> -Dtest=org.apache.wicket.markup.html.form.CollectionFormComponentTest#getSetUnmodifiableSet
> Most similar Similar issues
> FasterXML/jackson-jaxrs-providers#154
> https://github.com/FasterXML/jackson-annotations/pull/194/files
>Reporter: huiyang chi
>Priority: Major
>  Labels: pull-request-available
>
> The related PR had been approved  : 
> [https://github.com/apache/wicket/pull/707] :):):)
> h1. Problem
> In the test getSetUnmodifiableSet and getSetNullList, we use a set to 
> intitialize our choice, and assume it will have the order with 
> getDefaultModelObjectAsString to be [A, B], but this is not necessary true 
> according to [Oracle's official 
> document|https://docs.oracle.com/javase/8/docs/api/java/util/HashSet.html#:~:text=It%20makes%20no%20guarantees%20as%20to%20the%20iteration%20order%20of%20the%20set%3B%20in%20particular]
>  
> For the test renderAjaxAttributes, we create the Json string from the 
> AjaxRequestAttributes and assume the order of the fields in tests which is 
> not true because it serialize from extraParameters which was a HashMap, which 
> did not guarantee any order and will cause non-deterministic when we change 
> the environments like JDK version. Also the LinkedHashMap is designed with 
> specification to guarantee the order to resolve this kind of problem
> h1. Solution
> Use LinkedHashMap
> This problem had encountered and solved in wicket the same way before :
> [wicket/wicket-core/src/main/java/org/apache/wicket/ajax/json/README|https://github.com/apache/wicket/blob/b243eca31ab4a0ab78159fd2ccf7337a38b94840/wicket-core/src/main/java/org/apache/wicket/ajax/json/README#L4-L6]
> Lines 4 to 6 in 
> [b243eca|https://github.com/apache/wicket/commit/b243eca31ab4a0ab78159fd2ccf7337a38b94840]
> ||IMPORTANT: JSONObject#map field is manually changed to LinkedHashMap (from 
> HashMap) to keep||
> ||the order of the ajax attributes consistent for WicketTester based unit 
> tests||
>  
>  
> h1. Affected Tests
>  
> [INFO] 
> org.apache.wicket.markup.html.form.CollectionFormComponentTest#getSetUnmodifiableSet
> [INFO] 
> org.apache.wicket.markup.html.form.CollectionFormComponentTest#getSetNullSet
> [INFO] 
> org.apache.wicket.ajax.AbstractDefaultAjaxBehaviorTest#renderAjaxAttributes
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithConverted
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithExplicit
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithAll
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithContext
> [INFO] org.apache.wicket.ajax.AjaxCallbackFunctionTest#testJQueryUIEvent
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testCallbackFunctionWithResolved
> [INFO] 
> org.apache.wicket.ajax.AjaxCallbackFunctionTest#testDefaultCallbackFunction



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7086) Injecting Spring bean may cause ClassCastException

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792675#comment-17792675
 ] 

ASF GitHub Bot commented on WICKET-7086:


martin-g merged PR #709:
URL: https://github.com/apache/wicket/pull/709




> Injecting Spring bean may cause ClassCastException
> --
>
> Key: WICKET-7086
> URL: https://issues.apache.org/jira/browse/WICKET-7086
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-spring
>Affects Versions: 9.15.0
>Reporter: Miklós Győrfi
>Priority: Minor
> Attachments: repro.tgz
>
>
> h3. Issue Summary:
> The {{getBeanNameOfClass()}} method used for injecting Spring beans into 
> Wicket components has a limitation when dealing with generic collection 
> fields. The method is designed to look up a bean name based on the raw type 
> of the collection (e.g., {{{}List{}}}). However, in scenarios where there are 
> beans with more specific generic types (e.g., {{{}List{}}}), the 
> method incorrectly resolves and injects the bean, leading to potential 
> {{ClassCastException}} issues at runtime.
> h3. Problem Details:
> When the field class is a generic collection (e.g., {{{}List{}}}), 
> the {{getBeanNameOfClass()}} method resolves a bean with the type of the raw 
> collection (e.g., {{{}List{}}}). This behavior generally works as intended. 
> However, when there are beans with more specific generic types (e.g., 
> {{{}List{}}}), the method incorrectly identifies and injects the 
> bean, even if the generic types ({{{}SomeClass{}}} and {{{}AnyClass{}}}) do 
> not match. This results in unexpected behavior and may cause 
> {{ClassCastException}} errors later in the application.
> h3. Reproduction Scenario:
> This issue becomes apparent when using Apache Causeway in conjunction with 
> Spring Data REST.  There is a bean named {{defaultMessageConverters}} (wich 
> is a List) is inserted into {{CausewayWicketApplication}} within the 
> {{applicationInitializers}} field, it is erroneously resolved based on the 
> raw type, leading to improper injection.
> h3. Proposed Solution:
> Review and enhance the {{getBeanNameOfClass()}} method to consider generic 
> types more accurately, ensuring that beans are resolved based on 
> compatibility with the field's specific generic type. 
> Problem is here:
>  
> {code:java}
> List names = new ArrayList<>(
> Arrays.asList(BeanFactoryUtils.beanNamesForTypeIncludingAncestors(ctx, 
> clazz)));
>  {code}
>  
> It uses the clazz, without generic.
> Possible solution:
>  
> {code:java}
> ResolvableType resolvableType = generic != null ? 
> ResolvableType.forClassWithGenerics(clazz, generic) : 
> ResolvableType.forClass(clazz);
> List names = new ArrayList<>(
> Arrays.asList(BeanFactoryUtils.beanNamesForTypeIncludingAncestors(ctx, 
> resolvableType)));
>  {code}
>  
> It is compatible with Spring from 4.2. 
>  
> h3. Additional Context:
> This problem affects scenarios where generic collections are used in 
> Spring-Wicket integration, and it becomes particularly prominent when Apache 
> Causeway is utilized alongside Spring Data REST.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WICKET-7087) AjaxLazyLoadPanelTester not available in 10.0.0-M2

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/WICKET-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792672#comment-17792672
 ] 

ASF GitHub Bot commented on WICKET-7087:


martin-g merged PR #708:
URL: https://github.com/apache/wicket/pull/708




> AjaxLazyLoadPanelTester not available in 10.0.0-M2
> --
>
> Key: WICKET-7087
> URL: https://issues.apache.org/jira/browse/WICKET-7087
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 10.0.0-M2
>Reporter: Andreas Keefer
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
>  Labels: testability
>
> Since 10.0.0-M2 AjaxLazyLoadPanelTester has been moved to the test sources, 
> so it is no longer available to use.
> Copy-And-Own is also only possible in package 
> org.apache.wicket.extensions.ajax.markup.html, because class 
> AjaxLazyLoadTimer has package private visibility.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)