[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set
[
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)
Re: [PR] WICKET-7090: add outputTimestamp property to enable reproducible builds [wicket]
papegaaij commented on PR #758: URL: https://github.com/apache/wicket/pull/758#issuecomment-1885441134 Thank you @mattrpav -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@wicket.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set
[
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)
Re: [PR] WICKET-7090: add outputTimestamp property to enable reproducible builds [wicket]
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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@wicket.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] PartialPageUpdater could not update if different object references were used for its own page and the component to update [wicket]
aminabromand closed pull request #762: PartialPageUpdater could not update if different object references were used for its own page and the component to update URL: https://github.com/apache/wicket/pull/762 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@wicket.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] PartialPageUpdater could not update if different object references were used for its own page and the component to update [wicket]
aminabromand commented on code in PR #762:
URL: https://github.com/apache/wicket/pull/762#discussion_r1447225625
##
wicket-core/src/main/java/org/apache/wicket/page/PartialPageUpdate.java:
##
@@ -567,7 +567,7 @@ public final void add(final Component component, final
String markupId)
LOG.warn("Component '{}' not cannot be updated
because it was already removed from page", component);
return;
}
- else if (pageOfComponent != page)
+ else if (!pageOfComponent.equals(page))
Review Comment:
ok, understood.
Anyhow, thanks for the support and quick responses!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@wicket.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] PartialPageUpdater could not update if different object references were used for its own page and the component to update [wicket]
svenmeier commented on code in PR #762:
URL: https://github.com/apache/wicket/pull/762#discussion_r1447218599
##
wicket-core/src/main/java/org/apache/wicket/page/PartialPageUpdate.java:
##
@@ -567,7 +567,7 @@ public final void add(final Component component, final
String markupId)
LOG.warn("Component '{}' not cannot be updated
because it was already removed from page", component);
return;
}
- else if (pageOfComponent != page)
+ else if (!pageOfComponent.equals(page))
Review Comment:
Changing #equals and #hashCode in such a central class can have severe
negative consequence, that I would not like to risk.
Your idea with updating via component path sounds good to me.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@wicket.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] PartialPageUpdater could not update if different object references were used for its own page and the component to update [wicket]
aminabromand commented on code in PR #762:
URL: https://github.com/apache/wicket/pull/762#discussion_r1447215766
##
wicket-core/src/main/java/org/apache/wicket/Page.java:
##
@@ -1012,4 +1013,21 @@ public final boolean wasRendered(Component component)
{
return renderedComponents != null &&
renderedComponents.contains(component);
}
+
+ @Override
+ public boolean equals(Object o) {
+ if (this == o) {
+ return true;
+ }
+ if (o == null || getClass() != o.getClass()) {
+ return false;
+ }
+ Page that = (Page) o;
+ return autoIndex == that.autoIndex && numericId ==
that.numericId;
Review Comment:
you are right, that `autoIndex` is not good for the method as it can change.
But so does `renderCount`.
So I change the method to use `numericId` only.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@wicket.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] PartialPageUpdater could not update if different object references were used for its own page and the component to update [wicket]
aminabromand commented on code in PR #762:
URL: https://github.com/apache/wicket/pull/762#discussion_r1447214792
##
wicket-core/src/main/java/org/apache/wicket/page/PartialPageUpdate.java:
##
@@ -567,7 +567,7 @@ public final void add(final Component component, final
String markupId)
LOG.warn("Component '{}' not cannot be updated
because it was already removed from page", component);
return;
}
- else if (pageOfComponent != page)
+ else if (!pageOfComponent.equals(page))
Review Comment:
I agree with you, that the current design of the application does not look
that good.
But it is a legacy appliation, that I have inheritted and that I have just
updated from Wicket 6.x to Wicket 9.x.
I was able to find a workaround:
instead of calling `target.add(button);`, where `target` is the
`AjaxRequestTarget` in `@Override protected void onTimer(AjaxRequestTarget
target) {...}` and `button` is the `Component` from the registry.
now I call `getButtonRef(target.getPage(),
button.getPath()).ifPresentOrElse(target::add,() -> target.add(button));` with
`getButtonRef()` =
`
private Optional getButtonRef(Page page, String buttonPath) {
String pagePath = page.getPath();
if (!buttonPath.startsWith(pagePath)) {
return Optional.empty();
}
buttonPath = buttonPath.substring(pagePath.length() + 1);
return Optional.ofNullable(page.get(buttonPath));
}
`
so I look for the child component of the page, that has the same `path` as
the button in the registry.
Anyhow, I do think, doing the comparison with `equals()` instead of `==` has
some advantages.
But I let you decide :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@wicket.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] PartialPageUpdater could not update if different object references were used for its own page and the component to update [wicket]
martin-g commented on code in PR #762:
URL: https://github.com/apache/wicket/pull/762#discussion_r1447083054
##
wicket-core/src/main/java/org/apache/wicket/page/PartialPageUpdate.java:
##
@@ -567,7 +567,7 @@ public final void add(final Component component, final
String markupId)
LOG.warn("Component '{}' not cannot be updated
because it was already removed from page", component);
return;
}
- else if (pageOfComponent != page)
+ else if (!pageOfComponent.equals(page))
Review Comment:
> So when the `AbstractAjaxTimerBehavior` pulls the Buttons our of the
registry, the buttons are assigned to the same page, but it is not the very
same object in the heap.
So, you keep `Component`s (the buttons) in some registry ?
That would mean that you keep the buttons' parents in the registry, i.e. the
whole page instances.
I am not sure this is a good idea! The items in the registry may become
obsolete sooner or later depending on how much your application is based on SPA
(single page application) design. I hope you have some cleanup mechanism!
IMO it would be better to have a registry with `ButtonDescription`s which
are used to create Button components when needed and to replace the components
in the current page instance before render.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@wicket.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Resolved] (WICKET-7090) Files in release jars do not have a modification timestamp set
[
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij resolved WICKET-7090.
-
Fix Version/s: 10.0.0-M3
Resolution: Fixed
> 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] [Closed] (WICKET-7090) Files in release jars do not have a modification timestamp set
[
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij closed 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
> 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
[
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
[
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805028#comment-17805028
]
ASF subversion and git services commented on WICKET-7090:
-
Commit 83fc5fedfb592b2be532c28472bbd9a539167dbd in wicket's branch
refs/heads/master from Emond Papegaaij
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=83fc5fedfb ]
WICKET-7090: add outputTimestamp property to enable reproducible builds
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
>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)
(wicket) branch master updated (eadd734259 -> 07d457bd4d)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/wicket.git from eadd734259 Re-enable SpringWebApplicationFactoryTest add 83fc5fedfb WICKET-7090: add outputTimestamp property to enable reproducible builds add 7652239b31 WICKET-7090: use manifest from maven-bundle-plugin but use maven-jar-plugin for packaging add 07d457bd4d Merge pull request #758 from apache/wicket-7090 No new revisions were added by this update. Summary of changes: pom.xml| 7 +-- wicket-auth-roles/pom.xml | 2 +- wicket-bean-validation/pom.xml | 2 +- wicket-cdi/pom.xml | 2 +- wicket-core/pom.xml| 2 +- wicket-devutils/pom.xml| 2 +- wicket-experimental/wicket-metrics/pom.xml | 2 +- wicket-extensions-tester/pom.xml | 2 +- wicket-extensions/pom.xml | 2 +- wicket-guice/pom.xml | 2 +- wicket-ioc/pom.xml | 2 +- wicket-jmx/pom.xml | 2 +- wicket-native-websocket/wicket-native-websocket-core/pom.xml | 2 +- wicket-native-websocket/wicket-native-websocket-javax/pom.xml | 2 +- wicket-native-websocket/wicket-native-websocket-tester/pom.xml | 2 +- wicket-request/pom.xml | 2 +- wicket-spring/pom.xml | 2 +- wicket-tester/pom.xml | 2 +- wicket-util/pom.xml| 2 +- wicket-velocity/pom.xml| 2 +- 20 files changed, 24 insertions(+), 21 deletions(-)
[jira] [Commented] (WICKET-7090) Files in release jars do not have a modification timestamp set
[
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805030#comment-17805030
]
ASF subversion and git services commented on WICKET-7090:
-
Commit 07d457bd4d5b5d6c01d4ccb3e44489ec52d0ea1d in wicket's branch
refs/heads/master from Emond Papegaaij
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=07d457bd4d ]
Merge pull request #758 from apache/wicket-7090
WICKET-7090: add outputTimestamp property to enable reproducible builds
> 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
[
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805029#comment-17805029
]
ASF subversion and git services commented on WICKET-7090:
-
Commit 7652239b31c6b3fccaf62d39069f35fe0df6cec3 in wicket's branch
refs/heads/master from Emond Papegaaij
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=7652239b31 ]
WICKET-7090: use manifest from maven-bundle-plugin but use maven-jar-plugin for
packaging
> 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)
Re: [PR] WICKET-7090: add outputTimestamp property to enable reproducible builds [wicket]
papegaaij merged PR #758: URL: https://github.com/apache/wicket/pull/758 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@wicket.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] PartialPageUpdater could not update if different object references were used for its own page and the component to update [wicket]
martin-g commented on code in PR #762:
URL: https://github.com/apache/wicket/pull/762#discussion_r1447067469
##
wicket-core/src/main/java/org/apache/wicket/Page.java:
##
@@ -1012,4 +1013,21 @@ public final boolean wasRendered(Component component)
{
return renderedComponents != null &&
renderedComponents.contains(component);
}
+
+ @Override
+ public boolean equals(Object o) {
+ if (this == o) {
+ return true;
+ }
+ if (o == null || getClass() != o.getClass()) {
+ return false;
+ }
+ Page that = (Page) o;
+ return autoIndex == that.autoIndex && numericId ==
that.numericId;
Review Comment:
I think you should use `renderCount` instead of `autoIndex`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@wicket.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
(wicket) branch master updated: Re-enable SpringWebApplicationFactoryTest
This is an automated email from the ASF dual-hosted git repository.
mgrigorov pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/master by this push:
new eadd734259 Re-enable SpringWebApplicationFactoryTest
eadd734259 is described below
commit eadd734259ea2ec784523cf0ca55a3a29c89c26e
Author: Martin Tzvetanov Grigorov
AuthorDate: Wed Jan 10 10:51:09 2024 +0200
Re-enable SpringWebApplicationFactoryTest
Use JUnit 5.x APIs for the disabled CDI tests
Signed-off-by: Martin Tzvetanov Grigorov
---
.../apache/wicket/cdi/CdiConfigurationTest.java| 18 +++---
.../wicket/cdi/ConversationPropagatorTest.java | 28 +++---
.../spring/SpringWebApplicationFactoryTest.java| 5 +---
3 files changed, 24 insertions(+), 27 deletions(-)
diff --git
a/wicket-cdi/src/test/java/org/apache/wicket/cdi/CdiConfigurationTest.java
b/wicket-cdi/src/test/java/org/apache/wicket/cdi/CdiConfigurationTest.java
index 5a2391ed8f..0ee921bade 100644
--- a/wicket-cdi/src/test/java/org/apache/wicket/cdi/CdiConfigurationTest.java
+++ b/wicket-cdi/src/test/java/org/apache/wicket/cdi/CdiConfigurationTest.java
@@ -22,18 +22,18 @@ import static org.junit.jupiter.api.Assertions.assertThrows;
import org.apache.wicket.cdi.testapp.TestConversationPage;
import org.apache.wicket.cdi.testapp.TestPage;
import org.apache.wicket.util.tester.WicketTester;
-import org.junit.Ignore;
-import org.junit.Test;
+import org.junit.jupiter.api.Disabled;
+import org.junit.jupiter.api.Test;
/**
* @author jsarman
*/
-// FIXME Wicket 10
-@Ignore
-public class CdiConfigurationTest extends WicketCdiTestCase
+// FIXME Wicket 10. Re-enable once cdi-unit is adapted to jakarta.**
+@Disabled
+class CdiConfigurationTest extends WicketCdiTestCase
{
@Test
- public void testApplicationScope()
+ void testApplicationScope()
{
configure(new CdiConfiguration());
tester.startPage(TestPage.class);
@@ -41,7 +41,7 @@ public class CdiConfigurationTest extends WicketCdiTestCase
}
@Test
- public void testConversationScope()
+ void testConversationScope()
{
configure(new CdiConfiguration());
tester.startPage(TestConversationPage.class);
@@ -53,7 +53,7 @@ public class CdiConfigurationTest extends WicketCdiTestCase
}
@Test
- public void testConfigureTwice()
+ void testConfigureTwice()
{
configure(new CdiConfiguration());
@@ -64,7 +64,7 @@ public class CdiConfigurationTest extends WicketCdiTestCase
}
@Test
- public void testApplicationLevelConfiguration()
+ void testApplicationLevelConfiguration()
{
WicketTester tester = new WicketTester();
CdiConfiguration config = new CdiConfiguration();
diff --git
a/wicket-cdi/src/test/java/org/apache/wicket/cdi/ConversationPropagatorTest.java
b/wicket-cdi/src/test/java/org/apache/wicket/cdi/ConversationPropagatorTest.java
index 10033c0e40..e18971cfd4 100644
---
a/wicket-cdi/src/test/java/org/apache/wicket/cdi/ConversationPropagatorTest.java
+++
b/wicket-cdi/src/test/java/org/apache/wicket/cdi/ConversationPropagatorTest.java
@@ -25,21 +25,21 @@ import org.apache.wicket.cdi.testapp.TestConversationPage;
import org.apache.wicket.cdi.testapp.TestConversationalPage;
import org.apache.wicket.core.request.mapper.MountedMapper;
import org.apache.wicket.request.mapper.parameter.PageParameters;
-import org.junit.Ignore;
-import org.junit.Test;
+import org.junit.jupiter.api.Disabled;
+import org.junit.jupiter.api.Test;
/**
* @author jsarman
*/
-// FIXME Wicket 10
-@Ignore
-public class ConversationPropagatorTest extends WicketCdiTestCase
+// FIXME Wicket 10. Re-enable once cdi-unit is adapted to jakarta.**
+@Disabled
+class ConversationPropagatorTest extends WicketCdiTestCase
{
@Inject
Conversation conversation;
@Test
- public void testAutoConversationNonBookmarkable()
+ void testAutoConversationNonBookmarkable()
{
configure(new CdiConfiguration());
@@ -59,7 +59,7 @@ public class ConversationPropagatorTest extends
WicketCdiTestCase
}
@Test
- public void testAutoConversationBookmarkable()
+ void testAutoConversationBookmarkable()
{
configure(new CdiConfiguration());
@@ -81,7 +81,7 @@ public class ConversationPropagatorTest extends
WicketCdiTestCase
}
@Test
- public void testPropagationAllNonBookmarkable()
+ void testPropagationAllNonBookmarkable()
{
configure(new
CdiConfiguration().setPropagation(ConversationPropagation.ALL));
@@ -101,7 +101,7 @@ public class ConversationPropagatorTest extends
WicketCdiTestCase
}
@Test
- public void
