[jira] [Closed] (WICKET-7002) Application metadata access should not require synchronization
[ https://issues.apache.org/jira/browse/WICKET-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst closed WICKET-7002. > Application metadata access should not require synchronization > -- > > Key: WICKET-7002 > URL: https://issues.apache.org/jira/browse/WICKET-7002 > Project: Wicket > Issue Type: Improvement > Components: wicket-core >Affects Versions: 8.14.0, 9.11.0 >Reporter: Martijn Dashorst >Priority: Minor > Fix For: 10.0.0, 9.12.0, 8.15.0 > > Attachments: Screenshot 2022-09-02 at 17.18.44.png > > > The methods getMetaData and setMetaData from Application have synchronized > modifiers applied to them such that they block on the application instance. > This can cause blocking issues. When I looked at the monitor usage in our > application running in production the Application metadata locks are > responsible for 57% of all monitor usage. > I've included a screenshot of the monitor usage reverse call stacks. > The implementation should be changed to a ConcurrentHashMap so we can remove > the synchronization from the getter and setter, and just use the hashmap's > O(1) lookup rather than MetaDataKey's O( 1) lookup. This will eliminate the > blocking and (possibly) long lookups of metadata in the Application instance. > Note this does not involve modifying the component, session or requestcycle > metadata implementations (yet). > IMO this should be backported to at least 9, as this is a semver compatible > change. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (WICKET-7002) Application metadata access should not require synchronization
[ https://issues.apache.org/jira/browse/WICKET-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst resolved WICKET-7002. -- Fix Version/s: 8.15.0 10.0.0 9.12.0 Resolution: Fixed > Application metadata access should not require synchronization > -- > > Key: WICKET-7002 > URL: https://issues.apache.org/jira/browse/WICKET-7002 > Project: Wicket > Issue Type: Improvement > Components: wicket-core >Affects Versions: 8.14.0, 9.11.0 >Reporter: Martijn Dashorst >Priority: Minor > Fix For: 8.15.0, 10.0.0, 9.12.0 > > Attachments: Screenshot 2022-09-02 at 17.18.44.png > > > The methods getMetaData and setMetaData from Application have synchronized > modifiers applied to them such that they block on the application instance. > This can cause blocking issues. When I looked at the monitor usage in our > application running in production the Application metadata locks are > responsible for 57% of all monitor usage. > I've included a screenshot of the monitor usage reverse call stacks. > The implementation should be changed to a ConcurrentHashMap so we can remove > the synchronization from the getter and setter, and just use the hashmap's > O(1) lookup rather than MetaDataKey's O( 1) lookup. This will eliminate the > blocking and (possibly) long lookups of metadata in the Application instance. > Note this does not involve modifying the component, session or requestcycle > metadata implementations (yet). > IMO this should be backported to at least 9, as this is a semver compatible > change. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (WICKET-7002) Application metadata access should not require synchronization
[ https://issues.apache.org/jira/browse/WICKET-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-7002: - Description: The methods getMetaData and setMetaData from Application have synchronized modifiers applied to them such that they block on the application instance. This can cause blocking issues. When I looked at the monitor usage in our application running in production the Application metadata locks are responsible for 57% of all monitor usage. I've included a screenshot of the monitor usage reverse call stacks. The implementation should be changed to a ConcurrentHashMap so we can remove the synchronization from the getter and setter, and just use the hashmap's O(1) lookup rather than MetaDataKey's O( 1) lookup. This will eliminate the blocking and (possibly) long lookups of metadata in the Application instance. Note this does not involve modifying the component, session or requestcycle metadata implementations (yet). IMO this should be backported to at least 9, as this is a semver compatible change. was: The methods getMetaData and setMetaData from Application have synchronized modifiers applied to them such that they block on the application instance. This can cause blocking issues. When I looked at the monitor usage in our application running in production the Application metadata locks are responsible for 57% of all monitor usage. I've included a screenshot of the monitor usage reverse call stacks. The implementation should be changed to a ConcurrentHashMap so we can remove the synchronization from the getter and setter, and just use the hashmap's O(1) lookup rather than MetaDataKey's O(n) lookup. This will eliminate the blocking and (possibly) long lookups of metadata in the Application instance. Note this does not involve modifying the component, session or requestcycle metadata implementations (yet). IMO this should be backported to at least 9, as this is a semver compatible change. > Application metadata access should not require synchronization > -- > > Key: WICKET-7002 > URL: https://issues.apache.org/jira/browse/WICKET-7002 > Project: Wicket > Issue Type: Improvement > Components: wicket-core >Affects Versions: 8.14.0, 9.11.0 >Reporter: Martijn Dashorst >Priority: Minor > Attachments: Screenshot 2022-09-02 at 17.18.44.png > > > The methods getMetaData and setMetaData from Application have synchronized > modifiers applied to them such that they block on the application instance. > This can cause blocking issues. When I looked at the monitor usage in our > application running in production the Application metadata locks are > responsible for 57% of all monitor usage. > I've included a screenshot of the monitor usage reverse call stacks. > The implementation should be changed to a ConcurrentHashMap so we can remove > the synchronization from the getter and setter, and just use the hashmap's > O(1) lookup rather than MetaDataKey's O( 1) lookup. This will eliminate the > blocking and (possibly) long lookups of metadata in the Application instance. > Note this does not involve modifying the component, session or requestcycle > metadata implementations (yet). > IMO this should be backported to at least 9, as this is a semver compatible > change. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (WICKET-7002) Application metadata access should not require synchronization
Martijn Dashorst created WICKET-7002: Summary: Application metadata access should not require synchronization Key: WICKET-7002 URL: https://issues.apache.org/jira/browse/WICKET-7002 Project: Wicket Issue Type: Improvement Components: wicket-core Affects Versions: 9.11.0, 8.14.0 Reporter: Martijn Dashorst Attachments: Screenshot 2022-09-02 at 17.18.44.png The methods getMetaData and setMetaData from Application have synchronized modifiers applied to them such that they block on the application instance. This can cause blocking issues. When I looked at the monitor usage in our application running in production the Application metadata locks are responsible for 57% of all monitor usage. I've included a screenshot of the monitor usage reverse call stacks. The implementation should be changed to a ConcurrentHashMap so we can remove the synchronization from the getter and setter, and just use the hashmap's O(1) lookup rather than MetaDataKey's O(n) lookup. This will eliminate the blocking and (possibly) long lookups of metadata in the Application instance. Note this does not involve modifying the component, session or requestcycle metadata implementations (yet). IMO this should be backported to at least 9, as this is a semver compatible change. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (WICKET-6784) StockQuote example does not work because the web service is no more available
[
https://issues.apache.org/jira/browse/WICKET-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101590#comment-17101590
]
Martijn Dashorst commented on WICKET-6784:
--
Or just remove the example. It is really, really old...
> StockQuote example does not work because the web service is no more available
> -
>
> Key: WICKET-6784
> URL: https://issues.apache.org/jira/browse/WICKET-6784
> Project: Wicket
> Issue Type: Bug
> Components: wicket-examples
>Affects Versions: 7.16.0, 8.8.0, 9.0.0-M6
>Reporter: Martin Tzvetanov Grigorov
>Priority: Minor
>
> Wicket Examples' Stock Quote example fails with:
> {code}
> java.io.FileNotFoundException: http://webservicex.online/stockquote.asmx
> at
> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1915)
> at
> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1515)
> at
> org.apache.wicket.examples.stockquote.StockQuote.readResult(StockQuote.java:188)
> at
> org.apache.wicket.examples.stockquote.StockQuote.getSOAPQuote(StockQuote.java:128)
> at
> org.apache.wicket.examples.stockquote.StockQuote.getQuote(StockQuote.java:89)
> at
> org.apache.wicket.examples.stockquote.StockQuoteLabel.onComponentTagBody(StockQuoteLabel.java:77)
> at
> org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.onComponentTagBody(DefaultMarkupSourcingStrategy.java:70)
> ...
> {code}
> We need to change to another web service.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096310#comment-17096310
]
Martijn Dashorst commented on WICKET-6774:
--
When you mention the devil, you step on his tail: this newsletter
[https://www.javaspecialists.eu/archive/Issue278.html] tells (all) about Java
object sizes.
> Separate model, behaviors and metadata into separate fields
> ---
>
> Key: WICKET-6774
> URL: https://issues.apache.org/jira/browse/WICKET-6774
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
>Affects Versions: 9.0.0-M5
>Reporter: Thomas Heigl
>Priority: Major
>
> While investigating performance issues with metadata in WICKET-6771, I
> discovered that significant performance gains can be achieved by separating
> models, behaviors, and metadata into separate fields.
> Currently, all three types of data are stored in a single, untyped field
> {{Component.data}}. The idea is to minimize memory overhead by creating as
> few objects as possible.
> If a model or a single behavior or metadata is added, {{data}} stores only a
> reference to the object. When additional data is added, the reference becomes
> an array.
> This is the most memory-efficient way to store these three types of data. But
> it comes with a cost: code to manipulate that data structure is complex and
> not as efficient because it has to take all possible combinations of data
> into account.
> I suggest introducing 3 separate fields for the 3 types of data, trading a
> little bit of memory for reduced complexity and performance gains.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (WICKET-6528) Component part of Page check in AjaxRequestHandler breaks applications
Martijn Dashorst created WICKET-6528: Summary: Component part of Page check in AjaxRequestHandler breaks applications Key: WICKET-6528 URL: https://issues.apache.org/jira/browse/WICKET-6528 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 8.0.0-M8 Reporter: Martijn Dashorst Fix For: 8.0.0 The check if a component is part of the page hierarchy where an Ajax response is generated for breaks client applications in a most unpleasant way. While this check is good™, it should only generate errors in development mode. In deployment mode it should ignore the component (like in versions prior to Wicket 8) and log it as an error (which is expected: the application is in error). See method `public void add(Component... components)` in AjaxRequestHandler for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WICKET-6509) Do not import junit packages
[ https://issues.apache.org/jira/browse/WICKET-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296503#comment-16296503 ] Martijn Dashorst commented on WICKET-6509: -- They do depend on it, due to WicketTester and friends depending on the JUnit APIs. > Do not import junit packages > > > Key: WICKET-6509 > URL: https://issues.apache.org/jira/browse/WICKET-6509 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 8.0.0-M8 >Reporter: Christoph Läubrich > > Currently the wicket-core and the wicket-util bundle import junit packages, I > think they are not really required to run wicket but imported unintentionally. > They could be excluded by adding !org.junit* to the maninifest header config > section -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6280) Convert gdocs user guide to Asiidoctor
[ https://issues.apache.org/jira/browse/WICKET-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874499#comment-15874499 ] Martijn Dashorst commented on WICKET-6280: -- I guess we can, but multi-page HTML is not available AFIAK. And was 6.x converted? > Convert gdocs user guide to Asiidoctor > -- > > Key: WICKET-6280 > URL: https://issues.apache.org/jira/browse/WICKET-6280 > Project: Wicket > Issue Type: Task > Components: guide >Reporter: Martijn Dashorst >Assignee: Andrea Del Bene > > GDoc is deprecated, Asciidoctor the new king. We have to migrate to a better, > well maintained documentation format. This issue tracks the progress. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6074) Use SHA 256+ for signing the release artefacts
[
https://issues.apache.org/jira/browse/WICKET-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855650#comment-15855650
]
Martijn Dashorst commented on WICKET-6074:
--
First of all, you should verify the release by the GPG signed signature:
{{code}}
gpg --verify apache-wicket-*.tar.gz.asc
{{code}}
Now for the md5 and sha1 sums, I agree that the gpg format is strange due to
the extra new line between the path and checksum. We should at least change the
release script to pushd and popd to the dist folder before generating the
signatures, this will eliminate the target/dist/ from the path and the
extraneous new line.
Then it is just a
{{code}}
gpg --print-md MD5 apache-wicket-8.0.0-M4.tar.gz | diff
apache-wicket-8.0.0-M4.tar.gz.md5 -
{{code}}
away to verify the release. We can *also* change the extension of the gpg
message digest to .gpgmd5 and add md5sum signatures for BSD like verification.
I propose the following change to the release script:
{{code}}
pushd target/dist
for f in apache*.{gz,zip}
do
gpg --armor --detach-sign --use-agent --sign $f
gpg --print-md SHA1 $f > $f.gpgsha1
gpg --print-md MD5 $f > $f.gpgmd5
md5sum $f > $f.md5
sha1sum $f > $f.sha1
sha256sum $f > $f.sha256
done
popd
{{code}}
and do the same for the convenience binaries.
> Use SHA 256+ for signing the release artefacts
> --
>
> Key: WICKET-6074
> URL: https://issues.apache.org/jira/browse/WICKET-6074
> Project: Wicket
> Issue Type: Task
> Components: release
>Affects Versions: 6.21.0, 7.2.0
>Reporter: Martin Grigorov
>
> See the discussion at dev@ about checking the release:
> http://markmail.org/message/yu2f64rndmncseyd
> There are few issues:
> 1) It seems sha1sum is used. It will be better to use SHA 256+
> from release.sh:
> gpg --print-md SHA1 target/dist/apache-wicket-$version.tar.gz >
> target/dist/apache-wicket-$version.tar.gz.sha
> 2) Drop .md5 ?!
> "man md5sum" says:
> BUGS
>The MD5 algorithm should not be used any more for security related
> purposes. Instead, better use an SHA-2 algorithm, implemented in the
> programs sha224sum(1), sha256sum(1), sha384sum(1),
>sha512sum(1)
> 3) use "sha256sum" instead of "gpg --print-md SHA1" to create the file to
> make it simpler for checking later with "sha256sum -c"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (WICKET-6074) Use SHA 256+ for signing the release artefacts
[
https://issues.apache.org/jira/browse/WICKET-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855650#comment-15855650
]
Martijn Dashorst edited comment on WICKET-6074 at 2/7/17 9:43 AM:
--
First of all, you should verify the release by the GPG signed signature:
{code}
gpg --verify apache-wicket-*.tar.gz.asc
{code}
Now for the md5 and sha1 sums, I agree that the gpg format is strange due to
the extra new line between the path and checksum. We should at least change the
release script to pushd and popd to the dist folder before generating the
signatures, this will eliminate the target/dist/ from the path and the
extraneous new line.
Then it is just a
{{code}}
gpg --print-md MD5 apache-wicket-8.0.0-M4.tar.gz | diff
apache-wicket-8.0.0-M4.tar.gz.md5 -
{{code}}
away to verify the release. We can *also* change the extension of the gpg
message digest to .gpgmd5 and add md5sum signatures for BSD like verification.
I propose the following change to the release script:
{{code}}
pushd target/dist
for f in apache*.{gz,zip}
do
gpg --armor --detach-sign --use-agent --sign $f
gpg --print-md SHA1 $f > $f.gpgsha1
gpg --print-md MD5 $f > $f.gpgmd5
md5sum $f > $f.md5
sha1sum $f > $f.sha1
sha256sum $f > $f.sha256
done
popd
{{code}}
and do the same for the convenience binaries.
was (Author: dashorst):
First of all, you should verify the release by the GPG signed signature:
{{code}}
gpg --verify apache-wicket-*.tar.gz.asc
{{code}}
Now for the md5 and sha1 sums, I agree that the gpg format is strange due to
the extra new line between the path and checksum. We should at least change the
release script to pushd and popd to the dist folder before generating the
signatures, this will eliminate the target/dist/ from the path and the
extraneous new line.
Then it is just a
{{code}}
gpg --print-md MD5 apache-wicket-8.0.0-M4.tar.gz | diff
apache-wicket-8.0.0-M4.tar.gz.md5 -
{{code}}
away to verify the release. We can *also* change the extension of the gpg
message digest to .gpgmd5 and add md5sum signatures for BSD like verification.
I propose the following change to the release script:
{{code}}
pushd target/dist
for f in apache*.{gz,zip}
do
gpg --armor --detach-sign --use-agent --sign $f
gpg --print-md SHA1 $f > $f.gpgsha1
gpg --print-md MD5 $f > $f.gpgmd5
md5sum $f > $f.md5
sha1sum $f > $f.sha1
sha256sum $f > $f.sha256
done
popd
{{code}}
and do the same for the convenience binaries.
> Use SHA 256+ for signing the release artefacts
> --
>
> Key: WICKET-6074
> URL: https://issues.apache.org/jira/browse/WICKET-6074
> Project: Wicket
> Issue Type: Task
> Components: release
>Affects Versions: 6.21.0, 7.2.0
>Reporter: Martin Grigorov
>
> See the discussion at dev@ about checking the release:
> http://markmail.org/message/yu2f64rndmncseyd
> There are few issues:
> 1) It seems sha1sum is used. It will be better to use SHA 256+
> from release.sh:
> gpg --print-md SHA1 target/dist/apache-wicket-$version.tar.gz >
> target/dist/apache-wicket-$version.tar.gz.sha
> 2) Drop .md5 ?!
> "man md5sum" says:
> BUGS
>The MD5 algorithm should not be used any more for security related
> purposes. Instead, better use an SHA-2 algorithm, implemented in the
> programs sha224sum(1), sha256sum(1), sha384sum(1),
>sha512sum(1)
> 3) use "sha256sum" instead of "gpg --print-md SHA1" to create the file to
> make it simpler for checking later with "sha256sum -c"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (WICKET-6074) Use SHA 256+ for signing the release artefacts
[
https://issues.apache.org/jira/browse/WICKET-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855650#comment-15855650
]
Martijn Dashorst edited comment on WICKET-6074 at 2/7/17 9:43 AM:
--
First of all, you should verify the release by the GPG signed signature:
{code}
gpg --verify apache-wicket-*.tar.gz.asc
{code}
Now for the md5 and sha1 sums, I agree that the gpg format is strange due to
the extra new line between the path and checksum. We should at least change the
release script to pushd and popd to the dist folder before generating the
signatures, this will eliminate the target/dist/ from the path and the
extraneous new line.
Then it is just a
{code}
gpg --print-md MD5 apache-wicket-8.0.0-M4.tar.gz | diff
apache-wicket-8.0.0-M4.tar.gz.md5 -
{code}
away to verify the release. We can *also* change the extension of the gpg
message digest to .gpgmd5 and add md5sum signatures for BSD like verification.
I propose the following change to the release script:
{code}
pushd target/dist
for f in apache*.{gz,zip}
do
gpg --armor --detach-sign --use-agent --sign $f
gpg --print-md SHA1 $f > $f.gpgsha1
gpg --print-md MD5 $f > $f.gpgmd5
md5sum $f > $f.md5
sha1sum $f > $f.sha1
sha256sum $f > $f.sha256
done
popd
{code}
and do the same for the convenience binaries.
was (Author: dashorst):
First of all, you should verify the release by the GPG signed signature:
{code}
gpg --verify apache-wicket-*.tar.gz.asc
{code}
Now for the md5 and sha1 sums, I agree that the gpg format is strange due to
the extra new line between the path and checksum. We should at least change the
release script to pushd and popd to the dist folder before generating the
signatures, this will eliminate the target/dist/ from the path and the
extraneous new line.
Then it is just a
{{code}}
gpg --print-md MD5 apache-wicket-8.0.0-M4.tar.gz | diff
apache-wicket-8.0.0-M4.tar.gz.md5 -
{{code}}
away to verify the release. We can *also* change the extension of the gpg
message digest to .gpgmd5 and add md5sum signatures for BSD like verification.
I propose the following change to the release script:
{{code}}
pushd target/dist
for f in apache*.{gz,zip}
do
gpg --armor --detach-sign --use-agent --sign $f
gpg --print-md SHA1 $f > $f.gpgsha1
gpg --print-md MD5 $f > $f.gpgmd5
md5sum $f > $f.md5
sha1sum $f > $f.sha1
sha256sum $f > $f.sha256
done
popd
{{code}}
and do the same for the convenience binaries.
> Use SHA 256+ for signing the release artefacts
> --
>
> Key: WICKET-6074
> URL: https://issues.apache.org/jira/browse/WICKET-6074
> Project: Wicket
> Issue Type: Task
> Components: release
>Affects Versions: 6.21.0, 7.2.0
>Reporter: Martin Grigorov
>
> See the discussion at dev@ about checking the release:
> http://markmail.org/message/yu2f64rndmncseyd
> There are few issues:
> 1) It seems sha1sum is used. It will be better to use SHA 256+
> from release.sh:
> gpg --print-md SHA1 target/dist/apache-wicket-$version.tar.gz >
> target/dist/apache-wicket-$version.tar.gz.sha
> 2) Drop .md5 ?!
> "man md5sum" says:
> BUGS
>The MD5 algorithm should not be used any more for security related
> purposes. Instead, better use an SHA-2 algorithm, implemented in the
> programs sha224sum(1), sha256sum(1), sha384sum(1),
>sha512sum(1)
> 3) use "sha256sum" instead of "gpg --print-md SHA1" to create the file to
> make it simpler for checking later with "sha256sum -c"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-6074) Use SHA 256+ for signing the release artefacts
[ https://issues.apache.org/jira/browse/WICKET-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853895#comment-15853895 ] Martijn Dashorst commented on WICKET-6074: -- Please explain why is it extremely hard and not just hard or merely inconvenient? You already need to use gpg to verify the download of the release based on the private/public key signing. It is one installation (I'd preferably install it through a package management system like homebrew (macOS) or chocolatey/oneget (Windows)) away. You need maven, java, an IDE, etc. to be able to develop with Wicket. GPG is just one of the tools you need and is available for all platforms, so it is rather well suited as the default key generator (we already must sign the release with a GPG key pair) and digest checksum(s). > Use SHA 256+ for signing the release artefacts > -- > > Key: WICKET-6074 > URL: https://issues.apache.org/jira/browse/WICKET-6074 > Project: Wicket > Issue Type: Task > Components: release >Affects Versions: 6.21.0, 7.2.0 >Reporter: Martin Grigorov >Assignee: Martijn Dashorst > > See the discussion at dev@ about checking the release: > http://markmail.org/message/yu2f64rndmncseyd > There are few issues: > 1) It seems sha1sum is used. It will be better to use SHA 256+ > from release.sh: > gpg --print-md SHA1 target/dist/apache-wicket-$version.tar.gz > > target/dist/apache-wicket-$version.tar.gz.sha > 2) Drop .md5 ?! > "man md5sum" says: > BUGS >The MD5 algorithm should not be used any more for security related > purposes. Instead, better use an SHA-2 algorithm, implemented in the > programs sha224sum(1), sha256sum(1), sha384sum(1), >sha512sum(1) > 3) use "sha256sum" instead of "gpg --print-md SHA1" to create the file to > make it simpler for checking later with "sha256sum -c" -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (WICKET-6280) Convert gdocs user guide to Asiidoctor
Martijn Dashorst created WICKET-6280: Summary: Convert gdocs user guide to Asiidoctor Key: WICKET-6280 URL: https://issues.apache.org/jira/browse/WICKET-6280 Project: Wicket Issue Type: Task Components: guide Reporter: Martijn Dashorst Assignee: Andrea Del Bene GDoc is deprecated, Asciidoctor the new king. We have to migrate to a better, well maintained documentation format. This issue tracks the progress. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (WICKET-6275) Stream support for MarkupContainer
[ https://issues.apache.org/jira/browse/WICKET-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst resolved WICKET-6275. -- Resolution: Fixed > Stream support for MarkupContainer > -- > > Key: WICKET-6275 > URL: https://issues.apache.org/jira/browse/WICKET-6275 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 8.0.0-M2 >Reporter: Martijn Dashorst > Fix For: 8.0.0-M3 > > > Add stream() support to MarkupContainer to enable iterating and filtering of > children. Should allow for streaming only direct children and for the whole > component tree below the markup container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WICKET-6275) Stream support for MarkupContainer
[ https://issues.apache.org/jira/browse/WICKET-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst closed WICKET-6275. > Stream support for MarkupContainer > -- > > Key: WICKET-6275 > URL: https://issues.apache.org/jira/browse/WICKET-6275 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 8.0.0-M2 >Reporter: Martijn Dashorst > Fix For: 8.0.0-M3 > > > Add stream() support to MarkupContainer to enable iterating and filtering of > children. Should allow for streaming only direct children and for the whole > component tree below the markup container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WICKET-6275) Stream support for MarkupContainer
Martijn Dashorst created WICKET-6275: Summary: Stream support for MarkupContainer Key: WICKET-6275 URL: https://issues.apache.org/jira/browse/WICKET-6275 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 8.0.0-M2 Reporter: Martijn Dashorst Fix For: 8.0.0-M3 Add stream() support to MarkupContainer to enable iterating and filtering of children. Should allow for streaming only direct children and for the whole component tree below the markup container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (WICKET-6112) Microservices support (decoupled component usage)
[
https://issues.apache.org/jira/browse/WICKET-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst reopened WICKET-6112:
--
> Microservices support (decoupled component usage)
> -
>
> Key: WICKET-6112
> URL: https://issues.apache.org/jira/browse/WICKET-6112
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
>Affects Versions: 8.0.0-M1
>Reporter: Tobias Soloschenko
>Assignee: Tobias Soloschenko
> Labels: features
> Attachments: 0001-Microservices.patch, wicket.microservices.parent.zip
>
>
> It would be very nice to be able to instantiate components in a decoupled
> way, so that jars might be dropped into the web apps lib folder and if they
> are present, the web app show new functionality.
> Examples would look like this:
> {code}
> String microservicePage =
> "wicket.microservices.service1.MicroservicePage1";
> add(new Link("link")
> {
> private static final long serialVersionUID = 1L;
> @Override
> public void onClick()
> {
> setResponsePage(microservicePage);
> }
>
> @Override
> protected void onConfigure()
> {
>
> setVisible(Component.isAvailable(microservicePage));
> }
> });
> {code}
> or like this
> {code}
> String microservicePanel =
> "wicket.microservices.service2.MicroservicePanel2";
> if(Component.isAvailable(microservicePanel)){
> add(Component.newInstance(microservicePanel,"Yay this
> is a label"));
> }else{
> add(new EmptyPanel("panel"));
> }
> {code}
> The main benefit of this feature is that you are able to have jars that
> provide additional functionality but not required to be shipped with an
> initial deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (WICKET-6112) Microservices support (decoupled component usage)
[
https://issues.apache.org/jira/browse/WICKET-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst closed WICKET-6112.
Resolution: Won't Fix
> Microservices support (decoupled component usage)
> -
>
> Key: WICKET-6112
> URL: https://issues.apache.org/jira/browse/WICKET-6112
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
>Affects Versions: 8.0.0-M1
>Reporter: Tobias Soloschenko
>Assignee: Tobias Soloschenko
> Labels: features
> Attachments: 0001-Microservices.patch, wicket.microservices.parent.zip
>
>
> It would be very nice to be able to instantiate components in a decoupled
> way, so that jars might be dropped into the web apps lib folder and if they
> are present, the web app show new functionality.
> Examples would look like this:
> {code}
> String microservicePage =
> "wicket.microservices.service1.MicroservicePage1";
> add(new Link("link")
> {
> private static final long serialVersionUID = 1L;
> @Override
> public void onClick()
> {
> setResponsePage(microservicePage);
> }
>
> @Override
> protected void onConfigure()
> {
>
> setVisible(Component.isAvailable(microservicePage));
> }
> });
> {code}
> or like this
> {code}
> String microservicePanel =
> "wicket.microservices.service2.MicroservicePanel2";
> if(Component.isAvailable(microservicePanel)){
> add(Component.newInstance(microservicePanel,"Yay this
> is a label"));
> }else{
> add(new EmptyPanel("panel"));
> }
> {code}
> The main benefit of this feature is that you are able to have jars that
> provide additional functionality but not required to be shipped with an
> initial deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WICKET-6112) Microservices support (decoupled component usage)
[
https://issues.apache.org/jira/browse/WICKET-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst updated WICKET-6112:
-
Fix Version/s: (was: 8.0.0-M1)
> Microservices support (decoupled component usage)
> -
>
> Key: WICKET-6112
> URL: https://issues.apache.org/jira/browse/WICKET-6112
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
>Affects Versions: 8.0.0-M1
>Reporter: Tobias Soloschenko
>Assignee: Tobias Soloschenko
> Labels: features
> Attachments: 0001-Microservices.patch, wicket.microservices.parent.zip
>
>
> It would be very nice to be able to instantiate components in a decoupled
> way, so that jars might be dropped into the web apps lib folder and if they
> are present, the web app show new functionality.
> Examples would look like this:
> {code}
> String microservicePage =
> "wicket.microservices.service1.MicroservicePage1";
> add(new Link("link")
> {
> private static final long serialVersionUID = 1L;
> @Override
> public void onClick()
> {
> setResponsePage(microservicePage);
> }
>
> @Override
> protected void onConfigure()
> {
>
> setVisible(Component.isAvailable(microservicePage));
> }
> });
> {code}
> or like this
> {code}
> String microservicePanel =
> "wicket.microservices.service2.MicroservicePanel2";
> if(Component.isAvailable(microservicePanel)){
> add(Component.newInstance(microservicePanel,"Yay this
> is a label"));
> }else{
> add(new EmptyPanel("panel"));
> }
> {code}
> The main benefit of this feature is that you are able to have jars that
> provide additional functionality but not required to be shipped with an
> initial deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (WICKET-6250) FileUploadField does not deteach models and fails to null the reference to the transient fileUploads field if forceCloseStreamsOnDetach is false
[
https://issues.apache.org/jira/browse/WICKET-6250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst closed WICKET-6250.
> FileUploadField does not deteach models and fails to null the reference to
> the transient fileUploads field if forceCloseStreamsOnDetach is false
>
>
> Key: WICKET-6250
> URL: https://issues.apache.org/jira/browse/WICKET-6250
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 6.24.0
>Reporter: Torsten Krah
>Assignee: Sven Meier
> Labels: file_upload
> Fix For: 8.0.0-M2, 7.5.0, 6.26
>
>
> FileUpload does not clear our references and its model when the
> forceCloseStreamsOnDetach is false - which does not match the expectation
> from the javadoc:
> {code}
> /**
>* The FileUploadField will close any input streams you have opened in its
> FileUpload by
>* default. If you wish to manage the stream yourself (e.g. you want to use
> it in another
>* thread) then you can override this method to prevent this behavior.
>*
>* @return true if stream should be closed at the end of
> request
>*/
> {code}
> So it just is about not closing the streams.
> However the fileupload component does not only *not* close the streams - it
> also *fails* (if you return false from the *forceCloseStreamsOnDetach*
> method) to reset the model and forget about the current file uploads cached
> in the transient fileUploads variable.
> {code}
> protected void onDetach()
> {
> if ((fileUploads != null) && forceCloseStreamsOnDetach())
> {
> for (FileUpload fu : fileUploads)
> {
> fu.closeStreams();
> }
> fileUploads = null;
>
> if (getModel() != null)
> {
> getModel().setObject(null);
> }
> }
> super.onDetach();
> }
> {code}
> Shouldn't that read more like this:
> {code}
> protected void onDetach()
> {
> if ((fileUploads != null))
> {
> if(forceCloseStreamsOnDetach() {
>for (FileUpload fu : fileUploads)
>{
> fu.closeStreams();
>}
> }
> fileUploads = null;
>
> if (getModel() != null)
> {
> getModel().setObject(null);
> }
> }
> super.onDetach();
> }
> {code}
> In this case my streams wouldn't be closed but you could provide new streams
> in the next request.
> As the variable is private and i don't want to close the stream i have to use
> reflection at the moment to reset the field to null in an overridden
> onDeteach().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WICKET-6249) Invalid state of LoadableDetachableModel with exception during load()
[ https://issues.apache.org/jira/browse/WICKET-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-6249: - Fix Version/s: (was: 8.0.0-M3) (was: 7.6.0) 8.0.0-M2 7.5.0 > Invalid state of LoadableDetachableModel with exception during load() > - > > Key: WICKET-6249 > URL: https://issues.apache.org/jira/browse/WICKET-6249 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.4.0 >Reporter: Martijn Dashorst >Assignee: Martijn Dashorst > Fix For: 8.0.0-M2, 7.5.0 > > > When an Exception occurs during the `load()` phase of a > LoadableDetachableModel, the state of the LDM is "ATTACHING", but it can't > ever recover from it through detaching. > Detaching should always happen when the model doesn't have a state (state == > null) and the model hasn't been detached prior during the request. (the > inverse happens for attaching). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WICKET-6249) Invalid state of LoadableDetachableModel with exception during load()
[ https://issues.apache.org/jira/browse/WICKET-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst closed WICKET-6249. Resolution: Fixed > Invalid state of LoadableDetachableModel with exception during load() > - > > Key: WICKET-6249 > URL: https://issues.apache.org/jira/browse/WICKET-6249 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.4.0 >Reporter: Martijn Dashorst >Assignee: Martijn Dashorst > Fix For: 7.5.0, 8.0.0-M2 > > > When an Exception occurs during the `load()` phase of a > LoadableDetachableModel, the state of the LDM is "ATTACHING", but it can't > ever recover from it through detaching. > Detaching should always happen when the model doesn't have a state (state == > null) and the model hasn't been detached prior during the request. (the > inverse happens for attaching). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (WICKET-6245) Open up CsrfPreventionRequestCycleListener for extension
[ https://issues.apache.org/jira/browse/WICKET-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst resolved WICKET-6245. -- Resolution: Fixed > Open up CsrfPreventionRequestCycleListener for extension > > > Key: WICKET-6245 > URL: https://issues.apache.org/jira/browse/WICKET-6245 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.20.0, 7.0.0, 6.21.0, 7.1.0, 7.2.0, 7.3.0, 8.0.0-M1, > 6.22.0, 6.23.0, 7.4.0, 6.24.0 >Reporter: Martijn Dashorst >Assignee: Martijn Dashorst >Priority: Minor > Fix For: 7.5.0, 6.25.0, 8.0.0-M2 > > > The design of the CsrfPreventionRequestCycleListener is such that it is open > for extension, but fails to provide the right hooks for implementors. We > should allow private methods to be called from event handlers, and allow > overriding of several checkpoints in the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WICKET-6245) Open up CsrfPreventionRequestCycleListener for extension
[ https://issues.apache.org/jira/browse/WICKET-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst closed WICKET-6245. > Open up CsrfPreventionRequestCycleListener for extension > > > Key: WICKET-6245 > URL: https://issues.apache.org/jira/browse/WICKET-6245 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.20.0, 7.0.0, 6.21.0, 7.1.0, 7.2.0, 7.3.0, 8.0.0-M1, > 6.22.0, 6.23.0, 7.4.0, 6.24.0 >Reporter: Martijn Dashorst >Assignee: Martijn Dashorst >Priority: Minor > Fix For: 8.0.0-M2, 6.25.0, 7.5.0 > > > The design of the CsrfPreventionRequestCycleListener is such that it is open > for extension, but fails to provide the right hooks for implementors. We > should allow private methods to be called from event handlers, and allow > overriding of several checkpoints in the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-6245) Open up CsrfPreventionRequestCycleListener for extension
[ https://issues.apache.org/jira/browse/WICKET-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-6245: - Fix Version/s: (was: 8.0.0-M3) (was: 7.6.0) (was: 6.26) 8.0.0-M2 6.25.0 7.5.0 > Open up CsrfPreventionRequestCycleListener for extension > > > Key: WICKET-6245 > URL: https://issues.apache.org/jira/browse/WICKET-6245 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.20.0, 7.0.0, 6.21.0, 7.1.0, 7.2.0, 7.3.0, 8.0.0-M1, > 6.22.0, 6.23.0, 7.4.0, 6.24.0 >Reporter: Martijn Dashorst >Assignee: Martijn Dashorst >Priority: Minor > Fix For: 8.0.0-M2, 6.25.0, 7.5.0 > > > The design of the CsrfPreventionRequestCycleListener is such that it is open > for extension, but fails to provide the right hooks for implementors. We > should allow private methods to be called from event handlers, and allow > overriding of several checkpoints in the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-6245) Open up CsrfPreventionRequestCycleListener for extension
[ https://issues.apache.org/jira/browse/WICKET-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-6245: - Fix Version/s: (was: 8.0.0-M2) 8.0.0-M3 > Open up CsrfPreventionRequestCycleListener for extension > > > Key: WICKET-6245 > URL: https://issues.apache.org/jira/browse/WICKET-6245 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.20.0, 7.0.0, 6.21.0, 7.1.0, 7.2.0, 7.3.0, 8.0.0-M1, > 6.22.0, 6.23.0, 7.4.0, 6.24.0 >Reporter: Martijn Dashorst >Assignee: Martijn Dashorst >Priority: Minor > Fix For: 6.26, 7.6.0, 8.0.0-M3 > > > The design of the CsrfPreventionRequestCycleListener is such that it is open > for extension, but fails to provide the right hooks for implementors. We > should allow private methods to be called from event handlers, and allow > overriding of several checkpoints in the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-6041) Nested forms / parent FormComponents do not reflect updated model when nested form submitted
[ https://issues.apache.org/jira/browse/WICKET-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-6041: - Fix Version/s: (was: 8.0.0-M2) 8.0.0-M3 > Nested forms / parent FormComponents do not reflect updated model when nested > form submitted > > > Key: WICKET-6041 > URL: https://issues.apache.org/jira/browse/WICKET-6041 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.21.0, 7.1.0 >Reporter: Patrick Davids >Assignee: Andrea Del Bene > Fix For: 8.0.0-M3 > > Attachments: NonReflectingFormComponent.zip > > > Hi, > as discussed in user-list, here the ticket and quickstart attached. > I guess the quickstart looks quite unusual, because it is reduced to its > minimum to show what happens. > The use-case of such an nested form component tree is more clearer when > considering the usage in wizards, which holds its own form to be able to do > step-transitions. > In combination with dialogs (e.g. wicket-jquery-ui / greetings to [~sebfz1] > by the way), which also needed a form to work, you will get such a nested > form situation. > kind regards > Patrick -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-6249) Invalid state of LoadableDetachableModel with exception during load()
[ https://issues.apache.org/jira/browse/WICKET-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-6249: - Fix Version/s: (was: 8.0.0-M2) 8.0.0-M3 > Invalid state of LoadableDetachableModel with exception during load() > - > > Key: WICKET-6249 > URL: https://issues.apache.org/jira/browse/WICKET-6249 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.4.0 >Reporter: Martijn Dashorst >Assignee: Martijn Dashorst > Fix For: 7.6.0, 8.0.0-M3 > > > When an Exception occurs during the `load()` phase of a > LoadableDetachableModel, the state of the LDM is "ATTACHING", but it can't > ever recover from it through detaching. > Detaching should always happen when the model doesn't have a state (state == > null) and the model hasn't been detached prior during the request. (the > inverse happens for attaching). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-5920) roll a version of ListDataProvider implementing ISortableDetachable model
[ https://issues.apache.org/jira/browse/WICKET-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-5920: - Fix Version/s: (was: 8.0.0-M2) 8.0.0-M3 > roll a version of ListDataProvider implementing ISortableDetachable model > - > > Key: WICKET-5920 > URL: https://issues.apache.org/jira/browse/WICKET-5920 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 7.0.0-M5, 6.19.0 > Environment: Any >Reporter: Ernesto Reinaldo Barreiro >Assignee: Martin Grigorov >Priority: Minor > Fix For: 8.0.0-M3 > > > Roll a version of ListDataProvider implementing ISortableDetachable model. > Right now ListDataProvider just implements IDataProvider which makes it > unusable with many repeaters. See > http://apache-wicket.1842946.n4.nabble.com/a-sortable-version-of-of-ListDataProvider-tt4671089.html > For a discusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-6245) Open up CsrfPreventionRequestCycleListener for extension
[ https://issues.apache.org/jira/browse/WICKET-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-6245: - Fix Version/s: (was: 6.25.0) 6.26 > Open up CsrfPreventionRequestCycleListener for extension > > > Key: WICKET-6245 > URL: https://issues.apache.org/jira/browse/WICKET-6245 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.20.0, 7.0.0, 6.21.0, 7.1.0, 7.2.0, 7.3.0, 8.0.0-M1, > 6.22.0, 6.23.0, 7.4.0, 6.24.0 >Reporter: Martijn Dashorst >Assignee: Martijn Dashorst >Priority: Minor > Fix For: 6.26, 7.6.0, 8.0.0-M3 > > > The design of the CsrfPreventionRequestCycleListener is such that it is open > for extension, but fails to provide the right hooks for implementors. We > should allow private methods to be called from event handlers, and allow > overriding of several checkpoints in the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-6245) Open up CsrfPreventionRequestCycleListener for extension
[ https://issues.apache.org/jira/browse/WICKET-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-6245: - Fix Version/s: (was: 7.5.0) 7.6.0 > Open up CsrfPreventionRequestCycleListener for extension > > > Key: WICKET-6245 > URL: https://issues.apache.org/jira/browse/WICKET-6245 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.20.0, 7.0.0, 6.21.0, 7.1.0, 7.2.0, 7.3.0, 8.0.0-M1, > 6.22.0, 6.23.0, 7.4.0, 6.24.0 >Reporter: Martijn Dashorst >Assignee: Martijn Dashorst >Priority: Minor > Fix For: 8.0.0-M2, 6.25.0, 7.6.0 > > > The design of the CsrfPreventionRequestCycleListener is such that it is open > for extension, but fails to provide the right hooks for implementors. We > should allow private methods to be called from event handlers, and allow > overriding of several checkpoints in the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-6249) Invalid state of LoadableDetachableModel with exception during load()
[ https://issues.apache.org/jira/browse/WICKET-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-6249: - Fix Version/s: (was: 7.5.0) 7.6.0 > Invalid state of LoadableDetachableModel with exception during load() > - > > Key: WICKET-6249 > URL: https://issues.apache.org/jira/browse/WICKET-6249 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.4.0 >Reporter: Martijn Dashorst >Assignee: Martijn Dashorst > Fix For: 8.0.0-M2, 7.6.0 > > > When an Exception occurs during the `load()` phase of a > LoadableDetachableModel, the state of the LDM is "ATTACHING", but it can't > ever recover from it through detaching. > Detaching should always happen when the model doesn't have a state (state == > null) and the model hasn't been detached prior during the request. (the > inverse happens for attaching). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-6249) Invalid state of LoadableDetachableModel with exception during load()
[ https://issues.apache.org/jira/browse/WICKET-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-6249: - Fix Version/s: 8.0.0-M2 > Invalid state of LoadableDetachableModel with exception during load() > - > > Key: WICKET-6249 > URL: https://issues.apache.org/jira/browse/WICKET-6249 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.4.0 >Reporter: Martijn Dashorst >Assignee: Martijn Dashorst > Fix For: 8.0.0-M2, 7.5.0 > > > When an Exception occurs during the `load()` phase of a > LoadableDetachableModel, the state of the LDM is "ATTACHING", but it can't > ever recover from it through detaching. > Detaching should always happen when the model doesn't have a state (state == > null) and the model hasn't been detached prior during the request. (the > inverse happens for attaching). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WICKET-6249) Invalid state of LoadableDetachableModel with exception during load()
Martijn Dashorst created WICKET-6249: Summary: Invalid state of LoadableDetachableModel with exception during load() Key: WICKET-6249 URL: https://issues.apache.org/jira/browse/WICKET-6249 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 7.4.0 Reporter: Martijn Dashorst Assignee: Martijn Dashorst Fix For: 7.5.0 When an Exception occurs during the `load()` phase of a LoadableDetachableModel, the state of the LDM is "ATTACHING", but it can't ever recover from it through detaching. Detaching should always happen when the model doesn't have a state (state == null) and the model hasn't been detached prior during the request. (the inverse happens for attaching). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-6245) Open up CsrfPreventionRequestCycleListener for extension
[ https://issues.apache.org/jira/browse/WICKET-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-6245: - Assignee: Martijn Dashorst Affects Version/s: 6.20.0 7.0.0 6.21.0 7.1.0 7.2.0 7.3.0 8.0.0-M1 6.22.0 6.23.0 7.4.0 6.24.0 Fix Version/s: 7.5.0 6.25.0 8.0.0-M2 Component/s: wicket > Open up CsrfPreventionRequestCycleListener for extension > > > Key: WICKET-6245 > URL: https://issues.apache.org/jira/browse/WICKET-6245 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.20.0, 7.0.0, 6.21.0, 7.1.0, 7.2.0, 7.3.0, 8.0.0-M1, > 6.22.0, 6.23.0, 7.4.0, 6.24.0 >Reporter: Martijn Dashorst >Assignee: Martijn Dashorst >Priority: Minor > Fix For: 8.0.0-M2, 6.25.0, 7.5.0 > > > The design of the CsrfPreventionRequestCycleListener is such that it is open > for extension, but fails to provide the right hooks for implementors. We > should allow private methods to be called from event handlers, and allow > overriding of several checkpoints in the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WICKET-6245) Open up CsrfPreventionRequestCycleListener for extension
Martijn Dashorst created WICKET-6245: Summary: Open up CsrfPreventionRequestCycleListener for extension Key: WICKET-6245 URL: https://issues.apache.org/jira/browse/WICKET-6245 Project: Wicket Issue Type: Bug Reporter: Martijn Dashorst Priority: Minor The design of the CsrfPreventionRequestCycleListener is such that it is open for extension, but fails to provide the right hooks for implementors. We should allow private methods to be called from event handlers, and allow overriding of several checkpoints in the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-5836) Update the version of clirr-maven-plugin (current 2.6.1)
[ https://issues.apache.org/jira/browse/WICKET-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-5836: - Fix Version/s: (was: 8.0.0-M1) 8.0.0-M2 > Update the version of clirr-maven-plugin (current 2.6.1) > > > Key: WICKET-5836 > URL: https://issues.apache.org/jira/browse/WICKET-5836 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.20.0, 7.0.0-M6, 8.0.0-M1 >Reporter: Tobias Soloschenko >Priority: Minor > Fix For: 8.0.0-M2 > > > This ticket is targeting Wicket 6.x, 7.x, 8.x compiled with JDK 8, because > the current version of the clirr plugin 2.6.1 isn't compatible with Java 8. > At the moment there is no version higher then 2.6.1 so we have to wait until > release. > More information can be found here: > http://mail-archives.apache.org/mod_mbox/commons-dev/201407.mbox/%3ccaczkxpzs2nxtvk5sejfyikvhp2817ey2b+7rak0w_nuyzha...@mail.gmail.com%3E > http://mail-archives.apache.org/mod_mbox/commons-dev/201407.mbox/%3c11f48c22-60d5-4a94-8ed2-42cccfefa...@email.android.com%3E > Here the correlating tickets: > https://issues.apache.org/jira/browse/BCEL-173 > https://issues.apache.org/jira/browse/BCEL-174 > https://issues.apache.org/jira/browse/BCEL-175 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-5920) roll a version of ListDataProvider implementing ISortableDetachable model
[ https://issues.apache.org/jira/browse/WICKET-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-5920: - Fix Version/s: (was: 8.0.0-M1) 8.0.0-M2 > roll a version of ListDataProvider implementing ISortableDetachable model > - > > Key: WICKET-5920 > URL: https://issues.apache.org/jira/browse/WICKET-5920 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 7.0.0-M5, 6.19.0 > Environment: Any >Reporter: Ernesto Reinaldo Barreiro >Assignee: Martin Grigorov >Priority: Minor > Fix For: 8.0.0-M2 > > > Roll a version of ListDataProvider implementing ISortableDetachable model. > Right now ListDataProvider just implements IDataProvider which makes it > unusable with many repeaters. See > http://apache-wicket.1842946.n4.nabble.com/a-sortable-version-of-of-ListDataProvider-tt4671089.html > For a discusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-6041) Nested forms / parent FormComponents do not reflect updated model when nested form submitted
[ https://issues.apache.org/jira/browse/WICKET-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-6041: - Fix Version/s: (was: 8.0.0-M1) 8.0.0-M2 > Nested forms / parent FormComponents do not reflect updated model when nested > form submitted > > > Key: WICKET-6041 > URL: https://issues.apache.org/jira/browse/WICKET-6041 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.21.0, 7.1.0 >Reporter: Patrick Davids >Assignee: Andrea Del Bene > Fix For: 8.0.0-M2 > > Attachments: NonReflectingFormComponent.zip > > > Hi, > as discussed in user-list, here the ticket and quickstart attached. > I guess the quickstart looks quite unusual, because it is reduced to its > minimum to show what happens. > The use-case of such an nested form component tree is more clearer when > considering the usage in wizards, which holds its own form to be able to do > step-transitions. > In combination with dialogs (e.g. wicket-jquery-ui / greetings to [~sebfz1] > by the way), which also needed a form to work, you will get such a nested > form situation. > kind regards > Patrick -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-5866) Reconsider generics of IConverterLocator#getConverter()
[
https://issues.apache.org/jira/browse/WICKET-5866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst updated WICKET-5866:
-
Fix Version/s: (was: 8.0.0-M1)
8.0.0-M2
> Reconsider generics of IConverterLocator#getConverter()
> ---
>
> Key: WICKET-5866
> URL: https://issues.apache.org/jira/browse/WICKET-5866
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 7.0.0
>Reporter: Sven Meier
>Assignee: Sven Meier
>Priority: Minor
> Fix For: 8.0.0-M2
>
>
> IConverterLocator#getConverter() has a generic parameter currently.
> It seems to me that this is not very useful: almost all code calling
> #getConverter() does not care for the type parameter.
> From the user perspective it's very common to override
> Component#getConverter(). With the need for a cast and to suppress the
> generics warning, providing a custom converter is much too hard currently:
> {code}
> public IConverter getConverter(Class clazz)
> {
> if (Date.class.isAssignableFrom(clazz))
> {
> @SuppressWarnings("unchecked")
> return (IConverter)new DateConverter();
> }
> else
> {
> return super.getConverter(clazz);
> }
> }
> {code}
> I propose to remove the generics parameter from the method:
> {code}
> public IConverter getConverter(Class clazz)
> {
> if (Date.class.isAssignableFrom(clazz))
> {
> return new DateConverter();
> }
> else
> {
> return super.getConverter(clazz);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WICKET-6161) SecuritySettings.setEnforceMounts() should be applicable for all kind of pages
[ https://issues.apache.org/jira/browse/WICKET-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-6161: - Fix Version/s: (was: 8.0.0-M1) 8.0.0-M2 > SecuritySettings.setEnforceMounts() should be applicable for all kind of pages > -- > > Key: WICKET-6161 > URL: https://issues.apache.org/jira/browse/WICKET-6161 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.2.0 >Reporter: Ilia Naryzhny > Labels: mount, mountBookmarkablePage, security > Fix For: 8.0.0-M2 > > > Currently SecuritySettings.setEnforceMounts(true) works only for pages which > do have mount point and doesn't work other bookmarkable pages. > Issue discussed here: http://markmail.org/message/ctoac6eq26kt5jve > The point is to disallow of using /wicket/bookmarkable/ for all pages if > enforceMounts was set to true. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WICKET-6101) Bootstrap Modal is falsely blocked due to possible csrf attack
[ https://issues.apache.org/jira/browse/WICKET-6101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst closed WICKET-6101. Resolution: Not A Problem As you can see in the log, the request is not blocked. The origin header was not set, and the action is allowed. It is logged to ensure that the developer knows which Origin headers are being sent if at all, to be able to finetune the whitelist. See the documentation of the CsrfPreventionRequestCycleListener for more information on the configuration options. > Bootstrap Modal is falsely blocked due to possible csrf attack > -- > > Key: WICKET-6101 > URL: https://issues.apache.org/jira/browse/WICKET-6101 > Project: Wicket > Issue Type: Bug > Components: wicket >Reporter: Marc G. > > I've created this ticket here cause it was posted on my github project: > > Hey Marc, > i checked out your project yesterday an it works great so far. > I encountered a problem recently with the 'Wicket Bootstrap'-Api > (https://github.com/l0rdn1kk0n/wicket-bootstrap). > As soon as i open a modal window the application recognizes a possible csrf > attack because the origin of the request is empty. > Log says: INFO 869808 --- [nio-8080-exec-7] > w.p.h.CsrfPreventionRequestCycleListener : Possible CSRF attack, request URL: > http://localhost:8080/, Origin: null, action: allowed > Regards, pa7r1ck > --- > I'am also encounterd this problem when I'm using a > AjaxFallbackDefaultDataTable and changing the sorting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WICKET-6089) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/WICKET-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130039#comment-15130039 ] Martijn Dashorst commented on WICKET-6089: -- The post-processing scripts move the released artifacts from staging to dist in svn, but they can't drop the old release until the mirrors have picked up the new release. Therefore the script doesn't remove the old releases. I'll consider writing a release-cleanup script that removes the build branch and the previous release from the dist repo. But even then someone (i.e. the release manager) needs to run the script and find time to do so. Unless and until infra@ finds a way to have the mirrorring system sync up in minutes rather than hours this will remain a task that happens when someone finds time. > Please delete old releases from mirroring system > > > Key: WICKET-6089 > URL: https://issues.apache.org/jira/browse/WICKET-6089 > Project: Wicket > Issue Type: Task >Affects Versions: 1.4.23, 6.20.0, 7.1.0 > Environment: https://dist.apache.org/repos/dist/release/wicket/ >Reporter: Sebb >Assignee: Martin Grigorov > > To reduce the load on the ASF mirrors, projects are required to delete old > releases [1] > Please can you remove all non-current releases? > i.e. the ones listed as affected. > Thanks! > [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WICKET-6074) Use SHA 256+ for signing the release artefacts
[ https://issues.apache.org/jira/browse/WICKET-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15108608#comment-15108608 ] Martijn Dashorst commented on WICKET-6074: -- I wouldn't want to change anything. Using gpg digests is common across ASF projects and while md5 is not good for hashing passwords, it is suitable for a CRC checksum (i.e. is the download correct). For security one should explicitly check the GPG asc signature files against the GPG keys we use to sign the release. > Use SHA 256+ for signing the release artefacts > -- > > Key: WICKET-6074 > URL: https://issues.apache.org/jira/browse/WICKET-6074 > Project: Wicket > Issue Type: Task > Components: release >Affects Versions: 6.21.0, 7.2.0 >Reporter: Martin Grigorov >Assignee: Martijn Dashorst > > See the discussion at dev@ about checking the release: > http://markmail.org/message/yu2f64rndmncseyd > There are few issues: > 1) It seems sha1sum is used. It will be better to use SHA 256+ > from release.sh: > gpg --print-md SHA1 target/dist/apache-wicket-$version.tar.gz > > target/dist/apache-wicket-$version.tar.gz.sha > 2) Drop .md5 ?! > "man md5sum" says: > BUGS >The MD5 algorithm should not be used any more for security related > purposes. Instead, better use an SHA-2 algorithm, implemented in the > programs sha224sum(1), sha256sum(1), sha384sum(1), >sha512sum(1) > 3) use "sha256sum" instead of "gpg --print-md SHA1" to create the file to > make it simpler for checking later with "sha256sum -c" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WICKET-6055) AjaxLazyLoadPanel should provide non-blocking lazy load
Martijn Dashorst created WICKET-6055: Summary: AjaxLazyLoadPanel should provide non-blocking lazy load Key: WICKET-6055 URL: https://issues.apache.org/jira/browse/WICKET-6055 Project: Wicket Issue Type: Improvement Components: wicket-extensions Affects Versions: 7.1.0 Reporter: Martijn Dashorst Assignee: Martijn Dashorst When having multiple AjaxLazyLoadPanels on your page, they all block their Wicket request thread until the content is ready to load. This can be problematic when you try to wait for some background job to finish and want to poll for that job to be ready, and only then update the contents. The improvement would be to add a method that gives the developer the option to not update just yet (isReadyForReplacement) and when it returns true, start the replacement. By default this would return true, implementing the current behavior of the AjaxLazyLoadPanel. Furthermore to improve the responsiveness of the ALLP it should add a single timer to the page that can be used by multiple ALLPs to update themselves. The timer would poll each second and the ALLPs would use Wicket's event bus to update themselves. With some reference counting, the timer can remove itself from the page when all ALLPs have updated themselves. This enables refreshing the page as well when outside an AJAX context, or having a user be impatient and pressing F5. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (WICKET-6021) ConcurrentModificationException in MarkupContainer#iterator#next
[ https://issues.apache.org/jira/browse/WICKET-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst resolved WICKET-6021. -- Resolution: Fixed > ConcurrentModificationException in MarkupContainer#iterator#next > > > Key: WICKET-6021 > URL: https://issues.apache.org/jira/browse/WICKET-6021 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.1.0 >Reporter: Martin Grigorov >Assignee: Emond Papegaaij > Fix For: 7.2.0, 8.0.0-M1 > > > I'm upgrading Apache Isis to Wicket 7.1.0 (from 6.20) and I face the > following problem: > java.util.ConcurrentModificationException > at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901) > at java.util.ArrayList$Itr.next(ArrayList.java:851) > at org.apache.wicket.MarkupContainer$1.next(MarkupContainer.java:553) > at org.apache.wicket.MarkupContainer$1.next(MarkupContainer.java:522) > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:134) > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123) > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:192) > at > org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:891) > at > org.apache.wicket.MarkupContainer.internalInitialize(MarkupContainer.java:995) > at org.apache.wicket.Page.internalPrepareForRender(Page.java:240) > at org.apache.wicket.Component.render(Component.java:2304) > at org.apache.wicket.Page.renderPage(Page.java:1018) > I think it is caused by the changes in WICKET-5983 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WICKET-6021) ConcurrentModificationException in MarkupContainer#iterator#next
[ https://issues.apache.org/jira/browse/WICKET-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst closed WICKET-6021. > ConcurrentModificationException in MarkupContainer#iterator#next > > > Key: WICKET-6021 > URL: https://issues.apache.org/jira/browse/WICKET-6021 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.1.0 >Reporter: Martin Grigorov >Assignee: Emond Papegaaij > Fix For: 7.2.0, 8.0.0-M1 > > > I'm upgrading Apache Isis to Wicket 7.1.0 (from 6.20) and I face the > following problem: > java.util.ConcurrentModificationException > at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901) > at java.util.ArrayList$Itr.next(ArrayList.java:851) > at org.apache.wicket.MarkupContainer$1.next(MarkupContainer.java:553) > at org.apache.wicket.MarkupContainer$1.next(MarkupContainer.java:522) > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:134) > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123) > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:192) > at > org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:891) > at > org.apache.wicket.MarkupContainer.internalInitialize(MarkupContainer.java:995) > at org.apache.wicket.Page.internalPrepareForRender(Page.java:240) > at org.apache.wicket.Component.render(Component.java:2304) > at org.apache.wicket.Page.renderPage(Page.java:1018) > I think it is caused by the changes in WICKET-5983 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WICKET-6006) ModalWindow.closeCurrent() causes 414 status error
Martijn Dashorst created WICKET-6006:
Summary: ModalWindow.closeCurrent() causes 414 status error
Key: WICKET-6006
URL: https://issues.apache.org/jira/browse/WICKET-6006
Project: Wicket
Issue Type: Bug
Components: wicket-extensions
Affects Versions: 7.0.0, 6.20.0
Reporter: Martijn Dashorst
Priority: Minor
When you have a panel inside a modal window, and the panel contains a form with
e.g. a textarea, and you fill the textarea with about 10k of text, when the
modal window is closed using closeCurrent() you get a 414 status error stating
that the URL is too long (depends on the backend server).
{code}
public ModalPanel1(String id)
{
super(id);
Form form = new Form<>("form");
add(form);
add(new AjaxLink("closeCancel") {
@Override
public void onClick(AjaxRequestTarget target) {
ModalWindow.closeCurrent(target);
}
});
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1; i++)
sb.append("a");
form.add(new TextArea<>("bigFingTextField",
Model.of(sb.toString(;
}
{code}
Closing the window using ModalWindow.closeCurrent() will add the serializedForm
of the modal window's contents (See line 656 of wicket-ajax-debug.js) to the
URL that's sent to wicket. If the form inside the panel contains lots of data,
this will exceed the maximum URL length...
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js#L656
The workaround is of course to use
ModalWindow#close(IPartialPageRequestHandler) instead, however, why is
ModalWindow#closeCurrent() even there, and why doesn't it properly close the
window with the same behavior as the instance method?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WICKET-5998) Page is detached twice in same AJAX request
Martijn Dashorst created WICKET-5998:
Summary: Page is detached twice in same AJAX request
Key: WICKET-5998
URL: https://issues.apache.org/jira/browse/WICKET-5998
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Priority: Minor
While debugging some code I noticed that detaching happens twice during the
same (AJAX) request.
First through `ListenerInterfaceRequestHandler.detach()` and next through
`AjaxRequestHandler.detach(IRequestCycle)`.
The following stack traces show the code paths.
{code}
Thread [qtp1297836716-57] (Suspended (breakpoint at line 858 in MyWebPage))
MyWebPage.onDetach() line: 858
MyWebPage(Component).detach() line: 1162
PageAndComponentProvider(PageProvider).detach() line: 330
ListenerInterfaceRequestHandler.detach(IRequestCycle) line: 128
RequestCycle$HandlerExecutor.detach(IRequestHandler) line: 876
RequestCycle$HandlerExecutor(RequestHandlerStack).detach() line: 180
RequestCycle.onDetach() line: 641
RequestCycle.detach() line: 594
RequestCycle.processRequestAndDetach() line: 297
WicketFilter.processRequestCycle(RequestCycle, WebResponse,
HttpServletRequest, HttpServletResponse, FilterChain) line: 261
WicketFilter.processRequest(ServletRequest, ServletResponse,
FilterChain) line: 203
WicketFilter.doFilter(ServletRequest, ServletResponse, FilterChain)
line: 284
Thread [qtp1297836716-57] (Suspended (breakpoint at line 858 in MyWebPage))
MyWebPage.onDetach() line: 858
MyWebPage(Component).detach() line: 1162
AjaxRequestHandler$1(PartialPageUpdate).detach(IRequestCycle) line: 417
AjaxRequestHandler.detach(IRequestCycle) line: 277
RequestCycle$HandlerExecutor.detach(IRequestHandler) line: 876
RequestCycle$HandlerExecutor(RequestHandlerStack).detach() line: 180
RequestCycle.onDetach() line: 641
RequestCycle.detach() line: 594
RequestCycle.processRequestAndDetach() line: 297
WicketFilter.processRequestCycle(RequestCycle, WebResponse,
HttpServletRequest, HttpServletResponse, FilterChain) line: 261
WicketFilter.processRequest(ServletRequest, ServletResponse,
FilterChain) line: 203
WicketFilter.doFilter(ServletRequest, ServletResponse, FilterChain)
line: 284
{code}
Is this something that can be prevented? If you have a big component tree,
detaching twice can be quite expensive.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WICKET-5992) Add support for lambdas in Ajax behaviors & components
[
https://issues.apache.org/jira/browse/WICKET-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943047#comment-14943047
]
Martijn Dashorst commented on WICKET-5992:
--
We could opt for an interface you need to pass in as the first argument instead
of a string, this way you can distinguish between which events you'd accept, as
we can craft a hierarchy:
{code:java}
public interface DomEvent {
}
public interface DomActionEvent extends DomEvent {
}
public enum DomActionEvents {
DomActionEvent click,
DomActionEvent blur,
DomActionEvent focus;
}
public interface DomUpdatingEvent extends DomEvent {
}
public enum DomUpdatingsEvents {
DomUpdatingEvent change;
...?
}
{code}
> Add support for lambdas in Ajax behaviors & components
> --
>
> Key: WICKET-5992
> URL: https://issues.apache.org/jira/browse/WICKET-5992
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
>Affects Versions: 8.0.0-M1
>Reporter: Martin Grigorov
>
> Investigate whether using lambdas in Wicket Ajax behaviors and components
> will make it less verbose.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (WICKET-5967) Unable to load i18n minified js
[ https://issues.apache.org/jira/browse/WICKET-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst closed WICKET-5967. > Unable to load i18n minified js > --- > > Key: WICKET-5967 > URL: https://issues.apache.org/jira/browse/WICKET-5967 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.20.0, 7.0.0 >Reporter: Martijn Dashorst > Fix For: 7.1.0 > > > Wicket doesn't locate i18n minified resources from the class path correctly. > When style, variation, i18n and minification come into play, Wicket doesn't > find the correct styled, variationed, i18n and minified file. > Due to a combination of bugs and some changes we haven't yet discerned, > Wicket 7.0.0 fails to load a JavaScript file (to be exact: > wicket/resource/org.odlabs.wiquery.ui.datepicker.DatePickerLanguageResourceReference/i18n/jquery.ui.datepicker-nl-ver-143823914.js) > This issue is one of those bugs, which is present in 6.x but doesn't surface > there for a yet unknown reason. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-5967) Unable to load i18n minified js
[ https://issues.apache.org/jira/browse/WICKET-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-5967: - Fix Version/s: (was: 6.21.0) > Unable to load i18n minified js > --- > > Key: WICKET-5967 > URL: https://issues.apache.org/jira/browse/WICKET-5967 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.20.0, 7.0.0 >Reporter: Martijn Dashorst > Fix For: 7.1.0 > > > Wicket doesn't locate i18n minified resources from the class path correctly. > When style, variation, i18n and minification come into play, Wicket doesn't > find the correct styled, variationed, i18n and minified file. > Due to a combination of bugs and some changes we haven't yet discerned, > Wicket 7.0.0 fails to load a JavaScript file (to be exact: > wicket/resource/org.odlabs.wiquery.ui.datepicker.DatePickerLanguageResourceReference/i18n/jquery.ui.datepicker-nl-ver-143823914.js) > This issue is one of those bugs, which is present in 6.x but doesn't surface > there for a yet unknown reason. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (WICKET-5966) ResourceUtils.getLocaleFromFilename can't handle minimized resources well
[ https://issues.apache.org/jira/browse/WICKET-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst resolved WICKET-5966. -- Resolution: Fixed > ResourceUtils.getLocaleFromFilename can't handle minimized resources well > - > > Key: WICKET-5966 > URL: https://issues.apache.org/jira/browse/WICKET-5966 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.20.0, 7.0.0 >Reporter: Martijn Dashorst > Fix For: 7.1.0 > > > I think the ResourceUtils.getLocaleFromFilename(String path) has the order of > locale and minimization wrong: > It currently parses: File.min_Lang_Coun_Var.ext while the typical convention > is File_Lang_Coun_Var.min.ext > Surely considering the ResourceUtils.getMinifiedName() method which does work > according to convention. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WICKET-5966) ResourceUtils.getLocaleFromFilename can't handle minimized resources well
[ https://issues.apache.org/jira/browse/WICKET-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst closed WICKET-5966. > ResourceUtils.getLocaleFromFilename can't handle minimized resources well > - > > Key: WICKET-5966 > URL: https://issues.apache.org/jira/browse/WICKET-5966 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.20.0, 7.0.0 >Reporter: Martijn Dashorst > Fix For: 7.1.0 > > > I think the ResourceUtils.getLocaleFromFilename(String path) has the order of > locale and minimization wrong: > It currently parses: File.min_Lang_Coun_Var.ext while the typical convention > is File_Lang_Coun_Var.min.ext > Surely considering the ResourceUtils.getMinifiedName() method which does work > according to convention. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (WICKET-5980) When using Servlet 3.0 filter Wicket calculates filter path wrong
[
https://issues.apache.org/jira/browse/WICKET-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst resolved WICKET-5980.
--
Resolution: Fixed
> When using Servlet 3.0 filter Wicket calculates filter path wrong
> -
>
> Key: WICKET-5980
> URL: https://issues.apache.org/jira/browse/WICKET-5980
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.0.0
>Reporter: Martijn Dashorst
>Priority: Minor
> Fix For: 7.1.0
>
>
> When using a servlet 3.0 filter with annotations Wicket calculates the filter
> path wrong causing it to not match any pages other than the home page.
> e.g.
> {code}
> @WebFilter(value = "/web/*", initParams = {@WebInitParam(name =
> "applicationClassName", value = "com.example.CheesrApplication")})
> public class CheesrFilter extends WicketFilter {
> }
> {code}
> Will cause Wicket to create a filter path of /web/*/ instead of the expected
> /web.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WICKET-5981) Significant Performance Degradation From Wicket 6.20.0 to Wicket 7.0.0
[ https://issues.apache.org/jira/browse/WICKET-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-5981: - Fix Version/s: 7.1.0 > Significant Performance Degradation From Wicket 6.20.0 to Wicket 7.0.0 > -- > > Key: WICKET-5981 > URL: https://issues.apache.org/jira/browse/WICKET-5981 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.0.0 > Environment: OpenSuse 13.1 > Intellij 14.1.4 > JDK 1.8.0_60 > Solid State Hard Drive > 24 GB RAM >Reporter: Aaron J. Garcia >Assignee: Andrea Del Bene > Labels: performance > Fix For: 7.1.0 > > Attachments: > WICKET-5981-Significant-Performance-Degradation-From.patch, quickstart.tar > > > I am experiencing a significant performance degradation for component adds in > Wicket 7.0.0, once the component tree for a page gets reasonably large. > The attached quick start can be used to reproduce the issue. Please note > that NUM_ROWS is set to 10,000 to exaggerate the performance degradation as > the size of the component tree increases. The same degradation (to a lesser > extent) can be viewed with a smaller NUM_ROWS variable. > In Wicket 6.20.0, as the size of the component tree increases, the cost of > add() remains relatively constant time-wise. In Wicket 7.0.0, a component > add () is much more expensive (and actually makes our internal web > application unusable) with form submits taking more than two or three minutes > to come back from the server. > Here's some timing examples. > = > NUM_ROWS = 5000 > Wicket 6.20.0 -> ~200 milliseconds of server side rendering (before browser > paints HTML). > Wicket 7.0.0 -> ~ 10 seconds of server side rendering > NUM_ROWS = 1 > Wicket 6.20.0 -> ~ 500 milliseconds of server side rendering > Wicket 7.0.0 -> ~ 40 seconds of server side rendering > = > The attached quickstart can be used to reproduce the issue on your side. My > guess is that this has to do with the new component queuing feature that was > added as part of Wicket 7.0.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-5983) O(n^2) complexity in MarkupContainer.add
[ https://issues.apache.org/jira/browse/WICKET-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-5983: - Fix Version/s: 7.1.0 > O(n^2) complexity in MarkupContainer.add > > > Key: WICKET-5983 > URL: https://issues.apache.org/jira/browse/WICKET-5983 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.13, 6.20.0, 7.0.0 >Reporter: Emond Papegaaij >Assignee: Emond Papegaaij >Priority: Minor > Fix For: 7.1.0 > > > MarkupContainer.add has O(n^2) complexity on the number of childs, because it > searches through all other childs for a child with the same id. This may not > be much of a problem in most situations, but in large tables, the performance > can get very bad. > Constructing a table with n rows, with 6 cells in each row takes (10k > iterations) in Wicket 6.20.0 (Wicket 7 should be comparable, but WICKET-5981 > kills perfomance badly): > 10 -> 132ms > 20 -> 245ms > 40 -> 465ms > 80 -> 1000ms > 160 -> 2444ms > 320 -> 6989ms > 640 -> 23201ms > 1280 -> 80784ms -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (WICKET-5981) Significant Performance Degradation From Wicket 6.20.0 to Wicket 7.0.0
[ https://issues.apache.org/jira/browse/WICKET-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst resolved WICKET-5981. -- Resolution: Fixed Assignee: Emond Papegaaij (was: Andrea Del Bene) > Significant Performance Degradation From Wicket 6.20.0 to Wicket 7.0.0 > -- > > Key: WICKET-5981 > URL: https://issues.apache.org/jira/browse/WICKET-5981 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.0.0 > Environment: OpenSuse 13.1 > Intellij 14.1.4 > JDK 1.8.0_60 > Solid State Hard Drive > 24 GB RAM >Reporter: Aaron J. Garcia >Assignee: Emond Papegaaij > Labels: performance > Fix For: 7.1.0 > > Attachments: > WICKET-5981-Significant-Performance-Degradation-From.patch, quickstart.tar > > > I am experiencing a significant performance degradation for component adds in > Wicket 7.0.0, once the component tree for a page gets reasonably large. > The attached quick start can be used to reproduce the issue. Please note > that NUM_ROWS is set to 10,000 to exaggerate the performance degradation as > the size of the component tree increases. The same degradation (to a lesser > extent) can be viewed with a smaller NUM_ROWS variable. > In Wicket 6.20.0, as the size of the component tree increases, the cost of > add() remains relatively constant time-wise. In Wicket 7.0.0, a component > add () is much more expensive (and actually makes our internal web > application unusable) with form submits taking more than two or three minutes > to come back from the server. > Here's some timing examples. > = > NUM_ROWS = 5000 > Wicket 6.20.0 -> ~200 milliseconds of server side rendering (before browser > paints HTML). > Wicket 7.0.0 -> ~ 10 seconds of server side rendering > NUM_ROWS = 1 > Wicket 6.20.0 -> ~ 500 milliseconds of server side rendering > Wicket 7.0.0 -> ~ 40 seconds of server side rendering > = > The attached quickstart can be used to reproduce the issue on your side. My > guess is that this has to do with the new component queuing feature that was > added as part of Wicket 7.0.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (WICKET-5967) Unable to load i18n minified js
[ https://issues.apache.org/jira/browse/WICKET-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst resolved WICKET-5967. -- Resolution: Fixed > Unable to load i18n minified js > --- > > Key: WICKET-5967 > URL: https://issues.apache.org/jira/browse/WICKET-5967 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.20.0, 7.0.0 >Reporter: Martijn Dashorst > Fix For: 6.21.0, 7.1.0 > > > Wicket doesn't locate i18n minified resources from the class path correctly. > When style, variation, i18n and minification come into play, Wicket doesn't > find the correct styled, variationed, i18n and minified file. > Due to a combination of bugs and some changes we haven't yet discerned, > Wicket 7.0.0 fails to load a JavaScript file (to be exact: > wicket/resource/org.odlabs.wiquery.ui.datepicker.DatePickerLanguageResourceReference/i18n/jquery.ui.datepicker-nl-ver-143823914.js) > This issue is one of those bugs, which is present in 6.x but doesn't surface > there for a yet unknown reason. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WICKET-5980) When using Servlet 3.0 filter Wicket calculates filter path wrong
[
https://issues.apache.org/jira/browse/WICKET-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst closed WICKET-5980.
> When using Servlet 3.0 filter Wicket calculates filter path wrong
> -
>
> Key: WICKET-5980
> URL: https://issues.apache.org/jira/browse/WICKET-5980
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.0.0
>Reporter: Martijn Dashorst
>Priority: Minor
> Fix For: 7.1.0
>
>
> When using a servlet 3.0 filter with annotations Wicket calculates the filter
> path wrong causing it to not match any pages other than the home page.
> e.g.
> {code}
> @WebFilter(value = "/web/*", initParams = {@WebInitParam(name =
> "applicationClassName", value = "com.example.CheesrApplication")})
> public class CheesrFilter extends WicketFilter {
> }
> {code}
> Will cause Wicket to create a filter path of /web/*/ instead of the expected
> /web.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (WICKET-5983) O(n^2) complexity in MarkupContainer.add
[ https://issues.apache.org/jira/browse/WICKET-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst resolved WICKET-5983. -- Resolution: Fixed > O(n^2) complexity in MarkupContainer.add > > > Key: WICKET-5983 > URL: https://issues.apache.org/jira/browse/WICKET-5983 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.13, 6.20.0, 7.0.0 >Reporter: Emond Papegaaij >Assignee: Emond Papegaaij >Priority: Minor > Fix For: 7.1.0 > > > MarkupContainer.add has O(n^2) complexity on the number of childs, because it > searches through all other childs for a child with the same id. This may not > be much of a problem in most situations, but in large tables, the performance > can get very bad. > Constructing a table with n rows, with 6 cells in each row takes (10k > iterations) in Wicket 6.20.0 (Wicket 7 should be comparable, but WICKET-5981 > kills perfomance badly): > 10 -> 132ms > 20 -> 245ms > 40 -> 465ms > 80 -> 1000ms > 160 -> 2444ms > 320 -> 6989ms > 640 -> 23201ms > 1280 -> 80784ms -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WICKET-5981) Significant Performance Degradation From Wicket 6.20.0 to Wicket 7.0.0
[ https://issues.apache.org/jira/browse/WICKET-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst closed WICKET-5981. > Significant Performance Degradation From Wicket 6.20.0 to Wicket 7.0.0 > -- > > Key: WICKET-5981 > URL: https://issues.apache.org/jira/browse/WICKET-5981 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.0.0 > Environment: OpenSuse 13.1 > Intellij 14.1.4 > JDK 1.8.0_60 > Solid State Hard Drive > 24 GB RAM >Reporter: Aaron J. Garcia >Assignee: Emond Papegaaij > Labels: performance > Fix For: 7.1.0 > > Attachments: > WICKET-5981-Significant-Performance-Degradation-From.patch, quickstart.tar > > > I am experiencing a significant performance degradation for component adds in > Wicket 7.0.0, once the component tree for a page gets reasonably large. > The attached quick start can be used to reproduce the issue. Please note > that NUM_ROWS is set to 10,000 to exaggerate the performance degradation as > the size of the component tree increases. The same degradation (to a lesser > extent) can be viewed with a smaller NUM_ROWS variable. > In Wicket 6.20.0, as the size of the component tree increases, the cost of > add() remains relatively constant time-wise. In Wicket 7.0.0, a component > add () is much more expensive (and actually makes our internal web > application unusable) with form submits taking more than two or three minutes > to come back from the server. > Here's some timing examples. > = > NUM_ROWS = 5000 > Wicket 6.20.0 -> ~200 milliseconds of server side rendering (before browser > paints HTML). > Wicket 7.0.0 -> ~ 10 seconds of server side rendering > NUM_ROWS = 1 > Wicket 6.20.0 -> ~ 500 milliseconds of server side rendering > Wicket 7.0.0 -> ~ 40 seconds of server side rendering > = > The attached quickstart can be used to reproduce the issue on your side. My > guess is that this has to do with the new component queuing feature that was > added as part of Wicket 7.0.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WICKET-5983) O(n^2) complexity in MarkupContainer.add
[ https://issues.apache.org/jira/browse/WICKET-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst closed WICKET-5983. > O(n^2) complexity in MarkupContainer.add > > > Key: WICKET-5983 > URL: https://issues.apache.org/jira/browse/WICKET-5983 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.13, 6.20.0, 7.0.0 >Reporter: Emond Papegaaij >Assignee: Emond Papegaaij >Priority: Minor > Fix For: 7.1.0 > > > MarkupContainer.add has O(n^2) complexity on the number of childs, because it > searches through all other childs for a child with the same id. This may not > be much of a problem in most situations, but in large tables, the performance > can get very bad. > Constructing a table with n rows, with 6 cells in each row takes (10k > iterations) in Wicket 6.20.0 (Wicket 7 should be comparable, but WICKET-5981 > kills perfomance badly): > 10 -> 132ms > 20 -> 245ms > 40 -> 465ms > 80 -> 1000ms > 160 -> 2444ms > 320 -> 6989ms > 640 -> 23201ms > 1280 -> 80784ms -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WICKET-5980) When using Servlet 3.0 filter Wicket calculates filter path wrong
Martijn Dashorst created WICKET-5980:
Summary: When using Servlet 3.0 filter Wicket calculates filter
path wrong
Key: WICKET-5980
URL: https://issues.apache.org/jira/browse/WICKET-5980
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Priority: Minor
Fix For: 7.1.0
When using a servlet 3.0 filter with annotations Wicket calculates the filter
path wrong causing it to not match any pages other than the home page.
e.g.
{code}
@WebFilter(value = "/web/*", initParams = {@WebInitParam(name =
"applicationClassName", value = "com.example.CheesrApplication")})
public class CheesrFilter extends WicketFilter {
}
{code}
Will cause Wicket to create a filter path of /web/*/ instead of the expected
/web.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WICKET-5961) Wicket1.5 TreeTable can't find markup
[
https://issues.apache.org/jira/browse/WICKET-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14699213#comment-14699213
]
Martijn Dashorst commented on WICKET-5961:
--
I still think this is a regression from 6 to 7. The mentioned commit
f89b15618243075f8a8e90cb826550af525dabb7 removes previous working markup, and
I'm not convinced the two tests failing (MarkupFragmentTest.panel and
MarkupFragmentTest.panelWithAutoComponent) are actually testing a valid
assumption (because I don't know what the assumption is that they are
testing--I only see the state being tested).
Wicket1.5 TreeTable can't find markup
-
Key: WICKET-5961
URL: https://issues.apache.org/jira/browse/WICKET-5961
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
The recently moved TreeTable can't find its markup (for a TreeTableItem):
{code}
org.apache.wicket.markup.MarkupNotFoundException: Markup not found for
Component: [TreeTableItem [Component id = 0]]
at org.apache.wicket.Component.internalRender(Component.java:2347)
at org.apache.wicket.Component.render(Component.java:2307)
at
org.apache.wicket.extensions.markup.html.tree.table.SideColumnsView.onRender(SideColumnsView.java:103)
at org.apache.wicket.Component.internalRender(Component.java:2379)
at org.apache.wicket.Component.render(Component.java:2307)
at
org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1407)
at
org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1604)
at
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1579)
at
org.apache.wicket.MarkupContainer.renderAssociatedMarkup(MarkupContainer.java:691)
at
org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderAssociatedMarkup(AssociatedMarkupSourcingStrategy.java:77)
at
org.apache.wicket.markup.html.panel.PanelMarkupSourcingStrategy.onComponentTagBody(PanelMarkupSourcingStrategy.java:112)
at
org.apache.wicket.Component.internalRenderComponent(Component.java:2564)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1543)
at org.apache.wicket.Component.internalRender(Component.java:2379)
at org.apache.wicket.Component.render(Component.java:2307)
at
org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1407)
at
org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1604)
at org.apache.wicket.Page.onRender(Page.java:879)
at org.apache.wicket.markup.html.WebPage.onRender(WebPage.java:141)
at org.apache.wicket.Component.internalRender(Component.java:2379)
at org.apache.wicket.Component.render(Component.java:2307)
at org.apache.wicket.Page.renderPage(Page.java:1018)
at
org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:124)
at
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:236)
at
org.apache.wicket.util.tester.BaseWicketTester$LastPageRecordingPageRendererProvider$1.respond(BaseWicketTester.java:2745)
at
org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:865)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
at
org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:718)
at
org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:657)
at
org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:629)
at
org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:1262)
at
org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:1235)
at
org.apache.wicket.extensions.markup.html.tree.HomePageTest.homepageRenders(HomePageTest.java:10)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
[jira] [Commented] (WICKET-5960) Page header isn't rendered for pages where URL has changed during render
[
https://issues.apache.org/jira/browse/WICKET-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696687#comment-14696687
]
Martijn Dashorst commented on WICKET-5960:
--
The AJAX request replaces (or introduces) the PartialMarkupHtmlHeadContainer in
the page when it is performing the render of the feedback panel. My guess is to
capture any new header contributions. The issue is not this, it is that at the
end of the AJAX request the PartialMarkupHeaderContainer is still attached to
the page and the subsequent non-AJAX request uses this container to render the
head section, causing an empty head.
When you renamed onDetach to onAfterRender this problem was introduced because
somehow onAfterRender is not called in an AJAX update for the , but onDetach is.
I've committed the test case. When you comment out the two lines in
HtmlHeaderContainer's onDetach you can reproduce the bug.
Page header isn't rendered for pages where URL has changed during render
Key: WICKET-5960
URL: https://issues.apache.org/jira/browse/WICKET-5960
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Assignee: Sven Meier
Fix For: 6.21.0, 7.1.0
Due to the changes in WICKET-5309, a page is re-rendered when any of the URL
segments is modified during the request:
From WebPageRenderer.java:
{code}
// the url might have changed after page has been rendered (e.g. the
// stateless flag might have changed because stateful components
// were added)
final Url afterRenderUrl = requestCycle
.mapUrlFor(getRenderPageRequestHandler());
if (beforeRenderUrl.getSegments().equals(afterRenderUrl.getSegments())
== false)
{
// the amount of segments is different - generated relative URLs
// will not work, we need to rerender the page. This can happen
// with IRequestHandlers that produce different URLs with
// different amount of segments for stateless and stateful pages
response = renderPage(afterRenderUrl, requestCycle);
}
if (currentUrl.equals(afterRenderUrl))
{code}
The re-render causes the head section to be empty because it was already
rendered in the first try.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WICKET-5960) Page header isn't rendered for pages where URL has changed during render
[
https://issues.apache.org/jira/browse/WICKET-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696675#comment-14696675
]
Martijn Dashorst commented on WICKET-5960:
--
I see... Apparently I didn't commit the accompanying test case. There's a
separate test case for this.
Page header isn't rendered for pages where URL has changed during render
Key: WICKET-5960
URL: https://issues.apache.org/jira/browse/WICKET-5960
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Assignee: Sven Meier
Fix For: 6.21.0, 7.1.0
Due to the changes in WICKET-5309, a page is re-rendered when any of the URL
segments is modified during the request:
From WebPageRenderer.java:
{code}
// the url might have changed after page has been rendered (e.g. the
// stateless flag might have changed because stateful components
// were added)
final Url afterRenderUrl = requestCycle
.mapUrlFor(getRenderPageRequestHandler());
if (beforeRenderUrl.getSegments().equals(afterRenderUrl.getSegments())
== false)
{
// the amount of segments is different - generated relative URLs
// will not work, we need to rerender the page. This can happen
// with IRequestHandlers that produce different URLs with
// different amount of segments for stateless and stateful pages
response = renderPage(afterRenderUrl, requestCycle);
}
if (currentUrl.equals(afterRenderUrl))
{code}
The re-render causes the head section to be empty because it was already
rendered in the first try.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WICKET-5960) Page header isn't rendered for pages where URL has changed during render
[
https://issues.apache.org/jira/browse/WICKET-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14694992#comment-14694992
]
Martijn Dashorst commented on WICKET-5960:
--
Apparently this is caused by line 475 from PartialPageUpdate.java:
{code:java}
protected void writeHeaderContribution(final Response response, final
Component component)
{
headerRendering = true;
// create the htmlheadercontainer if needed
if (header == null)
{
header = new PartialHtmlHeaderContainer(this);
final Page parentPage = component.getPage();
parentPage.addOrReplace(header);
}
{code}
the offending line is parentPage.addOrReplace(header);
Page header isn't rendered for pages where URL has changed during render
Key: WICKET-5960
URL: https://issues.apache.org/jira/browse/WICKET-5960
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Assignee: Sven Meier
Fix For: 6.21.0, 7.1.0
Due to the changes in WICKET-5309, a page is re-rendered when any of the URL
segments is modified during the request:
From WebPageRenderer.java:
{code}
// the url might have changed after page has been rendered (e.g. the
// stateless flag might have changed because stateful components
// were added)
final Url afterRenderUrl = requestCycle
.mapUrlFor(getRenderPageRequestHandler());
if (beforeRenderUrl.getSegments().equals(afterRenderUrl.getSegments())
== false)
{
// the amount of segments is different - generated relative URLs
// will not work, we need to rerender the page. This can happen
// with IRequestHandlers that produce different URLs with
// different amount of segments for stateless and stateful pages
response = renderPage(afterRenderUrl, requestCycle);
}
if (currentUrl.equals(afterRenderUrl))
{code}
The re-render causes the head section to be empty because it was already
rendered in the first try.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WICKET-5960) Page header isn't rendered for pages where URL has changed during render
[
https://issues.apache.org/jira/browse/WICKET-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695188#comment-14695188
]
Martijn Dashorst commented on WICKET-5960:
--
https://github.com/dashorst/wicket-5960
Page header isn't rendered for pages where URL has changed during render
Key: WICKET-5960
URL: https://issues.apache.org/jira/browse/WICKET-5960
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Assignee: Sven Meier
Fix For: 6.21.0, 7.1.0
Due to the changes in WICKET-5309, a page is re-rendered when any of the URL
segments is modified during the request:
From WebPageRenderer.java:
{code}
// the url might have changed after page has been rendered (e.g. the
// stateless flag might have changed because stateful components
// were added)
final Url afterRenderUrl = requestCycle
.mapUrlFor(getRenderPageRequestHandler());
if (beforeRenderUrl.getSegments().equals(afterRenderUrl.getSegments())
== false)
{
// the amount of segments is different - generated relative URLs
// will not work, we need to rerender the page. This can happen
// with IRequestHandlers that produce different URLs with
// different amount of segments for stateless and stateful pages
response = renderPage(afterRenderUrl, requestCycle);
}
if (currentUrl.equals(afterRenderUrl))
{code}
The re-render causes the head section to be empty because it was already
rendered in the first try.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (WICKET-5960) Page header isn't rendered for pages where URL has changed during render
[
https://issues.apache.org/jira/browse/WICKET-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695188#comment-14695188
]
Martijn Dashorst edited comment on WICKET-5960 at 8/13/15 1:07 PM:
---
https://github.com/dashorst/wicket-5960
Scenario:
- have ajax update render a component
- click on normal submit
- see background go from gray to white
(and header be empty)
was (Author: dashorst):
https://github.com/dashorst/wicket-5960
Page header isn't rendered for pages where URL has changed during render
Key: WICKET-5960
URL: https://issues.apache.org/jira/browse/WICKET-5960
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Assignee: Sven Meier
Fix For: 6.21.0, 7.1.0
Due to the changes in WICKET-5309, a page is re-rendered when any of the URL
segments is modified during the request:
From WebPageRenderer.java:
{code}
// the url might have changed after page has been rendered (e.g. the
// stateless flag might have changed because stateful components
// were added)
final Url afterRenderUrl = requestCycle
.mapUrlFor(getRenderPageRequestHandler());
if (beforeRenderUrl.getSegments().equals(afterRenderUrl.getSegments())
== false)
{
// the amount of segments is different - generated relative URLs
// will not work, we need to rerender the page. This can happen
// with IRequestHandlers that produce different URLs with
// different amount of segments for stateless and stateful pages
response = renderPage(afterRenderUrl, requestCycle);
}
if (currentUrl.equals(afterRenderUrl))
{code}
The re-render causes the head section to be empty because it was already
rendered in the first try.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WICKET-5960) Page header isn't rendered for pages where URL has changed during render
[
https://issues.apache.org/jira/browse/WICKET-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695304#comment-14695304
]
Martijn Dashorst commented on WICKET-5960:
--
It appears that HtmlHeaderResponse's onAfterRender is not called when rendering
an AJAX response.
Page header isn't rendered for pages where URL has changed during render
Key: WICKET-5960
URL: https://issues.apache.org/jira/browse/WICKET-5960
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Assignee: Sven Meier
Fix For: 6.21.0, 7.1.0
Due to the changes in WICKET-5309, a page is re-rendered when any of the URL
segments is modified during the request:
From WebPageRenderer.java:
{code}
// the url might have changed after page has been rendered (e.g. the
// stateless flag might have changed because stateful components
// were added)
final Url afterRenderUrl = requestCycle
.mapUrlFor(getRenderPageRequestHandler());
if (beforeRenderUrl.getSegments().equals(afterRenderUrl.getSegments())
== false)
{
// the amount of segments is different - generated relative URLs
// will not work, we need to rerender the page. This can happen
// with IRequestHandlers that produce different URLs with
// different amount of segments for stateless and stateful pages
response = renderPage(afterRenderUrl, requestCycle);
}
if (currentUrl.equals(afterRenderUrl))
{code}
The re-render causes the head section to be empty because it was already
rendered in the first try.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WICKET-5960) Page header isn't rendered for pages where URL has changed during render
[
https://issues.apache.org/jira/browse/WICKET-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695315#comment-14695315
]
Martijn Dashorst commented on WICKET-5960:
--
Fixing the HtmlHeaderResponse such that also an onDetach is present to clear
out the temporary state, it solves this issue.
Page header isn't rendered for pages where URL has changed during render
Key: WICKET-5960
URL: https://issues.apache.org/jira/browse/WICKET-5960
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Assignee: Sven Meier
Fix For: 6.21.0, 7.1.0
Due to the changes in WICKET-5309, a page is re-rendered when any of the URL
segments is modified during the request:
From WebPageRenderer.java:
{code}
// the url might have changed after page has been rendered (e.g. the
// stateless flag might have changed because stateful components
// were added)
final Url afterRenderUrl = requestCycle
.mapUrlFor(getRenderPageRequestHandler());
if (beforeRenderUrl.getSegments().equals(afterRenderUrl.getSegments())
== false)
{
// the amount of segments is different - generated relative URLs
// will not work, we need to rerender the page. This can happen
// with IRequestHandlers that produce different URLs with
// different amount of segments for stateless and stateful pages
response = renderPage(afterRenderUrl, requestCycle);
}
if (currentUrl.equals(afterRenderUrl))
{code}
The re-render causes the head section to be empty because it was already
rendered in the first try.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WICKET-5960) Page header isn't rendered for pages where URL has changed during render
[
https://issues.apache.org/jira/browse/WICKET-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693547#comment-14693547
]
Martijn Dashorst commented on WICKET-5960:
--
It appears that this fix doesn't solve all our problems. While the test case is
fixed, we encounter reproducible empty head sections.
From what I gather it is mostly to do with 'back' navigations where we tell
wicket to rerender a previous page from the page store
(setResponsePage(getPage(pageId)));. However I'm investigating if this is
the cause, or something else is in play.
Page header isn't rendered for pages where URL has changed during render
Key: WICKET-5960
URL: https://issues.apache.org/jira/browse/WICKET-5960
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Assignee: Sven Meier
Fix For: 6.21.0, 7.1.0
Due to the changes in WICKET-5309, a page is re-rendered when any of the URL
segments is modified during the request:
From WebPageRenderer.java:
{code}
// the url might have changed after page has been rendered (e.g. the
// stateless flag might have changed because stateful components
// were added)
final Url afterRenderUrl = requestCycle
.mapUrlFor(getRenderPageRequestHandler());
if (beforeRenderUrl.getSegments().equals(afterRenderUrl.getSegments())
== false)
{
// the amount of segments is different - generated relative URLs
// will not work, we need to rerender the page. This can happen
// with IRequestHandlers that produce different URLs with
// different amount of segments for stateless and stateful pages
response = renderPage(afterRenderUrl, requestCycle);
}
if (currentUrl.equals(afterRenderUrl))
{code}
The re-render causes the head section to be empty because it was already
rendered in the first try.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WICKET-5967) Unable to load i18n minified js
[ https://issues.apache.org/jira/browse/WICKET-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14681413#comment-14681413 ] Martijn Dashorst commented on WICKET-5967: -- you can still lookup resources under any name. foo.compressed.js will still work. Only auto-selection between minified and non-minified is codified using '.min' in the framework, but that was already the case. I didn't modify that. Unable to load i18n minified js --- Key: WICKET-5967 URL: https://issues.apache.org/jira/browse/WICKET-5967 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.20.0, 7.0.0 Reporter: Martijn Dashorst Fix For: 6.21.0, 7.1.0 Wicket doesn't locate i18n minified resources from the class path correctly. When style, variation, i18n and minification come into play, Wicket doesn't find the correct styled, variationed, i18n and minified file. Due to a combination of bugs and some changes we haven't yet discerned, Wicket 7.0.0 fails to load a JavaScript file (to be exact: wicket/resource/org.odlabs.wiquery.ui.datepicker.DatePickerLanguageResourceReference/i18n/jquery.ui.datepicker-nl-ver-143823914.js) This issue is one of those bugs, which is present in 6.x but doesn't surface there for a yet unknown reason. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WICKET-5968) CachingResourceLocator lookup key doesn't take strict into account
Martijn Dashorst created WICKET-5968: Summary: CachingResourceLocator lookup key doesn't take strict into account Key: WICKET-5968 URL: https://issues.apache.org/jira/browse/WICKET-5968 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 7.0.0, 6.20.0 Reporter: Martijn Dashorst Fix For: 7.1.0 CachingResourceLocator uses a CacheKey to store lookups for resources. With e.g. - b_nl.js - b.js When e.g. a strict resource lookup for b.js with locale us is performed, it will store the not-found for locale us under the cache key. The cache key consists of resource name, locale, style and variation. However when you search non-strict for locale us, the resource locator should find the non-localized resource b.js, but since a matching key for the lookup was stored for this particular resource, it will fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WICKET-5968) CachingResourceLocator lookup key doesn't take strict into account
[ https://issues.apache.org/jira/browse/WICKET-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst closed WICKET-5968. CachingResourceLocator lookup key doesn't take strict into account -- Key: WICKET-5968 URL: https://issues.apache.org/jira/browse/WICKET-5968 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.20.0, 7.0.0 Reporter: Martijn Dashorst Assignee: Martijn Dashorst Fix For: 6.21.0, 7.1.0 CachingResourceLocator uses a CacheKey to store lookups for resources. With e.g. - b_nl.js - b.js When e.g. a strict resource lookup for b.js with locale us is performed, it will store the not-found for locale us under the cache key. The cache key consists of resource name, locale, style and variation. However when you search non-strict for locale us, the resource locator should find the non-localized resource b.js, but since a matching key for the lookup was stored for this particular resource, it will fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (WICKET-5968) CachingResourceLocator lookup key doesn't take strict into account
[ https://issues.apache.org/jira/browse/WICKET-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst resolved WICKET-5968. -- Resolution: Fixed Assignee: Martijn Dashorst Fix Version/s: 6.21.0 CachingResourceLocator lookup key doesn't take strict into account -- Key: WICKET-5968 URL: https://issues.apache.org/jira/browse/WICKET-5968 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.20.0, 7.0.0 Reporter: Martijn Dashorst Assignee: Martijn Dashorst Fix For: 6.21.0, 7.1.0 CachingResourceLocator uses a CacheKey to store lookups for resources. With e.g. - b_nl.js - b.js When e.g. a strict resource lookup for b.js with locale us is performed, it will store the not-found for locale us under the cache key. The cache key consists of resource name, locale, style and variation. However when you search non-strict for locale us, the resource locator should find the non-localized resource b.js, but since a matching key for the lookup was stored for this particular resource, it will fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-5966) ResourceUtils.getLocaleFromFilename can't handle minimized resources well
[ https://issues.apache.org/jira/browse/WICKET-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-5966: - Description: I think the ResourceUtils.getLocaleFromFilename(String path) has the order of locale and minimization wrong: It currently parses: File.min_Lang_Coun_Var.ext while the typical convention is File_Lang_Coun_Var.min.ext Surely considering the ResourceUtils.getMinifiedName() method which does work according to convention. was: I think the ResourceUtils.getLocaleFromFilename(String path) has the order of locale and minimization wrong: It currently parses: File.min_Lang_Coun_Var.ext while the typical convention is File_Lang_Coun_Var.min.ext Surely considering the ResourceUtils.getMinifiedName() method which does work according to convention. I am working on a patch that fixes this. ResourceUtils.getLocaleFromFilename can't handle minimized resources well - Key: WICKET-5966 URL: https://issues.apache.org/jira/browse/WICKET-5966 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.20.0, 7.0.0 Reporter: Martijn Dashorst Fix For: 7.1.0 I think the ResourceUtils.getLocaleFromFilename(String path) has the order of locale and minimization wrong: It currently parses: File.min_Lang_Coun_Var.ext while the typical convention is File_Lang_Coun_Var.min.ext Surely considering the ResourceUtils.getMinifiedName() method which does work according to convention. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-5966) ResourceUtils.getLocaleFromFilename can't handle minimized resources well
[ https://issues.apache.org/jira/browse/WICKET-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-5966: - Fix Version/s: 7.1.0 ResourceUtils.getLocaleFromFilename can't handle minimized resources well - Key: WICKET-5966 URL: https://issues.apache.org/jira/browse/WICKET-5966 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.20.0, 7.0.0 Reporter: Martijn Dashorst Fix For: 7.1.0 I think the ResourceUtils.getLocaleFromFilename(String path) has the order of locale and minimization wrong: It currently parses: File.min_Lang_Coun_Var.ext while the typical convention is File_Lang_Coun_Var.min.ext Surely considering the ResourceUtils.getMinifiedName() method which does work according to convention. I am working on a patch that fixes this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WICKET-5967) Unable to load i18n minified js
Martijn Dashorst created WICKET-5967: Summary: Unable to load i18n minified js Key: WICKET-5967 URL: https://issues.apache.org/jira/browse/WICKET-5967 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 7.0.0, 6.20.0 Reporter: Martijn Dashorst Fix For: 6.21.0, 7.1.0 Wicket doesn't locate i18n minified resources from the class path correctly. When a localization and minification come into play, Wicket only finds the root, minified resource instead of the localized, minified version. E.g. when you want b_nl.min.js (which is on the class path), Wicket will resolve b.min.js instead. Due to a combination of bugs and some changes we haven't yet discerned, Wicket 7.0.0 fails to load a JavaScript file (to be exact: wicket/resource/org.odlabs.wiquery.ui.datepicker.DatePickerLanguageResourceReference/i18n/jquery.ui.datepicker-nl-ver-143823914.js) This issue is one of those bugs, which is present in 6.x but doesn't surface there for a yet unknown reason. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WICKET-5967) Unable to load i18n minified js
[ https://issues.apache.org/jira/browse/WICKET-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-5967: - Description: Wicket doesn't locate i18n minified resources from the class path correctly. When style, variation, i18n and minification come into play, Wicket doesn't find the correct styled, variationed, i18n and minified file. Due to a combination of bugs and some changes we haven't yet discerned, Wicket 7.0.0 fails to load a JavaScript file (to be exact: wicket/resource/org.odlabs.wiquery.ui.datepicker.DatePickerLanguageResourceReference/i18n/jquery.ui.datepicker-nl-ver-143823914.js) This issue is one of those bugs, which is present in 6.x but doesn't surface there for a yet unknown reason. was: Wicket doesn't locate i18n minified resources from the class path correctly. When a localization and minification come into play, Wicket only finds the root, minified resource instead of the localized, minified version. E.g. when you want b_nl.min.js (which is on the class path), Wicket will resolve b.min.js instead. Due to a combination of bugs and some changes we haven't yet discerned, Wicket 7.0.0 fails to load a JavaScript file (to be exact: wicket/resource/org.odlabs.wiquery.ui.datepicker.DatePickerLanguageResourceReference/i18n/jquery.ui.datepicker-nl-ver-143823914.js) This issue is one of those bugs, which is present in 6.x but doesn't surface there for a yet unknown reason. Unable to load i18n minified js --- Key: WICKET-5967 URL: https://issues.apache.org/jira/browse/WICKET-5967 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.20.0, 7.0.0 Reporter: Martijn Dashorst Fix For: 6.21.0, 7.1.0 Wicket doesn't locate i18n minified resources from the class path correctly. When style, variation, i18n and minification come into play, Wicket doesn't find the correct styled, variationed, i18n and minified file. Due to a combination of bugs and some changes we haven't yet discerned, Wicket 7.0.0 fails to load a JavaScript file (to be exact: wicket/resource/org.odlabs.wiquery.ui.datepicker.DatePickerLanguageResourceReference/i18n/jquery.ui.datepicker-nl-ver-143823914.js) This issue is one of those bugs, which is present in 6.x but doesn't surface there for a yet unknown reason. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WICKET-5960) Page header isn't rendered for pages where URL has changed during render
[
https://issues.apache.org/jira/browse/WICKET-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680052#comment-14680052
]
Martijn Dashorst commented on WICKET-5960:
--
If it fixes the testcase I'm content!
Page header isn't rendered for pages where URL has changed during render
Key: WICKET-5960
URL: https://issues.apache.org/jira/browse/WICKET-5960
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Assignee: Sven Meier
Due to the changes in WICKET-5309, a page is re-rendered when any of the URL
segments is modified during the request:
From WebPageRenderer.java:
{code}
// the url might have changed after page has been rendered (e.g. the
// stateless flag might have changed because stateful components
// were added)
final Url afterRenderUrl = requestCycle
.mapUrlFor(getRenderPageRequestHandler());
if (beforeRenderUrl.getSegments().equals(afterRenderUrl.getSegments())
== false)
{
// the amount of segments is different - generated relative URLs
// will not work, we need to rerender the page. This can happen
// with IRequestHandlers that produce different URLs with
// different amount of segments for stateless and stateful pages
response = renderPage(afterRenderUrl, requestCycle);
}
if (currentUrl.equals(afterRenderUrl))
{code}
The re-render causes the head section to be empty because it was already
rendered in the first try.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (WICKET-5706) ResourceUtils.getLocaleFromFilename cannot handle filenames with classifiers
[
https://issues.apache.org/jira/browse/WICKET-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679850#comment-14679850
]
Martijn Dashorst edited comment on WICKET-5706 at 8/10/15 9:34 AM:
---
I think the ResourceUtils.getLocaleFromFilename(String path) has the order of
locale and minimization wrong:
It currently parses: File.min_Lang_Coun_Var.ext while the typical convention is
File_Lang_Coun_Var.min.ext
Surely considering the ResourceUtils.getMinifiedName() method which does work
according to convention.
I am working on a patch that fixes this, and also makes PathLocale have more
information regarding the filename.
was (Author: dashorst):
I think the ResourceUtils.getLocaleFromFilename(String path) has the order of
locale and minimization wrong:
It currently parses: File.min_Lang_Coun_Var.ext while the typical convention is
File_Lang_Coun_Var.min.ext
ResourceUtils.getLocaleFromFilename cannot handle filenames with classifiers
Key: WICKET-5706
URL: https://issues.apache.org/jira/browse/WICKET-5706
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 6.17.0
Reporter: Tamas Szendrei
Assignee: Martin Grigorov
Fix For: 6.18.0, 7.0.0-M4
When I try to get PathLocale with ResourceUtils, than get wrong values, when
the files contains '.' in name.
Example: 'jquery.test.js'
PathLocale.path=jquery, PathLocale.locale = null
or jquery.test_hu.js'.
PathLocale.path=jquery, PathLocale.locale = null
That's why I'd like to use
jquery.test_hu.js' as resource, the ResourceStreamLocator try to find
jquery.test_hu_hu_HU.js, jquery.test_hu_hu.js, and after jquery.test_hu.js.
Because the
ResourceStreamLocator.locate
PathLocale data = ResourceUtils.getLocaleFromFilename(path);
if ((data != null) (data.locale != null))
{
path = data.path;
locale = data.locale;
}
doesn't work in this case.
Should change the
ResourceUtils
public static PathLocale getLocaleFromFilename(String path) {
int pos = path.indexOf('.');
To
int pos = path.lastIndexOf('.');
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WICKET-5966) ResourceUtils.getLocaleFromFilename can't handle minimized resources well
Martijn Dashorst created WICKET-5966: Summary: ResourceUtils.getLocaleFromFilename can't handle minimized resources well Key: WICKET-5966 URL: https://issues.apache.org/jira/browse/WICKET-5966 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 7.0.0, 6.20.0 Reporter: Martijn Dashorst I think the ResourceUtils.getLocaleFromFilename(String path) has the order of locale and minimization wrong: It currently parses: File.min_Lang_Coun_Var.ext while the typical convention is File_Lang_Coun_Var.min.ext Surely considering the ResourceUtils.getMinifiedName() method which does work according to convention. I am working on a patch that fixes this, and also makes PathLocale have more information regarding the filename. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (WICKET-5706) ResourceUtils.getLocaleFromFilename cannot handle filenames with classifiers
[
https://issues.apache.org/jira/browse/WICKET-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst reopened WICKET-5706:
--
I think the ResourceUtils.getLocaleFromFilename(String path) has the order of
locale and minimization wrong:
It currently parses: File.min_Lang_Coun_Var.ext while the typical convention is
File_Lang_Coun_Var.min.ext
ResourceUtils.getLocaleFromFilename cannot handle filenames with classifiers
Key: WICKET-5706
URL: https://issues.apache.org/jira/browse/WICKET-5706
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 6.17.0
Reporter: Tamas Szendrei
Assignee: Martin Grigorov
Fix For: 6.18.0, 7.0.0-M4
When I try to get PathLocale with ResourceUtils, than get wrong values, when
the files contains '.' in name.
Example: 'jquery.test.js'
PathLocale.path=jquery, PathLocale.locale = null
or jquery.test_hu.js'.
PathLocale.path=jquery, PathLocale.locale = null
That's why I'd like to use
jquery.test_hu.js' as resource, the ResourceStreamLocator try to find
jquery.test_hu_hu_HU.js, jquery.test_hu_hu.js, and after jquery.test_hu.js.
Because the
ResourceStreamLocator.locate
PathLocale data = ResourceUtils.getLocaleFromFilename(path);
if ((data != null) (data.locale != null))
{
path = data.path;
locale = data.locale;
}
doesn't work in this case.
Should change the
ResourceUtils
public static PathLocale getLocaleFromFilename(String path) {
int pos = path.indexOf('.');
To
int pos = path.lastIndexOf('.');
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (WICKET-5706) ResourceUtils.getLocaleFromFilename cannot handle filenames with classifiers
[
https://issues.apache.org/jira/browse/WICKET-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst closed WICKET-5706.
Resolution: Fixed
ResourceUtils.getLocaleFromFilename cannot handle filenames with classifiers
Key: WICKET-5706
URL: https://issues.apache.org/jira/browse/WICKET-5706
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 6.17.0
Reporter: Tamas Szendrei
Assignee: Martin Grigorov
Fix For: 7.0.0-M4, 6.18.0
When I try to get PathLocale with ResourceUtils, than get wrong values, when
the files contains '.' in name.
Example: 'jquery.test.js'
PathLocale.path=jquery, PathLocale.locale = null
or jquery.test_hu.js'.
PathLocale.path=jquery, PathLocale.locale = null
That's why I'd like to use
jquery.test_hu.js' as resource, the ResourceStreamLocator try to find
jquery.test_hu_hu_HU.js, jquery.test_hu_hu.js, and after jquery.test_hu.js.
Because the
ResourceStreamLocator.locate
PathLocale data = ResourceUtils.getLocaleFromFilename(path);
if ((data != null) (data.locale != null))
{
path = data.path;
locale = data.locale;
}
doesn't work in this case.
Should change the
ResourceUtils
public static PathLocale getLocaleFromFilename(String path) {
int pos = path.indexOf('.');
To
int pos = path.lastIndexOf('.');
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WICKET-5966) ResourceUtils.getLocaleFromFilename can't handle minimized resources well
[ https://issues.apache.org/jira/browse/WICKET-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated WICKET-5966: - Description: I think the ResourceUtils.getLocaleFromFilename(String path) has the order of locale and minimization wrong: It currently parses: File.min_Lang_Coun_Var.ext while the typical convention is File_Lang_Coun_Var.min.ext Surely considering the ResourceUtils.getMinifiedName() method which does work according to convention. I am working on a patch that fixes this. was: I think the ResourceUtils.getLocaleFromFilename(String path) has the order of locale and minimization wrong: It currently parses: File.min_Lang_Coun_Var.ext while the typical convention is File_Lang_Coun_Var.min.ext Surely considering the ResourceUtils.getMinifiedName() method which does work according to convention. I am working on a patch that fixes this, and also makes PathLocale have more information regarding the filename. ResourceUtils.getLocaleFromFilename can't handle minimized resources well - Key: WICKET-5966 URL: https://issues.apache.org/jira/browse/WICKET-5966 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.20.0, 7.0.0 Reporter: Martijn Dashorst I think the ResourceUtils.getLocaleFromFilename(String path) has the order of locale and minimization wrong: It currently parses: File.min_Lang_Coun_Var.ext while the typical convention is File_Lang_Coun_Var.min.ext Surely considering the ResourceUtils.getMinifiedName() method which does work according to convention. I am working on a patch that fixes this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WICKET-5961) Wicket1.5 TreeTable can't find markup
[
https://issues.apache.org/jira/browse/WICKET-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659899#comment-14659899
]
Martijn Dashorst commented on WICKET-5961:
--
I've bisected Wicket and this issue, and the regression was introduced by
removing 'old wicket 1.4-1.5' migration code from
DefaultMarkupSourcingStrategy in commit
https://github.com/apache/wicket/commit/f89b15618243075f8a8e90cb826550af525dabb7,
that actually had one side effect on line 123 of the diff:
{code}
// The LoopItems markup is equal to the Loops markup
markup = container.getMarkup();
{code}
Reintroducing this old behaviour into DefaultMarkupSourcingStrategy solves the
problem from the TreeTableItem, but lets two test cases in Wicket 7 fail:
1. MarkupFragmentTest.panel
2. MarkupFragmentTest.panelWithAutoComponent
Both with the following failure:
{code}
java.lang.AssertionError: expected null, but
was:file:/Users/dashorst/Workspaces/wicket7/wicket/wicket-core/target/test-classes/org/apache/wicket/markupFragments/MyPage.html
!--
Licensed 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.
--
html xmlns:wicket
head/headbody
span wicket:id=labeltext/span
span wicket:id=containertext/span
/body
/html
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotNull(Assert.java:755)
at org.junit.Assert.assertNull(Assert.java:737)
at org.junit.Assert.assertNull(Assert.java:747)
at
org.apache.wicket.markupFragments.MarkupFragmentTest.panel(MarkupFragmentTest.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
{code}
This assertion fails:
{code}
// The Page is missing the tag to call the panel
assertNull(panel.getMarkup());
{code}
Wicket1.5 TreeTable can't find markup
-
Key: WICKET-5961
URL: https://issues.apache.org/jira/browse/WICKET-5961
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
The recently moved TreeTable can't find its markup (for a TreeTableItem):
{code}
org.apache.wicket.markup.MarkupNotFoundException: Markup not found
[jira] [Created] (WICKET-5961) Wicket1.5 TreeTable can't find markup
Martijn Dashorst created WICKET-5961:
Summary: Wicket1.5 TreeTable can't find markup
Key: WICKET-5961
URL: https://issues.apache.org/jira/browse/WICKET-5961
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
The recently moved TreeTable can't find its markup (for a TreeTableItem):
{code}
org.apache.wicket.markup.MarkupNotFoundException: Markup not found for
Component: [TreeTableItem [Component id = 0]]
at org.apache.wicket.Component.internalRender(Component.java:2347)
at org.apache.wicket.Component.render(Component.java:2307)
at
org.apache.wicket.extensions.markup.html.tree.table.SideColumnsView.onRender(SideColumnsView.java:103)
at org.apache.wicket.Component.internalRender(Component.java:2379)
at org.apache.wicket.Component.render(Component.java:2307)
at
org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1407)
at
org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1604)
at
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1579)
at
org.apache.wicket.MarkupContainer.renderAssociatedMarkup(MarkupContainer.java:691)
at
org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderAssociatedMarkup(AssociatedMarkupSourcingStrategy.java:77)
at
org.apache.wicket.markup.html.panel.PanelMarkupSourcingStrategy.onComponentTagBody(PanelMarkupSourcingStrategy.java:112)
at
org.apache.wicket.Component.internalRenderComponent(Component.java:2564)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1543)
at org.apache.wicket.Component.internalRender(Component.java:2379)
at org.apache.wicket.Component.render(Component.java:2307)
at
org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1407)
at
org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1604)
at org.apache.wicket.Page.onRender(Page.java:879)
at org.apache.wicket.markup.html.WebPage.onRender(WebPage.java:141)
at org.apache.wicket.Component.internalRender(Component.java:2379)
at org.apache.wicket.Component.render(Component.java:2307)
at org.apache.wicket.Page.renderPage(Page.java:1018)
at
org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:124)
at
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:236)
at
org.apache.wicket.util.tester.BaseWicketTester$LastPageRecordingPageRendererProvider$1.respond(BaseWicketTester.java:2745)
at
org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:865)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
at
org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:718)
at
org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:657)
at
org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:629)
at
org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:1262)
at
org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:1235)
at
org.apache.wicket.extensions.markup.html.tree.HomePageTest.homepageRenders(HomePageTest.java:10)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at
[jira] [Commented] (WICKET-5933) Avoid serialization of untouched page after ajax request
[
https://issues.apache.org/jira/browse/WICKET-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14653578#comment-14653578
]
Martijn Dashorst commented on WICKET-5933:
--
It is marked as unresolved.
Avoid serialization of untouched page after ajax request
Key: WICKET-5933
URL: https://issues.apache.org/jira/browse/WICKET-5933
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 6.19.0, 7.0.0-M6, 7.0.0
Reporter: Fridolin Jackstadt
Assignee: Andrea Del Bene
Fix For: 6.21.0, 7.1.0
Attachments: dirtycheck.tar.gz, wicket-5933.patch, wicket-touch.zip
We run into a disc and cpu bottleneck on a wicket page with 1+ users,
that uses ajax updates via polling (AjaxSelfUpdatingTimerBehavior).
The result of our investigation is that page store needs about 10ms for
serialization, while the framework serializes the same data again and again.
Our application doesn't touch the page, but the AbstractPageManager does:
{noformat}
IManageablePage page = getRequestAdapter().getPage(id);
if (page != null)
{
getRequestAdapter().touch(page);
}
{noformat}
Therefore the requested page is always touched, but we couldn't figure out
why. If it's possbile not to touch the page here (in some cases) that would
solve the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WICKET-5933) Avoid serialization of untouched page after ajax request
[
https://issues.apache.org/jira/browse/WICKET-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst updated WICKET-5933:
-
Fix Version/s: (was: 7.0.0)
7.1.0
Avoid serialization of untouched page after ajax request
Key: WICKET-5933
URL: https://issues.apache.org/jira/browse/WICKET-5933
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 6.19.0, 7.0.0-M6
Reporter: Fridolin Jackstadt
Assignee: Andrea Del Bene
Fix For: 6.21.0, 7.1.0
Attachments: dirtycheck.tar.gz, wicket-5933.patch, wicket-touch.zip
We run into a disc and cpu bottleneck on a wicket page with 1+ users,
that uses ajax updates via polling (AjaxSelfUpdatingTimerBehavior).
The result of our investigation is that page store needs about 10ms for
serialization, while the framework serializes the same data again and again.
Our application doesn't touch the page, but the AbstractPageManager does:
{noformat}
IManageablePage page = getRequestAdapter().getPage(id);
if (page != null)
{
getRequestAdapter().touch(page);
}
{noformat}
Therefore the requested page is always touched, but we couldn't figure out
why. If it's possbile not to touch the page here (in some cases) that would
solve the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WICKET-5933) Avoid serialization of untouched page after ajax request
[
https://issues.apache.org/jira/browse/WICKET-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst updated WICKET-5933:
-
Affects Version/s: 7.0.0
Avoid serialization of untouched page after ajax request
Key: WICKET-5933
URL: https://issues.apache.org/jira/browse/WICKET-5933
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 6.19.0, 7.0.0-M6, 7.0.0
Reporter: Fridolin Jackstadt
Assignee: Andrea Del Bene
Fix For: 6.21.0, 7.1.0
Attachments: dirtycheck.tar.gz, wicket-5933.patch, wicket-touch.zip
We run into a disc and cpu bottleneck on a wicket page with 1+ users,
that uses ajax updates via polling (AjaxSelfUpdatingTimerBehavior).
The result of our investigation is that page store needs about 10ms for
serialization, while the framework serializes the same data again and again.
Our application doesn't touch the page, but the AbstractPageManager does:
{noformat}
IManageablePage page = getRequestAdapter().getPage(id);
if (page != null)
{
getRequestAdapter().touch(page);
}
{noformat}
Therefore the requested page is always touched, but we couldn't figure out
why. If it's possbile not to touch the page here (in some cases) that would
solve the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WICKET-5960) Page header isn't rendered for pages where URL has changed during render
Martijn Dashorst created WICKET-5960:
Summary: Page header isn't rendered for pages where URL has
changed during render
Key: WICKET-5960
URL: https://issues.apache.org/jira/browse/WICKET-5960
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Due to the changes in WICKET-5309, a page is re-rendered when any of the URL
segments is modified during the request:
From WebPageRenderer.java:
{code}
// the url might have changed after page has been rendered (e.g. the
// stateless flag might have changed because stateful components
// were added)
final Url afterRenderUrl = requestCycle
.mapUrlFor(getRenderPageRequestHandler());
if (beforeRenderUrl.getSegments().equals(afterRenderUrl.getSegments())
== false)
{
// the amount of segments is different - generated relative URLs
// will not work, we need to rerender the page. This can happen
// with IRequestHandlers that produce different URLs with
// different amount of segments for stateless and stateful pages
response = renderPage(afterRenderUrl, requestCycle);
}
if (currentUrl.equals(afterRenderUrl))
{code}
The re-render causes the head section to be empty because it was already
rendered in the first try.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WICKET-5947) AjaxPagingNavigationLink throws exception that Behavior is not enabled
[
https://issues.apache.org/jira/browse/WICKET-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14620591#comment-14620591
]
Martijn Dashorst commented on WICKET-5947:
--
Correct: I didn't have two tabs open. I'm currently trying to craft a
quickstart for this issue, because bisecting with an app of 1.2M lines of code
is not fun.
AjaxPagingNavigationLink throws exception that Behavior is not enabled
--
Key: WICKET-5947
URL: https://issues.apache.org/jira/browse/WICKET-5947
Project: Wicket
Issue Type: Bug
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Priority: Blocker
When clicking on an AjaxPagingNavigationLink I get the exception below, based
on wicket-7.0.0-SNAPSHOT from yesterday.
{code}
13:12:23,425 WARN [org.apache.wicket.RequestListenerInterface] (default
task-10) behavior not enabled; ignore call. Behavior
org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigationLink$1@2281aefc
at component [AjaxPagingNavigationLink [Component id = pageLink]]
13:12:23,431 WARN [RequestCycleExtra] (default task-10)
13:12:23,431 WARN [RequestCycleExtra] (default task-10) Handling the
following exception:
org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
Behavior rejected interface invocation. Component: [AjaxPagingNavigationLink
[Component id = pageLink]] Behavior:
org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigationLink$1@2281aefc
Listener: [RequestListenerInterface name=IBehaviorListener, method=public
abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
at
org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:237)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:865)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
[wicket-request-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:284)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WICKET-5947) AjaxPagingNavigationLink throws exception that Behavior is not enabled
[
https://issues.apache.org/jira/browse/WICKET-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst updated WICKET-5947:
-
Priority: Trivial (was: Blocker)
AjaxPagingNavigationLink throws exception that Behavior is not enabled
--
Key: WICKET-5947
URL: https://issues.apache.org/jira/browse/WICKET-5947
Project: Wicket
Issue Type: Bug
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Priority: Trivial
When clicking on an AjaxPagingNavigationLink I get the exception below, based
on wicket-7.0.0-SNAPSHOT from yesterday.
{code}
13:12:23,425 WARN [org.apache.wicket.RequestListenerInterface] (default
task-10) behavior not enabled; ignore call. Behavior
org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigationLink$1@2281aefc
at component [AjaxPagingNavigationLink [Component id = pageLink]]
13:12:23,431 WARN [RequestCycleExtra] (default task-10)
13:12:23,431 WARN [RequestCycleExtra] (default task-10) Handling the
following exception:
org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
Behavior rejected interface invocation. Component: [AjaxPagingNavigationLink
[Component id = pageLink]] Behavior:
org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigationLink$1@2281aefc
Listener: [RequestListenerInterface name=IBehaviorListener, method=public
abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
at
org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:237)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:865)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
[wicket-request-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:284)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (WICKET-5947) AjaxPagingNavigationLink throws exception that Behavior is not enabled
[
https://issues.apache.org/jira/browse/WICKET-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst resolved WICKET-5947.
--
Resolution: Not A Problem
It appears that the issue is the following:
The drop down choice components are part of a larger filter. Initially the
selection is all students (i.e. 302 pages). The DDCs are only responsible for
updating themselves. When you modify the DDCs to a single school location, the
data table is not updated, but the underlying filter is. So when you click
**far enough** in the paging navigator, the navigator correctly discovers those
links are not available anymore, so the exception is thrown.
The reason I couldn't initially replicate the same behavior in our 6.x version
was the different database, where the number of selected students resulted in
enough navigator pages.
This is a non-issue and works as intended.
AjaxPagingNavigationLink throws exception that Behavior is not enabled
--
Key: WICKET-5947
URL: https://issues.apache.org/jira/browse/WICKET-5947
Project: Wicket
Issue Type: Bug
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Priority: Blocker
When clicking on an AjaxPagingNavigationLink I get the exception below, based
on wicket-7.0.0-SNAPSHOT from yesterday.
{code}
13:12:23,425 WARN [org.apache.wicket.RequestListenerInterface] (default
task-10) behavior not enabled; ignore call. Behavior
org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigationLink$1@2281aefc
at component [AjaxPagingNavigationLink [Component id = pageLink]]
13:12:23,431 WARN [RequestCycleExtra] (default task-10)
13:12:23,431 WARN [RequestCycleExtra] (default task-10) Handling the
following exception:
org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
Behavior rejected interface invocation. Component: [AjaxPagingNavigationLink
[Component id = pageLink]] Behavior:
org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigationLink$1@2281aefc
Listener: [RequestListenerInterface name=IBehaviorListener, method=public
abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
at
org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:237)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:865)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
[wicket-request-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:284)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (WICKET-5947) AjaxPagingNavigationLink throws exception that Behavior is not enabled
[
https://issues.apache.org/jira/browse/WICKET-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst closed WICKET-5947.
AjaxPagingNavigationLink throws exception that Behavior is not enabled
--
Key: WICKET-5947
URL: https://issues.apache.org/jira/browse/WICKET-5947
Project: Wicket
Issue Type: Bug
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Priority: Trivial
When clicking on an AjaxPagingNavigationLink I get the exception below, based
on wicket-7.0.0-SNAPSHOT from yesterday.
{code}
13:12:23,425 WARN [org.apache.wicket.RequestListenerInterface] (default
task-10) behavior not enabled; ignore call. Behavior
org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigationLink$1@2281aefc
at component [AjaxPagingNavigationLink [Component id = pageLink]]
13:12:23,431 WARN [RequestCycleExtra] (default task-10)
13:12:23,431 WARN [RequestCycleExtra] (default task-10) Handling the
following exception:
org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
Behavior rejected interface invocation. Component: [AjaxPagingNavigationLink
[Component id = pageLink]] Behavior:
org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigationLink$1@2281aefc
Listener: [RequestListenerInterface name=IBehaviorListener, method=public
abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
at
org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:237)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:865)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
[wicket-request-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:284)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WICKET-5947) AjaxPagingNavigationLink throws exception that Behavior is not enabled
Martijn Dashorst created WICKET-5947:
Summary: AjaxPagingNavigationLink throws exception that Behavior
is not enabled
Key: WICKET-5947
URL: https://issues.apache.org/jira/browse/WICKET-5947
Project: Wicket
Issue Type: Bug
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Priority: Blocker
When clicking on an AjaxPagingNavigationLink I get the exception below, based
on wicket-7.0.0-SNAPSHOT from yesterday.
{code}
13:12:23,425 WARN [org.apache.wicket.RequestListenerInterface] (default
task-10) behavior not enabled; ignore call. Behavior
org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigationLink$1@2281aefc
at component [AjaxPagingNavigationLink [Component id = pageLink]]
13:12:23,431 WARN [RequestCycleExtra] (default task-10)
13:12:23,431 WARN [RequestCycleExtra] (default task-10) Handling the following
exception:
org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
Behavior rejected interface invocation. Component: [AjaxPagingNavigationLink
[Component id = pageLink]] Behavior:
org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigationLink$1@2281aefc
Listener: [RequestListenerInterface name=IBehaviorListener, method=public
abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
at
org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:237)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:865)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
[wicket-request-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:284)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WICKET-5947) AjaxPagingNavigationLink throws exception that Behavior is not enabled
[
https://issues.apache.org/jira/browse/WICKET-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14620446#comment-14620446
]
Martijn Dashorst commented on WICKET-5947:
--
I don't think the two are the same problem though they look similar. I tried it
in our app with wicket 6.19, and that doesn't fail. So it is specific to
Wicket 7.
The scenario is two DDC's that update their contents through Ajax, and after a
couple of clicks on both DDC's I click on the 3rd AjaxNavigationLink, causing
the reported exception.
AjaxPagingNavigationLink throws exception that Behavior is not enabled
--
Key: WICKET-5947
URL: https://issues.apache.org/jira/browse/WICKET-5947
Project: Wicket
Issue Type: Bug
Affects Versions: 7.0.0
Reporter: Martijn Dashorst
Priority: Blocker
When clicking on an AjaxPagingNavigationLink I get the exception below, based
on wicket-7.0.0-SNAPSHOT from yesterday.
{code}
13:12:23,425 WARN [org.apache.wicket.RequestListenerInterface] (default
task-10) behavior not enabled; ignore call. Behavior
org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigationLink$1@2281aefc
at component [AjaxPagingNavigationLink [Component id = pageLink]]
13:12:23,431 WARN [RequestCycleExtra] (default task-10)
13:12:23,431 WARN [RequestCycleExtra] (default task-10) Handling the
following exception:
org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
Behavior rejected interface invocation. Component: [AjaxPagingNavigationLink
[Component id = pageLink]] Behavior:
org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigationLink$1@2281aefc
Listener: [RequestListenerInterface name=IBehaviorListener, method=public
abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
at
org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:237)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:865)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
[wicket-request-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:284)
[wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
