[jira] [Commented] (WICKET-6311) SignOutPage_ru.html is missing
[ https://issues.apache.org/jira/browse/WICKET-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838541#comment-15838541 ] ASF GitHub Bot commented on WICKET-6311: Github user asfgit closed the pull request at: https://github.com/apache/wicket/pull/206 > SignOutPage_ru.html is missing > -- > > Key: WICKET-6311 > URL: https://issues.apache.org/jira/browse/WICKET-6311 > Project: Wicket > Issue Type: Bug > Components: wicket-auth-roles >Affects Versions: 7.6.0 >Reporter: Maxim Solodovnik >Priority: Trivial > > SignInPage_ru.html present > SignOutPage_ru.html is missing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WICKET-6311) SignOutPage_ru.html is missing
[ https://issues.apache.org/jira/browse/WICKET-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838557#comment-15838557 ] ASF GitHub Bot commented on WICKET-6311: Github user martin-g commented on the issue: https://github.com/apache/wicket/pull/207 I've amended the commit to add 'WICKET-6311' in the message and now the auto-close won't work. @solomax Please close this PR! Thanks! > SignOutPage_ru.html is missing > -- > > Key: WICKET-6311 > URL: https://issues.apache.org/jira/browse/WICKET-6311 > Project: Wicket > Issue Type: Bug > Components: wicket-auth-roles >Affects Versions: 7.6.0 >Reporter: Maxim Solodovnik >Assignee: Martin Grigorov >Priority: Trivial > Fix For: 7.7.0, 8.0.0-M4 > > > SignInPage_ru.html present > SignOutPage_ru.html is missing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WICKET-6311) SignOutPage_ru.html is missing
[ https://issues.apache.org/jira/browse/WICKET-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838959#comment-15838959 ] ASF GitHub Bot commented on WICKET-6311: Github user solomax closed the pull request at: https://github.com/apache/wicket/pull/207 > SignOutPage_ru.html is missing > -- > > Key: WICKET-6311 > URL: https://issues.apache.org/jira/browse/WICKET-6311 > Project: Wicket > Issue Type: Bug > Components: wicket-auth-roles >Affects Versions: 7.6.0 >Reporter: Maxim Solodovnik >Assignee: Martin Grigorov >Priority: Trivial > Fix For: 7.7.0, 8.0.0-M4 > > > SignInPage_ru.html present > SignOutPage_ru.html is missing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WICKET-6289) Autolinking adds onclick attribute to tags
[
https://issues.apache.org/jira/browse/WICKET-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15847666#comment-15847666
]
ASF GitHub Bot commented on WICKET-6289:
Github user martin-g commented on the issue:
https://github.com/apache/wicket/pull/199
@duesenklipper Please close this PR! Thanks!
> Autolinking adds onclick attribute to tags
>
>
> Key: WICKET-6289
> URL: https://issues.apache.org/jira/browse/WICKET-6289
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 7.4.0, 8.0.0-M2, 6.25.0, 1.5.17
>Reporter: Carl-Eric Menzel
>Assignee: Carl-Eric Menzel
> Fix For: 7.6.0, 8.0.0-M3
>
>
> When the autolinker can't find the target of a src or href attribute, it
> falls back to a default autocomponent, that supposedly leaves the tag
> unchanged. Quoting AutolinkResolver:
> {code}
> if (autoComponent == null)
> {
> // resolving didn't have the desired result or there was no delegate
> // found; fallback on the default resolving which is a simple
> // component that leaves the tag unchanged
> autoComponent = new AutolinkExternalLink(componentId,
> pathInfo.reference);
> }
> {code}
> ...except that AutolinkExternalLink is an ExternalLink which is an
> AbstractLink which does change the original tag. Namely, when applied to
> something that is not it adds an onclick attribute. This leads to
> something like the following:
> {code}
> onclick="window.location.href='does-not-exist.png';return false;"/>
> {code}
> ...which is clearly nonsensical. This can happen when the referenced image is
> not in the classpath - it could either be missing, or it could be in the
> webapp root somewhere, which can be the case for some legacy applications.
> (This is how I came across this.)
> A simple fix appears to be to use a plain WebMarkupContainer in place of this
> particular AutolinkExternalLink. All tests pass when I do that.
> This affects all versions from 1.5 on upward. I'll prepare a pull request.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-6286) Would be good to have AjaxDownload available out of the box
[ https://issues.apache.org/jira/browse/WICKET-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15847667#comment-15847667 ] ASF GitHub Bot commented on WICKET-6286: Github user martin-g commented on the issue: https://github.com/apache/wicket/pull/191 @solomax Please close this PR! We will use the solution in https://issues.apache.org/jira/browse/WICKET-6286. Thanks! > Would be good to have AjaxDownload available out of the box > > > Key: WICKET-6286 > URL: https://issues.apache.org/jira/browse/WICKET-6286 > Project: Wicket > Issue Type: New Feature > Components: wicket-extensions >Affects Versions: 8.0.0-M2, 7.5.0 >Reporter: Maxim Solodovnik >Assignee: Sven Meier > Labels: patch > > Currently every project need to create own AjaxDownload component based on > the Wiki example. > Unfortunately this component has some issues with WebSockets > Discussion: http://markmail.org/message/gizsnqh2qgypcgri > PRs: > https://github.com/apache/wicket/pull/190 > https://github.com/apache/wicket/pull/191 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6286) Would be good to have AjaxDownload available out of the box
[ https://issues.apache.org/jira/browse/WICKET-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15847668#comment-15847668 ] ASF GitHub Bot commented on WICKET-6286: Github user martin-g commented on the issue: https://github.com/apache/wicket/pull/190 @solomax Please close this PR! We will use the solution in https://issues.apache.org/jira/browse/WICKET-6286. Thanks! > Would be good to have AjaxDownload available out of the box > > > Key: WICKET-6286 > URL: https://issues.apache.org/jira/browse/WICKET-6286 > Project: Wicket > Issue Type: New Feature > Components: wicket-extensions >Affects Versions: 8.0.0-M2, 7.5.0 >Reporter: Maxim Solodovnik >Assignee: Sven Meier > Labels: patch > > Currently every project need to create own AjaxDownload component based on > the Wiki example. > Unfortunately this component has some issues with WebSockets > Discussion: http://markmail.org/message/gizsnqh2qgypcgri > PRs: > https://github.com/apache/wicket/pull/190 > https://github.com/apache/wicket/pull/191 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6305) Remove Atmosphere module
[ https://issues.apache.org/jira/browse/WICKET-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15847669#comment-15847669 ] ASF GitHub Bot commented on WICKET-6305: Github user martin-g commented on the issue: https://github.com/apache/wicket/pull/160 @payou Please close this PR! Wicket team decided to discontinue the support for Wicket-Atmosphere (see https://issues.apache.org/jira/browse/WICKET-6305). Thanks! > Remove Atmosphere module > > > Key: WICKET-6305 > URL: https://issues.apache.org/jira/browse/WICKET-6305 > Project: Wicket > Issue Type: Task >Affects Versions: 8.0.0-M3 >Reporter: Martin Grigorov >Assignee: Martin Grigorov >Priority: Minor > Fix For: 8.0.0-M4 > > > As agreed at dev@ (http://markmail.org/message/i564t5cxolyne6zq) the > integration with Atmosphere (https://github.com/Atmosphere/atmosphere) won't > be maintained any more in favour of Wicket Native WebSockets. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6286) Would be good to have AjaxDownload available out of the box
[ https://issues.apache.org/jira/browse/WICKET-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15847896#comment-15847896 ] ASF GitHub Bot commented on WICKET-6286: Github user solomax closed the pull request at: https://github.com/apache/wicket/pull/191 > Would be good to have AjaxDownload available out of the box > > > Key: WICKET-6286 > URL: https://issues.apache.org/jira/browse/WICKET-6286 > Project: Wicket > Issue Type: New Feature > Components: wicket-extensions >Affects Versions: 8.0.0-M2, 7.5.0 >Reporter: Maxim Solodovnik >Assignee: Sven Meier > Labels: patch > > Currently every project need to create own AjaxDownload component based on > the Wiki example. > Unfortunately this component has some issues with WebSockets > Discussion: http://markmail.org/message/gizsnqh2qgypcgri > PRs: > https://github.com/apache/wicket/pull/190 > https://github.com/apache/wicket/pull/191 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6286) Would be good to have AjaxDownload available out of the box
[ https://issues.apache.org/jira/browse/WICKET-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15847897#comment-15847897 ] ASF GitHub Bot commented on WICKET-6286: Github user solomax closed the pull request at: https://github.com/apache/wicket/pull/190 > Would be good to have AjaxDownload available out of the box > > > Key: WICKET-6286 > URL: https://issues.apache.org/jira/browse/WICKET-6286 > Project: Wicket > Issue Type: New Feature > Components: wicket-extensions >Affects Versions: 8.0.0-M2, 7.5.0 >Reporter: Maxim Solodovnik >Assignee: Sven Meier > Labels: patch > > Currently every project need to create own AjaxDownload component based on > the Wiki example. > Unfortunately this component has some issues with WebSockets > Discussion: http://markmail.org/message/gizsnqh2qgypcgri > PRs: > https://github.com/apache/wicket/pull/190 > https://github.com/apache/wicket/pull/191 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-5847) Support for nested properties keys in translations
[
https://issues.apache.org/jira/browse/WICKET-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848769#comment-15848769
]
ASF GitHub Bot commented on WICKET-5847:
Github user robsonke closed the pull request at:
https://github.com/apache/wicket/pull/103
> Support for nested properties keys in translations
> --
>
> Key: WICKET-5847
> URL: https://issues.apache.org/jira/browse/WICKET-5847
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
>Affects Versions: 7.0.0-M5
>Reporter: Rob Sonke
>Assignee: Sven Meier
>Priority: Minor
> Attachments: i18nresolver.zip, keyreplacelocalizer.patch,
> screenshot-1.png
>
>
> I wrote an extended version of the Localizer class to support properties like:
> {code}
> lbl.test=This is a string including this ${lbl.other} test
> lbl.other=nested property
> {code}
> Based on this discussion:
> http://apache-wicket.1842946.n4.nabble.com/Resolving-nested-properties-td4669681.html
> It would be nice if this can be added to Wicket core to support this. Then
> developers can easily choose to use this one or not. By default the existing
> Localizer is used.
> I've attached a patch file based on today's master branch which includes the
> new class and some junit tests. Apart from that I attached a zipped
> quickstart that shows the use. Please be aware that I added the new class as
> a copy in that project on the same package as in the real Wicket jar.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-4201) IPageProvider and its implementations need to be improved
[
https://issues.apache.org/jira/browse/WICKET-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15856856#comment-15856856
]
ASF GitHub Bot commented on WICKET-4201:
Github user martin-g commented on a diff in the pull request:
https://github.com/apache/wicket/pull/210#discussion_r99936172
--- Diff:
wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java
---
@@ -197,26 +194,49 @@ else if (isNewPageInstance() == false)
}
/**
-* The page instance is new only if there is no cached instance or the
data stores doesn't have
-* a page with that id with the same {@linkplain #pageClass}.
-*
-* @see IPageProvider#isNewPageInstance()
+* @return negates {@link PageProvider#hasPageInstance()}
+* @deprecated use {@link PageProvider#hasPageInstance()} negation
instead
*/
@Override
public boolean isNewPageInstance()
{
- boolean isNew = pageInstance == null;
- if (isNew && pageId != null)
+ return !hasPageInstance();
+ }
+
+ /**
+* If this provider returns existing page, regardless if it was already
created by PageProvider
+* itself or is or can be found in the data store. The only guarantee
is that by calling
+* {@link PageProvider#getPageInstance()} this provider will return an
existing instance and no
+* page will be created.
+*
+* @return if provides an existing page
+*/
+ @Override
+ public final boolean hasPageInstance()
+ {
+ if (provision != null || pageId != null)
{
- IRequestablePage storedPageInstance =
getStoredPage(pageId);
- if (storedPageInstance != null)
- {
- pageInstance = storedPageInstance;
- isNew = false;
- }
+ return getProvision().didResolveToPage();
}
+ else
+ return false;
+ }
- return isNew;
+ /**
+* Returns whether or not the page instance held by this provider has
been instantiated by the
+* provider.
+*
+* @return {@code true} iff the page instance held by this provider was
instantiated by the
+* provider
+*/
+ @Override
+ public final boolean doesProvideNewPage()
+ {
+ if (provision == null)
+ {
+ throw new IllegalStateException("Page instance not yet
resolved");
--- End diff --
This doesn't look nice.
At
https://issues.apache.org/jira/browse/WICKET-4201?focusedCommentId=15853108&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15853108
you say
` removed the PageExpiredException from PageProvider since it breaks the
class coherence. It's designed to provide pages and related metadata (such as
if the page was expired included), not to change the application flow on
application exceptions.` but this runtime exception does exactly this.
IMO it would be better to return a three state result: `NEW`, `OLD` and
`UNKNOWN`
> IPageProvider and its implementations need to be improved
> -
>
> Key: WICKET-4201
> URL: https://issues.apache.org/jira/browse/WICKET-4201
> Project: Wicket
> Issue Type: Task
> Components: wicket
>Affects Versions: 1.5.0, 1.5.1, 1.5.2
>Reporter: Emond Papegaaij
>Assignee: Pedro Santos
>
> During the development op 1.5, IPageProvider and its implementations have
> become a bit of a mess. The interface is not clearly defined. One of the
> biggest problems is that several methods can throw exceptions and there is no
> way of knowing which method will throw which exception and when. It should
> always be clear what exceptions to expect. For example, getPage can throw a
> PageExpiredException, but getPageClass cannot, it should return null if no
> page class is set. Perhaps, it's even better to never throw exceptions at
> all. Also, the various introspection methods are not very well defined and
> make it almost impossible to come up with an alternative implementation of
> the interface (which, IMHO is a sign of a broken API).
> Changing this interface is not an option for 1.5, but looking at the number
> of subtle bugs that came from this part of the code, it should really be
> considered for wicket.next.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-5247) Broken Link in Tomcat because of Page Mount
[
https://issues.apache.org/jira/browse/WICKET-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15856928#comment-15856928
]
ASF GitHub Bot commented on WICKET-5247:
Github user martin-g commented on a diff in the pull request:
https://github.com/apache/wicket/pull/210#discussion_r99945970
--- Diff:
wicket-core/src/test/java/org/apache/wicket/core/request/mapper/MountedMapperTest.java
---
@@ -714,7 +714,7 @@ public boolean isNewPageInstance()
@Test
public void placeholderEncode4()
{
- PageProvider provider = new PageProvider(new MockPage())
+ PageProvider provider = new PageProvider(MockPage.class)
--- End diff --
I didn't understand you.
```java
/**
* WICKET-5247 page instantiated without required parameters won't be
mapped
*/
@Test
public void placeholderEncode4()
{
PageProvider provider = new PageProvider(new MockPage())
{
@Override
public boolean isNewPageInstance()
{
return false;
}
};
provider.setPageSource(context);
IRequestHandler handler = new
RenderPageRequestHandler(provider);
Url url = placeholderEncoder.mapHandler(handler);
assertNull(url);
}
```
The test setups a PageProvider and uses it. There is no replacement after.
By making this change I think we don't test the same as what broke in
WICKET-5247.
> Broken Link in Tomcat because of Page Mount
> ---
>
> Key: WICKET-5247
> URL: https://issues.apache.org/jira/browse/WICKET-5247
> Project: Wicket
> Issue Type: Bug
> Components: wicket-quickstart
>Affects Versions: 6.8.0
> Environment: Tomcat 7.0.41
>Reporter: Martin Wischnewski
>Assignee: Sven Meier
>Priority: Minor
> Fix For: 6.9.0, 1.5.11, 7.0.0-M1
>
> Attachments: quickstart.zip, webapp.war
>
>
> I post this message on the user mailing List
> (http://apache-wicket.1842946.n4.nabble.com/Broken-Link-in-Tomcat-because-of-Page-Mount-tt4659663.html)
> and Martin Grigorov asked me, to create a ticket on Jira.
> Broken Link in Tomcat because of Page Mount
> Following situation:
> -I have a Wicket Application(6.8.0) which runs under the context "webapp" on
> a Tomcat 7.0.41
> -I mount a Page with two parameters (this is important) in the
> WicketApplication.
> mountPage("/mount/${parameter1}/${parameter2}", MountedPage.class);
> -The mounted Page(MountedPage.class) has only a simple Link
> -There are two links on the HomePage to the mounted Page.
> They are declared as follows:
>
> add(new Link("link") {
> @Override
> public void onClick() {
> setResponsePage(MountedPage.class,
> linkParameters);
> }
> });
> add(new Link("brokenLink") {
> @Override
> public void onClick() {
> setResponsePage(new
> MountedPage(linkParameters));
> }
> });
>
> I deploy this Application as a war file on a Tomcat under the context
> "webapp".
> When I call the first Link on the HomePage and then the Link on the mounted
> Page, everything works fine.
> But if I call the second Link and then the Link on the mounted Page, the link
> is broken.
> The context is missing in the generated link
> http://localhost:8080/wicket/bookmarkable/com.mycompany.LinkedPage
> Does anyone have an idea, why the second link does not work on Tomcat?
> I add a Quickstart and the war file as attachment.
> Ps: Both links works fine in Jetty.
> Pss:If I remove the mount command, both links will work in Tomcat too.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-6177) Blocking page serialization
[ https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15862618#comment-15862618 ] ASF GitHub Bot commented on WICKET-6177: GitHub user manuelbarzi opened a pull request: https://github.com/apache/wicket/pull/212 WICKET-6177 Blocking page serialization from https://issues.apache.org/jira/browse/WICKET-6177 **AsyncPageStore** adds the capability to provide an asynchronous page storing by wrapping the original sync page store (e.g. DefaultPageStore) and handling store requests in a queue and storing pages in worker thread which makes use of the original store. The number of pages to be managed asynchronously is defined by a capacity, provided by estimation which should be done on each specific application where applied. The aim of AsyncPageStore is to unblock page requests when serialization process takes 'too long', giving the user the sensation of 'slow web'. This could happen in applications that for any reason delay on backing up pages by means of the current default wicket store. It adds the chance to manage a preset number of pages asynchronously, defined by the 'capacity', and in case that limit is exceeded by requests, it just works as the original sync page store, by simply delegating work on it until the queue is released and space is done to handle pages in asynchronous way again. It acts in a way like saying "let's handle storing of pages asynchronously for an estimated number of them in 'normal conditions', and in case there is an excess of pages to store (peak of requests), that is, exceeding async store 'capacity', then let's just work as normally. **AsyncPageStoreTest** provides initial on/off cases with the scenarios in which async page store works in 'normal conditions' (not exceeding capacity), and the opposite (arriving at a point of exceeding that capacity). original code is already 'gutted' in a **quickstart** for inspection and testing in https://github.com/manuelbarzi/wicket-async-page-store for further details on this projection, just following the first link above. You can merge this pull request into a Git repository by running: $ git pull https://github.com/manuelbarzi/wicket master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/212.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #212 commit 2ffd587dea4c5e1edec0853f35a9b5761e391917 Author: manuelbarzi Date: 2017-02-12T01:23:40Z WICKET-6177 Blocking page serialization > Blocking page serialization > --- > > Key: WICKET-6177 > URL: https://issues.apache.org/jira/browse/WICKET-6177 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.4.0 > Environment: any >Reporter: Martin Makundi > Labels: serialization > Attachments: 6177.tgz, Wicket_Quickstart_7.zip > > Original Estimate: 168h > Remaining Estimate: 168h > > We have a performance issue with our Wicket app, page serialization causes > inconvenience to user because PageStoreManager.storeTouchedPages() blocks the > request until pageSerializer.serialize(page) has been handled. > Could this be solved by serializing the page in a separate thread and let the > request complete? > The problem we have is that user is making quick small ajax modifications to > the page but serialization + network latency makes the delay very > inconvenient. If serialization could be done in separate thread, user would > feel only the network delay which is bearable. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6177) Blocking page serialization
[ https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15862819#comment-15862819 ] ASF GitHub Bot commented on WICKET-6177: Github user bitstorm commented on the issue: https://github.com/apache/wicket/pull/212 Hi @manuelbarzi thank you for you PR. I see you added Guava as dependency but I don't see any point where you use it. Am I missing something? > Blocking page serialization > --- > > Key: WICKET-6177 > URL: https://issues.apache.org/jira/browse/WICKET-6177 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.4.0 > Environment: any >Reporter: Martin Makundi > Labels: serialization > Attachments: 6177.tgz, Wicket_Quickstart_7.zip > > Original Estimate: 168h > Remaining Estimate: 168h > > We have a performance issue with our Wicket app, page serialization causes > inconvenience to user because PageStoreManager.storeTouchedPages() blocks the > request until pageSerializer.serialize(page) has been handled. > Could this be solved by serializing the page in a separate thread and let the > request complete? > The problem we have is that user is making quick small ajax modifications to > the page but serialization + network latency makes the delay very > inconvenient. If serialization could be done in separate thread, user would > feel only the network delay which is bearable. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6177) Blocking page serialization
[ https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15862988#comment-15862988 ] ASF GitHub Bot commented on WICKET-6177: Github user manuelbarzi commented on the issue: https://github.com/apache/wicket/pull/212 ciao @bitstorm yes, indeed, guava and commons-lang3, both for test purposes - test scope / pom - in AsyncPageStoreTest, making use of com.google.common.base.Stopwatch and org.apache.commons.lang3.RandomUtils, respectively. > Blocking page serialization > --- > > Key: WICKET-6177 > URL: https://issues.apache.org/jira/browse/WICKET-6177 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.4.0 > Environment: any >Reporter: Martin Makundi > Labels: serialization > Attachments: 6177.tgz, Wicket_Quickstart_7.zip > > Original Estimate: 168h > Remaining Estimate: 168h > > We have a performance issue with our Wicket app, page serialization causes > inconvenience to user because PageStoreManager.storeTouchedPages() blocks the > request until pageSerializer.serialize(page) has been handled. > Could this be solved by serializing the page in a separate thread and let the > request complete? > The problem we have is that user is making quick small ajax modifications to > the page but serialization + network latency makes the delay very > inconvenient. If serialization could be done in separate thread, user would > feel only the network delay which is bearable. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6177) Blocking page serialization
[ https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15863029#comment-15863029 ] ASF GitHub Bot commented on WICKET-6177: Github user bitstorm commented on the issue: https://github.com/apache/wicket/pull/212 ciao @manuelbarzi , my fault, I'm not very familiar with Guava and its package naming. > Blocking page serialization > --- > > Key: WICKET-6177 > URL: https://issues.apache.org/jira/browse/WICKET-6177 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.4.0 > Environment: any >Reporter: Martin Makundi > Labels: serialization > Attachments: 6177.tgz, Wicket_Quickstart_7.zip > > Original Estimate: 168h > Remaining Estimate: 168h > > We have a performance issue with our Wicket app, page serialization causes > inconvenience to user because PageStoreManager.storeTouchedPages() blocks the > request until pageSerializer.serialize(page) has been handled. > Could this be solved by serializing the page in a separate thread and let the > request complete? > The problem we have is that user is making quick small ajax modifications to > the page but serialization + network latency makes the delay very > inconvenient. If serialization could be done in separate thread, user would > feel only the network delay which is bearable. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6320) Minor Fixes to 8.X Documentation
[
https://issues.apache.org/jira/browse/WICKET-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873050#comment-15873050
]
ASF GitHub Bot commented on WICKET-6320:
GitHub user tflem opened a pull request:
https://github.com/apache/wicket/pull/213
WICKET-6320 - Minor Fixes to 8.X Documentation - Why Learn, Contribution,
and Hello World Sections
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tflem/wicket master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/wicket/pull/213.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #213
commit 77602c0deba29966e17beba8451de6046e5e6acc
Author: Tim Fleming
Date: 2017-02-18T06:15:28Z
Minor fixes to guide documentation
commit 4bfe38a840784a1ef1b6c919fc94a64cd0ffdf3e
Author: Tim Fleming
Date: 2017-02-18T08:01:48Z
Minor guide fixes
> Minor Fixes to 8.X Documentation
>
>
> Key: WICKET-6320
> URL: https://issues.apache.org/jira/browse/WICKET-6320
> Project: Wicket
> Issue Type: Improvement
> Components: guide
>Affects Versions: 8.0.0-M1
> Environment: Linux-Debian Jessie
>Reporter: Tim Fleming
>Assignee: Andrea Del Bene
>Priority: Minor
>
> Within the "Why Learn" section of the 8.x docs, fixed a few typos ("them"
> instead of "theme" and "tasks" instead of "task") and made other minor
> changes for better word flow and clarity. Additionally, fixed a typo within
> the "Contributing" doc. ("Apache" instead of "Apacke").
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-6320) Minor Fixes to 8.X Documentation
[
https://issues.apache.org/jira/browse/WICKET-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873085#comment-15873085
]
ASF GitHub Bot commented on WICKET-6320:
Github user asfgit closed the pull request at:
https://github.com/apache/wicket/pull/213
> Minor Fixes to 8.X Documentation
>
>
> Key: WICKET-6320
> URL: https://issues.apache.org/jira/browse/WICKET-6320
> Project: Wicket
> Issue Type: Improvement
> Components: guide
>Affects Versions: 8.0.0-M1
> Environment: Linux-Debian Jessie
>Reporter: Tim Fleming
>Assignee: Andrea Del Bene
>Priority: Minor
>
> Within the "Why Learn" section of the 8.x docs, fixed a few typos ("them"
> instead of "theme" and "tasks" instead of "task") and made other minor
> changes for better word flow and clarity. Additionally, fixed a typo within
> the "Contributing" doc. ("Apache" instead of "Apacke").
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-6177) Blocking page serialization
[
https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873999#comment-15873999
]
ASF GitHub Bot commented on WICKET-6177:
Github user mmakundi commented on the issue:
https://github.com/apache/wicket/pull/212
Thanks @manuelbarzi and Some findings:
1. I would remove the (non-Javadoc) and instead format those with
start-prefix /** like true javadoc and remove extra empty lines in the javadoc
2. All in all check for formatting and extra lines etc.
3. In case entries.offer fails, entryMap.remove is called before
pageStore.storePage. If we assume pageStore.storePage is slow, maybe it would
be good idea to postpone remove so that a new requiest during
pageStore.storePage can use the in-memory reference? Similar to what is
happening in PageSavingRunnable.run? Also this will make a great re-usable
method:
storePageAndRemoveFromMap(...) {
log.debug("Saving asynchronously: {}...", entry);
pageStore.storePage(sessionId, page);
entryMap.remove(getKey(entry));
}
4. Same as in (3.) to catch (InterruptedException e) {
log.error(e.getMessage(), e);; storePageAndRemoveFromMap(...); }
5. Please junit-test if any conflict occur if unbind(sessionId) is called
while there are entries in the queue for that session.
6. Please add tests also for borderline racing cases such as same instance
is returned for new request arriving before storing is complete.
7. I would rename AsyncPageStore -> AsynchronousPageStore for clarity and
symmetry (symmetric naming with AsynchronousDataStore),
8. Please propose a patch also into DefaultPageManagerProvider such that
new AsyncPageStore(super.newPageStore(dataStore), 100); would be the default
pagestore for wicket when dataStore.canBeAsynchronous()==true. Similar way that
AsynchronousDataStore is default.
> Blocking page serialization
> ---
>
> Key: WICKET-6177
> URL: https://issues.apache.org/jira/browse/WICKET-6177
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.4.0
> Environment: any
>Reporter: Martin Makundi
> Labels: serialization
> Attachments: 6177.tgz, Wicket_Quickstart_7.zip
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> We have a performance issue with our Wicket app, page serialization causes
> inconvenience to user because PageStoreManager.storeTouchedPages() blocks the
> request until pageSerializer.serialize(page) has been handled.
> Could this be solved by serializing the page in a separate thread and let the
> request complete?
> The problem we have is that user is making quick small ajax modifications to
> the page but serialization + network latency makes the delay very
> inconvenient. If serialization could be done in separate thread, user would
> feel only the network delay which is bearable.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-6177) Blocking page serialization
[
https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15927861#comment-15927861
]
ASF GitHub Bot commented on WICKET-6177:
Github user 1nside0ut commented on the issue:
https://github.com/apache/wicket/pull/212
hi @mmakundi
"3. In case entries.offer fails, entryMap.remove is called before
pageStore.storePage. If we assume pageStore.storePage is slow, maybe it would
be good idea to postpone remove so that a new requiest during
pageStore.storePage can use the in-memory reference? Similar to what is
happening in PageSavingRunnable.run? Also this will make a great re-usable
method:
storePageAndRemoveFromMap(...) {
log.debug("Saving asynchronously: {}...", entry);
pageStore.storePage(sessionId, page);
entryMap.remove(getKey(entry));
}"
entryMap is not supposed to be used as "backup mem", there's already one
queue for that (entries). it's not by mistake that map-removal is located
before synchronous store call for the same thread (not the worker). the reason
is simple: if before try-to-queue a page fails, or it simply takes to long
(offer), then that would mean app mem / process is in trouble, "no space /
speed for that", so there's not point on keeping that ref attached to map
(occupying) while synchronous storing ("slow" storing, as you say) if it has
already been stated a fail on trying to manage it in queue (mem). using map as
"a backup for when queuing fails" would just false the mechanism, imposing a
mem kept at a non-optimal point for that.
on the other hand, regarding the worker thread that "asynchronously" stores
the page, the case is the opposite. every single page that has achieved to
enter the queue before (that is, offer succeeded), has already got the
privilege to being kept in mem while not being entirely stored, so being
removed from map after that.
queue protects itself from accepting or not new entries depending on env
conditions, but outside it logic should act in coherence to it.
> Blocking page serialization
> ---
>
> Key: WICKET-6177
> URL: https://issues.apache.org/jira/browse/WICKET-6177
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.4.0
> Environment: any
>Reporter: Martin Makundi
> Labels: serialization
> Attachments: 6177.tgz, Wicket_Quickstart_7.zip
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> We have a performance issue with our Wicket app, page serialization causes
> inconvenience to user because PageStoreManager.storeTouchedPages() blocks the
> request until pageSerializer.serialize(page) has been handled.
> Could this be solved by serializing the page in a separate thread and let the
> request complete?
> The problem we have is that user is making quick small ajax modifications to
> the page but serialization + network latency makes the delay very
> inconvenient. If serialization could be done in separate thread, user would
> feel only the network delay which is bearable.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-6289) Autolinking adds onclick attribute to tags
[
https://issues.apache.org/jira/browse/WICKET-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15933641#comment-15933641
]
ASF GitHub Bot commented on WICKET-6289:
Github user martin-g commented on the issue:
https://github.com/apache/wicket/pull/199
@duesenklipper Ping!
> Autolinking adds onclick attribute to tags
>
>
> Key: WICKET-6289
> URL: https://issues.apache.org/jira/browse/WICKET-6289
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 7.4.0, 8.0.0-M2, 6.25.0, 1.5.17
>Reporter: Carl-Eric Menzel
>Assignee: Carl-Eric Menzel
> Fix For: 7.6.0, 8.0.0-M3
>
>
> When the autolinker can't find the target of a src or href attribute, it
> falls back to a default autocomponent, that supposedly leaves the tag
> unchanged. Quoting AutolinkResolver:
> {code}
> if (autoComponent == null)
> {
> // resolving didn't have the desired result or there was no delegate
> // found; fallback on the default resolving which is a simple
> // component that leaves the tag unchanged
> autoComponent = new AutolinkExternalLink(componentId,
> pathInfo.reference);
> }
> {code}
> ...except that AutolinkExternalLink is an ExternalLink which is an
> AbstractLink which does change the original tag. Namely, when applied to
> something that is not it adds an onclick attribute. This leads to
> something like the following:
> {code}
> onclick="window.location.href='does-not-exist.png';return false;"/>
> {code}
> ...which is clearly nonsensical. This can happen when the referenced image is
> not in the classpath - it could either be missing, or it could be in the
> webapp root somewhere, which can be the case for some legacy applications.
> (This is how I came across this.)
> A simple fix appears to be to use a plain WebMarkupContainer in place of this
> particular AutolinkExternalLink. All tests pass when I do that.
> This affects all versions from 1.5 on upward. I'll prepare a pull request.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-6350) setRequired checks for primitive type only when the FormComponent is NOT required
[
https://issues.apache.org/jira/browse/WICKET-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15947630#comment-15947630
]
ASF GitHub Bot commented on WICKET-6350:
GitHub user JoachimRohde opened a pull request:
https://github.com/apache/wicket/pull/217
[Fix] setRequired checked for primitive type only when the FormCompon…
…ent was NOT required
See https://issues.apache.org/jira/browse/WICKET-6350
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/JoachimRohde/wicket master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/wicket/pull/217.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #217
commit e0805a6e4c413875409e0301811e5097714be5ad
Author: JoachimRohde
Date: 2017-03-29T16:17:52Z
[Fix] setRequired checked for primitive type only when the FormComponent
was NOT required
> setRequired checks for primitive type only when the FormComponent is NOT
> required
> -
>
> Key: WICKET-6350
> URL: https://issues.apache.org/jira/browse/WICKET-6350
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 8.0.0-M4
>Reporter: Joachim Rohde
>Priority: Minor
>
> I was tinkering around with Kotlin and Wicket and had the following snippet:
> val housenumbervalue: Int? = null
> val housenumberModel: IModel = Model()
> val housenumber = TextField("housenumberModel", housenumberModel,
> Int::class.java)
> val form: Form = object : Form("adressForm") {}
> override fun onInitialize() {
> super.onInitialize()
> form.add(housenumber.setRequired(false))
> form.add(object : SubmitLink("submit") {
> override fun onSubmit() {
> super.onSubmit()
> println(housenumberModel.`object`)
> }
> })
> add(form)
> }
> This code resulted in
> org.apache.wicket.WicketRuntimeException: FormComponent can't be required
> when the type is primitive class: [TextField [Component id =
> housenumberModel]]
> at
> org.apache.wicket.markup.html.form.FormComponent.setRequired(FormComponent.java:1052)
> at com.mycompany.test.web.pages.Test.onInitialize(Test.kt:28)
> Turns out that setRequired was checking only if the FormComponent was *not*
> required. It should be the other way round. I opened a pull request.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-6350) setRequired checks for primitive type only when the FormComponent is NOT required
[
https://issues.apache.org/jira/browse/WICKET-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15948971#comment-15948971
]
ASF GitHub Bot commented on WICKET-6350:
Github user JoachimRohde closed the pull request at:
https://github.com/apache/wicket/pull/217
> setRequired checks for primitive type only when the FormComponent is NOT
> required
> -
>
> Key: WICKET-6350
> URL: https://issues.apache.org/jira/browse/WICKET-6350
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 8.0.0-M4
>Reporter: Joachim Rohde
>Priority: Minor
>
> I was tinkering around with Kotlin and Wicket and had the following snippet:
> val housenumbervalue: Int? = null
> val housenumberModel: IModel = Model()
> val housenumber = TextField("housenumberModel", housenumberModel,
> Int::class.java)
> val form: Form = object : Form("adressForm") {}
> override fun onInitialize() {
> super.onInitialize()
> form.add(housenumber.setRequired(false))
> form.add(object : SubmitLink("submit") {
> override fun onSubmit() {
> super.onSubmit()
> println(housenumberModel.`object`)
> }
> })
> add(form)
> }
> This code resulted in
> org.apache.wicket.WicketRuntimeException: FormComponent can't be required
> when the type is primitive class: [TextField [Component id =
> housenumberModel]]
> at
> org.apache.wicket.markup.html.form.FormComponent.setRequired(FormComponent.java:1052)
> at com.mycompany.test.web.pages.Test.onInitialize(Test.kt:28)
> Turns out that setRequired was checking only if the FormComponent was *not*
> required. It should be the other way round. I opened a pull request.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-6354) There is no constant for jquery3
[ https://issues.apache.org/jira/browse/WICKET-6354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962526#comment-15962526 ] ASF GitHub Bot commented on WICKET-6354: GitHub user solomax opened a pull request: https://github.com/apache/wicket/pull/218 [WICKET-6354] string constants and references are added for all versi… …ons of jquery You can merge this pull request into a Git repository by running: $ git pull https://github.com/solomax/wicket master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/218.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #218 commit dbfe141da0f447d86d4174c56454fe61cbe545f4 Author: Maxim Solodovnik Date: 2017-04-10T07:22:02Z [WICKET-6354] string constants and references are added for all versions of jquery > There is no constant for jquery3 > > > Key: WICKET-6354 > URL: https://issues.apache.org/jira/browse/WICKET-6354 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 8.0.0-M4 >Reporter: Maxim Solodovnik > > There is no constant for jquery3 in wicket > It would be good to have both > 1) String constant for jquery version (in sync with bundled version) > 2) JS references for all jquery versions -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6354) There is no constant for jquery3
[ https://issues.apache.org/jira/browse/WICKET-6354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962549#comment-15962549 ] ASF GitHub Bot commented on WICKET-6354: Github user asfgit closed the pull request at: https://github.com/apache/wicket/pull/218 > There is no constant for jquery3 > > > Key: WICKET-6354 > URL: https://issues.apache.org/jira/browse/WICKET-6354 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 8.0.0-M4 >Reporter: Maxim Solodovnik > > There is no constant for jquery3 in wicket > It would be good to have both > 1) String constant for jquery version (in sync with bundled version) > 2) JS references for all jquery versions -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6354) Add JavaScriptResourceReference for JQuery 3.x
[ https://issues.apache.org/jira/browse/WICKET-6354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962571#comment-15962571 ] ASF GitHub Bot commented on WICKET-6354: Github user sebfz1 commented on the issue: https://github.com/apache/wicket/pull/218 There is/was already a `VERSION_2` in `DynamicJQueryResourceReference`. I think only one should be kept... > Add JavaScriptResourceReference for JQuery 3.x > -- > > Key: WICKET-6354 > URL: https://issues.apache.org/jira/browse/WICKET-6354 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 8.0.0-M4 >Reporter: Maxim Solodovnik >Assignee: Martin Grigorov > Fix For: 8.0.0-M6 > > > There is no constant for jquery3 in wicket > It would be good to have both > 1) String constant for jquery version (in sync with bundled version) > 2) JS references for all jquery versions -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6354) Add JavaScriptResourceReference for JQuery 3.x
[ https://issues.apache.org/jira/browse/WICKET-6354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962573#comment-15962573 ] ASF GitHub Bot commented on WICKET-6354: Github user sebfz1 commented on the issue: https://github.com/apache/wicket/pull/218 My bad, you used it! ;) Then opened question: why not centralize all in `JQueryResourceReference` > Add JavaScriptResourceReference for JQuery 3.x > -- > > Key: WICKET-6354 > URL: https://issues.apache.org/jira/browse/WICKET-6354 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 8.0.0-M4 >Reporter: Maxim Solodovnik >Assignee: Martin Grigorov > Fix For: 8.0.0-M6 > > > There is no constant for jquery3 in wicket > It would be good to have both > 1) String constant for jquery version (in sync with bundled version) > 2) JS references for all jquery versions -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6354) Add JavaScriptResourceReference for JQuery 3.x
[ https://issues.apache.org/jira/browse/WICKET-6354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962576#comment-15962576 ] ASF GitHub Bot commented on WICKET-6354: Github user solomax commented on the issue: https://github.com/apache/wicket/pull/218 It actually was my plan But I was trying to keep changes minimal, hoping wicket team can polish it I guess some test that ensures VERSION_* is updated with jquery update are required > Add JavaScriptResourceReference for JQuery 3.x > -- > > Key: WICKET-6354 > URL: https://issues.apache.org/jira/browse/WICKET-6354 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 8.0.0-M4 >Reporter: Maxim Solodovnik >Assignee: Martin Grigorov > Fix For: 8.0.0-M6 > > > There is no constant for jquery3 in wicket > It would be good to have both > 1) String constant for jquery version (in sync with bundled version) > 2) JS references for all jquery versions -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6355) There should be possible to set fileName to FileSystemResource
[ https://issues.apache.org/jira/browse/WICKET-6355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965562#comment-15965562 ] ASF GitHub Bot commented on WICKET-6355: GitHub user solomax opened a pull request: https://github.com/apache/wicket/pull/219 [WICKET-6355] It is now possible to set fileName to FileSystemResource You can merge this pull request into a Git repository by running: $ git pull https://github.com/solomax/wicket master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/219.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #219 commit 71d5be39df87875d3550a05f44df8ba3e6659036 Author: Maxim Solodovnik Date: 2017-04-12T08:44:16Z [WICKET-6355] It is now possible to set fileName to FileSystemResource > There should be possible to set fileName to FileSystemResource > -- > > Key: WICKET-6355 > URL: https://issues.apache.org/jira/browse/WICKET-6355 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 8.0.0-M5 >Reporter: Maxim Solodovnik >Priority: Minor > > Currently no fileName is set to FileSystemResource, and there is no easy way > to do it -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6355) There should be possible to set fileName to FileSystemResource
[
https://issues.apache.org/jira/browse/WICKET-6355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965569#comment-15965569
]
ASF GitHub Bot commented on WICKET-6355:
Github user martin-g commented on a diff in the pull request:
https://github.com/apache/wicket/pull/219#discussion_r111096456
--- Diff:
wicket-core/src/main/java/org/apache/wicket/resource/FileSystemResource.java ---
@@ -68,17 +68,19 @@ public FileSystemResource()
@Override
protected ResourceResponse newResourceResponse(Attributes attributes)
{
- return createResourceResponse(path);
+ return createResourceResponse(path, null);
}
/**
* Creates a resource response based on the given attributes
*
* @param path
*the path to create the resource response with
+* @param fileName
+*fileName to set, path.getFileName() will be used in case
null passed
* @return the actual resource response x
*/
- protected ResourceResponse createResourceResponse(Path path)
+ protected ResourceResponse createResourceResponse(Path path, String
fileName)
--- End diff --
Do we really need this extra parameter here for the fileName ?
IMO by default it should do: `if (fileName != null)
resourceResponse.setFileName(path.getFileName().toString());`
If the application wants to override it then do something like:
```java
ResourceResponse rr = super.createResourceResponse(path);
rr.setFileName("custom.name");
return rr;
```
Also I think passing `Attributes` as a parameter would be useful!
> There should be possible to set fileName to FileSystemResource
> --
>
> Key: WICKET-6355
> URL: https://issues.apache.org/jira/browse/WICKET-6355
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 8.0.0-M5
>Reporter: Maxim Solodovnik
>Priority: Minor
>
> Currently no fileName is set to FileSystemResource, and there is no easy way
> to do it
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-6355) There should be possible to set fileName to FileSystemResource
[
https://issues.apache.org/jira/browse/WICKET-6355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965703#comment-15965703
]
ASF GitHub Bot commented on WICKET-6355:
Github user klopfdreh commented on a diff in the pull request:
https://github.com/apache/wicket/pull/219#discussion_r30176
--- Diff:
wicket-core/src/main/java/org/apache/wicket/resource/FileSystemResource.java ---
@@ -95,7 +95,9 @@ protected ResourceResponse createResourceResponse(Path
path, String fileName)
resourceResponse.setContentType(getMimeType());
resourceResponse.setAcceptRange(ContentRangeType.BYTES);
resourceResponse.setContentLength(size);
- resourceResponse.setFileName(fileName == null ?
path.getFileName().toString() : fileName);
+ if (path != null && path.getFileName() != null) {
--- End diff --
I think we don't need to check *path != null* because it is checked before
(and a WicketRuntimeException is thrown if it is null) - everything else looks
good.
> There should be possible to set fileName to FileSystemResource
> --
>
> Key: WICKET-6355
> URL: https://issues.apache.org/jira/browse/WICKET-6355
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 8.0.0-M5
>Reporter: Maxim Solodovnik
>Priority: Minor
>
> Currently no fileName is set to FileSystemResource, and there is no easy way
> to do it
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-6355) There should be possible to set fileName to FileSystemResource
[
https://issues.apache.org/jira/browse/WICKET-6355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965707#comment-15965707
]
ASF GitHub Bot commented on WICKET-6355:
Github user solomax commented on a diff in the pull request:
https://github.com/apache/wicket/pull/219#discussion_r30572
--- Diff:
wicket-core/src/main/java/org/apache/wicket/resource/FileSystemResource.java ---
@@ -95,7 +95,9 @@ protected ResourceResponse createResourceResponse(Path
path, String fileName)
resourceResponse.setContentType(getMimeType());
resourceResponse.setAcceptRange(ContentRangeType.BYTES);
resourceResponse.setContentLength(size);
- resourceResponse.setFileName(fileName == null ?
path.getFileName().toString() : fileName);
+ if (path != null && path.getFileName() != null) {
--- End diff --
My bad, will fix
> There should be possible to set fileName to FileSystemResource
> --
>
> Key: WICKET-6355
> URL: https://issues.apache.org/jira/browse/WICKET-6355
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 8.0.0-M5
>Reporter: Maxim Solodovnik
>Priority: Minor
>
> Currently no fileName is set to FileSystemResource, and there is no easy way
> to do it
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WICKET-6355) Pass the request attributes to FileSystemResource#createResourceResponse()
[ https://issues.apache.org/jira/browse/WICKET-6355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966546#comment-15966546 ] ASF GitHub Bot commented on WICKET-6355: Github user asfgit closed the pull request at: https://github.com/apache/wicket/pull/219 > Pass the request attributes to FileSystemResource#createResourceResponse() > -- > > Key: WICKET-6355 > URL: https://issues.apache.org/jira/browse/WICKET-6355 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 8.0.0-M5 >Reporter: Maxim Solodovnik >Assignee: Martin Grigorov >Priority: Minor > > org.apache.wicket.resource.FileSystemResource#newResourceResponse(Attributes) > should pass the request attributes as a second argument to > org.apache.wicket.resource.FileSystemResource#createResourceResponse(Path). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6177) Introduce AsynchronousPageStore
[ https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1595#comment-1595 ] ASF GitHub Bot commented on WICKET-6177: Github user asfgit closed the pull request at: https://github.com/apache/wicket/pull/212 > Introduce AsynchronousPageStore > --- > > Key: WICKET-6177 > URL: https://issues.apache.org/jira/browse/WICKET-6177 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.4.0 > Environment: any >Reporter: Martin Makundi >Assignee: Martin Grigorov > Labels: serialization > Attachments: 6177.tgz, Wicket_Quickstart_7.zip > > Original Estimate: 168h > Remaining Estimate: 168h > > We have a performance issue with our Wicket app, page serialization causes > inconvenience to user because PageStoreManager.storeTouchedPages() blocks the > request until pageSerializer.serialize(page) has been handled. > Could this be solved by serializing the page in a separate thread and let the > request complete? > The problem we have is that user is making quick small ajax modifications to > the page but serialization + network latency makes the delay very > inconvenient. If serialization could be done in separate thread, user would > feel only the network delay which is bearable. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6366) Autocomplete race condition makes page unresponsive
[ https://issues.apache.org/jira/browse/WICKET-6366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16000672#comment-16000672 ] ASF GitHub Bot commented on WICKET-6366: GitHub user perhuss opened a pull request: https://github.com/apache/wicket/pull/220 WICKET-6366: Autocomplete race condition makes page unresponsive Fixed bug. You can merge this pull request into a Git repository by running: $ git pull https://github.com/perhuss/wicket wicket-7.x Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/220.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #220 commit c722e0a136583fb6a05475bd4dd492e2cebe4440 Author: phuss Date: 2017-05-08T12:31:17Z WICKET-6366: Autocomplete race condition makes page unresponsive > Autocomplete race condition makes page unresponsive > --- > > Key: WICKET-6366 > URL: https://issues.apache.org/jira/browse/WICKET-6366 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 7.6.0 > Environment: Reproduced both with latest Firefox (53.0.2) and latest > Chrome (58.0.3029.96) >Reporter: Per Huss > Attachments: autocomplete.zip, exceptions.png > > > The autocomplete field can throw a javascript exception that makes the page > unresponsive. > To reproduce, run attached quickstart and: > 1. Click the text field and type "a" > 2. Quickly click the "hide" button, and > 3. Quickly click the text field again and type another "a", leaving the text > field focused. > 4. A couple of javascript exceptions will be thrown, where the first on seems > to break the ajax functionality. Clicking "show" has no effect now. > Attaching quickstart and screenshot of the exceptions. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6366) Autocomplete race condition makes page unresponsive
[ https://issues.apache.org/jira/browse/WICKET-6366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036865#comment-16036865 ] ASF GitHub Bot commented on WICKET-6366: Github user asfgit closed the pull request at: https://github.com/apache/wicket/pull/220 > Autocomplete race condition makes page unresponsive > --- > > Key: WICKET-6366 > URL: https://issues.apache.org/jira/browse/WICKET-6366 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 7.6.0 > Environment: Reproduced both with latest Firefox (53.0.2) and latest > Chrome (58.0.3029.96) >Reporter: Per Huss >Assignee: Sven Meier > Attachments: autocomplete.zip, exceptions.png > > > The autocomplete field can throw a javascript exception that makes the page > unresponsive. > To reproduce, run attached quickstart and: > 1. Click the text field and type "a" > 2. Quickly click the "hide" button, and > 3. Quickly click the text field again and type another "a", leaving the text > field focused. > 4. A couple of javascript exceptions will be thrown, where the first on seems > to break the ajax functionality. Clicking "show" has no effect now. > Attaching quickstart and screenshot of the exceptions. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6366) Autocomplete race condition makes page unresponsive
[ https://issues.apache.org/jira/browse/WICKET-6366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036869#comment-16036869 ] ASF GitHub Bot commented on WICKET-6366: Github user svenmeier commented on the issue: https://github.com/apache/wicket/pull/220 Thanks! > Autocomplete race condition makes page unresponsive > --- > > Key: WICKET-6366 > URL: https://issues.apache.org/jira/browse/WICKET-6366 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 7.6.0 > Environment: Reproduced both with latest Firefox (53.0.2) and latest > Chrome (58.0.3029.96) >Reporter: Per Huss >Assignee: Sven Meier > Attachments: autocomplete.zip, exceptions.png > > > The autocomplete field can throw a javascript exception that makes the page > unresponsive. > To reproduce, run attached quickstart and: > 1. Click the text field and type "a" > 2. Quickly click the "hide" button, and > 3. Quickly click the text field again and type another "a", leaving the text > field focused. > 4. A couple of javascript exceptions will be thrown, where the first on seems > to break the ajax functionality. Clicking "show" has no effect now. > Attaching quickstart and screenshot of the exceptions. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6204) Copy only the provided attributes for Ajax link inclusion
[ https://issues.apache.org/jira/browse/WICKET-6204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042416#comment-16042416 ] ASF GitHub Bot commented on WICKET-6204: GitHub user Jezza opened a pull request: https://github.com/apache/wicket/pull/221 Improve jQuery.noConflict() support. The fix that was introduced with the fix for WICKET-6204 fails to work with jQuery.noConflict(). You can merge this pull request into a Git repository by running: $ git pull https://github.com/Jezza/wicket master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/221.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #221 commit 98b1073090ab16df64eaa9ddffeba7489818a8be Author: Jezza Date: 2017-06-08T08:47:26Z Improve jQuery.noConflict() support. The fix that was introduced with the fix for WICKET-6204 fails to work with jQuery.noConflict(). > Copy only the provided attributes for Ajax link inclusion > - > > Key: WICKET-6204 > URL: https://issues.apache.org/jira/browse/WICKET-6204 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.3.0, 8.0.0-M1, 6.23.0 >Reporter: Martin Grigorov >Assignee: Martin Grigorov > Fix For: 7.4.0, 6.24.0, 8.0.0-M2 > > > See http://markmail.org/message/b7v6x7jgldg7jhcm > Wicket should copy only the available attributes of elements when they > are being added in an Ajax request. Nothing more, nothing less. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6204) Copy only the provided attributes for Ajax link inclusion
[ https://issues.apache.org/jira/browse/WICKET-6204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042529#comment-16042529 ] ASF GitHub Bot commented on WICKET-6204: Github user Jezza closed the pull request at: https://github.com/apache/wicket/pull/221 > Copy only the provided attributes for Ajax link inclusion > - > > Key: WICKET-6204 > URL: https://issues.apache.org/jira/browse/WICKET-6204 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.3.0, 8.0.0-M1, 6.23.0 >Reporter: Martin Grigorov >Assignee: Martin Grigorov > Fix For: 7.4.0, 6.24.0, 8.0.0-M2 > > > See http://markmail.org/message/b7v6x7jgldg7jhcm > Wicket should copy only the available attributes of elements when they > are being added in an Ajax request. Nothing more, nothing less. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6204) Copy only the provided attributes for Ajax link inclusion
[ https://issues.apache.org/jira/browse/WICKET-6204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042546#comment-16042546 ] ASF GitHub Bot commented on WICKET-6204: GitHub user Jezza reopened a pull request: https://github.com/apache/wicket/pull/221 Improve jQuery.noConflict() support. The fix that was introduced for WICKET-6204 fails to work with jQuery.noConflict(). You can merge this pull request into a Git repository by running: $ git pull https://github.com/Jezza/wicket master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/221.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #221 commit 98b1073090ab16df64eaa9ddffeba7489818a8be Author: Jezza Date: 2017-06-08T08:47:26Z Improve jQuery.noConflict() support. The fix that was introduced with the fix for WICKET-6204 fails to work with jQuery.noConflict(). > Copy only the provided attributes for Ajax link inclusion > - > > Key: WICKET-6204 > URL: https://issues.apache.org/jira/browse/WICKET-6204 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.3.0, 8.0.0-M1, 6.23.0 >Reporter: Martin Grigorov >Assignee: Martin Grigorov > Fix For: 7.4.0, 6.24.0, 8.0.0-M2 > > > See http://markmail.org/message/b7v6x7jgldg7jhcm > Wicket should copy only the available attributes of elements when they > are being added in an Ajax request. Nothing more, nothing less. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (WICKET-6398) WICKET-6204 breaks jQuery.noConflict()
[ https://issues.apache.org/jira/browse/WICKET-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049127#comment-16049127 ] ASF GitHub Bot commented on WICKET-6398: Github user martin-g commented on the issue: https://github.com/apache/wicket/pull/221 I've created https://issues.apache.org/jira/browse/WICKET-6398 for the changelog. > WICKET-6204 breaks jQuery.noConflict() > -- > > Key: WICKET-6398 > URL: https://issues.apache.org/jira/browse/WICKET-6398 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.7.0, 8.0.0-M6 >Reporter: Martin Grigorov > > Wicket JS code should not use "$", but "jQuery". > Pull Request: https://github.com/apache/wicket/pull/221 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6398) WICKET-6204 breaks jQuery.noConflict()
[ https://issues.apache.org/jira/browse/WICKET-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049135#comment-16049135 ] ASF GitHub Bot commented on WICKET-6398: Github user martin-g commented on the issue: https://github.com/apache/wicket/pull/221 The fix has been applied with https://issues.apache.org/jira/browse/WICKET-6398. @Jezza Please close this PR! Thank you ! > WICKET-6204 breaks jQuery.noConflict() > -- > > Key: WICKET-6398 > URL: https://issues.apache.org/jira/browse/WICKET-6398 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.7.0, 8.0.0-M6 >Reporter: Martin Grigorov >Assignee: Martin Grigorov > Fix For: 6.27.0, 7.8.0, 8.0.0-M7 > > > Wicket JS code should not use "$", but "jQuery". > Pull Request: https://github.com/apache/wicket/pull/221 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6055) AjaxLazyLoadPanel should provide non-blocking lazy load
[ https://issues.apache.org/jira/browse/WICKET-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049137#comment-16049137 ] ASF GitHub Bot commented on WICKET-6055: Github user martin-g commented on the issue: https://github.com/apache/wicket/pull/151 @dashorst Ping! > 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.4.14#64029)
[jira] [Commented] (WICKET-6204) Copy only the provided attributes for Ajax link inclusion
[ https://issues.apache.org/jira/browse/WICKET-6204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049177#comment-16049177 ] ASF GitHub Bot commented on WICKET-6204: Github user Jezza closed the pull request at: https://github.com/apache/wicket/pull/221 > Copy only the provided attributes for Ajax link inclusion > - > > Key: WICKET-6204 > URL: https://issues.apache.org/jira/browse/WICKET-6204 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.3.0, 8.0.0-M1, 6.23.0 >Reporter: Martin Grigorov >Assignee: Martin Grigorov > Fix For: 7.4.0, 6.24.0, 8.0.0-M2 > > > See http://markmail.org/message/b7v6x7jgldg7jhcm > Wicket should copy only the available attributes of elements when they > are being added in an Ajax request. Nothing more, nothing less. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6055) AjaxLazyLoadPanel should provide non-blocking lazy load
[ https://issues.apache.org/jira/browse/WICKET-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049215#comment-16049215 ] ASF GitHub Bot commented on WICKET-6055: Github user dashorst commented on the issue: https://github.com/apache/wicket/pull/151 Any comments about configuring the duration of the polling timer? I'm inclined to just defer that to a specific user request rather than implement it directly. Perhaps someone comes up with a better solution to configure the duration than what we have now. I'd rather wait for the need and a good solution than implement a solution that paints us in the corner. > 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.4.14#64029)
[jira] [Commented] (WICKET-6409) Session should use #getSessionStore() instead of 'sessionStore'
[ https://issues.apache.org/jira/browse/WICKET-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059888#comment-16059888 ] ASF GitHub Bot commented on WICKET-6409: Github user martin-g commented on the issue: https://github.com/apache/wicket/pull/222 https://issues.apache.org/jira/browse/WICKET-6409 > Session should use #getSessionStore() instead of 'sessionStore' > --- > > Key: WICKET-6409 > URL: https://issues.apache.org/jira/browse/WICKET-6409 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.26.0 >Reporter: Martin Grigorov > > From https://github.com/apache/wicket/pull/222: > Wicket 6.x fails Session.invalidateNow() after deserialisation (For example, > when using Oracle Coherence). > Session.destroy() uses sessionStore. But it is null after deserialisation > because sessionStore is transient. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered
[
https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100560#comment-16100560
]
ASF GitHub Bot commented on WICKET-6427:
Github user martin-g commented on a diff in the pull request:
https://github.com/apache/wicket/pull/223#discussion_r129394921
--- Diff:
wicket-core/src/main/java/org/apache/wicket/markup/head/ResourceAggregator.java
---
@@ -353,6 +353,7 @@ private void renderCombinedEventScripts()
}
if (combinedScript.length() > 0)
{
+
combinedScript.append("\nWicket.Event.publish(Wicket.Event.Topic.AJAX_TIMERS_BOUND);");
--- End diff --
How do you know that any timers are in the response ?
It looks to me that this event is published no matter whether there are
timer behaviors in use or not.
> Fire an event once all ajax timers are registered
> -
>
> Key: WICKET-6427
> URL: https://issues.apache.org/jira/browse/WICKET-6427
> Project: Wicket
> Issue Type: Improvement
>Reporter: Jezza
>Priority: Minor
>
> This is in the same vein as WICKET-5746.
> I just need some way to execute code after the timers have been registered,
> and it seemed weird to only have the event fired for one set of ajax related
> calls.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered
[
https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100612#comment-16100612
]
ASF GitHub Bot commented on WICKET-6427:
Github user Jezza commented on a diff in the pull request:
https://github.com/apache/wicket/pull/223#discussion_r129402277
--- Diff:
wicket-core/src/main/java/org/apache/wicket/markup/head/ResourceAggregator.java
---
@@ -353,6 +353,7 @@ private void renderCombinedEventScripts()
}
if (combinedScript.length() > 0)
{
+
combinedScript.append("\nWicket.Event.publish(Wicket.Event.Topic.AJAX_TIMERS_BOUND);");
--- End diff --
It follows the same logic as the
[AJAX_HANDLERS_BOUND](https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/markup/head/ResourceAggregator.java#L339)
event.
Which is always fired if there's `OnDomReadyHeaderItem`s.
If the event name is confusing, then I'd recommend changing both of them to
suit their actual function.
> Fire an event once all ajax timers are registered
> -
>
> Key: WICKET-6427
> URL: https://issues.apache.org/jira/browse/WICKET-6427
> Project: Wicket
> Issue Type: Improvement
>Reporter: Jezza
>Priority: Minor
>
> This is in the same vein as WICKET-5746.
> I just need some way to execute code after the timers have been registered,
> and it seemed weird to only have the event fired for one set of ajax related
> calls.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered
[
https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100616#comment-16100616
]
ASF GitHub Bot commented on WICKET-6427:
Github user Jezza commented on a diff in the pull request:
https://github.com/apache/wicket/pull/223#discussion_r129402793
--- Diff:
wicket-core/src/main/java/org/apache/wicket/markup/head/ResourceAggregator.java
---
@@ -353,6 +353,7 @@ private void renderCombinedEventScripts()
}
if (combinedScript.length() > 0)
{
+
combinedScript.append("\nWicket.Event.publish(Wicket.Event.Topic.AJAX_TIMERS_BOUND);");
--- End diff --
The events themselves are closer to post-`load`s or post-`domready`s
> Fire an event once all ajax timers are registered
> -
>
> Key: WICKET-6427
> URL: https://issues.apache.org/jira/browse/WICKET-6427
> Project: Wicket
> Issue Type: Improvement
>Reporter: Jezza
>Priority: Minor
>
> This is in the same vein as WICKET-5746.
> I just need some way to execute code after the timers have been registered,
> and it seemed weird to only have the event fired for one set of ajax related
> calls.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered
[
https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100639#comment-16100639
]
ASF GitHub Bot commented on WICKET-6427:
Github user martin-g commented on a diff in the pull request:
https://github.com/apache/wicket/pull/223#discussion_r129406187
--- Diff:
wicket-core/src/main/java/org/apache/wicket/markup/head/ResourceAggregator.java
---
@@ -353,6 +353,7 @@ private void renderCombinedEventScripts()
}
if (combinedScript.length() > 0)
{
+
combinedScript.append("\nWicket.Event.publish(Wicket.Event.Topic.AJAX_TIMERS_BOUND);");
--- End diff --
Right!
The names are confusing!
They should use `load` and `domready` in their names to be more clear.
What about `Wicket.Event.Topic.ONDOMREADY_EVENTS_BOUND` and
`...ONLOAD_EVENTS_BOUND` ?
> Fire an event once all ajax timers are registered
> -
>
> Key: WICKET-6427
> URL: https://issues.apache.org/jira/browse/WICKET-6427
> Project: Wicket
> Issue Type: Improvement
>Reporter: Jezza
>Priority: Minor
>
> This is in the same vein as WICKET-5746.
> I just need some way to execute code after the timers have been registered,
> and it seemed weird to only have the event fired for one set of ajax related
> calls.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered
[
https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100641#comment-16100641
]
ASF GitHub Bot commented on WICKET-6427:
Github user Jezza commented on a diff in the pull request:
https://github.com/apache/wicket/pull/223#discussion_r129406967
--- Diff:
wicket-core/src/main/java/org/apache/wicket/markup/head/ResourceAggregator.java
---
@@ -353,6 +353,7 @@ private void renderCombinedEventScripts()
}
if (combinedScript.length() > 0)
{
+
combinedScript.append("\nWicket.Event.publish(Wicket.Event.Topic.AJAX_TIMERS_BOUND);");
--- End diff --
I'd be happy to change it to that.
Should we offer some level of backwards compat, and alias
`AJAX_HANDLERS_BOUND`?
> Fire an event once all ajax timers are registered
> -
>
> Key: WICKET-6427
> URL: https://issues.apache.org/jira/browse/WICKET-6427
> Project: Wicket
> Issue Type: Improvement
>Reporter: Jezza
>Priority: Minor
>
> This is in the same vein as WICKET-5746.
> I just need some way to execute code after the timers have been registered,
> and it seemed weird to only have the event fired for one set of ajax related
> calls.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered
[
https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100659#comment-16100659
]
ASF GitHub Bot commented on WICKET-6427:
Github user martin-g commented on a diff in the pull request:
https://github.com/apache/wicket/pull/223#discussion_r129408806
--- Diff:
wicket-core/src/main/java/org/apache/wicket/markup/head/ResourceAggregator.java
---
@@ -353,6 +353,7 @@ private void renderCombinedEventScripts()
}
if (combinedScript.length() > 0)
{
+
combinedScript.append("\nWicket.Event.publish(Wicket.Event.Topic.AJAX_TIMERS_BOUND);");
--- End diff --
Yes, I think we should publish both for 8.x and remove
`AJAX_HANDLERS_BOUND` for 9.x.
We can also log a warning when `AJAX_HANDLERS_BOUND` published to a
subscriber.
> Fire an event once all ajax timers are registered
> -
>
> Key: WICKET-6427
> URL: https://issues.apache.org/jira/browse/WICKET-6427
> Project: Wicket
> Issue Type: Improvement
>Reporter: Jezza
>Priority: Minor
>
> This is in the same vein as WICKET-5746.
> I just need some way to execute code after the timers have been registered,
> and it seemed weird to only have the event fired for one set of ajax related
> calls.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered
[
https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100671#comment-16100671
]
ASF GitHub Bot commented on WICKET-6427:
Github user Jezza commented on a diff in the pull request:
https://github.com/apache/wicket/pull/223#discussion_r129410764
--- Diff:
wicket-core/src/main/java/org/apache/wicket/markup/head/ResourceAggregator.java
---
@@ -353,6 +353,7 @@ private void renderCombinedEventScripts()
}
if (combinedScript.length() > 0)
{
+
combinedScript.append("\nWicket.Event.publish(Wicket.Event.Topic.AJAX_TIMERS_BOUND);");
--- End diff --
Also, I noticed that it doesn't work for header items added via the
`AjaxRequestTarget`.
Should that be a concern?
> Fire an event once all ajax timers are registered
> -
>
> Key: WICKET-6427
> URL: https://issues.apache.org/jira/browse/WICKET-6427
> Project: Wicket
> Issue Type: Improvement
>Reporter: Jezza
>Priority: Minor
>
> This is in the same vein as WICKET-5746.
> I just need some way to execute code after the timers have been registered,
> and it seemed weird to only have the event fired for one set of ajax related
> calls.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered
[
https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100681#comment-16100681
]
ASF GitHub Bot commented on WICKET-6427:
Github user Jezza commented on a diff in the pull request:
https://github.com/apache/wicket/pull/223#discussion_r129411278
--- Diff:
wicket-core/src/main/java/org/apache/wicket/markup/head/ResourceAggregator.java
---
@@ -353,6 +353,7 @@ private void renderCombinedEventScripts()
}
if (combinedScript.length() > 0)
{
+
combinedScript.append("\nWicket.Event.publish(Wicket.Event.Topic.AJAX_TIMERS_BOUND);");
--- End diff --
That actually might just be my code specifically. I'll have to take a look
tomorrow.
> Fire an event once all ajax timers are registered
> -
>
> Key: WICKET-6427
> URL: https://issues.apache.org/jira/browse/WICKET-6427
> Project: Wicket
> Issue Type: Improvement
>Reporter: Jezza
>Priority: Minor
>
> This is in the same vein as WICKET-5746.
> I just need some way to execute code after the timers have been registered,
> and it seemed weird to only have the event fired for one set of ajax related
> calls.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered
[
https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100750#comment-16100750
]
ASF GitHub Bot commented on WICKET-6427:
Github user Jezza commented on a diff in the pull request:
https://github.com/apache/wicket/pull/223#discussion_r129420418
--- Diff:
wicket-core/src/main/java/org/apache/wicket/markup/head/ResourceAggregator.java
---
@@ -353,6 +353,7 @@ private void renderCombinedEventScripts()
}
if (combinedScript.length() > 0)
{
+
combinedScript.append("\nWicket.Event.publish(Wicket.Event.Topic.AJAX_TIMERS_BOUND);");
--- End diff --
There we go, I pushed the latest state of the branch.
> Fire an event once all ajax timers are registered
> -
>
> Key: WICKET-6427
> URL: https://issues.apache.org/jira/browse/WICKET-6427
> Project: Wicket
> Issue Type: Improvement
>Reporter: Jezza
>Priority: Minor
>
> This is in the same vein as WICKET-5746.
> I just need some way to execute code after the timers have been registered,
> and it seemed weird to only have the event fired for one set of ajax related
> calls.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered
[
https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100768#comment-16100768
]
ASF GitHub Bot commented on WICKET-6427:
Github user martin-g commented on a diff in the pull request:
https://github.com/apache/wicket/pull/223#discussion_r129422115
--- Diff:
wicket-core/src/main/java/org/apache/wicket/markup/head/ResourceAggregator.java
---
@@ -336,7 +336,7 @@ private void renderCombinedEventScripts()
}
if (combinedScript.length() > 0)
{
-
combinedScript.append("\nWicket.Event.publish(Wicket.Event.Topic.AJAX_HANDLERS_BOUND);");
+
combinedScript.append("\nWicket.Event.publish(Wicket.Event.Topic.AJAX_ONDOMREADY_EVENTS_BOUND);");
--- End diff --
I think we should keep both here, to be backward compatible.
> Fire an event once all ajax timers are registered
> -
>
> Key: WICKET-6427
> URL: https://issues.apache.org/jira/browse/WICKET-6427
> Project: Wicket
> Issue Type: Improvement
>Reporter: Jezza
>Priority: Minor
>
> This is in the same vein as WICKET-5746.
> I just need some way to execute code after the timers have been registered,
> and it seemed weird to only have the event fired for one set of ajax related
> calls.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered
[
https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100767#comment-16100767
]
ASF GitHub Bot commented on WICKET-6427:
Github user martin-g commented on a diff in the pull request:
https://github.com/apache/wicket/pull/223#discussion_r129422438
--- Diff:
wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-event-jquery.js
---
@@ -277,6 +277,10 @@
* @param topic {String} - the channel name for which
all subscribers will be notified.
*/
publish: function (topic) {
+ if (topic === Topic.AJAX_HANDLERS_BOUND) {
+ console.warn("As of Wicket 8,
Topic.AJAX_HANDLERS_BOUND has been deprecated in favour of
Topic.AJAX_ONDOMREADY_EVENTS_BOUND and will be removed in Wicket 9.")
+ topic = Topic.AJAX_ONDOMREADY_EVENTS_BOUND;
+ }
--- End diff --
To be backward compatible we will have to still publish this event together
with the new one.
This check and warning should be moved to `#subscribe()`.
> Fire an event once all ajax timers are registered
> -
>
> Key: WICKET-6427
> URL: https://issues.apache.org/jira/browse/WICKET-6427
> Project: Wicket
> Issue Type: Improvement
>Reporter: Jezza
>Priority: Minor
>
> This is in the same vein as WICKET-5746.
> I just need some way to execute code after the timers have been registered,
> and it seemed weird to only have the event fired for one set of ajax related
> calls.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered
[ https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16101762#comment-16101762 ] ASF GitHub Bot commented on WICKET-6427: Github user Jezza commented on the issue: https://github.com/apache/wicket/pull/223 Pushed the latest changes. Though that does spring a question to mind, the events are only published if there's `OnDomReady` or `OnLoad` events, so should we just always include them? > Fire an event once all ajax timers are registered > - > > Key: WICKET-6427 > URL: https://issues.apache.org/jira/browse/WICKET-6427 > Project: Wicket > Issue Type: Improvement >Reporter: Jezza >Priority: Minor > > This is in the same vein as WICKET-5746. > I just need some way to execute code after the timers have been registered, > and it seemed weird to only have the event fired for one set of ajax related > calls. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6433) Allow to set the rel attribute with CssHeaderItem
[ https://issues.apache.org/jira/browse/WICKET-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112568#comment-16112568 ] ASF GitHub Bot commented on WICKET-6433: Github user klopfdreh commented on the issue: https://github.com/apache/wicket/pull/226 Ticket: https://issues.apache.org/jira/browse/WICKET-6433 > Allow to set the rel attribute with CssHeaderItem > - > > Key: WICKET-6433 > URL: https://issues.apache.org/jira/browse/WICKET-6433 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 8.0.0-M6 >Reporter: Tobias Soloschenko >Assignee: Tobias Soloschenko >Priority: Trivial > Labels: improvement > Fix For: 8.0.0-M7 > > > Allow to set the rel attribute with CssHeaderItem: > https://github.com/apache/wicket/pull/226 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6434) Fixed WicketTester to detect components in enclosure when doing isComponentOnAjaxResponse.
[ https://issues.apache.org/jira/browse/WICKET-6434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112589#comment-16112589 ] ASF GitHub Bot commented on WICKET-6434: Github user klopfdreh commented on the issue: https://github.com/apache/wicket/pull/224 Thanks a lot for your effort. @martin-g I saw you did the review already. I created a JIRA ticket: https://issues.apache.org/jira/browse/WICKET-6434. > Fixed WicketTester to detect components in enclosure when doing > isComponentOnAjaxResponse. > -- > > Key: WICKET-6434 > URL: https://issues.apache.org/jira/browse/WICKET-6434 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 8.0.0-M6 >Reporter: Tobias Soloschenko >Assignee: Martin Grigorov >Priority: Minor > Labels: fix > Fix For: 8.0.0-M7 > > > When a component is in a wicket:enclosure and is then correctly re-rendered > using ajax, WicketTester seemed to not be able to detect that the component > was in the ajax response in the isComponentOnAjaxResponse method. > A functionality has been additionalwhere isComponentOnAjaxResponse tries to > find an enclosure whose child is the given component, and if one is found, it > recurses into isComponentOnAjaxResponse passing the enclosure as an argument. > In order not to duplicate logic detecting when an enclosure's child is a > given component, AjaxEnclosureListener's isControllerOfEnclosure has been > switched to public and static. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6437) Libraries should be updated to most recent versions
[ https://issues.apache.org/jira/browse/WICKET-6437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115424#comment-16115424 ] ASF GitHub Bot commented on WICKET-6437: GitHub user solomax opened a pull request: https://github.com/apache/wicket/pull/228 WICKET-6437: Library versions are updated I was unable to update org.jglue.cdi-unit:cdi-unit and wildfly It seems code/build modifications are required for this :( You can merge this pull request into a Git repository by running: $ git pull https://github.com/solomax/wicket WICKET-6437 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/228.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #228 commit dad47df0bde5cb1ab312d719ac9283c52abb7301 Author: Maxim Solodovnik Date: 2017-08-05T15:08:45Z Library versions are updated > Libraries should be updated to most recent versions > --- > > Key: WICKET-6437 > URL: https://issues.apache.org/jira/browse/WICKET-6437 > Project: Wicket > Issue Type: Improvement > Components: release >Affects Versions: 8.0.0-M6 >Reporter: Maxim Solodovnik > > Libraries should be updated to most recent versions -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6438) 8.x reference guide needs a few minor improvements
[ https://issues.apache.org/jira/browse/WICKET-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1611#comment-1611 ] ASF GitHub Bot commented on WICKET-6438: GitHub user ozeray opened a pull request: https://github.com/apache/wicket/pull/229 WICKET-6438 - 8.x reference guide needs a few minor improvements Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during maven packaging phase: WARNING: image to embed not found or not readable: F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg Minor fix in contributing.adoc: Revised the generated document target directory for the user guide documentation. Cropped top and bottom blank parts in comsysto-logo.png to have the Introduction page fit in one page in PDF. Made minor changes in helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ozeray/wicket master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/229.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #229 commit 9e323be5eecba1052414e22f4d3505bbc5863238 Author: ozeray Date: 2017-08-06T00:12:03Z A few minor improvements Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during maven packaging phase: WARNING: image to embed not found or not readable: F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg Minor fix in contributing.adoc: Revised the generated document target directory for the user guide documentation. Cropped top and bottom blank parts in comsysto-logo.png to have the Introduction page fit in one page in PDF. Made minor changes in helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. > 8.x reference guide needs a few minor improvements > -- > > Key: WICKET-6438 > URL: https://issues.apache.org/jira/browse/WICKET-6438 > Project: Wicket > Issue Type: Improvement > Components: guide >Affects Versions: 8.0.0 >Reporter: Ahmet Yaşar Özer >Assignee: Andrea Del Bene >Priority: Minor > Labels: documentation > > Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during > maven packaging phase: > WARNING: image to embed not found or not readable: > F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg > Minor fix in contributing.adoc: Revised the generated document target > directory for the user guide documentation. > Cropped top and bottom blank parts in comsysto-logo.png to have the > Introduction page fit in one page in PDF. Made minor changes in > helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6438) 8.x reference guide needs a few minor improvements
[ https://issues.apache.org/jira/browse/WICKET-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115560#comment-16115560 ] ASF GitHub Bot commented on WICKET-6438: Github user ozeray commented on the issue: https://github.com/apache/wicket/pull/229 Added github forking step into Contribution section. Made a few minor changes to adapt with this new step. > 8.x reference guide needs a few minor improvements > -- > > Key: WICKET-6438 > URL: https://issues.apache.org/jira/browse/WICKET-6438 > Project: Wicket > Issue Type: Improvement > Components: guide >Affects Versions: 8.0.0 >Reporter: Ahmet Yaşar Özer >Assignee: Andrea Del Bene >Priority: Minor > Labels: documentation > > Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during > maven packaging phase: > WARNING: image to embed not found or not readable: > F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg > Minor fix in contributing.adoc: Revised the generated document target > directory for the user guide documentation. > Cropped top and bottom blank parts in comsysto-logo.png to have the > Introduction page fit in one page in PDF. Made minor changes in > helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6438) 8.x reference guide needs a few minor improvements
[ https://issues.apache.org/jira/browse/WICKET-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115561#comment-16115561 ] ASF GitHub Bot commented on WICKET-6438: Github user ozeray closed the pull request at: https://github.com/apache/wicket/pull/229 > 8.x reference guide needs a few minor improvements > -- > > Key: WICKET-6438 > URL: https://issues.apache.org/jira/browse/WICKET-6438 > Project: Wicket > Issue Type: Improvement > Components: guide >Affects Versions: 8.0.0 >Reporter: Ahmet Yaşar Özer >Assignee: Andrea Del Bene >Priority: Minor > Labels: documentation > > Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during > maven packaging phase: > WARNING: image to embed not found or not readable: > F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg > Minor fix in contributing.adoc: Revised the generated document target > directory for the user guide documentation. > Cropped top and bottom blank parts in comsysto-logo.png to have the > Introduction page fit in one page in PDF. Made minor changes in > helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6438) 8.x reference guide needs a few minor improvements
[ https://issues.apache.org/jira/browse/WICKET-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115562#comment-16115562 ] ASF GitHub Bot commented on WICKET-6438: Github user ozeray commented on the issue: https://github.com/apache/wicket/pull/229 Closed by fault. Sorry. Reopened the pull request. > 8.x reference guide needs a few minor improvements > -- > > Key: WICKET-6438 > URL: https://issues.apache.org/jira/browse/WICKET-6438 > Project: Wicket > Issue Type: Improvement > Components: guide >Affects Versions: 8.0.0 >Reporter: Ahmet Yaşar Özer >Assignee: Andrea Del Bene >Priority: Minor > Labels: documentation > > Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during > maven packaging phase: > WARNING: image to embed not found or not readable: > F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg > Minor fix in contributing.adoc: Revised the generated document target > directory for the user guide documentation. > Cropped top and bottom blank parts in comsysto-logo.png to have the > Introduction page fit in one page in PDF. Made minor changes in > helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6438) 8.x reference guide needs a few minor improvements
[ https://issues.apache.org/jira/browse/WICKET-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115563#comment-16115563 ] ASF GitHub Bot commented on WICKET-6438: GitHub user ozeray reopened a pull request: https://github.com/apache/wicket/pull/229 WICKET-6438 - 8.x reference guide needs a few minor improvements Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during maven packaging phase: WARNING: image to embed not found or not readable: F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg Minor fix in contributing.adoc: Revised the generated document target directory for the user guide documentation. Cropped top and bottom blank parts in comsysto-logo.png to have the Introduction page fit in one page in PDF. Made minor changes in helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ozeray/wicket master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/229.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #229 commit 9e323be5eecba1052414e22f4d3505bbc5863238 Author: ozeray Date: 2017-08-06T00:12:03Z A few minor improvements Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during maven packaging phase: WARNING: image to embed not found or not readable: F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg Minor fix in contributing.adoc: Revised the generated document target directory for the user guide documentation. Cropped top and bottom blank parts in comsysto-logo.png to have the Introduction page fit in one page in PDF. Made minor changes in helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. commit 149134dbea8bb99253853338f471a2dab207733c Author: ozeray Date: 2017-08-06T00:42:04Z Added github forking step into Contribution section. Made a few minor changes to adapt with this new step. > 8.x reference guide needs a few minor improvements > -- > > Key: WICKET-6438 > URL: https://issues.apache.org/jira/browse/WICKET-6438 > Project: Wicket > Issue Type: Improvement > Components: guide >Affects Versions: 8.0.0 >Reporter: Ahmet Yaşar Özer >Assignee: Andrea Del Bene >Priority: Minor > Labels: documentation > > Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during > maven packaging phase: > WARNING: image to embed not found or not readable: > F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg > Minor fix in contributing.adoc: Revised the generated document target > directory for the user guide documentation. > Cropped top and bottom blank parts in comsysto-logo.png to have the > Introduction page fit in one page in PDF. Made minor changes in > helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6438) 8.x reference guide needs a few minor improvements
[ https://issues.apache.org/jira/browse/WICKET-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115778#comment-16115778 ] ASF GitHub Bot commented on WICKET-6438: Github user martin-g commented on a diff in the pull request: https://github.com/apache/wicket/pull/229#discussion_r131541043 --- Diff: wicket-user-guide/src/main/asciidoc/introduction.adoc --- @@ -27,8 +26,7 @@ Editors: *Joachim Rohde* -*PS*: this guide is based on Wicket 6. However if you are using an older version you should find this guide useful as well, but it's likely that the code and the snippets won't work with your version. - +*PS*: this guide is based on Wicket 6. However if you are using an older version you should find this guide useful as well, but it's likely that the code and the snippets won't work with your version. + --- End diff -- Note to the one merging this PR: It should be `Wicket 8` instead of `6` > 8.x reference guide needs a few minor improvements > -- > > Key: WICKET-6438 > URL: https://issues.apache.org/jira/browse/WICKET-6438 > Project: Wicket > Issue Type: Improvement > Components: guide >Affects Versions: 8.0.0 >Reporter: Ahmet Yaşar Özer >Assignee: Andrea Del Bene >Priority: Minor > Labels: documentation > > Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during > maven packaging phase: > WARNING: image to embed not found or not readable: > F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg > Minor fix in contributing.adoc: Revised the generated document target > directory for the user guide documentation. > Cropped top and bottom blank parts in comsysto-logo.png to have the > Introduction page fit in one page in PDF. Made minor changes in > helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6437) Libraries should be updated to most recent versions
[ https://issues.apache.org/jira/browse/WICKET-6437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115781#comment-16115781 ] ASF GitHub Bot commented on WICKET-6437: Github user asfgit closed the pull request at: https://github.com/apache/wicket/pull/228 > Libraries should be updated to most recent versions > --- > > Key: WICKET-6437 > URL: https://issues.apache.org/jira/browse/WICKET-6437 > Project: Wicket > Issue Type: Improvement > Components: release >Affects Versions: 8.0.0-M6 >Reporter: Maxim Solodovnik >Assignee: Martin Grigorov > > Libraries should be updated to most recent versions -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6438) 8.x reference guide needs a few minor improvements
[ https://issues.apache.org/jira/browse/WICKET-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115828#comment-16115828 ] ASF GitHub Bot commented on WICKET-6438: Github user ozeray commented on the issue: https://github.com/apache/wicket/pull/229 Implemented Martin's diff request. Made some more improvements on 8.x reference documentation. > 8.x reference guide needs a few minor improvements > -- > > Key: WICKET-6438 > URL: https://issues.apache.org/jira/browse/WICKET-6438 > Project: Wicket > Issue Type: Improvement > Components: guide >Affects Versions: 8.0.0 >Reporter: Ahmet Yaşar Özer >Assignee: Andrea Del Bene >Priority: Minor > Labels: documentation > > Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during > maven packaging phase: > WARNING: image to embed not found or not readable: > F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg > Minor fix in contributing.adoc: Revised the generated document target > directory for the user guide documentation. > Cropped top and bottom blank parts in comsysto-logo.png to have the > Introduction page fit in one page in PDF. Made minor changes in > helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6438) 8.x reference guide needs a few minor improvements
[ https://issues.apache.org/jira/browse/WICKET-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124594#comment-16124594 ] ASF GitHub Bot commented on WICKET-6438: Github user bitstorm commented on the issue: https://github.com/apache/wicket/pull/229 hi @ozeray , please close this issue as i don't have the rights to do it > 8.x reference guide needs a few minor improvements > -- > > Key: WICKET-6438 > URL: https://issues.apache.org/jira/browse/WICKET-6438 > Project: Wicket > Issue Type: Improvement > Components: guide >Affects Versions: 8.0.0 >Reporter: Ahmet Yaşar Özer >Assignee: Andrea Del Bene >Priority: Minor > Labels: documentation > > Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during > maven packaging phase: > WARNING: image to embed not found or not readable: > F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg > Minor fix in contributing.adoc: Revised the generated document target > directory for the user guide documentation. > Cropped top and bottom blank parts in comsysto-logo.png to have the > Introduction page fit in one page in PDF. Made minor changes in > helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6438) 8.x reference guide needs a few minor improvements
[ https://issues.apache.org/jira/browse/WICKET-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125255#comment-16125255 ] ASF GitHub Bot commented on WICKET-6438: Github user klopfdreh commented on the issue: https://github.com/apache/wicket/pull/229 The changes of the PR are integrated with commit 075d8371ef3eb2e5f3bdadf008ae904cafd222b3 > 8.x reference guide needs a few minor improvements > -- > > Key: WICKET-6438 > URL: https://issues.apache.org/jira/browse/WICKET-6438 > Project: Wicket > Issue Type: Improvement > Components: guide >Affects Versions: 8.0.0 >Reporter: Ahmet Yaşar Özer >Assignee: Andrea Del Bene >Priority: Minor > Labels: documentation > > Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during > maven packaging phase: > WARNING: image to embed not found or not readable: > F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg > Minor fix in contributing.adoc: Revised the generated document target > directory for the user guide documentation. > Cropped top and bottom blank parts in comsysto-logo.png to have the > Introduction page fit in one page in PDF. Made minor changes in > helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6457) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145374#comment-16145374
]
ASF GitHub Bot commented on WICKET-6457:
GitHub user papegaaij opened a pull request:
https://github.com/apache/wicket/pull/231
WICKET-6457: clear updating boolean when attribute is bound
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/topicusonderwijs/wicket fix-WICKET-6457
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/wicket/pull/231.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #231
commit 61c89369c4016154cd333e204a20c9030249481d
Author: Emond Papegaaij
Date: 2017-08-29T14:25:43Z
WICKET-6457: clear updating boolean when attribute is bound
> PageStore not cleared at session end
>
>
> Key: WICKET-6457
> URL: https://issues.apache.org/jira/browse/WICKET-6457
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Undertow
>Reporter: Emond Papegaaij
>Priority: Critical
>
> WICKET-6387 causes the page store not to be cleared at logout on Undertow.
> The problem is that Undertow does not call {{valueUnbound}} when an attribute
> is set to the current value (new == old). It does however call {{valueBound}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6457) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145961#comment-16145961
]
ASF GitHub Bot commented on WICKET-6457:
Github user svenmeier commented on the issue:
https://github.com/apache/wicket/pull/231
+1 looks good
> PageStore not cleared at session end
>
>
> Key: WICKET-6457
> URL: https://issues.apache.org/jira/browse/WICKET-6457
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Undertow
>Reporter: Emond Papegaaij
>Priority: Critical
>
> WICKET-6387 causes the page store not to be cleared at logout on Undertow.
> The problem is that Undertow does not call {{valueUnbound}} when an attribute
> is set to the current value (new == old). It does however call {{valueBound}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6457) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146797#comment-16146797
]
ASF GitHub Bot commented on WICKET-6457:
Github user martin-g commented on the issue:
https://github.com/apache/wicket/pull/231
+1
> PageStore not cleared at session end
>
>
> Key: WICKET-6457
> URL: https://issues.apache.org/jira/browse/WICKET-6457
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Undertow
>Reporter: Emond Papegaaij
>Priority: Critical
>
> WICKET-6387 causes the page store not to be cleared at logout on Undertow.
> The problem is that Undertow does not call {{valueUnbound}} when an attribute
> is set to the current value (new == old). It does however call {{valueBound}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6457) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147069#comment-16147069
]
ASF GitHub Bot commented on WICKET-6457:
Github user papegaaij closed the pull request at:
https://github.com/apache/wicket/pull/231
> PageStore not cleared at session end
>
>
> Key: WICKET-6457
> URL: https://issues.apache.org/jira/browse/WICKET-6457
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Undertow
>Reporter: Emond Papegaaij
>Priority: Critical
>
> WICKET-6387 causes the page store not to be cleared at logout on Undertow.
> The problem is that Undertow does not call {{valueUnbound}} when an attribute
> is set to the current value (new == old). It does however call {{valueBound}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6459) Ajax re-renders of enclosures do not render their children's header contributions
[ https://issues.apache.org/jira/browse/WICKET-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152559#comment-16152559 ] ASF GitHub Bot commented on WICKET-6459: GitHub user disblader opened a pull request: https://github.com/apache/wicket/pull/232 Ajax inline enclosure fix. A fix for the issue I described in WICKET-6459. I've made this for 7.x as that's the version relevant for me, but I'd like it to be propogate to 8.x as well, how would I do that? Should I create a new pull request trying to merge this branch into 8.x? You can merge this pull request into a Git repository by running: $ git pull https://github.com/disblader/wicket enclosure-ajax Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/232.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #232 commit 3b21b3a1d2a2220452eac74ec19e78b2c2d6da4a Author: Domas Poliakas Date: 2017-09-01T16:39:42Z Ajax inline enclosure fix. > Ajax re-renders of enclosures do not render their children's header > contributions > - > > Key: WICKET-6459 > URL: https://issues.apache.org/jira/browse/WICKET-6459 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 8.0.0-M6, 7.8.0 >Reporter: Domas Poliakas >Priority: Minor > > When a component in an enclosure is added to the AjaxRequestTarget, its (and > subsequently its children's) header contributions are not rendered. > AjaxEnclosureListener replaces any components with enclosures that are in the > target with their enclosures. However, in the wicket hierarchy the enclosures > appear to be siblings to the components they enclose. What this causes is > that when the default ChildFirstHeaderRenderStrategy attempts to render the > header contributions for the enclosure, nothing is rendered as the enclosure > itself has no children in the hierarchy. > On one hand, ChildFirstHeaderRenderStrategy seems to be the culprit - it > should detect enclosures and act accordingly - but fixing the problem there > would cause it to resurface in the future if the default implementation of > header render strategy is changed. What would be a correct way fix for this? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6459) Ajax re-renders of enclosures do not render their children's header contributions
[
https://issues.apache.org/jira/browse/WICKET-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152858#comment-16152858
]
ASF GitHub Bot commented on WICKET-6459:
Github user martin-g commented on a diff in the pull request:
https://github.com/apache/wicket/pull/232#discussion_r136861843
--- Diff:
wicket-core/src/test/java/org/apache/wicket/markup/renderStrategy/ChildFirstHeaderRenderStrategyTest.java
---
@@ -51,6 +57,39 @@ public void test2() throws Exception
}
/**
+* Tests that when a controller of an enclosure is added to the ajax
target, its header
+* contributions reach the response
+*
+* WICKET-6459
+*
+*/
+ @Test
+ public void testAjaxAndEnclosures() throws Exception
+ {
+
+ tester.startPage(SimplePage3.class);
--- End diff --
Let's rename the page name to `InlineEnclosureAjaxRenderPage`.
`SimplePage`s are legacy, but for new stuff we should try better! :-)
> Ajax re-renders of enclosures do not render their children's header
> contributions
> -
>
> Key: WICKET-6459
> URL: https://issues.apache.org/jira/browse/WICKET-6459
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 8.0.0-M6, 7.8.0
>Reporter: Domas Poliakas
>Priority: Minor
>
> When a component in an enclosure is added to the AjaxRequestTarget, its (and
> subsequently its children's) header contributions are not rendered.
> AjaxEnclosureListener replaces any components with enclosures that are in the
> target with their enclosures. However, in the wicket hierarchy the enclosures
> appear to be siblings to the components they enclose. What this causes is
> that when the default ChildFirstHeaderRenderStrategy attempts to render the
> header contributions for the enclosure, nothing is rendered as the enclosure
> itself has no children in the hierarchy.
> On one hand, ChildFirstHeaderRenderStrategy seems to be the culprit - it
> should detect enclosures and act accordingly - but fixing the problem there
> would cause it to resurface in the future if the default implementation of
> header render strategy is changed. What would be a correct way fix for this?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6459) Ajax re-renders of enclosures do not render their children's header contributions
[
https://issues.apache.org/jira/browse/WICKET-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152871#comment-16152871
]
ASF GitHub Bot commented on WICKET-6459:
Github user disblader commented on a diff in the pull request:
https://github.com/apache/wicket/pull/232#discussion_r136863271
--- Diff:
wicket-core/src/test/java/org/apache/wicket/markup/renderStrategy/ChildFirstHeaderRenderStrategyTest.java
---
@@ -51,6 +57,39 @@ public void test2() throws Exception
}
/**
+* Tests that when a controller of an enclosure is added to the ajax
target, its header
+* contributions reach the response
+*
+* WICKET-6459
+*
+*/
+ @Test
+ public void testAjaxAndEnclosures() throws Exception
+ {
+
+ tester.startPage(SimplePage3.class);
--- End diff --
I renamed it to `EnclosureAjaxRenderPage`, since it actually tests for both
regular and inline enclosures
> Ajax re-renders of enclosures do not render their children's header
> contributions
> -
>
> Key: WICKET-6459
> URL: https://issues.apache.org/jira/browse/WICKET-6459
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 8.0.0-M6, 7.8.0
>Reporter: Domas Poliakas
>Priority: Minor
>
> When a component in an enclosure is added to the AjaxRequestTarget, its (and
> subsequently its children's) header contributions are not rendered.
> AjaxEnclosureListener replaces any components with enclosures that are in the
> target with their enclosures. However, in the wicket hierarchy the enclosures
> appear to be siblings to the components they enclose. What this causes is
> that when the default ChildFirstHeaderRenderStrategy attempts to render the
> header contributions for the enclosure, nothing is rendered as the enclosure
> itself has no children in the hierarchy.
> On one hand, ChildFirstHeaderRenderStrategy seems to be the culprit - it
> should detect enclosures and act accordingly - but fixing the problem there
> would cause it to resurface in the future if the default implementation of
> header render strategy is changed. What would be a correct way fix for this?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6459) Ajax re-renders of enclosures do not render their children's header contributions
[ https://issues.apache.org/jira/browse/WICKET-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152950#comment-16152950 ] ASF GitHub Bot commented on WICKET-6459: Github user disblader closed the pull request at: https://github.com/apache/wicket/pull/232 > Ajax re-renders of enclosures do not render their children's header > contributions > - > > Key: WICKET-6459 > URL: https://issues.apache.org/jira/browse/WICKET-6459 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 8.0.0-M6, 7.8.0 >Reporter: Domas Poliakas >Assignee: Martin Grigorov >Priority: Minor > Fix For: 7.9.0, 8.0.0-M8 > > > When a component in an enclosure is added to the AjaxRequestTarget, its (and > subsequently its children's) header contributions are not rendered. > AjaxEnclosureListener replaces any components with enclosures that are in the > target with their enclosures. However, in the wicket hierarchy the enclosures > appear to be siblings to the components they enclose. What this causes is > that when the default ChildFirstHeaderRenderStrategy attempts to render the > header contributions for the enclosure, nothing is rendered as the enclosure > itself has no children in the hierarchy. > On one hand, ChildFirstHeaderRenderStrategy seems to be the culprit - it > should detect enclosures and act accordingly - but fixing the problem there > would cause it to resurface in the future if the default implementation of > header render strategy is changed. What would be a correct way fix for this? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6438) 8.x reference guide needs a few minor improvements
[ https://issues.apache.org/jira/browse/WICKET-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153336#comment-16153336 ] ASF GitHub Bot commented on WICKET-6438: Github user bitstorm commented on the issue: https://github.com/apache/wicket/pull/229 @ozeray , could you please close this PR? Thank you! > 8.x reference guide needs a few minor improvements > -- > > Key: WICKET-6438 > URL: https://issues.apache.org/jira/browse/WICKET-6438 > Project: Wicket > Issue Type: Improvement > Components: guide >Affects Versions: 8.0.0 >Reporter: Ahmet Yaşar Özer >Assignee: Andrea Del Bene >Priority: Minor > Labels: documentation > > Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during > maven packaging phase: > WARNING: image to embed not found or not readable: > F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg > Minor fix in contributing.adoc: Revised the generated document target > directory for the user guide documentation. > Cropped top and bottom blank parts in comsysto-logo.png to have the > Introduction page fit in one page in PDF. Made minor changes in > helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6438) 8.x reference guide needs a few minor improvements
[ https://issues.apache.org/jira/browse/WICKET-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153378#comment-16153378 ] ASF GitHub Bot commented on WICKET-6438: Github user ozeray closed the pull request at: https://github.com/apache/wicket/pull/229 > 8.x reference guide needs a few minor improvements > -- > > Key: WICKET-6438 > URL: https://issues.apache.org/jira/browse/WICKET-6438 > Project: Wicket > Issue Type: Improvement > Components: guide >Affects Versions: 8.0.0 >Reporter: Ahmet Yaşar Özer >Assignee: Andrea Del Bene >Priority: Minor > Labels: documentation > > Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during > maven packaging phase: > WARNING: image to embed not found or not readable: > F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg > Minor fix in contributing.adoc: Revised the generated document target > directory for the user guide documentation. > Cropped top and bottom blank parts in comsysto-logo.png to have the > Introduction page fit in one page in PDF. Made minor changes in > helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6465) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16160272#comment-16160272
]
ASF GitHub Bot commented on WICKET-6465:
GitHub user svenmeier opened a pull request:
https://github.com/apache/wicket/pull/233
WICKET-6465 prevent unbound during storeTouchedPages only
Why so complicated? We just want to prevent valueUnbound() from doing any
harm while we're resetting the attribute during storeTouchedPages.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/svenmeier/wicket master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/wicket/pull/233.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #233
commit 8c7497144311923f7761e26eadedadfc9046f48e
Author: Sven Meier
Date: 2017-09-10T08:36:00Z
WICKET-6465 prevent unbound during storeTouchedPages only
> PageStore not cleared at session end
>
>
> Key: WICKET-6465
> URL: https://issues.apache.org/jira/browse/WICKET-6465
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Tomcat
>Reporter: Franta Mejta
>Assignee: Emond Papegaaij
>Priority: Critical
>
> WICKET-6387 causes the page store not to be cleared at logout on Tomcat. The
> problem is that tomcat does not call {{valueUnbound}} or {{valueBound}} when
> an attribute is set to the current value (new == old).
> https://github.com/apache/tomcat/blob/e28b35c9e40aeb4b7ac52a98f07ad965630e2766/java/org/apache/catalina/session/StandardSession.java#L1424
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6465) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16161024#comment-16161024
]
ASF GitHub Bot commented on WICKET-6465:
Github user bitstorm commented on the issue:
https://github.com/apache/wicket/pull/233
We should consider method Session.destroy() to remove pages when session
expires. See my comment at https://issues.apache.org/jira/browse/WICKET-6465
> PageStore not cleared at session end
>
>
> Key: WICKET-6465
> URL: https://issues.apache.org/jira/browse/WICKET-6465
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Tomcat
>Reporter: Franta Mejta
>Assignee: Emond Papegaaij
>Priority: Critical
> Attachments: WICKET-6465.patch
>
>
> WICKET-6387 causes the page store not to be cleared at logout on Tomcat. The
> problem is that tomcat does not call {{valueUnbound}} or {{valueBound}} when
> an attribute is set to the current value (new == old).
> https://github.com/apache/tomcat/blob/e28b35c9e40aeb4b7ac52a98f07ad965630e2766/java/org/apache/catalina/session/StandardSession.java#L1424
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6465) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16161115#comment-16161115
]
ASF GitHub Bot commented on WICKET-6465:
Github user martin-g commented on the issue:
https://github.com/apache/wicket/pull/233
When the session expires or is invalidated via API call then
`#valueUnbound()` is called and this clears the storages.
This is how it worked last time I worked in this area of the code.
> PageStore not cleared at session end
>
>
> Key: WICKET-6465
> URL: https://issues.apache.org/jira/browse/WICKET-6465
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Tomcat
>Reporter: Franta Mejta
>Assignee: Emond Papegaaij
>Priority: Critical
> Attachments: WICKET-6465.patch
>
>
> WICKET-6387 causes the page store not to be cleared at logout on Tomcat. The
> problem is that tomcat does not call {{valueUnbound}} or {{valueBound}} when
> an attribute is set to the current value (new == old).
> https://github.com/apache/tomcat/blob/e28b35c9e40aeb4b7ac52a98f07ad965630e2766/java/org/apache/catalina/session/StandardSession.java#L1424
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6465) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16161131#comment-16161131
]
ASF GitHub Bot commented on WICKET-6465:
Github user papegaaij commented on the issue:
https://github.com/apache/wicket/pull/233
Indeed, Sesison.destroy() is only called under certain conditions, and in
those conditions, valueUnbound() will also be called.
> PageStore not cleared at session end
>
>
> Key: WICKET-6465
> URL: https://issues.apache.org/jira/browse/WICKET-6465
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Tomcat
>Reporter: Franta Mejta
>Assignee: Emond Papegaaij
>Priority: Critical
> Attachments: WICKET-6465.patch
>
>
> WICKET-6387 causes the page store not to be cleared at logout on Tomcat. The
> problem is that tomcat does not call {{valueUnbound}} or {{valueBound}} when
> an attribute is set to the current value (new == old).
> https://github.com/apache/tomcat/blob/e28b35c9e40aeb4b7ac52a98f07ad965630e2766/java/org/apache/catalina/session/StandardSession.java#L1424
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6465) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16161313#comment-16161313
]
ASF GitHub Bot commented on WICKET-6465:
Github user bitstorm commented on the issue:
https://github.com/apache/wicket/pull/233
I see. thank you for the clarification. Still, I'd like to evaluate more
structural solutions, at least for Wicket 8. A good start point might be
HttpSessionStore.SessionBindingListener#valueUnbound.
It's already used to call Session#onInvalidate and we can add
Session#clear() after it.
> PageStore not cleared at session end
>
>
> Key: WICKET-6465
> URL: https://issues.apache.org/jira/browse/WICKET-6465
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Tomcat
>Reporter: Franta Mejta
>Assignee: Emond Papegaaij
>Priority: Critical
> Attachments: WICKET-6465.patch
>
>
> WICKET-6387 causes the page store not to be cleared at logout on Tomcat. The
> problem is that tomcat does not call {{valueUnbound}} or {{valueBound}} when
> an attribute is set to the current value (new == old).
> https://github.com/apache/tomcat/blob/e28b35c9e40aeb4b7ac52a98f07ad965630e2766/java/org/apache/catalina/session/StandardSession.java#L1424
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6465) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16161726#comment-16161726
]
ASF GitHub Bot commented on WICKET-6465:
Github user svenmeier commented on the issue:
https://github.com/apache/wicket/pull/233
Currently HttpSessionStore and PageStoreManager each use their own instance
of HttpSessionBindingListener.
Yes, we might be able to unify these. But with a simple fix we don't
introduce even more - possibly faulty - changes.
It was unfortunate that we didn't consider all possible callbacks from
Servlet containers when this problem started with WICKET-6356.
IMHO we should go with the simplest fix: Prevent anything bad from
happening, when re-setting the session attribute:
- clustering will work (because the attribute is re-set)
- it doesn't matter whether the container calls valueBound() or not
- if the container calls valueUnbound(), it does nothing bad during
storeTouchedPages()
Andrea, what do you think?
BTW do we have to take care of concurrent access to the SessionEntry? I see
that Martin used an AtomicBoolean, but how does that help if there are two
request simultaneously storing touched pages?
> PageStore not cleared at session end
>
>
> Key: WICKET-6465
> URL: https://issues.apache.org/jira/browse/WICKET-6465
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Tomcat
>Reporter: Franta Mejta
>Assignee: Emond Papegaaij
>Priority: Critical
> Attachments: WICKET-6465.patch
>
>
> WICKET-6387 causes the page store not to be cleared at logout on Tomcat. The
> problem is that tomcat does not call {{valueUnbound}} or {{valueBound}} when
> an attribute is set to the current value (new == old).
> https://github.com/apache/tomcat/blob/e28b35c9e40aeb4b7ac52a98f07ad965630e2766/java/org/apache/catalina/session/StandardSession.java#L1424
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6465) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16161858#comment-16161858
]
ASF GitHub Bot commented on WICKET-6465:
Github user bitstorm commented on the issue:
https://github.com/apache/wicket/pull/233
I'm fine with this quick fix, but I warmly suggest to improve it after it
has been applied, at least in master branch.
About concurrent access afaik we do have to take care of concurrency. At
the moment we don't have any guarantee that setSessionAttribute saves the entry
for the last request submitted (for the same session).
> PageStore not cleared at session end
>
>
> Key: WICKET-6465
> URL: https://issues.apache.org/jira/browse/WICKET-6465
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Tomcat
>Reporter: Franta Mejta
>Assignee: Emond Papegaaij
>Priority: Critical
> Attachments: WICKET-6465.patch
>
>
> WICKET-6387 causes the page store not to be cleared at logout on Tomcat. The
> problem is that tomcat does not call {{valueUnbound}} or {{valueBound}} when
> an attribute is set to the current value (new == old).
> https://github.com/apache/tomcat/blob/e28b35c9e40aeb4b7ac52a98f07ad965630e2766/java/org/apache/catalina/session/StandardSession.java#L1424
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6465) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16162574#comment-16162574
]
ASF GitHub Bot commented on WICKET-6465:
Github user papegaaij commented on the issue:
https://github.com/apache/wicket/pull/233
I don't see why the current implementation uses `AtomicBoolean`. The
current implementation could just as well use a normal boolean. If we need to
take concurrent access into account (and I think we do), we should probably use
a `ThreadLocal`. Of course this assumes that the servlet container will call
(un)bound from the same thread, but the current implementation already has that
assumption. If a container decides to make the calls async, there is no way of
telling if it will happen between the setting and clearing of the boolean.
> PageStore not cleared at session end
>
>
> Key: WICKET-6465
> URL: https://issues.apache.org/jira/browse/WICKET-6465
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Tomcat
>Reporter: Franta Mejta
>Assignee: Emond Papegaaij
>Priority: Critical
> Attachments: WICKET-6465.patch
>
>
> WICKET-6387 causes the page store not to be cleared at logout on Tomcat. The
> problem is that tomcat does not call {{valueUnbound}} or {{valueBound}} when
> an attribute is set to the current value (new == old).
> https://github.com/apache/tomcat/blob/e28b35c9e40aeb4b7ac52a98f07ad965630e2766/java/org/apache/catalina/session/StandardSession.java#L1424
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6465) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16162651#comment-16162651
]
ASF GitHub Bot commented on WICKET-6465:
Github user bitstorm commented on the issue:
https://github.com/apache/wicket/pull/233
I agree about the use of a normal boolean, but I'm not sure I've understood
your idea about ThreadLocal. What I would like to do is to prevent race
conditions inside storeTouchedPages. I would do it using synchronized on entry
object:
```
protected void storeTouchedPages(final List touchedPages)
{
if (!touchedPages.isEmpty())
{
SessionEntry entry = getSessionEntry(true);
synchronized (entry)
{
entry.setSessionCache(touchedPages);
for (IManageablePage page : touchedPages)
{
// WICKET-5103 use the same sessionId as used
in SessionEntry#getPage()
pageStore.storePage(entry.sessionId, page);
}
entry.updating.set(true);
setSessionAttribute(getAttributeName(), entry);
}
}
}
```
In this way two possible concurrent requests for the same session would
execute storeTouchedPages one at a time.
> PageStore not cleared at session end
>
>
> Key: WICKET-6465
> URL: https://issues.apache.org/jira/browse/WICKET-6465
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Tomcat
>Reporter: Franta Mejta
>Assignee: Emond Papegaaij
>Priority: Critical
> Attachments: WICKET-6465.patch
>
>
> WICKET-6387 causes the page store not to be cleared at logout on Tomcat. The
> problem is that tomcat does not call {{valueUnbound}} or {{valueBound}} when
> an attribute is set to the current value (new == old).
> https://github.com/apache/tomcat/blob/e28b35c9e40aeb4b7ac52a98f07ad965630e2766/java/org/apache/catalina/session/StandardSession.java#L1424
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6465) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16162667#comment-16162667
]
ASF GitHub Bot commented on WICKET-6465:
Github user papegaaij commented on the issue:
https://github.com/apache/wicket/pull/233
We don't care about concurrent calls to valueUnbound, that's fine. All code
in that method is thread safe. What we don't want is multiple calls to
storeTouchedPages and valueUnbound (session expiry) to interfere with each
other. Synchronizing on the entry will not help as session expiry is probably
done from a different thread.
> PageStore not cleared at session end
>
>
> Key: WICKET-6465
> URL: https://issues.apache.org/jira/browse/WICKET-6465
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Tomcat
>Reporter: Franta Mejta
>Assignee: Emond Papegaaij
>Priority: Critical
> Attachments: WICKET-6465.patch
>
>
> WICKET-6387 causes the page store not to be cleared at logout on Tomcat. The
> problem is that tomcat does not call {{valueUnbound}} or {{valueBound}} when
> an attribute is set to the current value (new == old).
> https://github.com/apache/tomcat/blob/e28b35c9e40aeb4b7ac52a98f07ad965630e2766/java/org/apache/catalina/session/StandardSession.java#L1424
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6465) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16164236#comment-16164236
]
ASF GitHub Bot commented on WICKET-6465:
Github user papegaaij commented on the issue:
https://github.com/apache/wicket/pull/233
Yes, this is what I had in mind. I'm ok to merge this in 7.x and 8.
> PageStore not cleared at session end
>
>
> Key: WICKET-6465
> URL: https://issues.apache.org/jira/browse/WICKET-6465
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Tomcat
>Reporter: Franta Mejta
>Assignee: Emond Papegaaij
>Priority: Critical
> Attachments: WICKET-6465.patch
>
>
> WICKET-6387 causes the page store not to be cleared at logout on Tomcat. The
> problem is that tomcat does not call {{valueUnbound}} or {{valueBound}} when
> an attribute is set to the current value (new == old).
> https://github.com/apache/tomcat/blob/e28b35c9e40aeb4b7ac52a98f07ad965630e2766/java/org/apache/catalina/session/StandardSession.java#L1424
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6465) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16165154#comment-16165154
]
ASF GitHub Bot commented on WICKET-6465:
Github user bitstorm commented on the issue:
https://github.com/apache/wicket/pull/233
Don't forget to fix brackets indentation before commit
> PageStore not cleared at session end
>
>
> Key: WICKET-6465
> URL: https://issues.apache.org/jira/browse/WICKET-6465
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Tomcat
>Reporter: Franta Mejta
>Assignee: Emond Papegaaij
>Priority: Critical
> Attachments: WICKET-6465.patch
>
>
> WICKET-6387 causes the page store not to be cleared at logout on Tomcat. The
> problem is that tomcat does not call {{valueUnbound}} or {{valueBound}} when
> an attribute is set to the current value (new == old).
> https://github.com/apache/tomcat/blob/e28b35c9e40aeb4b7ac52a98f07ad965630e2766/java/org/apache/catalina/session/StandardSession.java#L1424
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6465) PageStore not cleared at session end
[
https://issues.apache.org/jira/browse/WICKET-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16165373#comment-16165373
]
ASF GitHub Bot commented on WICKET-6465:
Github user asfgit closed the pull request at:
https://github.com/apache/wicket/pull/233
> PageStore not cleared at session end
>
>
> Key: WICKET-6465
> URL: https://issues.apache.org/jira/browse/WICKET-6465
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
> Environment: Tomcat
>Reporter: Franta Mejta
>Assignee: Emond Papegaaij
>Priority: Critical
> Attachments: WICKET-6465.patch
>
>
> WICKET-6387 causes the page store not to be cleared at logout on Tomcat. The
> problem is that tomcat does not call {{valueUnbound}} or {{valueBound}} when
> an attribute is set to the current value (new == old).
> https://github.com/apache/tomcat/blob/e28b35c9e40aeb4b7ac52a98f07ad965630e2766/java/org/apache/catalina/session/StandardSession.java#L1424
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6476) It is impossible to use multiple WebSocketTester with the same WebApplication
[ https://issues.apache.org/jira/browse/WICKET-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189262#comment-16189262 ] ASF GitHub Bot commented on WICKET-6476: GitHub user solomax opened a pull request: https://github.com/apache/wicket/pull/236 [WICKET-6476] check is added while setting filter path to prevent exc… …eption You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/wicket WICKET-6476-websocket-tester Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/236.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #236 commit 58a7106d74de02cc9f193d95613b6c1f3483ca7b Author: Maxim Solodovnik Date: 2017-10-03T04:46:28Z [WICKET-6476] check is added while setting filter path to prevent exception > It is impossible to use multiple WebSocketTester with the same WebApplication > - > > Key: WICKET-6476 > URL: https://issues.apache.org/jira/browse/WICKET-6476 > Project: Wicket > Issue Type: Bug > Components: wicket-native-websocket >Affects Versions: 8.0.0-M7 >Reporter: Maxim Solodovnik >Assignee: Maxim Solodovnik >Priority: Minor > Fix For: 8.0.0-M8 > > > WebSocketTester set FilterPath for underlying Application without ant checks > The issue is: setFilterPath can be called only once. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6476) It is impossible to use multiple WebSocketTester with the same WebApplication
[ https://issues.apache.org/jira/browse/WICKET-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189425#comment-16189425 ] ASF GitHub Bot commented on WICKET-6476: Github user solomax commented on the issue: https://github.com/apache/wicket/pull/236 @martin-g Should I merge then delete the branch? Is the process of merging documented somewhere? > It is impossible to use multiple WebSocketTester with the same WebApplication > - > > Key: WICKET-6476 > URL: https://issues.apache.org/jira/browse/WICKET-6476 > Project: Wicket > Issue Type: Bug > Components: wicket-native-websocket >Affects Versions: 8.0.0-M7 >Reporter: Maxim Solodovnik >Assignee: Maxim Solodovnik >Priority: Minor > Fix For: 8.0.0-M8 > > > WebSocketTester set FilterPath for underlying Application without ant checks > The issue is: setFilterPath can be called only once. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6476) It is impossible to use multiple WebSocketTester with the same WebApplication
[ https://issues.apache.org/jira/browse/WICKET-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189472#comment-16189472 ] ASF GitHub Bot commented on WICKET-6476: Github user asfgit closed the pull request at: https://github.com/apache/wicket/pull/236 > It is impossible to use multiple WebSocketTester with the same WebApplication > - > > Key: WICKET-6476 > URL: https://issues.apache.org/jira/browse/WICKET-6476 > Project: Wicket > Issue Type: Bug > Components: wicket-native-websocket >Affects Versions: 8.0.0-M7 >Reporter: Maxim Solodovnik >Assignee: Maxim Solodovnik >Priority: Minor > Fix For: 8.0.0-M8 > > > WebSocketTester set FilterPath for underlying Application without ant checks > The issue is: setFilterPath can be called only once. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6476) It is impossible to use multiple WebSocketTester with the same WebApplication
[ https://issues.apache.org/jira/browse/WICKET-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189474#comment-16189474 ] ASF GitHub Bot commented on WICKET-6476: Github user solomax commented on the issue: https://github.com/apache/wicket/pull/236 Should this change be cherry-picked to other branches? > It is impossible to use multiple WebSocketTester with the same WebApplication > - > > Key: WICKET-6476 > URL: https://issues.apache.org/jira/browse/WICKET-6476 > Project: Wicket > Issue Type: Bug > Components: wicket-native-websocket >Affects Versions: 8.0.0-M7 >Reporter: Maxim Solodovnik >Assignee: Maxim Solodovnik >Priority: Minor > Fix For: 8.0.0-M8 > > > WebSocketTester set FilterPath for underlying Application without ant checks > The issue is: setFilterPath can be called only once. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6476) It is impossible to use multiple WebSocketTester with the same WebApplication
[ https://issues.apache.org/jira/browse/WICKET-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189501#comment-16189501 ] ASF GitHub Bot commented on WICKET-6476: Github user martin-g commented on the issue: https://github.com/apache/wicket/pull/236 1) yes, delete the branch 2) cherry-pick in 7.x > It is impossible to use multiple WebSocketTester with the same WebApplication > - > > Key: WICKET-6476 > URL: https://issues.apache.org/jira/browse/WICKET-6476 > Project: Wicket > Issue Type: Bug > Components: wicket-native-websocket >Affects Versions: 8.0.0-M7 >Reporter: Maxim Solodovnik >Assignee: Maxim Solodovnik >Priority: Minor > Fix For: 8.0.0-M8 > > > WebSocketTester set FilterPath for underlying Application without ant checks > The issue is: setFilterPath can be called only once. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6479) AjaxNewWindowNotifyingBehavior erroneously reports new window
[ https://issues.apache.org/jira/browse/WICKET-6479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199449#comment-16199449 ] ASF GitHub Bot commented on WICKET-6479: GitHub user svenmeier opened a pull request: https://github.com/apache/wicket/pull/238 WICKET-6479 keep window name If the page was not yet rendered into any window, just keep the window name as is, instead of changing it for each new page. You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/wicket WICKET-6479-new-window Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/238.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #238 commit 00e84ea1926d38496607780c8b8985cab488b758 Author: Sven Meier Date: 2017-10-10T22:05:35Z WICKET-6479 keep window name if the page was not yet rendered into any window, just keep the window name as is, instead of changing it > AjaxNewWindowNotifyingBehavior erroneously reports new window > - > > Key: WICKET-6479 > URL: https://issues.apache.org/jira/browse/WICKET-6479 > Project: Wicket > Issue Type: Bug >Affects Versions: 8.0.0-M8, 7.10.0, 6.29.0 >Reporter: Sven Meier >Assignee: Sven Meier >Priority: Minor > > When opening an 'old' page (e.g. through back button or via link to a certain > page reference), AjaxNewWindowNotifyingBehavior reports a new window. > This is wrong, when that page was in fact rendered in that same window, but > the window name has meanwhile been changed by a more recent page. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
