Re: Possible bug / edge case found where page is not detached

2021-07-24 Thread Sven Meier
Hi Bas,

that sounds like a bug.

Your quickstart didn't make it through the mailing list, would you please 
attach it to a new Jira issue?

Thanks
Sven

Am 23. Juli 2021 19:30:46 MESZ schrieb Bas Gooren :
>Hi all,
>
>Today I spent the better part of my day investigating a bug report
>regarding a hibernate LazyInitializationException.
>Since we use detaching models everywhere and (in general) never see
>such
>issues anymore, this one was interesting :-)
>
>After much debugging I found out what is happening.
>
>We have a page which has a database model + links for prev/next item
>(in
>the database).
>When the users double-clicks on one of the links, the first click is
>OK,
>and the second click throws a StalePageException during request cycle
>processing.
>
>So far, normal.
>
>However, stepping through the wicket code, this is what happens:
>
>1) Resolve to ListenerRequestHandler, execute it, throws
>StalePageException
>2) exception mapper handles this and we execute a
>RenderPageRequestHandler,
>which re-renders the page
>3) the request cycle detaches, which delegates in part
>to RequestHandlerExecutor.detach()
>4) The handlers to detach are both handlers from step 1 and 2; During
>the
>detach of ListenerRequestHandler, it initializes ListenerLogData, which
>(in
>the PageLogData ctor) throws the StalePageException again!
>5) The second handler (RenderPageRequestHandler) is not detached, thus
>all
>models in the page are not detached
>6) The user clicks on a link and boom, the models are all still
>attached
>and there we get the LazyInitializationException
>
>I think that (a) RequestHandlerExecutor.detach() should ensure all
>handlers
>are detached, and (b) that failing to collect LogData should not stop
>the
>detaching of a request handler.
>
>What do you think?
>
>I tried to make the simplest possible Quickstart to demonstrate this.
>
>Weird stuff: on the homepage of the quick start, the page is properly
>detached when a stale link is clicked;
>On another (test) page, the page is not properly detached.
>
>Steps to reproduce:
>
>Run Quickstart
>Click on “Test” link on homepage
>Observe that the following is logged:
>
>Model still attached? false
>Page detaching
>
>Now click on "Click me (stale link)!”
>Now refresh the page (re-render)
>
>Observe that the following is logged:
>
>Model still attached? true
>Page detaching
>
>—> So the page was not detached
>
>These steps don’t have the same result on the homepage. So my guess is
>there is some relation to the fact that we are interacting with a
>stateful,
>non-mounted page.
>
>Met vriendelijke groet,
>Kind regards,
>
>Bas Gooren


Re: ComponentNotFoundException during concurrent requests to the same page ?

2021-07-22 Thread Sven Meier
Hi,

> IMHO this should not happen because the link URL includes the page version 
> number and in that version of the page 

for Ajax requests the page id is not increased. So your second non-ajax request 
hits the same page instance with an updated component tree.

For these cases (mixing ajax with non-ajax inside repeaters) it's better to use 
bookmarkable links inside the table - I assume these respond with some kind of 
detail page anyways.

Hope this helps
Sven



Am 22. Juli 2021 11:15:51 MESZ schrieb Tobias Gierke 
:
>Hi,
>
>I'm currently investigating the root cause of a 
>ComponentNotFoundException in our application (Wicket 8.12) that IMHO 
>should not happen in the first place (assuming I understood Wicket page
>
>versioning correctly, that is).
>
>1. The offending page displays search results using a DataTable with 
>non-AJAX links on items in each of the rows plus one "page backwards" 
>and one "page forwards" AJAX link outside of the DataTable to switch to
>
>the next/previous page of results
>
>  
>
>+-- data table --+
>| item1    |
>++
>| item2    |
>++
>|  etc...    |
>++
>
>The crash is happening 100% of the time when doing the following:
>
>1.) Artifically increasing the round-trip time to the server by a lot 
>using NetEM (I'm on Linux), for example to a 400ms RTT:
>
>|tc qdisc add dev lo root handle ||1||:||0| |netem delay 200msec|
>
>2.) Clicking the "previous" or "next" AJAX link on the page
>3.) Immediately afterwards clicking any of the regular links inside the
>
>data table rows without waiting for the AJAX request to complete
>
>This gets me a ComponentNotFoundException
>
>org.apache.wicket.core.request.handler.ComponentNotFoundException: 
>Component 
>'resultList:streamList:streamListTable:body:rows:3:cells:3:cell:link' 
>has been removed from page.
>at 
>org.apache.wicket.core.request.handler.ListenerRequestHandler.respond(ListenerRequestHandler.java:166)
>at 
>org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:907)
>at 
>org.apache.wicket.request.RequestHandlerExecutor.execute(RequestHandlerExecutor.java:65)
>at 
>org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:293)
>at 
>org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:254)
>at 
>org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:276)
>at 
>org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
>
>every time after the AJAX request completes and releases the page lock 
>so the second HTTP request is getting processed. IMHO this should not 
>happen because the link URL (from the regular link inside the data 
>table) includes the page version number and in that version of the page
>
>object graph the Link component should still exist (we've configured
>the 
>PageStore to keep 20 versions).
>
>What am I missing here ? Is this somehow related to mixing AJAX and 
>non-AJAX requests here ? FWIW, the DataTable is using the default 
>ItemReuseStrategy.
>
>Cheers,
>Tobias


Re: RestartResponseException ajaxbutton

2021-07-21 Thread Sven Meier

Hi,

there a slight difference on how the response is rendered, see 
WebPageRenderer#shouldRedirectToTargetUrl()


    (isAjax(cycle) && targetUrl.equals(currentUrl))

This is the case for the Ajax submit creating PageOne, where - after the 
redirect - an additional page instance is created (since the URL does 
not contain a page id).
In both other cases the rendering result of the target page is buffered 
and fetch afterwards by the redirect.



Did I miss something or am I misusing RestartResponseException ?
Are the tests in the UnVersionedUrlMapper wrong ?


I don't know why you are using UnVersionedUrlMapper or where it is 
coming from, so I cannot comment on it.


Your usage of RestartResponseException seems correct.

Best regards
Sven


On 20.07.21 14:35, Francois Meillet wrote:


I have two pages (identical) called PageOne and PageTwo, each with a form, 
mounted with an UnVersionedUrlMapper.

When I do a RestartResponseException in the submit (via an AjaxButton) to the 
same page (from pageOne to pageOne),
the PageOne's constructor is called twice. (onInitialize is called once)

But If I throw RestartResponseException (via an AjaxButton) from pageOne to 
pageTwo the PageTwo's constructor is called once or if I throw 
RestartResponseException (via a standard Button) from pageOne to pageOne the 
pageOne's constructor is called once.


Tested with all the 9.x


Here is the test the UnVersionedUrlMapper # mapHandler
if (requestHandler instanceof ListenerRequestHandler || requestHandler 
instanceof BookmarkableListenerRequestHandler) {
 return null;
}
else {
 return super.mapHandler(requestHandler);
}


Did I miss something or am I misusing RestartResponseException ?
Are the tests in the UnVersionedUrlMapper wrong ?

Thanks for your help.






François



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


Re: pass error in submit method

2021-07-02 Thread Sven Meier

Hi,

sorry, IPageRequestHandler#getPage() is new in Wicket 9.x:

https://github.com/apache/wicket/blob/0c747f494d0dacc0255a2162bee559c57719f0fb/wicket-core/src/main/java/org/apache/wicket/core/request/handler/IPageRequestHandler.java#L67

You can copy that method.

Have fun
Sven


On 02.07.21 13:11, vahid ghasemi wrote:

I am trying to use the above code and I getting this error:
Non-static method 'getPage()' cannot be referenced from a static context.
my wicket version is 8.9.0.

On Tue, Jun 29, 2021 at 9:54 PM Sven Meier  wrote:


Hi,

instead of worrying about exceptions in your #onSubmit() and always
wrapping your code in catch-try, you can just use a general exception
handler:

  getRequestCycleListeners().add(new IRequestCycleListener()
  {
  @Override
  public IRequestHandler onException(RequestCycle cycle,
Exception ex)
  {
  MyCustomValidationException validation =
Exceptions.findCause(ex, MyCustomValidationException.class);
  if (validation != null) {
  Page page =
IPageRequestHandler.getPage(cycle.getActiveRequestHandler())
  if (page != null) {
  // add error messages ...
page.error(page.getString(validation.getCode()));
  return new RenderPageRequestHandler(page);
  }
  }
  return null;
  }
  });

Hope this helps
Sven


On 29.06.21 18:41, vahid ghasemi wrote:

thanks again for answering my questions.
can you send me some examples of this concept?
(IRequestCycleListener#onException())
just I want to know more about that.

On Tue, Jun 29, 2021 at 8:32 PM Sven Meier  wrote:


Hi,

you could use a FormValidator.

Or let your onSubmit() (or any code it forwards to) throw exceptions and
register an IRequestCycleListener#onException() to handle exceptions
during form submit.

Have fun
Sven


On 29.06.21 17:51, vahid ghasemi wrote:

I want to add form data to the database.
so it's not good to loading data for every input and checks from the
database.
I am using validation and when everything is ok then I connect to the
database for better performance :).
one Idea is to call the onError method into the onSubmit method. but I

want

to know is a better way to handle this situation?

On Tue, Jun 29, 2021 at 8:11 PM Maxim Solodovnik 
Maybe it would be better to perform checks during validation ?

from mobile (sorry for typos ;)


On Tue, Jun 29, 2021, 22:33 vahid ghasemi 
wrote:


Hello
How can I pass an error in an onSubmit method?
I have some errors that can detect in the onSubmit method.
I throw exceptions at end of the onSubmit method.
In the catch block, I call the error method, but after that, I expect

to

don't go into the afterOnSubmit method, but he will go and I am

getting

the wrong response.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: pass error in submit method

2021-06-29 Thread Sven Meier

Hi,

instead of worrying about exceptions in your #onSubmit() and always 
wrapping your code in catch-try, you can just use a general exception 
handler:


    getRequestCycleListeners().add(new IRequestCycleListener()
        {
            @Override
            public IRequestHandler onException(RequestCycle cycle, 
Exception ex)

            {
    MyCustomValidationException validation = 
Exceptions.findCause(ex, MyCustomValidationException.class);

    if (validation != null) {
    Page page = 
IPageRequestHandler.getPage(cycle.getActiveRequestHandler())

    if (page != null) {
    // add error messages ...
page.error(page.getString(validation.getCode()));
    return new RenderPageRequestHandler(page);
    }
    }
    return null;
        }
        });

Hope this helps
Sven


On 29.06.21 18:41, vahid ghasemi wrote:

thanks again for answering my questions.
can you send me some examples of this concept?
(IRequestCycleListener#onException())
just I want to know more about that.

On Tue, Jun 29, 2021 at 8:32 PM Sven Meier  wrote:


Hi,

you could use a FormValidator.

Or let your onSubmit() (or any code it forwards to) throw exceptions and
register an IRequestCycleListener#onException() to handle exceptions
during form submit.

Have fun
Sven


On 29.06.21 17:51, vahid ghasemi wrote:

I want to add form data to the database.
so it's not good to loading data for every input and checks from the
database.
I am using validation and when everything is ok then I connect to the
database for better performance :).
one Idea is to call the onError method into the onSubmit method. but I

want

to know is a better way to handle this situation?

On Tue, Jun 29, 2021 at 8:11 PM Maxim Solodovnik 
wrote:


Maybe it would be better to perform checks during validation ?

from mobile (sorry for typos ;)


On Tue, Jun 29, 2021, 22:33 vahid ghasemi 
wrote:


Hello
How can I pass an error in an onSubmit method?
I have some errors that can detect in the onSubmit method.
I throw exceptions at end of the onSubmit method.
In the catch block, I call the error method, but after that, I expect

to

don't go into the afterOnSubmit method, but he will go and I am getting
the wrong response.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: pass error in submit method

2021-06-29 Thread Sven Meier

Hi,

you could use a FormValidator.

Or let your onSubmit() (or any code it forwards to) throw exceptions and 
register an IRequestCycleListener#onException() to handle exceptions 
during form submit.


Have fun
Sven


On 29.06.21 17:51, vahid ghasemi wrote:

I want to add form data to the database.
so it's not good to loading data for every input and checks from the
database.
I am using validation and when everything is ok then I connect to the
database for better performance :).
one Idea is to call the onError method into the onSubmit method. but I want
to know is a better way to handle this situation?

On Tue, Jun 29, 2021 at 8:11 PM Maxim Solodovnik 
wrote:


Maybe it would be better to perform checks during validation ?

from mobile (sorry for typos ;)


On Tue, Jun 29, 2021, 22:33 vahid ghasemi 
wrote:


Hello
How can I pass an error in an onSubmit method?
I have some errors that can detect in the onSubmit method.
I throw exceptions at end of the onSubmit method.
In the catch block, I call the error method, but after that, I expect to
don't go into the afterOnSubmit method, but he will go and I am getting
the wrong response.



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: reset form

2021-06-29 Thread Sven Meier

Hi,

you have to call #setDefaultFormProcessing(false).

Have fun
Sven


On 29.06.21 09:46, vahid ghasemi wrote:

Hello guys.
I have a form that has two buttons (Submit, Reset) and my form is
CompoundPropertiesModel.
The type of these buttons are AjaxButtons.
but Reset only works when the form is valid, otherwise it goes into the
onError method.
The type of reset button tag is "reset" and also the submit button is
"submit".
Before submitting the form (and without the wicket ajax button for reset
button) the reset button is working. But after submitting when I click on
the reset button (still without the wicket ajax button) my inputs don't go
empty.
So i think my problem was for CompoundPropertiesModel and i should set
empty fields of class and i need to add a wicket button to reset button
that reset inputs.
But the reset buttons it's not working because he thinks it is a submit
button.
So my questions are:
1- How can i add some button link reset button for working when form is not
valid.
2- What is the best way to reset the form with a button?
3- why the reset button (just with type="reset") is not working after
submitting form?



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Strange outcome - setRequired with OnChangeBehavior

2021-06-22 Thread Sven Meier

Hi,

with #setRequired(true) an empty string is not a valid value, thus 
#onUpdate is not called, see javadoc:


    "Listener invoked on the ajax request. This listener is invoked 
after the component's model has been updated."


The model is not updated because of the invalid value, you have to 
override #onError too.


Best regards
Sven


On 22.06.21 16:25, Mihir Chhaya wrote:

Hello Wicket Wizards,

I am experiencing this strange behavior with the *CompoundPropertyModel
form, a required text field, and the OnChangeBehavior added to the text
field*.

*Apache Wicket Version: 8.12.0 *

Here is the situation:

//Page/Class level variable
int charCount = 0;

//Inside Page constructor
Form criteriaForm = new Form ("searchCriteria",
  new CompoundPropertyModel< CriteriaTO >(criteriaObject));

TextField txtFirstName = new TextField
("firstName");//firstName is bean property
*txtFirstName.setRequired(true); //This seems to be preventing the change
event when removing the last remaining character*
txtFirstName.setOutputMarkupId(true);
txtFirstName.setMarkupId("firstNmId");

//Now, add onChange behavior to capture the change event
txtFirstName .add(new OnChangeAjaxBehavior() {

/**
*
*/
private static final long serialVersionUID = 1L;

@Override
protected void onUpdate(AjaxRequestTarget target) {

System.out.println("Change counter:" + ++counter);

}

});

criteriaForm.add(txtFirstName);

Test: Enter a then b then c then d and then e in first Name. Following is
the output for each change event.
  [stdout] (default task-21) Change counter:1
  [stdout] (default task-22) Change counter:2
  [stdout] (default task-20) Change counter:3
  [stdout] (default task-23) Change counter:4
  [stdout] (default task-24) Change counter:5

When removing each letter at a time, the change event seems to be* not
fired when the last letter is left*. Following is the output when I start
removing one letter at a time from the end.
  [stdout] (default task-25) Change counter:6
  [stdout] (default task-26) Change counter:7
  [stdout] (default task-28) Change counter:8
  [stdout] (default task-27) Change counter:9

Here, Change counter:10 did not get printed when removing 'a' from the
page. Additionally, the bean firstName field had one letter left i.e. 'a'
even though the UI has all letters removed from the screen.

When I remove the txtFirstName.setRequired(true) line the OnChangeBehavior
works just fine, printing the Change Counter:10  and also removing the last
character from the bean property.

Any suggestions?

Thank you,
-Mihir.



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: CompoundPropertyModel - white space

2021-06-08 Thread Sven Meier

Hi,

by default textfields trim their input, so I'd expect the total count 
characters to be correct to the processed input:


  "f " + "m" + "l" -> "fml" = 3 characters (also a space was entered 
after the *f*


You might want to override #shouldTrimInput if you want to keep the 
whitespace.


Have fun
Sven


On 08.06.21 21:05, Mihir Chhaya wrote:

Hello,

Apache Wicket version used: 8.12.0

I need to show total characters entered into First, Middle and Last name
text fields + one drop down for Suffix. The combined length of these four
fields should not exceed the set limit.
For this, I have added OnChangeAjaxBehavior to all the three text fields +
the drop down.

These fields are bound to the respective bean properties using
CompoundProperyModel. The bean has a generic getter method to calculate
combined length without trimming white space from any field.

Issue:
The CompoundPropertyModel bean setter method is not called when a white
space is entered after any letter in the field.
For example, entering "f" in the first name will call the setter method,
but entering white space after "f" does not call the setter method until
the next character is entered.
This is messing up the total chars count.

Here is how the length looks like without any white space trimming:

(1) F + M + L = "f" + "m" + "l" = 3
(2) F + M + L = "f " + "m" + "l" = 3 (Please note the white space after f)
(3) F + M + L = "f n" + "m" + "l" = 5

As one can see, the 2nd scenario is what I am trying to solve.

The OnChangeAjaxBehavior event is called when entering the white space, but
the bean setter is not, causing misleading total chars count.

Any suggestions?

Thank you,
-Mihir.



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: using web sockets push to repaint parts of UI (wicket 9.3.0)

2021-05-19 Thread Sven Meier

Hi Ernesto,

have you compared with Wicket's websocket example?

Check what thread is locking your page - do you have 
ExceptionSettings#ThreadDumpStrategy set to THREAD_HOLDING_LOCK or 
ALL_THREADS?


Regards
Sven


On 19.05.21 19:14, Ernesto Reinaldo Barreiro wrote:

Hi,

Context: we are trying to replace in our wicket application the use of AJAX
timers with Web sockets push. We are getting "strange" exceptions like the
ones below.

--
java.lang.InterruptedException
at
java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1261)
at
java.base/java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:317)
at
java.base/java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:371)
at
org.apache.wicket.pageStore.AsynchronousPageStore.addPage(AsynchronousPageStore.java:375)
at
org.apache.wicket.pageStore.SerializingPageStore.addPage(SerializingPageStore.java:82)
at
org.apache.wicket.pageStore.CachingPageStore.addPage(CachingPageStore.java:73)
at
org.apache.wicket.pageStore.RequestPageStore.detach(RequestPageStore.java:114)
at org.apache.wicket.page.PageManager.detach(PageManager.java:91)
at
org.apache.wicket.page.PageAccessSynchronizer$1.detach(PageAccessSynchronizer.java:170)
at
org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor$1.onDetach(AbstractWebSocketProcessor.java:322)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:105)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:101)
at
org.apache.wicket.util.listener.ListenerCollection$1.notify(ListenerCollection.java:120)
at
org.apache.wicket.util.listener.ListenerCollection.reversedNotify(ListenerCollection.java:144)
at
org.apache.wicket.util.listener.ListenerCollection.reversedNotifyIgnoringExceptions(ListenerCollection.java:113)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection.onDetach(RequestCycleListenerCollection.java:100)
at
org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:670)
at
org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:625)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:227)
at
org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor.broadcastMessage(AbstractWebSocketProcessor.java:272)
at
org.apache.wicket.protocol.ws.api.AbstractWebSocketConnection.sendMessage(AbstractWebSocketConnection.java:53)
at
org.apache.wicket.protocol.ws.api.WebSocketPushBroadcaster$1.run(WebSocketPushBroadcaster.java:124)
at
org.apache.wicket.protocol.ws.WebSocketSettings$WebSocketPushMessageExecutor.run(WebSocketSettings.java:456)
at
org.apache.wicket.protocol.ws.api.WebSocketPushBroadcaster.process(WebSocketPushBroadcaster.java:119)
at
org.apache.wicket.protocol.ws.api.WebSocketPushBroadcaster.broadcast(WebSocketPushBroadcaster.java:79)



org.apache.wicket.page.CouldNotLockPageException: Could not lock page 5.
Attempt lasted PT1M
at
org.apache.wicket.page.DefaultPageLockManager.lockPage(DefaultPageLockManager.java:170)
at
org.apache.wicket.page.PageAccessSynchronizer.lockPage(PageAccessSynchronizer.java:72)
at
org.apache.wicket.page.PageAccessSynchronizer$1.getPage(PageAccessSynchronizer.java:116)
at
org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor.getPage(AbstractWebSocketProcessor.java:340)
at
org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor.broadcastMessage(AbstractWebSocketProcessor.java:258)
at
org.apache.wicket.protocol.ws.api.AbstractWebSocketConnection.sendMessage(AbstractWebSocketConnection.java:53)
at
org.apache.wicket.protocol.ws.api.WebSocketPushBroadcaster$1.run(WebSocketPushBroadcaster.java:124)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)

Are there any recommendations or requirements needed to get server side
push working properly?



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Ajax debug window missing in Wicket 9

2021-04-07 Thread Sven Meier
Hi,

that setting is still used - it controls whether Ajax log messages end up in 
the console at all.

Have fun
Sven


Am 7. April 2021 18:29:19 MESZ schrieb Bergmann Manfred 
:
>Yep, that’s OK.
>
>But shouldn’t the settings also be gone?
>
>
>
>Manfred
>
>
>> Am 07.04.2021 um 17:32 schrieb Sven Meier :
>> 
>> Yes, it was deemed superfluous:
>> 
>> https://issues.apache.org/jira/browse/WICKET-6667
>> 
>> Use you favorite browser's JS console instead.
>> 
>> Best regards
>> Sven
>> 
>> 
>> On 07.04.21 16:15, Ernesto Reinaldo Barreiro wrote:
>>> It is gone there AFAIK.
>>> 
>>> On Wed, Apr 7, 2021 at 5:11 PM Bergmann Manfred
>
>>> wrote:
>>> 
>>>> Hi.
>>>> 
>>>> Even when setting explicitly:
>>>> 
>>>> getDebugSettings().setAjaxDebugModeEnabled(true)
>>>> 
>>>> I don’t see the Ajax debug window.
>>>> Was this a change in Wicket 9?
>>>> 
>>>> 
>>>> Manfred
>>>> 
>>>> 
>>>>
>-
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>> 
>>>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>> 
>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


Re: Ajax debug window missing in Wicket 9

2021-04-07 Thread Sven Meier

Yes, it was deemed superfluous:

    https://issues.apache.org/jira/browse/WICKET-6667

Use you favorite browser's JS console instead.

Best regards
Sven


On 07.04.21 16:15, Ernesto Reinaldo Barreiro wrote:

It is gone there AFAIK.

On Wed, Apr 7, 2021 at 5:11 PM Bergmann Manfred 
wrote:


Hi.

Even when setting explicitly:

getDebugSettings().setAjaxDebugModeEnabled(true)

I don’t see the Ajax debug window.
Was this a change in Wicket 9?


Manfred


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Replacement for HttpSessionDataStore

2021-04-01 Thread Sven Meier

Hi,

with that setup you lose back-button support - the serializer you're 
passing to the InSessionPageStore is used only should the container 
serialize the web session.


You should serialize *all* pages into the persistent store instead:

var store: IPageStore = new InSessionPageStore(1)
store = new SerializingPageStore(store)
store = new CachingPageStore(store, new InMemoryPageStore("ui", 5))
store = new RequestPageStore(store)
new PageManager(store)

Hope this helps
Sven


On 01.04.21 16:44, Bergmann Manfred wrote:

OK, got it.

A sequence of this:

var store: IPageStore = new InSessionPageStore(1, 
getFrameworkSettings().getSerializer())
store = new CachingPageStore(store, new InMemoryPageStore("ui", 5))
store = new RequestPageStore(store)
new PageManager(store)

seems to do it.


Thanks,
Manfred



Am 01.04.2021 um 15:27 schrieb Bergmann Manfred :

Hi.

In Wicket 8 we used HttpSessionDataStore.
What is the right replacement for this in Wicket 9?

I tried overriding newPersistentStore() with InSessionPageStore but that 
doesn’t seem to do the same as HttpSessionDataStore.


Manfred


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Replacement for HttpSessionDataStore

2021-04-01 Thread Sven Meier

Hi Manfred,

yes, you should use InSessionPageStore as a replacement.

>but that doesn’t seem to do the same as HttpSessionDataStore

Please be more specific, in what way does it differ? Pages are kept in 
the session, there's not difference there.


Regards
Sven


On 01.04.21 15:27, Bergmann Manfred wrote:

Hi.

In Wicket 8 we used HttpSessionDataStore.
What is the right replacement for this in Wicket 9?

I tried overriding newPersistentStore() with InSessionPageStore but that 
doesn’t seem to do the same as HttpSessionDataStore.


Manfred
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Extend session metadata with user-data-scope after login (spring question)

2021-03-07 Thread Sven Meier

Hi,

Wicket tries to create a proxy for your bean.

Apparently UserScopeFinder doesn't have a default constructor, which is 
required for creation of a proxy class.
Easiest solution is to introduce an interface (e.g. IUserScopeFinder) 
and let your bean implement that:


@SpringBean(name = "userScopeFinder")
private IUserScopeFinder userScopeFinder;

Hope this helps
Sven


On 07.03.21 09:58, Per Newgro wrote:

Hi,

i would like to extend a session (metadata) with scope of user logged in. Something like 
"allowed countries", "allowed companies" and so on.
That scope is provided by a spring bean (UserScopeFinder). This bean is created 
in a Configuration as a @Bean.

What i tried so far is add an ISessionListener to WebApplication and inject the 
UserScopeFinder.


@com.giffing.wicket.spring.boot.context.extensions.ApplicationInitExtension
public class AuthorizationInitializer implements 
com.giffing.wicket.spring.boot.context.extensions.WicketApplicationInitConfiguration
 {

@Override
public void init(WebApplication webApplication) {
IAuthorizationStrategy strategy;
strategy = new ApplicationAuthorizationStrategy(new 
UserRolesAuthorizer());

webApplication.getSecuritySettings().setAuthorizationStrategy(strategy);
webApplication.getSessionListeners().add(new 
UserScopeInjector());
}
}

public class UserScopeInjector implements ISessionListener {

@SpringBean(name = "userScopeFinder")
private UserScopeFinder userScopeFinder;

public UserScopeInjector() {
super();
Injector.get().inject(this);
}

@Override
public void onCreated(Session session) {
System.out.println("Works");
}
}


But in that case i get:


...
Caused by: java.lang.RuntimeException: error while injecting object 
[my.app.core.wicket.authorization.UserScopeInjector@283465af] of type 
[my.app.core.wicket.authorization.UserScopeInjector]
at org.apache.wicket.injection.Injector.inject(Injector.java:122)
at 
org.apache.wicket.spring.injection.annot.SpringComponentInjector.inject(SpringComponentInjector.java:124)
at 
my.app.core.wicket.authorization.UserScopeInjector.(UserScopeInjector.java:17)
at 
my.app.core.wicket.authorization.AuthorizationInitializer.init(AuthorizationInitializer.java:19)
at 
com.giffing.wicket.spring.boot.starter.app.WicketBootSecuredWebApplication.init(WicketBootSecuredWebApplication.java:83)
at org.apache.wicket.Application.initApplication(Application.java:762)
at 
org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:441)
... 47 common frames omitted
Caused by: java.lang.IllegalArgumentException: Superclass has no null 
constructors but no arguments were given
at net.sf.cglib.proxy.Enhancer.emitConstructors(Enhancer.java:931)
at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:631)
at 
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at 
net.sf.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:332)
at net.sf.cglib.proxy.Enhancer.generate(Enhancer.java:492)
at 
net.sf.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:96)
at 
net.sf.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:94)
at net.sf.cglib.core.internal.LoadingCache$2.call(LoadingCache.java:54)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
net.sf.cglib.core.internal.LoadingCache.createEntry(LoadingCache.java:61)
at net.sf.cglib.core.internal.LoadingCache.get(LoadingCache.java:34)
at 
net.sf.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:119)
at 
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:294)
at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:480)
at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:305)
at 
org.apache.wicket.proxy.LazyInitProxyFactory.createProxy(LazyInitProxyFactory.java:191)
at 
org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.getFieldValue(AnnotProxyFieldValueFactory.java:166)
at org.apache.wicket.injection.Injector.inject(Injector.java:111)
... 53 common frames omitted


I'm a little bit lost, if my strategy is working in common. Has someone maybe 
an example for me?

Thanks for your support
Per

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: 

Re: Escaping Braces in StringResourceModel

2021-02-15 Thread Sven Meier

Hi Johannes,

StringResourceModel uses a MessageFormat depending on the presence of 
message parameters.
Without automatic escaping, editors of resource files would have to 
escape single-quotes in some resource strings and not-escape in others.


Regretfully this means you can't use escapes as you want to.
I'd recommend you use standard Wicket properties instead, e.g. "{div} 
This is a ${day} day. {/div}'


I've used markdown in labels for several of my projects: 
https://www.markdownguide.org/basic-syntax


Best regards
Sven


On 15.02.21 08:37, Johannes Renoth wrote:

Hello,

Recently i created and Extension to Label that uses { and } as Markup
Delimiters to create a kind of safe Markup with a very limited set of
HTML-Tags like

{h3}Title{/h3}

{div}Hello{/div}

The purpose of this is to get rid of the setEscapeModelStrings(false) to
be found everywhere which is actually quite dangerous when combined with
user-input.

Now someone has combined my new Label with StringResourceModel which
uses the Syntax defined in MessageFormat which also uses { and } as
delimiting characters for its placeholders, for example

This is a {0} day.

Now both Formats collide but there would be an easy workaround if Wicket
would actually honor the possible escaping defined in MessageFormat, i
would just have to write

'{'div'}' This is a {0} day. '{'/div'}'

But StringResourceModel Line 478 escapes these ' in its code so the
resulting Text is actually

''{''div''}'' This is a {0} day. ''{''/div''}'' and the escaping for my
markup does not work anymore since the double single quotes are
interpreted as single single quote by the MessageFormat parser.

I would argue that StringResourceModel is doing the wrong thing here by
purposefully escaping the single quotes when it is not intended by the
user. I also have not found the reason why it does this in the first
place. Any suggestions or ideas?

Greetings,

Johannes Renoth



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Checking preconditions/changes in models

2021-02-02 Thread Sven Meier

Hi Bas,

> The thread local is probably to store the component + exception, so 
the listener can access it?


yes, it allows the exception handler to identify the when and where of a 
problem. A redirect to a full page render is possible, after 
removing/replacing the offending component.


Regretfully I don't have any code for that available any longer :(

Have fun
Sven



On 29.01.21 14:55, Bas Gooren wrote:

Hi Sven,

Thank you for explaining in detail, it helps a lot :-)

Part of your steps I have already implemented, but I never thought 
about marking optional components or relying on Behavior#onException.


Since some components can be replaced in AJAX request, I guess you add 
an exception-catching behavior to those components, and a page-level 
behavior as “catch-all” for normal render requests?
(Since the catch-all behavior on the page will not catch exceptions 
that occur when only a subtree of the page is rendered)
The thread local is probably to store the component + exception, so 
the listener can access it?


Are you able to share some (stripped down) code of the request cycle 
listener?


I all the non-trivial apps that I’ve built in wicket, exception 
handling always becomes an issue at some point.
There’s not much documentation on this besides catching all exceptions 
and displaying an error page.


So I’d like to take a stab at rolling a wicketstuff project for this, 
so others can use it (or learn from it) :-)


Met vriendelijke groet,
Kind regards,

Bas

Op 20 januari 2021 bij 11:06:13, Sven Meier (s...@meiers.net 
<mailto:s...@meiers.net>) schreef:



Hi Bas,

>E.g. do you handle exceptions within the model itself, or with a
RequestCycleListener?

a requestCycleListener is my preferred solution:

- I've used Spring interceptors to wrap all exceptions from the service
layer for easier identification of the origin of the problem
- check the current handler to differentiate between actions or 
rendering

- in case of actions check targeted component (e.g. use annotations to
mark optional components)
- in case of rendering you can identify the failing component with
Behavior#onException() (utilizing a ThreadLocal)
- inspect the stacktrace as last resort
- re-render the page and show a feedback message

Regards
Sven


On 20.01.21 09:18, Bas Gooren wrote:
> Hi Sven,
>
> Thank you for your reply.
>
> On catching failure “when it happens”: can you explain what that 
looks like

> for you?
>
> E.g. do you handle exceptions within the model itself, or with a
> RequestCycleListener?
>
> I think the tricky part is handling exceptions thrown by models, 
unless I

> guard every call to “getModelObject()” inside my components with a
> try-catch (so in methods like onConfigure, onClick etc).
>
> Met vriendelijke groet,
> Kind regards,
>
> Bas Gooren
>
> Op 14 januari 2021 bij 19:18:57, Sven Meier (s...@meiers.net 
<mailto:s...@meiers.net>) schreef:

>
> Hi Bas,
>
> in my experience is is very hard to check every possible failure 
upfront

> in preconditions (whether from page or models). There's always a
> corner-case waiting to hunt you.
>
> Therefore I prefer using option 1: catch the failure when it happens.
> Worked fine for me (most of the time), but maybe not a suitable 
approach

> for all kind of applications.
>
> Regards
> Sven
>
>
>
> On 12.01.21 14:37, Bas Gooren wrote:
>> Hi all,
>>
>> First off: best wishes to everyone for 2021, and that we may all 
have fun

>> this year building stuff in Wicket!
>>
>> I’m wondering how others implement the following requirement…
>>
>> Suppose a page has a model backed by something stored in the 
session or

>> database (e.g. an e-commerce basket page or checkout).
>> When the user opens multiple tabs (with different instances of the 
page),

>> either page can become “outdated” with regards to the actual data.
>>
>> E.g. in Tab A the customer removes a product.
>>
>> When the users then tries to update the quantity of that product 
in Tab

> B,
>> it can lead to a variety of runtime exceptions:
>> For example: Basket items are rendered with a repeater; If the # 
items in

>> the basket changes, rows may reference non-existant items (either by
>> database ID or by list index in the basket rows).
>>
>> This sort of problem appears in various shapes and forms when a page
>> references data that may change independent from the page itself.
>>
>> Over the years I have attempted to fix this in three ways:
>>
>> 1. Catch RTEs/Exceptions and re-render page (works OK); But suppose a
>> ListView is used, this also needs to handle things like
>> IndexOutOfBoundsException (thrown from inside ListItemModel) /
>> EntityNotFoundException / NullPointerException. F

Re: Wicket 9 clustered sessions

2021-01-20 Thread Sven Meier

Hi,

>'org.apache.wicket.pageStore.InSessionPageStore' can not be asynchronous

yes, pages cannot be stored in the session asynchronously. Same holds 
for the old HttpSessionDataStore in Wicket 8.x.


>Adding this fixes the warning getStoreSettings().setAsynchronous(false);

Yes, that's the correct fix.

>Might this clustered use-case be common enough to justify adding another
>IPageManagerProvider implementation to Wicket with default behavior more
>appropriate for clustering?

As you've seen, there are many possible combinations for these page stores:

https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/DefaultPageManagerProvider.java#L43

I'm not sure which concrete combination would be *the* most appropriate 
for clustering.


Have fun
Sven


On 20.01.21 18:34, Greb Lindqvist wrote:

Overriding #newPersistentStore() should be enough:

Thank you for your response.

I tried only overriding newPersistentStore() like this

 setPageManagerProvider(new DefaultPageManagerProvider(this) {
 @Override
 protected IPageStore newPersistentStore() {
 return new InSessionPageStore(20);
 }
 });

but get warnings like
WARN  o.a.w.p.AsynchronousPageStore - Delegated page store
'org.apache.wicket.pageStore.InSessionPageStore' can not be asynchronous

Adding this fixes the warning
getStoreSettings().setAsynchronous(false);

but looking at the DefaultPageManagerProvider chain:
RequestPageStore -> CachingPageStore -> SerializingPageStore
-> AsynchronousPageStore -> CryptingPageStore -> DiskPageStore

CachingPageStore wraps an InSessionPageStore of its own but I'm thinking
that is not useful when clustering - especially since I'm
using DeflatedJavaSerializer and want it invoked before storing in the
session. For clustering, maybe this makes more sense (assuming using
something like Spring Session)
RequestPageStore -> SerializingPageStore -> CryptingPageStore
-> InSessionPageStore

It seems like this does what I want but I need to test more.

 setPageManagerProvider(new DefaultPageManagerProvider(this) {
 @Override
 protected IPageStore newPersistentStore() {
 return new InSessionPageStore(20);
 }

 @Override
 protected IPageStore newCachingStore(IPageStore pageStore) {
 return pageStore;
 }

 @Override
 protected IPageStore newAsynchronousStore(IPageStore pageStore)
{
 return pageStore;
 }
 });

Might this clustered use-case be common enough to justify adding another
IPageManagerProvider implementation to Wicket with default behavior more
appropriate for clustering?

Thanks again

On Tue, Jan 19, 2021 at 11:57 AM Sven Meier  wrote:


Hi,

  > Is it helpful if I add documentation issues to Wicket Jira?

pull-requests are always preferred :P

  >

https://ci.apache.org/projects/wicket/guide/9.x/single.html#_httpsessiondatastore


I will take care of this.

  >For Wicket 9 I'm overriding DefaultPageManagerProvider like below. Is
that
  > a good replacement for my Wicket 8 code?

Overriding #newPersistentStore() should be enough:

@Override
protected IPageStore newPersistentStore() {
   return new InSessionPageStore(20);
}

  >Wicket alive and well! I've been using it since 1.3 :)

Thanks for reporting back.

Regards
Sven

On 19.01.21 16:02, Greb Lindqvist wrote:

Hello everyone,

I'm updating an application from Wicket 8 to Wicket 9 and see that
IDataStore has been removed. I think the documentation needs to be

updated

here


https://ci.apache.org/projects/wicket/guide/9.x/single.html#_httpsessiondatastore

Is it helpful if I add documentation issues to Wicket Jira?

My application uses
https://spring.io/projects/spring-session-data-redis
so it can be clustered.

My Wicket 8 code is like
  setSessionStoreProvider(HttpSessionStore::new);

  setPageManagerProvider(new DefaultPageManagerProvider(this) {
  @Override
  protected IDataStore newDataStore() {
  return new HttpSessionDataStore(getPageManagerContext(),
new PageNumberEvictionStrategy(20));
  }
  });

For Wicket 9 I'm overriding DefaultPageManagerProvider like below. Is

that

a good replacement for my Wicket 8 code? It seems to mostly work but I'm
seeing slight weirdness that doesn't happen in Wicket 8. If
overriding DefaultPageManagerProvider is the correct approach, it would

be

helpful to mention it in the migration guide with a pointer to the

updated

documentation.

Thanks to everyone for keeping Wicket alive and well! I've been using it
since 1.3 :)

  setPageManagerProvider(new DefaultPageManagerProvider(this) {
  @Override
  public IPageManager get()
  {
  IPageStore

Re: Checking preconditions/changes in models

2021-01-20 Thread Sven Meier

Hi Bas,

>E.g. do you handle exceptions within the model itself, or with a 
RequestCycleListener?


a requestCycleListener is my preferred solution:

- I've used Spring interceptors to wrap all exceptions from the service 
layer for easier identification of the origin of the problem

- check the current handler to differentiate between actions or rendering
- in case of actions check targeted component (e.g. use annotations to 
mark optional components)
- in case of rendering you can identify the failing component with 
Behavior#onException() (utilizing a ThreadLocal)

- inspect the stacktrace as last resort
- re-render the page and show a feedback message

Regards
Sven


On 20.01.21 09:18, Bas Gooren wrote:

Hi Sven,

Thank you for your reply.

On catching failure “when it happens”: can you explain what that looks like
for you?

E.g. do you handle exceptions within the model itself, or with a
RequestCycleListener?

I think the tricky part is handling exceptions thrown by models, unless I
guard every call to “getModelObject()” inside my components with a
try-catch (so in methods like onConfigure, onClick etc).

Met vriendelijke groet,
Kind regards,

Bas Gooren

Op 14 januari 2021 bij 19:18:57, Sven Meier (s...@meiers.net) schreef:

Hi Bas,

in my experience is is very hard to check every possible failure upfront
in preconditions (whether from page or models). There's always a
corner-case waiting to hunt you.

Therefore I prefer using option 1: catch the failure when it happens.
Worked fine for me (most of the time), but maybe not a suitable approach
for all kind of applications.

Regards
Sven



On 12.01.21 14:37, Bas Gooren wrote:

Hi all,

First off: best wishes to everyone for 2021, and that we may all have fun
this year building stuff in Wicket!

I’m wondering how others implement the following requirement…

Suppose a page has a model backed by something stored in the session or
database (e.g. an e-commerce basket page or checkout).
When the user opens multiple tabs (with different instances of the page),
either page can become “outdated” with regards to the actual data.

E.g. in Tab A the customer removes a product.

When the users then tries to update the quantity of that product in Tab

B,

it can lead to a variety of runtime exceptions:
For example: Basket items are rendered with a repeater; If the # items in
the basket changes, rows may reference non-existant items (either by
database ID or by list index in the basket rows).

This sort of problem appears in various shapes and forms when a page
references data that may change independent from the page itself.

Over the years I have attempted to fix this in three ways:

1. Catch RTEs/Exceptions and re-render page (works OK); But suppose a
ListView is used, this also needs to handle things like
IndexOutOfBoundsException (thrown from inside ListItemModel) /
EntityNotFoundException / NullPointerException. Feels cluttered and
“cleaning up after the fact” instead of preventing the RTE in the first
place.
2. Check preconditions in page’s onConfigure(). Mixed results,
preconditions not always checked before action is executed (e.g. ajax

link

click, form submit). So leads to finding more spots to check for
preconditions, e.g. Form#process
3. Wrap models with decorating models at the page level that check
preconditions; E.g. BasketNotEmptyModel; Usually combined with

specialized

subclass of Form which manages transaction and commit/rollback

Of all these ways I prefer option 3 nowadays, as this is a close to the
“root” of the problem as possible: at the point where the data is

accessed.

Since such models are always caching models (LDM), the overhead is

minimal

(called once or twice per request).
Another advantage is that all components in the page point to the parent
model, which means preconditions are always checked for any component on
the page.

When using JPA we can even do a simple check for the entity “last

modified”

or version, to ensure that the entity did not change between requests.

However, I’m evaluating which variant I will use from now on in projects
(to standardize) and am wondering how others handle this.

Any input/feedback is highly appreciated!

Kind regards,

Bas


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket 9 clustered sessions

2021-01-19 Thread Sven Meier

Hi,

> Is it helpful if I add documentation issues to Wicket Jira?

pull-requests are always preferred :P

> 
https://ci.apache.org/projects/wicket/guide/9.x/single.html#_httpsessiondatastore 



I will take care of this.

>For Wicket 9 I'm overriding DefaultPageManagerProvider like below. Is that
> a good replacement for my Wicket 8 code?

Overriding #newPersistentStore() should be enough:

  @Override
  protected IPageStore newPersistentStore() {
 return new InSessionPageStore(20);
  }

>Wicket alive and well! I've been using it since 1.3 :)

Thanks for reporting back.

Regards
Sven

On 19.01.21 16:02, Greb Lindqvist wrote:

Hello everyone,

I'm updating an application from Wicket 8 to Wicket 9 and see that
IDataStore has been removed. I think the documentation needs to be updated
here
https://ci.apache.org/projects/wicket/guide/9.x/single.html#_httpsessiondatastore
Is it helpful if I add documentation issues to Wicket Jira?

My application uses
https://spring.io/projects/spring-session-data-redis
so it can be clustered.

My Wicket 8 code is like
 setSessionStoreProvider(HttpSessionStore::new);

 setPageManagerProvider(new DefaultPageManagerProvider(this) {
 @Override
 protected IDataStore newDataStore() {
 return new HttpSessionDataStore(getPageManagerContext(),
new PageNumberEvictionStrategy(20));
 }
 });

For Wicket 9 I'm overriding DefaultPageManagerProvider like below. Is that
a good replacement for my Wicket 8 code? It seems to mostly work but I'm
seeing slight weirdness that doesn't happen in Wicket 8. If
overriding DefaultPageManagerProvider is the correct approach, it would be
helpful to mention it in the migration guide with a pointer to the updated
documentation.

Thanks to everyone for keeping Wicket alive and well! I've been using it
since 1.3 :)

 setPageManagerProvider(new DefaultPageManagerProvider(this) {
 @Override
 public IPageManager get()
 {
 IPageStore store = newPersistentStore();
 store = newSerializingStore(store);
 store = newRequestStore(store);
 return new PageManager(store);
 }

 @Override
 protected IPageStore newPersistentStore() {
 return new InSessionPageStore(20);
 }
 });



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Checking preconditions/changes in models

2021-01-14 Thread Sven Meier

Hi Bas,

in my experience is is very hard to check every possible failure upfront 
in preconditions (whether from page or models). There's always a 
corner-case waiting to hunt you.


Therefore I prefer using option 1: catch the failure when it happens.
Worked fine for me (most of the time), but maybe not a suitable approach 
for all kind of applications.


Regards
Sven



On 12.01.21 14:37, Bas Gooren wrote:

Hi all,

First off: best wishes to everyone for 2021, and that we may all have fun
this year building stuff in Wicket!

I’m wondering how others implement the following requirement…

Suppose a page has a model backed by something stored in the session or
database (e.g. an e-commerce basket page or checkout).
When the user opens multiple tabs (with different instances of the page),
either page can become “outdated” with regards to the actual data.

E.g. in Tab A the customer removes a product.

When the users then tries to update the quantity of that product in Tab B,
it can lead to a variety of runtime exceptions:
For example: Basket items are rendered with a repeater; If the # items in
the basket changes, rows may reference non-existant items (either by
database ID or by list index in the basket rows).

This sort of problem appears in various shapes and forms when a page
references data that may change independent from the page itself.

Over the years I have attempted to fix this in three ways:

1. Catch RTEs/Exceptions and re-render page (works OK); But suppose a
ListView is used, this also needs to handle things like
IndexOutOfBoundsException (thrown from inside ListItemModel) /
EntityNotFoundException / NullPointerException. Feels cluttered and
“cleaning up after the fact” instead of preventing the RTE in the first
place.
2. Check preconditions in page’s onConfigure(). Mixed results,
preconditions not always checked before action is executed (e.g. ajax link
click, form submit). So leads to finding more spots to check for
preconditions, e.g. Form#process
3. Wrap models with decorating models at the page level that check
preconditions; E.g. BasketNotEmptyModel; Usually combined with specialized
subclass of Form which manages transaction and commit/rollback

Of all these ways I prefer option 3 nowadays, as this is a close to the
“root” of the problem as possible: at the point where the data is accessed.
Since such models are always caching models (LDM), the overhead is minimal
(called once or twice per request).
Another advantage is that all components in the page point to the parent
model, which means preconditions are always checked for any component on
the page.

When using JPA we can even do a simple check for the entity “last modified”
or version, to ensure that the entity did not change between requests.

However, I’m evaluating which variant I will use from now on in projects
(to standardize) and am wondering how others handle this.

Any input/feedback is highly appreciated!

Kind regards,

Bas



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Issue overriding JSession cookie name - Wicket assumes overwritten name contains no uppercase characters

2020-12-09 Thread Sven Meier
Thanks!

Sven

Am 9. Dezember 2020 16:24:53 MEZ schrieb Martin Grigorov :
>https://issues.apache.org/jira/browse/WICKET-6858
>
>On Tue, Dec 8, 2020 at 11:19 AM Sven Meier  wrote:
>
>> Hi Chris,
>>
>> that #toLowerCase() has been introduced with WICKET-4816.
>>
>> The commit does not mention anything about the requirement for a
>lower
>> case comparison, and the test does not enforce it either:
>>
>>
>>
>https://github.com/apache/wicket/commit/66bfc8851c0250c02ff6ee0af0f42407a7873ca5#diff-2eff23be497b622b61b1181a1a97d8dcd70143cde2f14d644df573b3ecf7b5f5
>>
>> So this has probably been just an unnecessary precaution.
>>
>> Please open an issue.
>>
>> Thanks
>> Sven
>>
>>
>> On 08.12.20 08:48, Chris Colman wrote:
>> > Tomcat, and presumably other JEE app containers, now allow the
>> > specification of the name of the JSESSIONID parameter to use in the
>> > URL (even though cookies are largely used in place of this the
>initial
>> > hit on a web site will include the jsessionid parameter by default)
>> >
>> > This is done by setting a  attribute called
>'sessionCookieName'
>> >
>> > e.g.
>> >
>> > 
>> >
>> > This can be specified in mixed case and Tomcat will preserve the
>case.
>> >
>> > Wicket allows a matching value to be specified via a Java -D
>command
>> > line option:
>> >
>> > e.g.
>> >
>> > -Dwicket.jsessionid.name=JSESSIONID-Integration
>> >
>> > However Wicket's Strings.stripJSessionId() method assumes that the
>> > JSESSIONID parameter name is always in lowercase which causes
>failures
>> > if it is not:
>> >
>> >
>> > public static String stripJSessionId(final String url)
>> > {
>> > if (Strings.isEmpty(url))
>> > {
>> > return url;
>> > }
>> >
>> > // http://.../abc;jsessionid=...?param=...
>> > int ixSemiColon =
>> > url.toLowerCase(Locale.ROOT).indexOf(SESSION_ID_PARAM);<--
>> > seemingly unnecessary, unwanted toLowerCase() call
>> > if (ixSemiColon == -1)
>> > {
>> > return url;
>> > }
>> >
>> > ...
>> >
>> > }
>> >
>> >
>> > Is there any need for the toLowerCase() method call in there? No
>app
>> > container should be performing a "to lower case" on the parameter
>name
>> > and URLs in general can have case sensitive parameter names in
>query
>> > parameters etc., so the toLowerCase seems redundant and it causes
>> > issues as detailed above.
>> >
>> >
>> > Regards,
>> >
>> > Chris
>> >
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>


Re: Issue overriding JSession cookie name - Wicket assumes overwritten name contains no uppercase characters

2020-12-08 Thread Sven Meier

Hi Chris,

that #toLowerCase() has been introduced with WICKET-4816.

The commit does not mention anything about the requirement for a lower 
case comparison, and the test does not enforce it either:


https://github.com/apache/wicket/commit/66bfc8851c0250c02ff6ee0af0f42407a7873ca5#diff-2eff23be497b622b61b1181a1a97d8dcd70143cde2f14d644df573b3ecf7b5f5

So this has probably been just an unnecessary precaution.

Please open an issue.

Thanks
Sven


On 08.12.20 08:48, Chris Colman wrote:
Tomcat, and presumably other JEE app containers, now allow the 
specification of the name of the JSESSIONID parameter to use in the 
URL (even though cookies are largely used in place of this the initial 
hit on a web site will include the jsessionid parameter by default)


This is done by setting a  attribute called 'sessionCookieName'

e.g.



This can be specified in mixed case and Tomcat will preserve the case.

Wicket allows a matching value to be specified via a Java -D command 
line option:


e.g.

-Dwicket.jsessionid.name=JSESSIONID-Integration

However Wicket's Strings.stripJSessionId() method assumes that the 
JSESSIONID parameter name is always in lowercase which causes failures 
if it is not:



public static String stripJSessionId(final String url)
    {
        if (Strings.isEmpty(url))
        {
            return url;
        }

        // http://.../abc;jsessionid=...?param=...
        int ixSemiColon = 
url.toLowerCase(Locale.ROOT).indexOf(SESSION_ID_PARAM);    <-- 
seemingly unnecessary, unwanted toLowerCase() call

        if (ixSemiColon == -1)
        {
            return url;
        }

...

}


Is there any need for the toLowerCase() method call in there? No app 
container should be performing a "to lower case" on the parameter name 
and URLs in general can have case sensitive parameter names in query 
parameters etc., so the toLowerCase seems redundant and it causes 
issues as detailed above.



Regards,

Chris





-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Under certain circumstances, prevent the replacement of markup after a successful Ajax response

2020-10-21 Thread Sven Meier

Hi,


By inactivity, I could also only refresh only the info box without the form


that's the correct solution.

Updating a text component (or its parent) via Ajax while it has focus will lead 
to jumping cursors and/or lost user input.

Have fun
Sven

 


On 21.10.20 09:35, Holzmueller wrote:

Hi,

thanks for your feedback.

My use-case is a text input field, that submits the form data on blur. But also 
after an timespan of inactivity in the input filed itself (user stopped 
writing).
The ajax response refreshed the form (invalidation messages) and in addition to 
that an info box. Of course, the form refresh replaces the current input field 
(that's the problem).

By inactivity, I could also only refresh only the info box without the form. 
This could be a solution and maybe it is good enough.

An other approach (still updating the form) is to store and restore the value 
(and focus, and cursor position) of the input field. I could use 
AjaxRequestTarget.prependJavaScript() and AjaxRequestTarget.appendJavaScript() 
for that.

I think I will try one of those two solutions.

Thanks for the help.



Am 20.10.20 um 20:06 schrieb Sven Meier:

Hi,

from the JavaDoc:

     /**
      * Indicates whether or not this AjaxBehavior will produce 
. By default it will
      * produce it but some behaviors may need to return their own response 
which shouldn't be
      * processed by wicket-ajax.js
      */
     private boolean wicketAjaxResponse = true;

So with wicketAjaxResponse = false (attrs.wr = false) you can specify that your 
code wants to handle the Ajax response instead of Wicket's default handling 
(i.e. changing the DOM).


My goal is to prevent the ajax component replacement in some circumstances.
The circumstances could be changed during the delay between request and 
response.

I don't see a solution how you could change .wr dynamically, since no event is 
published before handling of the Ajax response.

What's your use-case?

Have fun
Sven


On 20.10.20 17:57, Holzmueller wrote:

Hi everyone,

I've a question about the wicket ajax response processing.
What's the meaning behind the attrs.wr JavaScript boolean attribute?

I can change it with JavaScript by the IAjaxCallListener.getBeforeSendHandler() 
method.

My goal is to prevent the ajax component replacement in some circumstances.

The IAjaxCallListener.getPrecondition() is to early. The circumstances could be 
changed during the delay between request and response.

Thanks for any help.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Under certain circumstances, prevent the replacement of markup after a successful Ajax response

2020-10-20 Thread Sven Meier

Hi,

from the JavaDoc:

    /**
     * Indicates whether or not this AjaxBehavior will produce 
. By default it will
     * produce it but some behaviors may need to return their own 
response which shouldn't be

     * processed by wicket-ajax.js
     */
    private boolean wicketAjaxResponse = true;

So with wicketAjaxResponse = false (attrs.wr = false) you can specify 
that your code wants to handle the Ajax response instead of Wicket's 
default handling (i.e. changing the DOM).


>My goal is to prevent the ajax component replacement in some 
circumstances.
>The circumstances could be changed during the delay between request 
and response.


I don't see a solution how you could change .wr dynamically, since no 
event is published before handling of the Ajax response.


What's your use-case?

Have fun
Sven


On 20.10.20 17:57, Holzmueller wrote:

Hi everyone,

I've a question about the wicket ajax response processing.
What's the meaning behind the attrs.wr JavaScript boolean attribute?

I can change it with JavaScript by the IAjaxCallListener.getBeforeSendHandler() 
method.

My goal is to prevent the ajax component replacement in some circumstances.

The IAjaxCallListener.getPrecondition() is to early. The circumstances could be 
changed during the delay between request and response.

Thanks for any help.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket - Enforcing POST on Ajax calls

2020-10-19 Thread Sven Meier

+1 that's a good proposal

Sven


On 19.10.20 12:33, Maxim Solodovnik wrote:

+1

On Mon, 19 Oct 2020 at 17:28, Martin Grigorov  wrote:


Hi Eric,

You can implement it yourself:

In #onUpdate(AjaxRequestTarget) start with:

AjaxRequestAttributes attrs = getAttributes();
String desiredMethod = attrs.getMethod().toString();
String actualMethod = ((HttpServletRequest)
RequestCycle.get().getRequest().getContainerRequest()).getMethod();
if (!desiredMethod.equalsIgnoreCase(actualMethod)) {}

@devs: What do you think about adding the above to
AjaxFormComponentUpdatingBehavior#onEvent() ?
We can add #onMethodMismatch() to AjaxFormComponentUpdatingBehavior that is
similar to one in Form. If it returns ABORT then we will execute the code
above. If it returns CONTINUE (the default) then no need to calculate the
AjaxRequestAttributes


On Sun, Oct 18, 2020 at 11:40 PM Sven Meier  wrote:


Hi,

with AjaxFormComponentUpdatingBehavior only a single component is
processed and not the complete Form.
So method mismatches are not checked.

Have fun
Sven


On 17.10.20 14:34, Eric Hamel wrote:

Looking at our implementation, we are using an

AjaxFormComponentUpdatingBehavior to trigger our data save.

Even though we do a have parent form the onSubmit is never called.

Is there an alternative to the onMethodMismatch ?

—
Eric Hamel
Senior Project Manager
Albany Information Technology Group
C. 518-698-4503


On Oct 16, 2020, at 4:32 PM, Martin Grigorov 

wrote:

On Fri, Oct 16, 2020, 23:27 Eric Hamel 

wrote:

I apologize in advance for my vague question. Our Wicket 8 based
application was submitted to pen testing from our EISO. While I

understand

the finding, I'm not 100% sure I understand the problem nor do I know

how

to address it.

In one of our complex forms that uses Ajax Calls to automatically

update

the DB when the fields lose focus, the tester made the following

remark:

Applications accepts GET requests for coded POST Ajax calls –

parameters

can be passed in URL

It appears that through his "fuzzer", even though our requests are

marked

as POST, it still processes GET requests. Is there a way to enforce

POST ?

Is there any way to mitigate this issue globally from a configuration
standpoint ?


See Form#onMethodMismatch()


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket - Enforcing POST on Ajax calls

2020-10-18 Thread Sven Meier

Hi,

with AjaxFormComponentUpdatingBehavior only a single component is processed and 
not the complete Form.
So method mismatches are not checked.

Have fun
Sven


On 17.10.20 14:34, Eric Hamel wrote:

Looking at our implementation, we are using an 
AjaxFormComponentUpdatingBehavior to trigger our data save.

Even though we do a have parent form the onSubmit is never called.

Is there an alternative to the onMethodMismatch ?

—
Eric Hamel
Senior Project Manager
Albany Information Technology Group
C. 518-698-4503


On Oct 16, 2020, at 4:32 PM, Martin Grigorov  wrote:

On Fri, Oct 16, 2020, 23:27 Eric Hamel  wrote:


I apologize in advance for my vague question. Our Wicket 8 based
application was submitted to pen testing from our EISO. While I understand
the finding, I'm not 100% sure I understand the problem nor do I know how
to address it.

In one of our complex forms that uses Ajax Calls to automatically update
the DB when the fields lose focus, the tester made the following remark:

Applications accepts GET requests for coded POST Ajax calls – parameters
can be passed in URL

It appears that through his "fuzzer", even though our requests are marked
as POST, it still processes GET requests. Is there a way to enforce POST ?
Is there any way to mitigate this issue globally from a configuration
standpoint ?



See Form#onMethodMismatch()


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Does wicket 9 support reactive programming?

2020-09-18 Thread Sven Meier

That would be a nice addition to wicketstuff.

Please keep us updated on how you solved it.

Have fun
Sven


On 18.09.20 11:02, Emmanuel Sowah wrote:

Hi Korbinian,

Thanks for the quick response.
I will look into the native websockets option and see if I can work
something out.
It would be nicer though if wicket could support reactive programming
natively, and for example simply pass Flux data to a repeater like
ListView> or a Mono as a model to a wicket Label.

Cheers

On Fri, Sep 18, 2020 at 10:45 AM Korbinian Bachl <
korbinian.ba...@whiskyworld.de> wrote:


Maybe Ajax

https://ci.apache.org/projects/wicket/guide/9.x/single.html#_creating_custom_ajax_call_listener
or Websockets 

https://ci.apache.org/projects/wicket/guide/9.x/single.html#_native_websockets

- Ursprüngliche Mail -

Von: "Emmanuel Sowah"
An: "users" 
Gesendet: Freitag, 18. September 2020 10:35:24
Betreff: Does wicket 9 support reactive programming?
Hi,

I am using spring 5 and via reactive programming, I am receiving a Flux
data which I am trying to display in a table on a Wicket page. However I
get an exception during rendering of the table. The exception basically
says the RequestCycle is closed, which sounds logical to me if wicket is
not supporting reactive programming due to the non-blocking nature of
reactive programming.

Does someone have a work-around for this problem? I was thinking along

the

lines of saving the RequestCycle and reusing it when data arrives later

but

I am not sure if that is the right way to go.

Currently I am using blocking on the reactive stream as a work-around but
that leads to a sequential behaviour, which of course defeats the basic
idea of reactive programming.

Any tips or ideas?

Cheers,
Emmanuel

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Component.getPage() and Exception Handling

2020-08-24 Thread Sven Meier

Hi,

I didn't understand what's your problem.

Sven


On 24.08.20 16:56, Daniel Weiss wrote:

Hello all,

I don't like the exception handling of Component.getPage(). We are 
working on the integration to Wicket 8.4. We use panels or dialogs as 
anonymous classes / instances and this feature will blocked us to 
redefine a parent component or page.


In fact (I think ..) we don't need this to handle anonymous 
implementations. My first thoughts about this was "what the hell ... 
why ... and whats the benefit of it?" :)


Please explain or link a reason,documentation etc. to handle it and 
the reason for it.


Thx in advance!
Daniel

https://issues.apache.org/jira/browse/WICKET-6415
https://github.com/apache/wicket/commit/140fea6/




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: AbstractTransformerBehavior prevents further rendering.

2020-08-18 Thread Sven Meier

Hi Thorsten,

>Is that a special restriction for transformers only?

transformers do something very special, they temporarily replace the 
response:


https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/markup/transformer/AbstractTransformerBehavior.java

I haven't tried it, but using two of these seems not to work. I never 
seen the need for this though.


Have fun
Sven


On 18.08.20 14:38, Thorsten Schöning wrote:

Guten Tag Sven Meier,
am Dienstag, 18. August 2020 um 08:50 schrieben Sie:


sorry I missed that: on first sight it seems to work with a single
transformer only.

Is that a special restriction for transformers only? Because
behaviours in general seem to be looped through when rendering
components.

Doesn't it make more sense to support multiple transformers as well?
Need to decide if I try to fix the underlying root cause or implement
a workaround. Combing my transformers isn't that easy, they are
totally unrelated in theory and are used individually already.

Mit freundlichen Grüßen,

Thorsten Schöning



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Sub: HSTS filter

2020-08-18 Thread Sven Meier

Hi,

are these headers preserved on other dynamic content, e.g. a servlet or jsp?

Or are they missing from Wicket generated content only?

Have fun
Sven


On 18.08.20 08:27, sundar saba wrote:

Hi all,

   I deploy wicket quick start application in tomcat and run in
https. I enabled HSTS headers in tomcat. I access the application  in
browser and various tools(Postman) HSTS filters are only displayed for pure
HTML pages in response header and wherever I use wicket component in HTML
pages HSTS filters are not displayed in response headers  for those pages.
Can you all please give your suggestion or feedbacks to move forward in
this issue.



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: AbstractTransformerBehavior prevents further rendering.

2020-08-18 Thread Sven Meier

Hi,

sorry I missed that: on first sight it seems to work with a single 
transformer only.


Better you combined both your behaviors into one.

Have fun
Sven


On 18.08.20 08:11, Thorsten Schöning wrote:

Guten Tag Sven Meier,
am Montag, 17. August 2020 um 20:34 schrieben Sie:


please create a quickstart, without debugging I cannot pinpoint the problem.

Will try to have a look at this later. In general, should multiple of
my behaviours on the same component work? Do you know of any tests in
place already making sure this works?

Because in my setup the problem happens when executed using
WicketTester, which might make a difference to normal rendering as
well.

Mit freundlichen Grüßen,

Thorsten Schöning



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: AbstractTransformerBehavior prevents further rendering.

2020-08-17 Thread Sven Meier

Hi Thorsten,

please create a quickstart, without debugging I cannot pinpoint the problem.

Have fun
Sven


On 17.08.20 19:52, Thorsten Schöning wrote:

Hi all,

I'm using Wicket as a renderer for HTML-reports WITHOUT browser, web
server or requests, only by using ComponentRenderer. There are two
implementations of AbstractTransformerBehavior to update "colspan"
attributes of table cells and IDs of arbitrary HTML nodes. Both are
used on the same component:


resultsCont.add(new DvResultsCont.ColSpanUpdater());
resultsCont.add(new MkIdReplacer
(
   "th", "id", "td", "headers",
   String.format("%d.%s", itemIdx, kindOfDetail)
));

When only ONE of both behaviours is used, the page renders
successfully and it doesn't make any difference which one is used. If
both of those are used OTOH, the page stops rendering after the markup
of the component "resultsCont". That component renders to a table, so
the last markup I have is the following:



[...]


In theory, after that table there should be additional content like
foots, closing elements for HTML itself etc. So the current rendering
is invalid. It's important to note, though, that I don't get any
exception, things seems to simply stop. When enabling DEBUG logging
during rendering, the logs make pretty much clear that Wicket really
tries to continue rendering, but the output is simply missing.

It might be of interest that the resulting HTML is somewhat large,
around 1,7 MiB. Though I didn't find any hard-coded limits in the
behaviours yet in that direction.

As no exceptions are thrown and output seems to simply be ignored at
some point, I have the feeling the problem is in handling the response
objects in "AbstractTransformerBehavior.afterRender". But I couldn't
find anything problematic during debugging yet and things seem to work
with only one behaviour applied.

Do you have any idea what might go wrong? Is there any size limit with
behaviours or when rendering at all? Is it generally OK to place
multiple behaviours onto one and the same component?

Thanks for your ideas!

Mit freundlichen Grüßen,

Thorsten Schöning



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wizard - showing Modal on "next" button

2020-07-16 Thread Sven Meier

Hi,

easiest solution is to do the confirmation in JS only:

        button.add(new Behavior() {
            @Override
            public void renderHead(Component component, IHeaderResponse 
response)

            {
response.render(OnEventHeaderItem.forComponent(component, "click", 
"return confirm('Do you really want to perform this action?');"));

            }
        });


NextButton of the WizardButtonBar is a simple Button and so it lacks a 
RequestTarget to refresh the ModalWindow


Yes, you can use AjaxWizardButtonBar instead, if you want to use a ModalWindow 
instead.
 


Have fun
Sven


On 15.07.20 16:14, Leonardo D'Alimonte wrote:

Hello,

I'm writing a Wizard with some steps inside which the user must follow.
I wonder if there's the chance to display a modal window with a warning
message when the user clicks the "Next" button, in order to ask for a
confirmation.

Once the user acknowledges the message with the OK button, step can be
marked as complete and the user can go on with the following steps.

Has someone ever experienced a usage like this? Do you have any suggestion
about how to implement this additional modal window?

NextButton of the WizardButtonBar is a simple Button and so it lacks a
RequestTarget to refresh the ModalWindow, is that correct?

Thanks,


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Page locked for a long time

2020-07-05 Thread Sven Meier

Hi Maxim,

you'll have to upload these files to a resource separately.

I'm not aware of a reusable solution for that.

Have fun
Sven


On 05.07.20 17:20, Maxim Solodovnik wrote:

Hello All,

our app allows huge file uploads
I have noticed the page is locked while incoming input stream is being
copied
(might take more than an hour)

  at java.base@11.0.7/java.io.InputStream.read(InputStream.java:205)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:98)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:68)
at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:346)
at
org.apache.wicket.protocol.http.servlet.MultipartServletWebRequestImpl.parseFileParts(MultipartServletWebRequestImpl.java:196)
at org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1470)

Are there any options to prevent page lock?



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket can't distinguish multiple submit button in case of one form.

2020-06-26 Thread Sven Meier

Hi Thorsten,

this is all HTML standard:

    https://stackoverflow.com/questions/2129346

I have no clue why it doesn't work for you.

Please isolate the problem in a jsfiddle or similar.

Have fun
Sven


On 26.06.20 10:44, Thorsten Schöning wrote:

Guten Tag Thorsten Schöning,
am Freitag, 26. Juni 2020 um 10:34 schrieben Sie:




Using a button instead works as one would expect: When that button is
clicked, the form gets submitted and the name and value of the button
are send as part of the POST-data. If any other "submit" gets clicked,
no names and values are part of the POST-data, not even the name and
value of the button. Which makes sense, because it wasn't clicked.



   foobar button


I don't understand what I'm doing wrong, the plain HTML submit-input
is pretty much exactly what is documnted elsewhere:





https://stackoverflow.com/questions/22579616/send-value-of-submit-button-when-form-gets-posted


Jeder Submit-Button hat ein individuelles name-Attribut, mit dem die
Anwendung auf dem Server den Datensatz identifiziert.

https://www.mediaevent.de/html/submit.html

Mit freundlichen Grüßen,

Thorsten Schöning



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket can't distinguish multiple submit button in case of one form.

2020-06-25 Thread Sven Meier

Hi Thorsten,

for a normal form submit the browser should send "bcdHistory.upload" as 
post parameter.


That should definitely work. Show us your HTML, maybe something is wrong 
there.


Have fun
Sven



On 25.06.20 19:05, Thorsten Schöning wrote:

Hi all,

I have one form in which I need two submit buttons with different
behaviour. The first is to submit the form with default
implementation, to do whatever the form needs to do. The second is to
submit the form WITHOUT doing what the form normally does, but
something completely different and redirect differently afterwards.

I've implemented this simply following the official docs:

https://cwiki.apache.org/confluence/display/WICKET/Multiple+submit+buttons

The problem is that Wicket can't properly find the submitting button
of the second request and therefore routes ALL requests to "onSubmit"
of the form only. "onSubmit" of the additionally added button never
fires. During debugging, one can easily see that when iterating
possible components in "Form.findSubmittingButton", Wicket doesn't
find the necessary component name of the second buttin in the request
parameters.

My request looks like the following, with the first being the
requested URL:


wicket/bookmarkable/de.am_soft.sm_mtg.frontend.pages.real_estates.PgInstallTest?22-9.-html-body-realEstates.fmInstallTest

Posted form data:


realEstates.fcPnTargetSearch:realEstate: F6 F9
text.seconds: Sekunden
text.minutes: Minuten
text.hours: Stunden
text.days: Tage
realEstates.fcPnBcdUpload:basicClaimsData.upload: (binary)
readings.fcPnTimeWindowDetailed:timeWindow.detailed.negativeVariation.quantity: 
15
readings.fcPnTimeWindowDetailed:timeWindow.detailed.negativeVariation.unit: 
MINUTE
readings.fcPnTimeWindowDetailed:timeWindow.detailed.timestamp.date: 2020-06-25
readings.fcPnTimeWindowDetailed:timeWindow.detailed.timestamp.time: 18:16
readings.fcPnTimeWindowDetailed:timeWindow.detailed.positiveVariation.quantity: 
15
readings.fcPnTimeWindowDetailed:timeWindow.detailed.positiveVariation.unit: 
MINUTE
readings.fcPnOptClientTz:options.clientTimeZone: Europe/Berlin
realEstates.fcPnBcdUploadCharset:basicClaimsData.charset: Windows-1252
readings.fcPnOptCsvCharset:options.csvCharset: Windows-1252
realEstates.fcPnBcdUploadCache:basicClaimsData.cache: on
readings.fcPnOptRecords:options.mostCurrentRecords: on

The name of the second submit button within the same form:


bcdHistory.upload

While the button is properly reflected in the HTML, there's no hint to
it in the posted data or in the requested URL.

So how should adressing different "onSubmit"s work in generally? Does
the parent form encode hints in the requested URL? If so, what could
be the reason that it doesn't in my case?

Thanks!

Mit freundlichen Grüßen,

Thorsten Schöning



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: one pass render, mounted page back button

2020-06-24 Thread Sven Meier

Hi Rob,

without a redirect, your first page will be presented without page id in 
the url.


Thus when you return back from another page, the browser will just 
request a fresh page. An F5 while on your first page should result in 
the same problem.


I don't know how to square that circle.

Have fun
Sven


On 24.06.20 17:12, Rob Audenaerde wrote:

Hi all,

We switched our app to use the renderstategy ONE_PASS_RENDER for SEO
reasons (reduce the number of redirects).

However, this causes the back-button to behave differently.

Before, when we update a part of the screen via ajax; then following a
link, then going back shows the page as it was after all the ajax stuff.
(which is really great for users)

Now, it generates a clean new page without all the changes.

What would be the best way to still work around is problem? Or is there a
simple fix?

Thanks in advance,
Rob Audenaerde



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Stateless page with AjaxSelfUpdatingTimerBehavior

2020-06-23 Thread Sven Meier

Hi,

you can make any Ajax behavior stateless as follows:

        component.setMarkupId("stable-id");
        add(component);

        component.add(new 
AjaxSelfUpdatingTimerBehavior(Duration.seconds(5)) {

            @Override
            public boolean getStatelessHint(Component component) {
                return true;
            }
        });

Note that you have to use a stable markup id for the component, 
otherwise it cannot be updated.


Have fun
Sven


On 23.06.20 17:21, Zbynek Vavros wrote:

Hi,

We have a page with AjaxSelfUpdatingTimerBehavior and now one of our
customers is complaining about "weird" behavior when this page is opened in
multiple browser tabs (yeah yeah we told him not to do it...).

What happens is that after opening this page in new tab, the previous tab
gets ajax redirect on mentioned timer.

After some digging I found out that this is happening because the page is
stateful.
Excerpt from Wicket code:

// If the page is stateful then we cannot assume that the listener
interface is
// invoked on its initial state (right after page initialization) and that
its
// component and/or behavior will be available. That's why the listener
interface
// should be ignored and the best we can do is to re-paint the newly
constructed
// page.

I did use StatelessChecker (very useful!) and found out that the reason is
this AjaxSelfUpdatingTimerBehavior.

Googling around I found this thread from 2011 -
http://apache-wicket.1842946.n4.nabble.com/Stateless-page-with-an-auto-update-section-td3795927.html.
The suggestion here is to "roll your own timer behavior".

Well, I spent some time with Wicket already but this is beyond my
knowledge. Can anyone please point me the right direction? Is this even
possible? I just have to say the AjaxSelfUpdatingTimerBehavior must stay -
this page displays progress bar of background task that is non-negotiable.

Thanks,
Zbynek



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: JS - defer automatic?

2020-06-22 Thread Sven Meier

Hi Rob,

have you tried JavaScriptDeferHeaderResponse?

And here's some background on how we arrived at this solution:

https://issues.apache.org/jira/browse/WICKET-6498

Have fun
Sven


On 22.06.20 13:23, Rob Audenaerde wrote:

Hi all,

I'm trying to increase the google-page-speed of some WicketApplication. It
seems most jquery javascript is 'blocking', i.e. not usign 'defer'.

For example this google-chrome-audit section:

URL
Size
Potential Savings
…jquery/jquery-2.2.4-ver-F9E….js

(localhost)
167 KB
2,560 ms
…com.googlecode.wicket.jquery.ui.resource.JQueryUIR…/jquery-….js

(localhost)
494 KB
4,360 ms
…js/wicket-aj….js

(localhost)
86 KB
1,660 ms
/style.css 
(localhost)
4 KB
310 ms

Is there a reason why this is all non-deferred? Or an easy way to change
this? Most functionality is added in an DomReady event anyway.



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Executing AjaxEvent reset form inputs during Wicket test

2020-06-01 Thread Sven Meier

Hard to tell, the code looks fine to me :/

Have fun
Sven


On 01.06.20 15:09, leodali83 wrote:

Hello Sven,
actually it helps a bit, some error feedback messages related to the 2 input
fields on which I set the value just after instantiation of FormTester
disappered.

Therefore, test fails again signaling the second dropdown (e.g.
"secondDropDownSelect") is required, which actually it is.

After instantiating again FormTester, code looks like this:
...

FormTester formTester = 
wicketTester.newFormTester("detailsForm");
formTester.select("firstDropDownSelect", 0);
wicketTester.executeAjaxEvent("detailsForm:firstDropDownSelect",
"change");

formTester = wicketTester.newFormTester("detailsForm");
formTester.setValue("codice", "001");
formTester.setValue("matricola", "123456");
formTester.select("status", 0);
formTester.setValue("maxValoreTotalizzatore", "");
formTester.select("secondDropDownSelect", 0);

LocalDate tomorrow = LocalDate.now().plusDays(1);
String tomorrowAsString =
tomorrow.format(DateTimeFormatter.ofPattern("dd/MM/"));
formTester.setValue("scadenzaCertificatoMid:dateWrapper:date",
tomorrowAsString);

formTester.submit("save");
   
...


Sounds a bit strange. Is it losing again my request?

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Locatable UnsupportedOperationException

2020-06-01 Thread Sven Meier

+1 that should have no negative impact

Sven

On 01.06.20 11:22, Martin Grigorov wrote:

Hi,

I like the idea to catch UnsupportedOperationException at
org.apache.wicket.IGenericComponent#setModelObject(T) and re-throw it as:
throw new WicketRuntimeException("You need to use read/write Model for
component '{}", this.getPageRelativePath(), uox)

Does anyone see a drawback ?

Martin

On Sat, May 30, 2020 at 11:42 PM Sven Meier  wrote:


Hi,

just put a breakpoint on IModel#setObject().

Once your problem hits that breakpoint, you'll be able to derive the
offending component/model from the stacktrace/variables in your favorite
IDE.

Have fun
Sven


On 30.05.20 17:13, smallufo wrote:

Is it possible to try { setObjectObject(value) } catch { e }
and pinpoint which class/model causes this problem ?
Or is it too costly ?


Francois Meillet  於 2020年5月30日 週六 下午11:02寫道:


Hope that help

During the process of throwing an exception, the Java Virtual Machine
abruptly completes, one by one, any expressions, statements, method and
constructor invocations, initializers, and field initialization

expressions

that have begun but not completed execution in the current thread. This
process continues until a handler is found that indicates that it

handles

that particular exception by naming the class of the exception or a
superclass of the class of the exception (§11.2 <
https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.2

).

If no such handler is found, then the exception may be handled by one

of a

hierarchy of uncaught exception handlers (§11.3 <
https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.3

)

- thus every effort is made to avoid letting an exception go unhandled.

https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html <
https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html>


François




Le 30 mai 2020 à 16:52, smallufo  a écrit :

Francois Meillet  於 2020年5月30日 週六

下午10:48寫道:

sompage?67-1.-border-content-border_body-form is the path to your

model

Yes , but it may contains deep-nested model

The form contains FormComponentPanel and contains another
FormComponentPanels and widgets , very deep ...
The error may lay under very deep model , which is very hard to debug.
And the error message should be able to pinpoint which model causes the
problem

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Executing AjaxEvent reset form inputs during Wicket test

2020-06-01 Thread Sven Meier

Hi,

you have to use a new FormTester instance after executing the Ajax event:

...
    formTester = tester.newFormTester(path)
    formTester.select("field1", ""); // required field
    formTester.select("field2", ""); // required field
    .
    formTester.select("firstDropDownSelect", 0);
wicketTester.executeAjaxEvent("detailsForm:firstDropDownSelect","change");
    formTester.select("secondDropDownSelect", 0);

    formTester = tester.newFormTester(path);
    formTester.submit()
...

Executing a request (e.g. via executeAjaxEvent) 'consumes' the current 
request and WicketTester sets up a new 'empty' request.


A new FormTester will fill the parameters of that new request with the 
current state of your components.


Hope this helps
Sven



Hi,

you have to use a new FormTester instance after executing the Ajax event:

...
    formTester = tester.newFormTester(path)
    formTester.select("field1", ""); // required field
    formTester.select("field2", ""); // required field
    .
    formTester.select("firstDropDownSelect", 0);
wicketTester.executeAjaxEvent("detailsForm:firstDropDownSelect","change");
    formTester.select("secondDropDownSelect", 0);

    formTester = tester.newFormTester(path)
    formTester.submit()
...

Executing a request (e.g. via executeAjaxEvent) 'consumes' the current 
request and a new one is set up by WicketTester.


Otherwise the values of the form




On 01.06.20 09:59, leodali83 wrote:

Hello everybody,
I'm developing a web application built on Wicket 8.

Now i'm testing a form containing 2 DropDownChoice, the selection of the
first one should refresh elements to be choose on the second through the
Ajax "change" event.
When i submit my form and I test feedback messages displayed during the
process, the form seems to have lost all the other field setted before the 2
drop downs below:

...
 formTester.select("field1", ""); // required field
 formTester.select("field2", ""); // required field
 .
formTester.select("firstDropDownSelect", 0);
wicketTester.executeAjaxEvent("detailsForm:firstDropDownSelect",
"change");
formTester.select("secondDropDownSelect", 0);
...

The Wicket Tester fails the test stating "field1" and "field2" are required
fields, although I setted it correctly... :/

If I try the same behaviour interactively, it works fine.

What am I missing from my test?

Thanks in advance for any suggestions,
Leonardo

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Locatable UnsupportedOperationException

2020-05-30 Thread Sven Meier

Hi,

just put a breakpoint on IModel#setObject().

Once your problem hits that breakpoint, you'll be able to derive the 
offending component/model from the stacktrace/variables in your favorite 
IDE.


Have fun
Sven


On 30.05.20 17:13, smallufo wrote:

Is it possible to try { setObjectObject(value) } catch { e }
and pinpoint which class/model causes this problem ?
Or is it too costly ?


Francois Meillet  於 2020年5月30日 週六 下午11:02寫道:


Hope that help

During the process of throwing an exception, the Java Virtual Machine
abruptly completes, one by one, any expressions, statements, method and
constructor invocations, initializers, and field initialization expressions
that have begun but not completed execution in the current thread. This
process continues until a handler is found that indicates that it handles
that particular exception by naming the class of the exception or a
superclass of the class of the exception (§11.2 <
https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.2>).
If no such handler is found, then the exception may be handled by one of a
hierarchy of uncaught exception handlers (§11.3 <
https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.3>)
- thus every effort is made to avoid letting an exception go unhandled.

https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html <
https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html>


François




Le 30 mai 2020 à 16:52, smallufo  a écrit :

Francois Meillet  於 2020年5月30日 週六 下午10:48寫道:


sompage?67-1.-border-content-border_body-form is the path to your model


Yes , but it may contains deep-nested model

The form contains FormComponentPanel and contains another
FormComponentPanels and widgets , very deep ...
The error may lay under very deep model , which is very hard to debug.
And the error message should be able to pinpoint which model causes the
problem




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket HttpSessionDataStore, InMemoryCacheSize and MaxSizePerSession

2020-05-24 Thread Sven Meier

Hi,

both settings are unrelated:

- inMemoryCacheSize is 0 by default anyway
- maxSizePerSession is used by DiskDataStore (which you are replacing 
with HttpSessionDataStore)


Have fun
Sven


On 25.05.20 03:51, ShengChe Hsiao wrote:

Dear all

I want to use HttpSessionDataStore as default page store for session
cluster, does InMemoryCacheSize and MaxSizePersession affect it's function,
if both of them were 0 ?


--->
To boldly go where no man has gone before.

--->
We do this not because it is easy. We do this because it is hard.
-
-->
If I have seen further it is by standing on the shoulders of giants.
--
->
front...@gmail.com
->



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: WebSocket concurrent modification

2020-05-20 Thread Sven Meier

Hi,

I can reproduce the problem, but don't know yet what is causing this.

What I can see is that the page is properly locked when being accessed 
via Ajax or via a web socket push.

Thus a concurrent modification should not occur.

I'll have to investigate further.

Have fun
Sven


On 20.05.20 09:59, fanfy wrote:

Hello,

Maybe you can help me with a problem related to wicket 8.8.0 with websocket.
Sometimes (usually when there are many ajax request in a short time
interval) I encounter ConcurrentModificationException. The page store saving
is synchronous. I created a sample project (attached  websocket-test.tar

)

mvn package
java -jar target/websocket-test-0.0.1-SNAPSHOT.jar
http://localhost:8080/)

If clicking multiple times on 'New message' AjaxLink soon the exception is
thrown. Internally I have a timer that creates messages on 50 milliseconds
frequency (may be changed in src/main/resources/application.properties -
fanfy.messsage-generator-frequency=50)

Below is a sample stacktrace.

Thank you.

2020-05-20 10:43:55.241 ERROR 246999 --- [nio-8080-exec-1]
o.apache.wicket.DefaultExceptionMapper   : Unexpected error occurred

java.util.ConcurrentModificationException: null
at
org.apache.commons.collections4.map.AbstractLinkedMap$LinkIterator.nextEntry(AbstractLinkedMap.java:574)
~[commons-collections4-4.4.jar!/:4.4]
at
org.apache.commons.collections4.map.AbstractLinkedMap$ValuesIterator.next(AbstractLinkedMap.java:506)
~[commons-collections4-4.4.jar!/:4.4]
at
org.apache.wicket.MarkupContainer$1MarkupChildIterator.refreshInternalIteratorIfNeeded(MarkupContainer.java:624)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.MarkupContainer$1MarkupChildIterator.hasNext(MarkupContainer.java:573)
~[wicket-core-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:134)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:192)
~[wicket-util-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:976)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.ComponentEventSender.breadth(ComponentEventSender.java:160)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.ComponentEventSender.send(ComponentEventSender.java:68)
~[wicket-core-8.8.0.jar!/:8.8.0]
at org.apache.wicket.Component.send(Component.java:4413)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.ajax.AjaxRequestHandler.respond(AjaxRequestHandler.java:349)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:914)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.RequestHandlerExecutor.execute(RequestHandlerExecutor.java:65)
~[wicket-request-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:282)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:253)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:221)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.protocol.ws.AbstractUpgradeFilter.processRequestCycle(AbstractUpgradeFilter.java:70)
[wicket-native-websocket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:206)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:299)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)

Re: Page deserialization problem after a network problem

2020-05-19 Thread Sven Meier

Hi,

I don't understand how that exception ends up in your component 
hierarchy either.


Do you use a custom exception mapper or listener? I don't see any place 
in Wicket where that exception is stored.


Best regards

Sven


On 18.05.20 17:12, Calin Pavel wrote:

Sometime our customers have network problems (e.g connection interrupted
for a short period) and if that happens when we are sending response for a
page, an exception is thrown:



*2020-04-23 18:47:28 ERROR [ba00c0b5f1c83a39/ba00c0b5f1c83a39] [00529169]
[m00080874] DefaultExceptionMapper:144 - Connection lost, give up
responding.org.apache.wicket.protocol.http.servlet.ResponseIOException:
org.eclipse.jetty.io.EofException*

which is normal.

But after that if a user tries to do something else in the same page (e.g
clicks on an Ajax Link) a deserialization error appears (like stack trace
below).

Did anybody else encounter the same behaviour?

We are using Wicket 7.10.0 and do not understand:
1. why serialized page contains information (details of connection
exception) when serialized
2. why EofException is not found during deserialization, since it was
thrown seconds before in the same running JVM



2020-04-23 18:49:51 ERROR [850aa812ac5fa019/850aa812ac5fa019] [00529169]
[m00080874] DefaultExceptionMapper:170 - Unexpected error occurred
java.lang.RuntimeException: Could not deserialize object from byte[]
at
org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:143)
at
org.apache.wicket.pageStore.AbstractPageStore.deserializePage(AbstractPageStore.java:152)
at
org.apache.wicket.pageStore.AbstractCachingPageStore.getPage(AbstractCachingPageStore.java:67)
at
org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:231)
at
org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:393)
at
org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:82)
at
org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50)
at
org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:246)
at
org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:113)
at
org.apache.wicket.core.request.handler.PageProvider.getStoredPage(PageProvider.java:299)
at
org.apache.wicket.core.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
at
org.apache.wicket.core.request.handler.PageProvider.getPageInstance(PageProvider.java:169)
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:96)
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:157)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:895)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:284)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)
at
com.tvh.wicket.protocol.http.RequestTimeLoggingFilter.doFilter(RequestTimeLoggingFilter.java:167)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)
at brave.servlet.TracingFilter.doFilter(TracingFilter.java:86)
at
com.tvh.website.ecommerce.tracing.web.DelegatingTracingFilter.doFilter(DelegatingTracingFilter.java:38)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1125)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1059)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
at

Re: ModalWindow alert popup that submits form

2020-05-15 Thread Sven Meier

Sorry, we seem to speak about different buttons.

Could you create a quickstart? I've used validation in modal dialogs 
plenty of times and it works as expected.


Have fun
Sven


On 14.05.20 19:14, Entropy wrote:

The panel that launches the modal is not inside the form (it's part of a
standard header), so when i remove it from the constructor I get an illegal
state exception saying "form was not specified in the constructor and cannot
be found in the hierarchy of the component this behavior is attached to"

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: ModalWindow alert popup that submits form

2020-05-14 Thread Sven Meier
Hi,

form processing should work as usual in the modal window, including validation 
of course.

Does it make a difference when you let the AjaxButton find its form by itself?

Have fun
Sven

Am 13. Mai 2020 22:29:59 MESZ schrieb Entropy :
>We have a custom popup alert box launched from wicket.  It's build
>around
>org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow.  It
>works
>great in most situations where it's just messaging and doing other
>not-validating things.  But one of the buttons in one scenario needs to
>cause a save (and validate) of the form.  The buttons are based on
>AjaxButton, and the defaultformprocessing flag was set to true on that
>button during initialization.  the button has reference back to the
>form on
>the main page (the form is not INSIDE the modal).
>
>But everytime I submit, the onSubmit() runs instead of the onError()
>despite
>the fact that I deliberately put a validation error in the text that
>DOES
>get trapped on the normal submit process.
>
>Does anyone have an idea of where I should look?  or if this is just
>something you can't do from inside a modalwindow?  
>
>--
>Sent from:
>http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


Re: Access to initial IRequestHandler on IRequestCycleListener.onException

2020-05-02 Thread Sven Meier

Hi,

you can use PageRequestHandlerTracker for that:

https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/request/cycle/PageRequestHandlerTracker.java

Have fun
Sven


On 02.05.20 18:41, Olivier Dutrieux wrote:

Is there a possibility to access to initial IRequestHandler
(AjaxRequestHandler) on IRequestCycleListener.onException when the exception
is due to the rendering exception (Model do RuntimeException) of this ajax
request.

I see on RequestCycle.get() the initial ajax request but I can access it and
RequestCycle.get().find(AjaxRequestTarget.class) is empty.







-
Duto
--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: The AutoCompleteTextField model callback setObject() not working

2020-04-28 Thread Sven Meier

Hi,

you find an example page in wicket-examples 
org.apache.wicket.examples.ajax.builtin.AutoCompletePage that works fine.


Could you try it and check the difference to your code please?

Have fun
Sven


On 28.04.20 10:55, kyc wrote:

Dear Martin,

Thank you for your answer.

I upgraded to wicket 7.16 to test my program but the result is the same.  I
checked the browser console / the network console and no error is found.
(WICKET AJAX DEBUG box is also no error)

Please note the model getObject() call back is called normally.  The item
can be selected in the popup list and the selected string is shown in the
textfield.  However, the value will be disappeared after refresh as the
setObject() is not being called.



Brenda

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId

2020-04-24 Thread Sven Meier

Hi,

>Request URL:
>https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw
>Request Method:
>GET

that is a GET request with query parameters.

Form inputs should be able to pick up the values from the query parameters.

Maybe the problem is related to the cryptoMapper? Could you disable it 
for a test?


Have fun
Sven


On 24.04.20 17:43, Igor Khvostenkov wrote:

Hi Sven,

Yes exactly, but in fact this is POST. This is GET with POST parameters. And 
then FormComponent#getParameterValues(String inputName)

case Form.METHOD_GET:
  parameters = request.getQueryParameters();
  break;

Instead of

case Form.METHOD_POST:
  parameters = request.getPostParameters();
  break;

And I lost my POST parameters. Nothing works after.

-Igor.


On 24. Apr 2020, at 15:07, Sven Meier mailto:s...@meiers.net>> 
wrote:

Hi Igor,

so the browser sends the request a second time via "get".

That shouldn't be a problem, since in that case all FormComponents will read 
their parameters from the query parameters.

So what is your actual problem?

Have fun
Sven


On 24.04.20 11:34, Igor Khvostenkov wrote:
Hi Martin,

Thanks for the hint with "Preserve log”. Looks like still this is exactly what 
I described in reply to Sven. Browser does really POST request:


  *
Request URL:
https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw
  *
Request Method:
POST
  *
Status Code:
302
  *
Remote Address:
xxx:443
  *
Referrer Policy:
no-referrer-when-downgrade
   1.  Response Headers
  *
cache-control:
no-cache, no-store
  *
content-length:
0
  *
date:
Fri, 24 Apr 2020 09:17:33 GMT
  *
expires:
Thu, 01 Jan 1970 00:00:00 GMT
  *
location:
./DHB1U_x9J1dRXqDe8wegYw/DHB6d
  *
pragma:
no-cache
  *
server:
nginx
  *
status:
302

And then it gets redirect from proxy-server. And next request Browser 
substitutes POST to GET, as stated in RFC:


  *
Request URL:
https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw
  *
Request Method:
GET
  *
Status Code:
302
  *
Remote Address:
10.1.37.99:443
  *
Referrer Policy:
no-referrer-when-downgrade
   1.  Response Headers
  *
cache-control:
no-cache, no-store
  *
content-length:
0
  *
date:
Fri, 24 Apr 2020 09:17:33 GMT
  *
expires:
Thu, 01 Jan 1970 00:00:00 GMT
  *
location:
./login.html?wicket-crypt=0SaMcpSjW2Y
  *
pragma:
no-cache
  *
server:
nginx
  *
status:
302

  Am I missing something?

-Igor.

On 24. Apr 2020, at 09:41, Martin Grigorov 
mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>>
 wrote:

On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov
mailto:igor.khvosten...@lindenbaum.eu.invalid><mailto:igor.khvosten...@lindenbaum.eu.invalid>>
 wrote:

Hi Martin,

Yes, this is login form with special “token".

If this is PRG should I see POST request in Browser console? I see only
GET. Exactly one I’ve posted. Meaning that Browser does the substitution.


Yes, you should see POST with status 302 and then GET.
But to see them both you need to check "Preserve log" in the Network tab.
Otherwise the browser shows only the requests for the last load of the page
(including the request for the page itself and all resources like
css/js/images)



-Igor.

On 24. Apr 2020, at 06:02, Martin Grigorov 
mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>>>
 wrote:

Hi Igor,



On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov
mailto:igor.khvosten...@lindenbaum.eu.invalid><mailto:igor.khvosten...@lindenbaum.eu.invalid>mailto:igor.khvosten...@lindenbaum.eu.invalid><mailto:igor.khvosten...@lindenbaum.eu.invalid>>>
 wrote:

Hi Sven,

POST is substituted with GET by the HTTP client (Browser).

A web-server, any web-server, returns a 301 or 302 redirect then Browser,
on client side, will replace any type of request to GET. No server-side
configuration or any http headers returned will not change that.

-Igor.


On 23. Apr 2020, at 22:47, Sven Meier 
mailto:s...@meiers.net><mailto:s...@meiers.net>mailto:s...@meiers.net><mailto:s...@meiers.net>>mailto:s...@meiers.net><mailto:s...@meiers.net><mailto:s...@meiers.net>>>
 wrote:

Hi Igor,

so you think the "post" is redirected to a "get"? Why should that be the
case?

Who issues this redirect?

Best regar

Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId

2020-04-24 Thread Sven Meier

Hi Igor,

so the browser sends the request a second time via "get".

That shouldn't be a problem, since in that case all FormComponents will 
read their parameters from the query parameters.


So what is your actual problem?

Have fun
Sven


On 24.04.20 11:34, Igor Khvostenkov wrote:

Hi Martin,

Thanks for the hint with "Preserve log”. Looks like still this is exactly what 
I described in reply to Sven. Browser does really POST request:


  *
Request URL:
https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw
  *
Request Method:
POST
  *
Status Code:
302
  *
Remote Address:
xxx:443
  *
Referrer Policy:
no-referrer-when-downgrade
   1.  Response Headers
  *
cache-control:
no-cache, no-store
  *
content-length:
0
  *
date:
Fri, 24 Apr 2020 09:17:33 GMT
  *
expires:
Thu, 01 Jan 1970 00:00:00 GMT
  *
location:
./DHB1U_x9J1dRXqDe8wegYw/DHB6d
  *
pragma:
no-cache
  *
server:
nginx
  *
status:
302

And then it gets redirect from proxy-server. And next request Browser 
substitutes POST to GET, as stated in RFC:


  *
Request URL:
https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw
  *
Request Method:
GET
  *
Status Code:
302
  *
Remote Address:
10.1.37.99:443
  *
Referrer Policy:
no-referrer-when-downgrade
   1.  Response Headers
  *
cache-control:
no-cache, no-store
  *
content-length:
0
  *
date:
Fri, 24 Apr 2020 09:17:33 GMT
  *
expires:
Thu, 01 Jan 1970 00:00:00 GMT
  *
location:
./login.html?wicket-crypt=0SaMcpSjW2Y
  *
pragma:
no-cache
  *
server:
nginx
  *
status:
302

  Am I missing something?

-Igor.

On 24. Apr 2020, at 09:41, Martin Grigorov 
mailto:mgrigo...@apache.org>> wrote:

On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov
mailto:igor.khvosten...@lindenbaum.eu.invalid>>
 wrote:

Hi Martin,

Yes, this is login form with special “token".

If this is PRG should I see POST request in Browser console? I see only
GET. Exactly one I’ve posted. Meaning that Browser does the substitution.


Yes, you should see POST with status 302 and then GET.
But to see them both you need to check "Preserve log" in the Network tab.
Otherwise the browser shows only the requests for the last load of the page
(including the request for the page itself and all resources like
css/js/images)



-Igor.

On 24. Apr 2020, at 06:02, Martin Grigorov 
mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org>>> wrote:

Hi Igor,



On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov
mailto:igor.khvosten...@lindenbaum.eu.invalid>mailto:igor.khvosten...@lindenbaum.eu.invalid>>>
 wrote:

Hi Sven,

POST is substituted with GET by the HTTP client (Browser).

A web-server, any web-server, returns a 301 or 302 redirect then Browser,
on client side, will replace any type of request to GET. No server-side
configuration or any http headers returned will not change that.

-Igor.


On 23. Apr 2020, at 22:47, Sven Meier 
mailto:s...@meiers.net>mailto:s...@meiers.net>>mailto:s...@meiers.net><mailto:s...@meiers.net>>> wrote:

Hi Igor,

so you think the "post" is redirected to a "get"? Why should that be the
case?

Who issues this redirect?

Best regards
Sven


On 23.04.20 22:37, Igor Khvostenkov wrote:
Hi Sven,

Thank you for your reply. I did some deep investigation in the problem and
this is what I found:

if the generated HTML contains method="post", the browser will send the
form as post request.
This is no exactly true. Or let’s say this is true not in all cases. The
problem could happen when your web server returns a 301 or 302 redirect
then Browser will replace any type of request to GET:


Note: RFC 1945<https://tools.ietf.org/html/rfc1945> and RFC 2068<
https://tools.ietf.org/html/rfc2068> specify that the client is not
allowed
 to change the method on the redirected request.  However, most
 existing user agent implementations treat 302 as if it were a 303
 response, performing a GET on the Location field-value regardless
 of the original request method. The status codes 303 and 307 have
 been added for servers that wish to make unambiguously clear which
 kind of reaction is expected of the client.

This is exactly what happens in my case. And I can not really do anything
here, this is how all Browsers work. This was working good until we
upgraded to Wicket 7.16. There is one change which “broke” previously
working stuff. This change
https://issues.apache.org/jira/browse/WICKET-6708 and more precise this
code

https://github.com/

Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId

2020-04-23 Thread Sven Meier

Hi Igor,

so you think the "post" is redirected to a "get"? Why should that be the 
case?


Who issues this redirect?

Best regards
Sven


On 23.04.20 22:37, Igor Khvostenkov wrote:

Hi Sven,

Thank you for your reply. I did some deep investigation in the problem and this 
is what I found:

if the generated HTML contains method="post", the browser will send the form as 
post request.
This is no exactly true. Or let’s say this is true not in all cases. The 
problem could happen when your web server returns a 301 or 302 redirect then 
Browser will replace any type of request to GET:


Note: RFC 1945<https://tools.ietf.org/html/rfc1945> and RFC 
2068<https://tools.ietf.org/html/rfc2068> specify that the client is not allowed
   to change the method on the redirected request.  However, most
   existing user agent implementations treat 302 as if it were a 303
   response, performing a GET on the Location field-value regardless
   of the original request method. The status codes 303 and 307 have
   been added for servers that wish to make unambiguously clear which
   kind of reaction is expected of the client.

This is exactly what happens in my case. And I can not really do anything here, 
this is how all Browsers work. This was working good until we upgraded to 
Wicket 7.16. There is one change which “broke” previously working stuff. This 
change https://issues.apache.org/jira/browse/WICKET-6708 and more precise this 
code 
https://github.com/apache/wicket/commit/0c19cf8/#diff-51cf2faf6078497df77cc6d995dd1b98.
 Starting from Wicket 7.16 you distinguish between GET and POST in 
FormComponent#getInputAsArray() and for the form submit this will not work in 
case of redirect.

-Igor.

On 23. Apr 2020, at 17:15, Sven Meier mailto:s...@meiers.net>> 
wrote:

Hi,

if the generated HTML contains method="post", the browser will send the form as 
post request.

Without more detailed information, it's hard to find the error. Can you write a 
quickstart?

Have fun
Sven


On 23.04.20 11:59, Igor Khvostenkov wrote:
Hi *,

I faced with the problem. When Wicket-generated URL contains jsessionId, form 
submitted with GET request, and not POST. If I remove jsessionId from URL, then 
normal POST request is done. I have no idea where this GET is coming from. I 
ovverode getMethod() to always return POST and issue still exist. Any ideas 
where I can look to figure out why GET request is done?

Generated HTML:



  Konferenz-Teilnehmer 

https://xxx/conference/ng/wicket/page?3
   10.
sec-fetch-dest:
document
   11.
sec-fetch-mode:
navigate
   12.
sec-fetch-site:
same-origin
   13.
upgrade-insecure-requests:
1
   14.
user-agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like 
Gecko) Chrome/81.0.4044.122 Safari/537.36

-Igor.



-
To unsubscribe, e-mail: 
users-unsubscr...@wicket.apache.org<mailto:users-unsubscr...@wicket.apache.org>
For additional commands, e-mail: 
users-h...@wicket.apache.org<mailto:users-h...@wicket.apache.org>






-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId

2020-04-23 Thread Sven Meier

Hi,

if the generated HTML contains method="post", the browser will send the 
form as post request.


Without more detailed information, it's hard to find the error. Can you 
write a quickstart?


Have fun
Sven


On 23.04.20 11:59, Igor Khvostenkov wrote:

Hi *,

I faced with the problem. When Wicket-generated URL contains jsessionId, form 
submitted with GET request, and not POST. If I remove jsessionId from URL, then 
normal POST request is done. I have no idea where this GET is coming from. I 
ovverode getMethod() to always return POST and issue still exist. Any ideas 
where I can look to figure out why GET request is done?

Generated HTML:



  Konferenz-Teilnehmer 

https://xxx/conference/ng/wicket/page?3
   10.
sec-fetch-dest:
document
   11.
sec-fetch-mode:
navigate
   12.
sec-fetch-site:
same-origin
   13.
upgrade-insecure-requests:
1
   14.
user-agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like 
Gecko) Chrome/81.0.4044.122 Safari/537.36

-Igor.




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-15 Thread Sven Meier

Hi Thomas,

I've pushed a change for 
https://issues.apache.org/jira/browse/WICKET-6769 to master.


I'm not sure about the API right now, but it allows you to easily use 
any other map implementation.


Caffeine's Cache#asMap() should work fine with here, although I didn't 
test it myself.


Have fun
Sven


On 12.04.20 20:41, Thomas Heigl wrote:

Hi Sven,

I was thinking about this as well.

SoftReferences worked well in my application. G1GC seems to start to evict
them when -XX:InitiatingHeapOccupancyPercent is reached. In my case, when
the heap is around 60% full.
But as you said, there is no real control over which references are evicted
and it is much harder to monitor the current state of the memory map.

We are already using Caffeine extensively and your suggested solution would
allow me much more control over the cache.
We could still use SoftReferences with Caffeine if we wanted to in addition
to setting a global limit on cache size and an eviction policy.

To avoid calling an overridable method from the constructor you could add a
Supplier> argument. I usually choose a
supplier-based approach in such cases.

Let's go for this solution!

Best regards,

Thomas



On Sun, Apr 12, 2020 at 6:57 PM Sven Meier  wrote:


Hi Thomas,

I've did a little research on using SoftReferences for caches:

https://stackoverflow.com/questions/264582/is-there-a-softhashmap-in-java

http://jeremymanson.blogspot.com/2009/07/how-hotspot-decides-to-clear_07.html

The experts seem to agree that depending on the GC to clean up your
cache is a bad idea:

- you can't control which elements in the cache are evicted first
- eviction happens only when the system is low on memory

Best option would be using Guava's CacheBuilder:

https://github.com/google/guava/wiki/CachesExplained

IMHO these are very special solutions and we don't actually need to
integrate one of them into Wicket.
Instead we can leave that decision to your application, by adding an
overridable method to InMemoryPageStore:

  /**
   * Create a map to hold memory data for all sessions.
   *
   * @return a {@link ConcurrentHashMap} by default
   */
  protected Map newMemoryMap()
  {
  return new ConcurrentHashMap<>();
  }

(Yes, it would be called from the constructor which is a bad practice by
itself, but this is the simplest solution.)

What do you think?

Sven


On 12.04.20 10:34, Thomas Heigl wrote:

Hi Sven,

That's good to hear! Please let me know when you have an implementation

and

I'll give it another go.

Best regards,

Thomas

On Sat, Apr 11, 2020 at 11:01 PM Sven Meier  wrote:


Hi Thomas,

actually not bad news at all (for Wicket 9 at least).

The old page manager implementation had so many special concepts and
solutions, it's easy to miss one.

A soft reference feature can easily be added/restored. I'm already
checking where it fits best.

Thanks for your thorough testing.

Best regards
Sven


On 11.04.20 10:58, Thomas Heigl wrote:

Hi all,

Bad news. My application was caught in a GC loop after running for 8

hours.

The old generation was exhausted.

I couldn't get a heap dump at that time but restarted the application,

took

a heap dump after about an hour, and reverted back to Wicket 8.

The problem is this: The heap was full of objects referencing
InMemoryPageStore, i.e. the in-memory 2nd-level cache for pages. My

first

thought was that there is something wrong with the implementation of

that

store and pages do not get limited or removed correctly.  So I debugged
it locally but everything is working fine.

Then I noticed that there are a lot of instances of Hibernate entities

on

the heap. So there definitely is an issue with models somewhere in my
application. To be sure that this is not a new issue, I took another

heap

dump from production - now running Wicket 8 again - and compared it.
There are undetached entity models on the heap as well.

So why does it not OOM with Wicket 8? Well, the PerSessionPageStore
(roughly the equivalent of InMemoryPageStore in Wicket 9) uses
SoftReferences for storing pages. InMemoryPageStore does not and GC

cannot

reclaim memory from it.

So while this surfaced some issues in my application that I just

fixed, I

believe that InMemoryPageStore should use SoftReferences or another
implementation based on SoftReferences should be added to Wicket 9. A

cache

should not consume all the memory if it can easily re-fetch
the value from persistent storage.

I guess the reason for not using SoftReferences in InMemoryPageStore is
that it can theoretically be used as a "persistent" store for pages. If

that

behavior is really required, I suggest adding another implementation

using

SoftReferences.

Best regards,

Thomas

On Fri, Apr 10, 2020 at 7:19 PM Martin Grigorov 
wrote:


On Fri, Apr 10, 2020 at 4:01 PM Thomas Heigl 

wrote:

FYI: I deployed Wicket 9.0.0-M5 to production an hour ago. 100k

requests

served and no issues so far.


Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-12 Thread Sven Meier

Hi Thomas,

I've did a little research on using SoftReferences for caches:

https://stackoverflow.com/questions/264582/is-there-a-softhashmap-in-java
http://jeremymanson.blogspot.com/2009/07/how-hotspot-decides-to-clear_07.html

The experts seem to agree that depending on the GC to clean up your 
cache is a bad idea:


- you can't control which elements in the cache are evicted first
- eviction happens only when the system is low on memory

Best option would be using Guava's CacheBuilder:

  https://github.com/google/guava/wiki/CachesExplained

IMHO these are very special solutions and we don't actually need to 
integrate one of them into Wicket.
Instead we can leave that decision to your application, by adding an 
overridable method to InMemoryPageStore:


    /**
     * Create a map to hold memory data for all sessions.
     *
     * @return a {@link ConcurrentHashMap} by default
     */
    protected Map newMemoryMap()
    {
        return new ConcurrentHashMap<>();
    }

(Yes, it would be called from the constructor which is a bad practice by 
itself, but this is the simplest solution.)


What do you think?

Sven


On 12.04.20 10:34, Thomas Heigl wrote:

Hi Sven,

That's good to hear! Please let me know when you have an implementation and
I'll give it another go.

Best regards,

Thomas

On Sat, Apr 11, 2020 at 11:01 PM Sven Meier  wrote:


Hi Thomas,

actually not bad news at all (for Wicket 9 at least).

The old page manager implementation had so many special concepts and
solutions, it's easy to miss one.

A soft reference feature can easily be added/restored. I'm already
checking where it fits best.

Thanks for your thorough testing.

Best regards
Sven


On 11.04.20 10:58, Thomas Heigl wrote:

Hi all,

Bad news. My application was caught in a GC loop after running for 8

hours.

The old generation was exhausted.

I couldn't get a heap dump at that time but restarted the application,

took

a heap dump after about an hour, and reverted back to Wicket 8.

The problem is this: The heap was full of objects referencing
InMemoryPageStore, i.e. the in-memory 2nd-level cache for pages. My first
thought was that there is something wrong with the implementation of that
store and pages do not get limited or removed correctly.  So I debugged
it locally but everything is working fine.

Then I noticed that there are a lot of instances of Hibernate entities on
the heap. So there definitely is an issue with models somewhere in my
application. To be sure that this is not a new issue, I took another heap
dump from production - now running Wicket 8 again - and compared it.
There are undetached entity models on the heap as well.

So why does it not OOM with Wicket 8? Well, the PerSessionPageStore
(roughly the equivalent of InMemoryPageStore in Wicket 9) uses
SoftReferences for storing pages. InMemoryPageStore does not and GC

cannot

reclaim memory from it.

So while this surfaced some issues in my application that I just fixed, I
believe that InMemoryPageStore should use SoftReferences or another
implementation based on SoftReferences should be added to Wicket 9. A

cache

should not consume all the memory if it can easily re-fetch
the value from persistent storage.

I guess the reason for not using SoftReferences in InMemoryPageStore is
that it can theoretically be used as a "persistent" store for pages. If

that

behavior is really required, I suggest adding another implementation

using

SoftReferences.

Best regards,

Thomas

On Fri, Apr 10, 2020 at 7:19 PM Martin Grigorov 
wrote:


On Fri, Apr 10, 2020 at 4:01 PM Thomas Heigl 

wrote:

FYI: I deployed Wicket 9.0.0-M5 to production an hour ago. 100k

requests

served and no issues so far.


Awesome!
Thank you for testing it!



Great work!

Thomas

On Wed, Apr 8, 2020 at 3:13 PM Sven Meier  wrote:


Many thanks Maxim!

Sven

On 08.04.20 14:29, Maxim Solodovnik wrote:

Released :)

On Wed, 8 Apr 2020 at 15:41, Maxim Solodovnik 

wrote:

OK

Will start new release process in couple of hours
Please stop me if you will find any blocker :)

On Wed, 8 Apr 2020 at 14:36, Thomas Heigl 

wrote:

Hi Maxim,

It works for me now!

Thomas

On Wed, Apr 8, 2020 at 9:17 AM Maxim Solodovnik <

solomax...@gmail.com>

wrote:


Thanks a million!

On Wed, 8 Apr 2020 at 14:10, Thomas Heigl 

wrote:

Hi Maxim,

I'm testing against the snapshot now. Will get back to you

shortly.

Thomas

On Wed, Apr 8, 2020 at 2:53 AM Maxim Solodovnik <

solomax...@gmail.com>

wrote:


Hello All,

M5 seems to be broken (deploy has failed more than 10 times

during

my

build attempts)
I have to start another release
Could you please tell when can I start?

On Wed, 8 Apr 2020 at 07:01, Maxim Solodovnik <

solomax...@gmail.com

wrote:

Hello Thomas,

Please test M6-SNAPSHOT (so I don't have to release M5.2 :

On Wed, 8 Apr 2020 at 02:39, Thomas Heigl 
wrote:

Hi Maxim,

That would be great. I want to do some more extensive testing

and

then

deploy M5 into produc

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-11 Thread Sven Meier

Hi Thomas,

actually not bad news at all (for Wicket 9 at least).

The old page manager implementation had so many special concepts and 
solutions, it's easy to miss one.


A soft reference feature can easily be added/restored. I'm already 
checking where it fits best.


Thanks for your thorough testing.

Best regards
Sven


On 11.04.20 10:58, Thomas Heigl wrote:

Hi all,

Bad news. My application was caught in a GC loop after running for 8 hours.
The old generation was exhausted.

I couldn't get a heap dump at that time but restarted the application, took
a heap dump after about an hour, and reverted back to Wicket 8.

The problem is this: The heap was full of objects referencing
InMemoryPageStore, i.e. the in-memory 2nd-level cache for pages. My first
thought was that there is something wrong with the implementation of that
store and pages do not get limited or removed correctly.  So I debugged
it locally but everything is working fine.

Then I noticed that there are a lot of instances of Hibernate entities on
the heap. So there definitely is an issue with models somewhere in my
application. To be sure that this is not a new issue, I took another heap
dump from production - now running Wicket 8 again - and compared it.
There are undetached entity models on the heap as well.

So why does it not OOM with Wicket 8? Well, the PerSessionPageStore
(roughly the equivalent of InMemoryPageStore in Wicket 9) uses
SoftReferences for storing pages. InMemoryPageStore does not and GC cannot
reclaim memory from it.

So while this surfaced some issues in my application that I just fixed, I
believe that InMemoryPageStore should use SoftReferences or another
implementation based on SoftReferences should be added to Wicket 9. A cache
should not consume all the memory if it can easily re-fetch
the value from persistent storage.

I guess the reason for not using SoftReferences in InMemoryPageStore is
that it can theoretically be used as a "persistent" store for pages. If that
behavior is really required, I suggest adding another implementation using
SoftReferences.

Best regards,

Thomas

On Fri, Apr 10, 2020 at 7:19 PM Martin Grigorov 
wrote:


On Fri, Apr 10, 2020 at 4:01 PM Thomas Heigl  wrote:


FYI: I deployed Wicket 9.0.0-M5 to production an hour ago. 100k requests
served and no issues so far.


Awesome!
Thank you for testing it!



Great work!

Thomas

On Wed, Apr 8, 2020 at 3:13 PM Sven Meier  wrote:


Many thanks Maxim!

Sven

On 08.04.20 14:29, Maxim Solodovnik wrote:

Released :)

On Wed, 8 Apr 2020 at 15:41, Maxim Solodovnik 

wrote:

OK

Will start new release process in couple of hours
Please stop me if you will find any blocker :)

On Wed, 8 Apr 2020 at 14:36, Thomas Heigl 

wrote:

Hi Maxim,

It works for me now!

Thomas

On Wed, Apr 8, 2020 at 9:17 AM Maxim Solodovnik <

solomax...@gmail.com>

wrote:


Thanks a million!

On Wed, 8 Apr 2020 at 14:10, Thomas Heigl 

wrote:

Hi Maxim,

I'm testing against the snapshot now. Will get back to you

shortly.

Thomas

On Wed, Apr 8, 2020 at 2:53 AM Maxim Solodovnik <

solomax...@gmail.com>

wrote:


Hello All,

M5 seems to be broken (deploy has failed more than 10 times

during

my

build attempts)
I have to start another release
Could you please tell when can I start?

On Wed, 8 Apr 2020 at 07:01, Maxim Solodovnik <

solomax...@gmail.com

wrote:

Hello Thomas,

Please test M6-SNAPSHOT (so I don't have to release M5.2 :

On Wed, 8 Apr 2020 at 02:39, Thomas Heigl 
wrote:

Hi Maxim,

That would be great. I want to do some more extensive testing

and

then

deploy M5 into production. ;)

Thomas

On Tue, Apr 7, 2020 at 7:50 PM Maxim Solodovnik <

solomax...@gmail.com>

wrote:


I can pack another release
later this week ...

On Wed, 8 Apr 2020 at 00:48, Thomas Heigl <

tho...@umschalt.com

wrote:

Thanks Sven!

Did your changes make it into the release? Or did they just

miss

it?

Thomas

On Tue, Apr 7, 2020 at 7:43 PM Sven Meier 

wrote:

Hi Thomas,

yes, you're right:

wicketstuff data stores missed some adjustments to the

latest

updates

in

wicket-core.

And SessionQuotaManagingDataStore$DelegatedPage must be

serializable of

course.

I've pushed changes to wicketstuff master.

Thanks
Sven


On 07.04.20 14:14, Thomas Heigl wrote:

And one more thing. There is now a warning logged just

before

serialization:

WARN o.a.w.pageStore.AsynchronousPageStore: Delegated

page

store

'org.apache.wicket.pageStore.SerializingPageStore' can

not be

asynchronous

On Tue, Apr 7, 2020 at 2:09 PM Thomas Heigl <

tho...@umschalt.com>

wrote:

The cause is the following MetaData entry in the session:

class

org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$1=org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$SizeLimitedData@4090594a

On Tue, Apr 7, 2020 at 1:59 PM Thomas Heigl <

tho...@umschalt.com>

wrote:

Hi Sven,

I just found time to give this a try with Wicket

9.0.0-M5.

There

seem

Re: Upgrade to Wicket 9: troubles with WicketTester and MockPageStore

2020-04-10 Thread Sven Meier

Hi Francesco,

there was a slight difference in the mock setup, which should now be as 
in Wicket 8:


    https://issues.apache.org/jira/browse/WICKET-6766

Many thanks for testing with Wicket 9!

Sven


On 09.04.20 16:42, Francesco Chicchiriccò wrote:

On 2020/04/09 12:04:00, Sven Meier  wrote:

Hi Francesco,

I'll have to check what has changed here.

I wouldn't expect any problems with MockPageStore, but perhaps it
changed slightly.

Can you write a testcase that runs in Wicket 8 but fails in 9?

Not sure if I am able, but I'll try.
Meanwhile, should you get an enlightenment, please report.

Regards.


On 09.04.20 12:20, Francesco Chicchiriccò wrote:

Hi all,
at Syncope we have been upgrading our Console and Enduser web applications from 
Wicket 8 to 9.0.0-M5, in our master branch.

The process have been quite smooth effectively, with a single noticeable 
exception: in our tests we largely use WicketTester; we have verified, however, 
that Pages in the MockPageStore are incrementing their numericId during tests 
execution, even though they are still looked up by their initial numericId.

We are using this workaround:

https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/AbstractConsoleITCase.java#L107-L125

which is serving its purpose for the moment; please note that this was not 
needed with Wicket 8.

Are we missing something or the one above is effectively a bug?

Thanks for your support.
Regards.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Upgrade to Wicket 9: troubles with WicketTester and MockPageStore

2020-04-09 Thread Sven Meier

Hi Francesco,

I'll have to check what has changed here.

I wouldn't expect any problems with MockPageStore, but perhaps it 
changed slightly.


Can you write a testcase that runs in Wicket 8 but fails in 9?

Have fun
Sven


On 09.04.20 12:20, Francesco Chicchiriccò wrote:

Hi all,
at Syncope we have been upgrading our Console and Enduser web applications from 
Wicket 8 to 9.0.0-M5, in our master branch.

The process have been quite smooth effectively, with a single noticeable 
exception: in our tests we largely use WicketTester; we have verified, however, 
that Pages in the MockPageStore are incrementing their numericId during tests 
execution, even though they are still looked up by their initial numericId.

We are using this workaround:

https://github.com/apache/syncope/blob/master/fit/core-reference/src/test/java/org/apache/syncope/fit/console/AbstractConsoleITCase.java#L107-L125

which is serving its purpose for the moment; please note that this was not 
needed with Wicket 8.

Are we missing something or the one above is effectively a bug?

Thanks for your support.
Regards.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-08 Thread Sven Meier

Many thanks Maxim!

Sven

On 08.04.20 14:29, Maxim Solodovnik wrote:

Released :)

On Wed, 8 Apr 2020 at 15:41, Maxim Solodovnik  wrote:

OK

Will start new release process in couple of hours
Please stop me if you will find any blocker :)

On Wed, 8 Apr 2020 at 14:36, Thomas Heigl  wrote:

Hi Maxim,

It works for me now!

Thomas

On Wed, Apr 8, 2020 at 9:17 AM Maxim Solodovnik 
wrote:


Thanks a million!

On Wed, 8 Apr 2020 at 14:10, Thomas Heigl  wrote:

Hi Maxim,

I'm testing against the snapshot now. Will get back to you shortly.

Thomas

On Wed, Apr 8, 2020 at 2:53 AM Maxim Solodovnik 
wrote:


Hello All,

M5 seems to be broken (deploy has failed more than 10 times during my
build attempts)
I have to start another release
Could you please tell when can I start?

On Wed, 8 Apr 2020 at 07:01, Maxim Solodovnik 
wrote:

Hello Thomas,

Please test M6-SNAPSHOT (so I don't have to release M5.2 :

On Wed, 8 Apr 2020 at 02:39, Thomas Heigl 

wrote:

Hi Maxim,

That would be great. I want to do some more extensive testing and

then

deploy M5 into production. ;)

Thomas

On Tue, Apr 7, 2020 at 7:50 PM Maxim Solodovnik <

solomax...@gmail.com>

wrote:


I can pack another release
later this week ...

On Wed, 8 Apr 2020 at 00:48, Thomas Heigl 

wrote:

Thanks Sven!

Did your changes make it into the release? Or did they just

miss

it?

Thomas

On Tue, Apr 7, 2020 at 7:43 PM Sven Meier 

wrote:

Hi Thomas,

yes, you're right:

wicketstuff data stores missed some adjustments to the latest

updates

in

wicket-core.

And SessionQuotaManagingDataStore$DelegatedPage must be

serializable of

course.

I've pushed changes to wicketstuff master.

Thanks
Sven


On 07.04.20 14:14, Thomas Heigl wrote:

And one more thing. There is now a warning logged just

before

serialization:

WARN o.a.w.pageStore.AsynchronousPageStore: Delegated

page

store

'org.apache.wicket.pageStore.SerializingPageStore' can

not be

asynchronous


On Tue, Apr 7, 2020 at 2:09 PM Thomas Heigl <

tho...@umschalt.com>

wrote:

The cause is the following MetaData entry in the session:

class

org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$1=org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$SizeLimitedData@4090594a

On Tue, Apr 7, 2020 at 1:59 PM Thomas Heigl <

tho...@umschalt.com>

wrote:

Hi Sven,

I just found time to give this a try with Wicket

9.0.0-M5.

There

seem

to

be issues with serialization now.

My new config:

protected IPageStore newCachingStore(IPageStore

pageStore) {

return new CachingPageStore(pageStore, new

InMemoryPageStore(getName(),

MAX_PAGES_CACHED_PER_SESSION));
}
protected IPageStore newPersistentStore() {
final RedissonRedisCache redisCache = new
RedissonRedisCache(redissonClient);
final RedisDataStore redisDataStore = new

RedisDataStore(getName(),

redisCache, new RedisSettings());
return new SessionQuotaManagingDataStore(redisDataStore,
DATA_STORE_MAX_BYTES_PER_SESSION);
}

This exception is logged after requests:



org.springframework.data.redis.serializer.SerializationException:

Cannot

serialize; nested exception is


org.springframework.core.serializer.support.SerializationFailedException:

Failed to serialize object using DefaultSerializer;

nested

exception

is

java.io.NotSerializableException:


org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$DelegatedPage

at


org.springframework.data.redis.serializer.JdkSerializationRedisSerializer.serialize(JdkSerializationRedisSerializer.java:96)

at


org.springframework.data.redis.core.AbstractOperations.rawHashValue(AbstractOperations.java:185)

at


org.springframework.data.redis.core.DefaultHashOperations.putAll(DefaultHashOperations.java:147)

at


org.springframework.data.redis.core.DefaultBoundHashOperations.putAll(DefaultBoundHashOperations.java:147)

at


org.springframework.session.data.redis.RedisIndexedSessionRepository$RedisSession.saveDelta(RedisIndexedSessionRepository.java:795)

at


org.springframework.session.data.redis.RedisIndexedSessionRepository$RedisSession.save(RedisIndexedSessionRepository.java:783)

at


org.springframework.session.data.redis.RedisIndexedSessionRepository$RedisSession.access$000(RedisIndexedSessionRepository.java:670)

at


org.springframework.session.data.redis.RedisIndexedSessionRepository.save(RedisIndexedSessionRepository.java:398)

at


org.springframework.session.data.redis.RedisIndexedSessionRepository.save(RedisIndexedSessionRepository.java:249)

at


com.myproject.session.InstrumentedFindByIndexNameSessionRepository.save(InstrumentedFindByIndexNameSessionRepository.java:29)

at


java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native

Method)
at


java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at


java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at

java.base/java.lang.reflect.Method.invo

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-07 Thread Sven Meier
(JdkDynamicAopProxy.java:212)
at com.sun.proxy.$Proxy296.save(Unknown Source)
at
org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.commitSession(SessionRepositoryFilter.java:225)
at
org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.access$100(SessionRepositoryFilter.java:192)
at
org.springframework.session.web.http.SessionRepositoryFilter.doFilterInternal(SessionRepositoryFilter.java:144)
at
org.springframework.session.web.http.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:82)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:666)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1594)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by:
org.springframework.core.serializer.support.SerializationFailedException:
Failed to serialize object using DefaultSerializer; nested exception is
java.io.NotSerializableException:
org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$DelegatedPage
at
org.springframework.core.serializer.support.SerializingConverter.convert(SerializingConverter.java:68)
at
org.springframework.core.serializer.support.SerializingConverter.convert(SerializingConverter.java:35)
at
org.springframework.data.redis.serializer.JdkSerializationRedisSerializer.serialize(JdkSerializationRedisSerializer.java:94)
... 52 common frames omitted
Caused by: java.io.NotSerializableException:
org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$DelegatedPage


Why does Wicket 9 try to serialize the SessionQuotaManagingDataStore in
the session? Is this intended and does DelegatePage simply need to
implement Serializable or shouldn't this be serialized at all? In Wicket 8,
the corresponding PageData wasn't serializable either so my guess would be
that this behavior is not intended.

I'm using the following config for Wicket 8 and there are no such issues:

protected IPageStore newPageStore(IDataStore dataStore) {

final ISerializer pageSerializer =
getFrameworkSettings().getSerializer();
return new PerSessionPageStore(pageSerializer, dataStore,
MAX_PAGES_CACHED_PER_SESSION);
}
protected IDataStore newDataStore() {
final RedissonRedisCache redisCache = new
RedissonRedisCache(redissonClient.get());
final RedisDataStore redisDataStore = new RedisDataStore(redisCache, new
RedisSettings());
return new SessionQuotaManagingDataStore(redisDataStore,
DATA_STORE_MAX_BYTES_PER_SESSION);
}


Best regards,

Thomas

On Sat, Mar 28, 2020 at 10:23 AM Thomas Heigl 
wrote:


Thanks Sven!

That looks much better. I'll give it a try as soon as I can.

Best regards,

Thomas

On Fri, Mar 27, 2020 at 2:23 PM Sven Meier  wrote:


Hi Thomas,

your question comes at the right time.

I was able to improve the implementation with a new CachingPageStore:


https://github.com/apache/wicket/blob/8df3528dc44a08b7d375c20e764a3664cd6a5f30/wicket-core/src/main/java/org/apache/wicket/DefaultPageManagerProvider.java#L145

You can now use InMemoryPageStore as a cache too.

Have fun
Sven


On 27.03.20 09:34, Sven Meier wrote:

Hi Thomas,

I thought I covered that usecase, but I will have to take a look.

Thanks for testing Wicket 9
Sven

On 25.03.20 20:10, Thomas Heigl wrote:

Maybe the same approach could be used as for InSessionPageStore that
can be
used as cache and a store:



https://github.com/apache/wicket/commit/894799e01227781be76886b2d1cdb2a424c812e0


On Wed, Mar 25, 2020 at 6:35 PM Thomas Heigl 
wrote:


Hi all,

I just merged our master in our Wicket 9 branch and I ran into an
issue:

Our current configuration with Wicket 8 looks like this:

PageStore = PerSessionPageStore
DataStore

Re: How can a component know if it's being rendered as part of Ajax response?

2020-04-05 Thread Sven Meier

Hi,

actually it's not that common, in wicket-core and -extensions this 
pattern is used 9 times only.


When the RequestCycle API emerged, we decided against a specific method 
and chose a generic one with parameter instead.


Have fun
Sven


On 05.04.20 08:47, Vit Rozkovec wrote:
Hi, this seems to be a frequent use case, wouldn't there be a good fit 
for some shorthand method?


Like

/getRequestCycle().onAjax(t-> {});/
boolean getRequestCycle().isAjax();

?

Vit


On 4/4/20 11:51 PM, Sven Meier wrote:

Hi,

you can test for the appropriate request handler:

getRequestCycle().find(IPartialPageRequestHandler.class).ifPresent(target 
-> /* do things on partial page update */));


Have fun
Sven


On 04.04.20 23:43, Vilius Vaivada wrote:

Hey guys,

I'm pretty sure I'm missing something obvious here, but I can't 
figure out
a simple way for a component to contribute slightly different 
Javascript
based on whether it's being rendered for a full page load or a 
partial Ajax

response. Any clues?

Thanks a lot!



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How can a component know if it's being rendered as part of Ajax response?

2020-04-04 Thread Sven Meier

Hi,

you can test for the appropriate request handler:

getRequestCycle().find(IPartialPageRequestHandler.class).ifPresent(target 
-> /* do things on partial page update */));


Have fun
Sven


On 04.04.20 23:43, Vilius Vaivada wrote:

Hey guys,

I'm pretty sure I'm missing something obvious here, but I can't figure out
a simple way for a component to contribute slightly different Javascript
based on whether it's being rendered for a full page load or a partial Ajax
response. Any clues?

Thanks a lot!



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wizard vs WicketTester

2020-04-04 Thread Sven Meier

Hi Maxim,

> lastRendered page === 'null' after submit
> Maybe I'm doing something wrong?

it seems so. Check the log output and/or provide a testcase please.

Have fun
Sven


On 04.04.20 07:35, Maxim Solodovnik wrote:

Hello All,

I'm trying to to test Wizard with WicketTester
Wizard is the component with "splitted" form which is partially submitted
multiple times
FormTester allows only single submit

it's not a problem to create second FormTester BUT lastRendered page ===
'null' after submit :(

Maybe I'm doing something wrong?

BTW there is no tests for Wizard in Wicket code base, only WizardModel is
tested



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket.Ajax.Call.processEvaluation // how to not get reference errors in case one has to check for a var?

2020-04-02 Thread Sven Meier

Hi Korbinian,

Wicket just evaluates your JS, if you get a ReferenceError then surely 
there's something wrong in your code.


Are you sure you're looking on the correct source line?

Have fun

Sven


On 02.04.20 15:57, Korbinian Bachl wrote:

Hi,

i've added some JS to be exectued after AJAX but wicket always sees an error 
where none is:

Wicket.Ajax:  Wicket.Ajax.Call.processEvaluation: Exception evaluating 
javascript: ReferenceError: etCommerce is not defined, text: (function(){var p=
{
...
}
if(etCommerce) { etCommerce.sendEvent('insertToBasket', product, 1); }})();

Here we get an error that etCommerce is not defined - thats right but it is checked for 
it with "if(etCommerce)", so its perfectly valid JS?

Also if I user if(etCommerce !== 'undefined') nothing changes as well, error 
stays?!?

How can I get rid of these console alarms? And why is this also done in 
production mode?

Best,

KB

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: ERROR org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse

2020-04-01 Thread Sven Meier

Hi Thorsten,

I wanted to ask for that stacktrace anyway: )

Seems WebPageRenderer thinks it has to store the rendering result and 
redirect to it.
That's definitely nothing something you want to have when using 
ComponentRenderer.


There's probably something in your setup that triggers this redirect 
(e.g. page url changes after render). Maybe we could improve 
ComponentRender so it never redirects.


Best regards
Sven


On 01.04.20 19:53, Thorsten Schöning wrote:

Guten Tag Sven Meier,
am Mittwoch, 1. April 2020 um 17:31 schrieben Sie:


Without a quickstart it's hard to guess whether this is an error
actually or you did something wrong.

Things are easy in my opinion: There's no session-ID in my use case at
all, the code itself is tolerant and many other places are as well,
like BufferedResponseMapper:


 protected String getSessionId()
 {
 String sessionId = null;

 if (Application.exists() && RequestCycle.get() != null)
 {
[...]
 Session session = 
sessionStore.lookup(requestCycle.getRequest());
 if (session != null)
 {
 sessionId = session.getId();
 }
 }

 return sessionId;
 }
 protected boolean hasBufferedResponse(Url url)
 {
 String sessionId = getSessionId();
 boolean hasResponse = false;
 if (Strings.isEmpty(sessionId) == false)
 {
 hasResponse = 
WebApplication.get().hasBufferedResponse(sessionId, url);
 }
  return hasResponse;
 }

I tried to reproduce this using a quickstart but failed, it's too much
work to get all my components/customizations into place to see which
triggers the code path. The original quickstart doesn't seem to
trigger it.

So my approach is different, I'm simply overriding the method in
question and make it more tolerant myself. This allows me to get a
stacktrace of the code path triggered as well:


java.lang.UnsupportedOperationException: foobar
 at 
de.am_soft.sm_mtg.view.report.VwrRenderApp.storeBufferedResponse(VwrRenderApp.java:112)
 at 
org.apache.wicket.request.handler.render.WebPageRenderer.storeBufferedResponse(WebPageRenderer.java:87)
 at 
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:278)
 at 
org.apache.wicket.util.tester.BaseWicketTester$LastPageRecordingPageRendererProvider$1.respond(BaseWicketTester.java:2824)
 at 
org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:202)
 at 
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:914)
 at 
org.apache.wicket.request.RequestHandlerExecutor.execute(RequestHandlerExecutor.java:65)
 at 
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:282)
 at 
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:253)
 at 
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:221)
 at 
org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:713)
 at 
org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:652)
 at 
org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:879)
 at 
org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:896)
 at 
de.am_soft.sm_mtg.view.report.html.pages.meter_cnt.some_month.VwrPgMcsmSummaryTest.wicket(VwrPgMcsmSummaryTest.java:63)
 try (VwrCtxThreadScoped scopedCtx = new 
VwrCtxThreadScoped(ctx0))
 {
 Supplier   page= () -> new 
VwrPgMcsmSummary();
 VwrRenderAppapp = new 
VwrRenderApp(page);
 WicketTestertester  = new 
WicketTester(app);

 tester.startPage(page.get());
 }

Mit freundlichen Grüßen,

Thorsten Schöning



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: update DropDownList via AJAX

2020-04-01 Thread Sven Meier

Hi,

if the DropDownList is updated via Ajax, the DOM element gets replaced 
and the  closes,

I don't see a way around that.

You could try updating the select's inner  (via some Ajax JS 
magic) only. I'm not aware of a pre-build Wicket solution that would do 
that though.

Maybe Select2 or similar can help you with that.

Have fun
Sven


On 01.04.20 11:35, Sretan wrote:

Hello,

I have one TextField and one DropDownList.

When i enter example '1' in the TextField and after that click on the
DropDownList,
DropDownList is opened and at the same time is updated from the server
(because of the event fired from TextField) via AJAX.
The DropDownList list is updated and closed.

I must click again on DropDownList to open it. Can some how this closing be
prevented or any other ideas how to solve this?

I am using wicket 6.13.

Thanks

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: ERROR org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse

2020-04-01 Thread Sven Meier

Hi Thorsten,

the log message seems to have served it's purpose:
You reported the problem :P.

Without a quickstart it's hard to guess whether this is an error 
actually or you did something wrong.


Sven


On 01.04.20 17:06, Thorsten Schöning wrote:

Hi all

I have a project in which I use Wicket as some rendering engine only,
without actual HTTP-requests of any kind. As has been advised here in
the past, this is done using ComponentRenderer and some custom mocks
for the serializer and session store. The latter are pretty much what
is used within ComponentRenderer as well already.

Additionally I started using WicketTester in that project to test
things and during running tests I get the following errors logged:


16:31:21 ERROR
org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse:
storeBufferedResponse needs a valid session id to store the
response, but a null one was found. Please report the problem to dev
team and try to reproduce it in a quickstart project.

Nevertheless, things succeed, because the logging code simply returns
and in that case it doesn't seem to make any difference:


 public void storeBufferedResponse(String sessionId, Url url, 
BufferedWebResponse response)
 {
 if (Strings.isEmpty(sessionId))
 {
 log.error("storeBufferedResponse needs a valid session id 
to store the response, but a null one was found. "
 + "Please report the problem to dev team 
and try to reproduce it in a quickstart project.");
 return;
 }

 String key = sessionId + url.toString();
 storedResponses.put(key, response);
 }

Shouldn't this be changed to at least a warning, if not removed
entirely?

Both of my cases seem to be valid use cases in the end. So logging an
error when things can't ever work this way in those use cases seems
overkill and unnecessary alarming to me.

Mit freundlichen Grüßen,

Thorsten Schöning



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: FileUpload class still implements IClusterable

2020-03-30 Thread Sven Meier

This will be fixed with Wicket 9.

Have fun
Sven

On 30.03.20 19:32, natefki wrote:

FileUpload class despite everything actualizes IClusterable however it
contains a field of type FileItem: which is never again Serializable, Drop
IClusterable.

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Is it safe to use ComponentRenderer with different apps in the same thread one after another?

2020-03-29 Thread Sven Meier

Hi Thorsten,

> As well I really only need to render within one and the same thread
> one after another,

that should work.

> is it safe to render recursively using ComponentRenderer within
> one and the same thread?

I assume you mean 'consecutively'? Yes, see above.

Have fun
Sven


On 29.03.20 15:45, Thorsten Schöning wrote:

Hi all,

I'm using Wicket as some render engine to render mails for reports
consisting of different individual render approaches: plain text only,
HTML only, a combination of both. In the latter case I of course would
like to simply reuse the former approaches, but am not sure if the
used ComponentRenderer does support that.

My individual rendering looks like the following:


private static  String
 forSome(VwrCtxctx,
 Supplier page)
{
 try (VwrCtxThreadScoped scopedCtx = new VwrCtxThreadScoped(ctx))
 {
 VwrHtmlApp  app = new VwrHtmlApp();
 ComponentRenderer   renderer= new ComponentRenderer(app);
 CharSequenceretVal  = renderer.renderPage(page);

 return retVal.toString();
 }
}

"renderer.renderPage" is where I would call the above additionally to
provide text- and HTML-only. From my understanding that should be
safe, because ComponentRenderer supports multiple different contexts
for app etc.:


private  T inThreadContext(Supplier supplier)
{
 ThreadContext oldContext = ThreadContext.detach();

 try
 {
 ThreadContext.setApplication(application);

 return supplier.get();
 }
 finally
 {

 ThreadContext.restore(oldContext);
 }
}

As well I really only need to render within one and the same thread
one after another, I'm not resuing apps or contexts between different
threads in parallel. If that would be needed at some point, it would
be dealt with at a higher level rendering using some threadpool.

So, is it safe to render recursively using ComponentRenderer within
one and the same thread? Thanks!

Mit freundlichen Grüßen,

Thorsten Schöning



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Equivalent for PerSessionPageStore in Wicket 9

2020-03-27 Thread Sven Meier

Hi Thomas,

your question comes at the right time.

I was able to improve the implementation with a new CachingPageStore:

https://github.com/apache/wicket/blob/8df3528dc44a08b7d375c20e764a3664cd6a5f30/wicket-core/src/main/java/org/apache/wicket/DefaultPageManagerProvider.java#L145

You can now use InMemoryPageStore as a cache too.

Have fun
Sven


On 27.03.20 09:34, Sven Meier wrote:

Hi Thomas,

I thought I covered that usecase, but I will have to take a look.

Thanks for testing Wicket 9
Sven

On 25.03.20 20:10, Thomas Heigl wrote:
Maybe the same approach could be used as for InSessionPageStore that 
can be

used as cache and a store:

https://github.com/apache/wicket/commit/894799e01227781be76886b2d1cdb2a424c812e0 



On Wed, Mar 25, 2020 at 6:35 PM Thomas Heigl  
wrote:



Hi all,

I just merged our master in our Wicket 9 branch and I ran into an 
issue:


Our current configuration with Wicket 8 looks like this:

PageStore = PerSessionPageStore
DataStore = RedisDataStore

So the page store keeps the last couple of pages of a session in memory
and Redis is used as a persistent store.

I tried to recreate this behavior with Wicket 9:

SessionStore = InMemoryPageStore
PersistentStore = RedisDataStore

This looks correct, but it *does not work* because InMemoryPage store
implements AbstractPersistentPageStore and does *not* delegate to the
next store in the chain.

So we basically lost the option to use a memory page store in front 
of a

persistent store.

We need this functionality because we are using Spring Session and 
cannot

use the session as a page store.

Would it be possible to add an InMemory store that delegates to the 
next

store in the chain? Or do I have to implement it myself?

Best regards,

Thomas



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Equivalent for PerSessionPageStore in Wicket 9

2020-03-27 Thread Sven Meier

Hi Thomas,

I thought I covered that usecase, but I will have to take a look.

Thanks for testing Wicket 9
Sven

On 25.03.20 20:10, Thomas Heigl wrote:

Maybe the same approach could be used as for InSessionPageStore that can be
used as cache and a store:

https://github.com/apache/wicket/commit/894799e01227781be76886b2d1cdb2a424c812e0

On Wed, Mar 25, 2020 at 6:35 PM Thomas Heigl  wrote:


Hi all,

I just merged our master in our Wicket 9 branch and I ran into an issue:

Our current configuration with Wicket 8 looks like this:

PageStore = PerSessionPageStore
DataStore = RedisDataStore

So the page store keeps the last couple of pages of a session in memory
and Redis is used as a persistent store.

I tried to recreate this behavior with Wicket 9:

SessionStore = InMemoryPageStore
PersistentStore = RedisDataStore

This looks correct, but it *does not work* because InMemoryPage store
implements AbstractPersistentPageStore and does *not* delegate to the
next store in the chain.

So we basically lost the option to use a memory page store in front of a
persistent store.

We need this functionality because we are using Spring Session and cannot
use the session as a page store.

Would it be possible to add an InMemory store that delegates to the next
store in the chain? Or do I have to implement it myself?

Best regards,

Thomas



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Unexpected component-ID "2" for 1 child of repeating view.

2020-03-18 Thread Sven Meier

Hi,

that looks fine.

I was thinking of longer tests:

- start page
- click link*
- click button*
- ...
- check table contents

(* initiating a page render)

You could put a breakpoint in RepeatingView#newChildId() and check who's 
creating new items.


Have fun
Sven


On 18.03.20 12:38, Thorsten Schöning wrote:

Guten Tag Sven Meier,
am Mittwoch, 18. März 2020 um 10:04 schrieben Sie:


what IItemReuseStrategy are you using?
DefaultItemReuseStrategy creates new items on each render, which leads
to new ids.

I didn't care yet and can't find anything regarding that strategy, so
I guess it's the default one. While I indeed render the same page
multiple times within the same test, things look like the following:


try (VwrCtxThreadScoped scopedCtx = new VwrCtxThreadScoped(ctx0))
{
   VwrHtmlApp  app = new VwrHtmlApp();
   WicketTestertester  = new WicketTester(app);
   VwrHtmlPage page= new VwrPgMcsmSummary();

   tester.startPage(page);
   this.wicketAssertBase(tester, page);
   
tester.assertVisible("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:noResults");
   tester.destroy();
}

So each invocation works with new instances of everything in theory.
Even the results to render themself change, as those are contained in
"ctx0", "ctx1" and "ctx3".

So, shouldn't each of those blocks start freshly in theory?

Mit freundlichen Grüßen,

Thorsten Schöning



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to change the target of some form-action to some configured value?

2020-03-18 Thread Sven Meier

Hi Thorsten,

have you tried overriding #getActionUrl()?

Sven


On 18.03.20 10:19, Thorsten Schöning wrote:

Hi all,

I'm rendering a web page for offline use, but am playing around with
integration into the parent web site where that offline page comes
from. The current approach is to simply show the same auth-form used
by the online variant itself already and to simply POST credentials
there.

The problem is that Wicket generates a local action-target for the
form and I don't see any way to override that behaviour. Look at the
following examples:



vs.



What I'm currently doing is implementing a custom
"AbstractTransformerBehavior" simply changing the action-attribute in
the generated markup using some configured value.

Is that the easiest/preferred approach?

Searchign for that topic I only found Ajax-related things, which is
not what I'm interested in. But I couldn't find somethign to simply
set the target or override the strategy how that is calculated or
such.

Thanks for your hints!

Mit freundlichen Grüßen,

Thorsten Schöning



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Unexpected component-ID "2" for 1 child of repeating view.

2020-03-18 Thread Sven Meier

Hi Thorsten,

what IItemReuseStrategy are you using?

DefaultItemReuseStrategy creates new items on each render, which leads 
to new ids.


Maybe testing your additional panels initiates additional pages renderings?

Have fun
Sven


On 18.03.20 09:29, Thorsten Schöning wrote:

Hi all,

I have some test in Wicket which renders a HTML-table using some
"DataView" and in that test I'm distinguishing the cases 0, 1 and 3
result rows. The following is an example for 1 and 3 rows:


assertNotNull(tester.getComponentFromLastRenderedPage("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:resultsRow:1",
 true,  false), "No first result item available.");
assertNull(   
tester.getComponentFromLastRenderedPage("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:resultsRow:2",
 false, false), "A second result item available.");
assertNotNull(tester.getComponentFromLastRenderedPage("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:resultsRow:3",
 true,  false), "No third result item available.");
assertNull(   
tester.getComponentFromLastRenderedPage("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:resultsRow:4",
 false, false), "A fourth result item available.");

The above worked for some days, but yesterday I changed the overall
HTML-template to add additional panels and the tests above stopped to
work. It's important to note that the added panel has nothing to do
with that table, it is completely unrelated in the header-part of the
body of the template and therefore shouldn't have any influence on the
table.

Nevertheless, the tests fail now, because the IDs of the generated
result rows seem to be off by one. In the debugger I can see that the
number of result rows is still as expected, but the former ID "1" has
changed to "2" now for some reason. So after reimplementing the test
to check "rows.getItemCount()" instead of concrete component-IDs, they
succeed again. But checking availability of expected components felt
more correct to me.

Any idea what the cause for the changed child-component-ID might be?

Looking at "RepeatingView", it seems the generated ID is neither
static nor am I aware of reusing components during tests. And I don't
think that the newly added panel has any influence, I guess it's more
on execution order of tests or something. But all my tests are
executed in order 0, 1 and 3 results and that didn't change since the
days before as well.

As I have changed the tests this is not a big deal currently, but I'm
wondering what I'm missing here. Thanks for your thoughts!

Mit freundlichen Grüßen,

Thorsten Schöning



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to make Wicket prefer a custom resource finder always?

2020-03-04 Thread Sven Meier
Hi,

have you tried removing the default finders?

settings.getResourceFinders().clear();

Maybe the default classpath finder is kicking in and loads a template for a 
class that would otherwise inherit its markup from its superclass?

Sven

Am 3. März 2020 20:28:19 MEZ schrieb "Thorsten Schöning" 
:
>Hi all,
>
>I'm maintaining a Wicket webapp with slightly modified directories to
>get templates and language files from and created implementations of
>IResourceFinder for both. Things worked like epxected for some years
>now, but recently I changed deployment a bit to provide Javadoc by
>default for all my artifacts.
>
>Javadoc is simply deployed as JARs and because it's stored in
>"WEB-INF/lib", available in the classpath by default. That leads to
>the problem that Wicket now finds HTML files generated by Javadoc as
>templates to use. That doesn't work of course and results in errors
>like the following:
>
>> Expected to find  in associated markup file. Markup:
>>
>jar:file:/C:/Program%20Files/Apache/Tomcat%209.0/webapps/de.am_soft.sm_mtg.frontend.bug_2590_gradle/WEB-INF/lib/de.am_soft.sm_mtg.frontend-javadoc.jar!/de/am_soft/sm_mtg/frontend/panels/collectors/PnReadWithRealEstates.html
>
>So the first approach was to simply change the place where I provide
>my own resource finders to Wicket to make them the first items in the
>list. The current code is the following:
>
>> ResourceSettings  settings = this.getResourceSettings();
>> List finders  = settings.getResourceFinders();
>>
>> finders.add(0, new CustDefTmplResFinder(this.getServletContext()));
>> finders.add(1, new LangResFinder(this.getServletContext()));
>
>But that works for some pages only, sadly not for all. E.g. the
>login-page works well that way, but after logging in, the former error
>occurs again.
>
>So how do I tell Wicket to really always use my resource finders
>first? Thanks!
>
>Mit freundlichen Grüßen,
>
>Thorsten Schöning
>
>-- 
>Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
>AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
>
>Telefon...05151-  9468- 55
>Fax...05151-  9468- 88
>Mobil..0178-8 9468- 04
>
>AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
>AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


Re: PerSessionPageStore thread-safety

2020-02-26 Thread Sven Meier
Hi Thomas,

Im wondering whether you're running into 
https://issues.apache.org/jira/browse/WICKET-6702

I've been working on a solution to that problem, which is caused by pages being 
asynchronously serialized while another request is already coming in.

Or maybe it is something different.
Could you create a quickstart?

Sven

Am 25. Februar 2020 22:12:46 MEZ schrieb Thomas Heigl :
>Hi again,
>
>I investigated a bit and it does not seem to have anything to do with
>the
>PerSessionPageStore. I implemented a completely synchronized version of
>it
>and the problems still exist.
>
>If I switch to the default second-level cache that stores serialized
>pages
>in application scope, everything works as expected. Only the
>non-serialized
>pages in PerSessionPageStore seem to be affected by concurrent ajax
>modifications.
>
>What is the difference between keeping pages in the session and keeping
>the
>same pages in the PerSessionPageStore? Is there some additional locking
>done for pages in the session?
>
>Best,
>
>Thomas
>
>On Tue, Feb 25, 2020 at 8:25 PM Thomas Heigl 
>wrote:
>
>> Hi all,
>>
>> I'm currently experimenting with PerSessionPageStore as a
>second-level
>> cache. We are moving our page store from memory (i.e. session) to
>Redis and
>> keeping 1-2 pages per session in memory speeds up ajax requests quite
>a bit
>> because network roundtrips and (de)serialization can be skipped for
>cached
>> pages.
>>
>> Our application is very ajax heavy (it is basically a single page
>> application with lots of lazy-loading). While rapidly clicking around
>and
>> firing as many parallel ajax requests as possible, I noticed that it
>is
>> quite easy to trigger exceptions that I have never seen before.
>> ConcurrentModificationExceptions during serialization,
>> MarkupNotFoundExceptions, exceptions about components already
>dequeuing etc.
>>
>> So I had a look at the implementation of PerSessionPageStore and
>noticed
>> that is does not do any kind of synchronization and does not use
>atomic
>> operations when updating the cache. It seems to me that the
>second-level
>> cache is not really usable in a concurrent ajax environment.
>>
>> I think that writing pages to the second level cache store should
>either
>> synchronize on sessionId+pageId or attempt to use atomic operations
>> provided by ConcurrentHashMap.
>>
>> Did anyone else ever run into these issues? The code
>> of PerSessionPageStore is quite complex because of soft references,
>> skip-list maps etc. so I'm not sure what the right approach to
>address
>> these problems would be.
>>
>> Best regards,
>>
>> Thomas
>>


Re: AjaxDownloadBehavior with resource reference does not trigger respond() method

2020-02-06 Thread Sven Meier

Hi,

when downloading a resource-reference via non-blob you have to call

                AjaxDownloadBehavior.markCompleted(attributes);

.. from your resource.Please see AjaxDownloadPage.StaticResource from 
wicket-examples.


When using a resource this is automatically done for you.

I think we'll have to improve the Javadoc for this.

Have fun
Sven



On 06.02.20 16:03, Timo Schmidt wrote:

Hi Sven,

On Mi 05.02.2020 21:35, Sven Meier wrote:

On 05.02.20 21:14, Timo Schmidt wrote:

On Mi 05.02.2020 20:48, Timo Schmidt wrote:

im currently trying to setup a download behavior for large
file downloads. Using the AjaxDownloadBehavior with a resource
reference, the respond method is not called for all available
download locations but »Blob«.

But I need this method to be called to register the download on
server side and the Blob download location is not usable for my
use case, as the the blob is limited in its size depending on
the browser/OS and the files to be download are quite large.

Is there a way to get the respond method called using a
location other than blob?

forgot to mention: I'am using Wicket in version 8.7.0 and
9.0.0-M4

have you tried the download in wicket-examples?

The #respond notification is called there after download
completed for any location.

in order to provide a process info about the file download
preparation, an AjaxSelfUpdatingTimerBehavior is added, when
the download link is clicked.

Providing the AjaxDownloadBehavior with a resource reference,
the respond method is not called for location IFrame, but for
location Blob.

Providing the AjaxDownloadBehavior with a resource directly,
the respond method is called for both - location IFrame and
location Blob.

See the attached quickstart.

   -Timo

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


Re: AjaxDownloadBehavior with resource reference does not trigger respond() method

2020-02-05 Thread Sven Meier

Hi,

have you tried the download in wicket-examples?

The #respond notification is called there after download completed for 
any location.


Have fun
Sven


On 05.02.20 21:14, Timo Schmidt wrote:

On Mi 05.02.2020 20:48, Timo Schmidt wrote:

im currently trying to setup a download behavior for large
file downloads. Using the AjaxDownloadBehavior with a resource
reference, the respond method is not called for all available
download locations but »Blob«.

But I need this method to be called to register the download on
server side and the Blob download location is not usable for my
use case, as the the blob is limited in its size depending on
the browser/OS and the files to be download are quite large.

Is there a way to get the respond method called using a
location other than blob?

forgot to mention: I'am using Wicket in version 8.7.0 and
9.0.0-M4

   -Timo

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Need an event later than 'done'

2020-01-23 Thread Sven Meier

Cool, thanks for the update!

Sven

On 23.01.20 20:19, Entropy wrote:

Okay, nevermind.  I solved that by using a MutationObserver in javascript to
look for the thing Wicket makes visible or not and invoke my javascript as
needed.

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Need an event later than 'done'

2020-01-22 Thread Sven Meier

Hi,

sorry, I thought you know that detail:

If a behavior or any of the components in the hierarchy implements 
IAjaxIndicatorAware, it can specify the id of a markup to be shown 
during Ajax processing:


https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/IAjaxIndicatorAware.java

This id is stored in the JavaScript attributes as attr.i - if you set it 
from Java (by implementing the interface) or by setting directly from 
JavaScript (e.g. in before), Wicket will show the veil and keep it shown 
when a redirect happens.


Hope this helps
Sven


On 22.01.20 21:25, Entropy wrote:

Sven,

I'm afraid I don't know what you mean.  Our real jQuery expert quit abruptly
and hasn't been replaced yet, so I'm sorry if this is a jQuery thing, but
your last two paragraphs don't make sense to me.  What is attrs.i?  It's not
on the object from what I see in the F12 tools.  There's alot of one and two
letter vars, but not i.  I assume by AJAX_CALL_BEFORE you mean subscribe to
/ajax/call/before, which I can do.  Are you suggesting that I can launch the
veil there?  I am currently launching it in beforeSend.  But how would it
automatically remove it?  Removing it at the right time is of course the
issue.

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Need an event later than 'done'

2020-01-22 Thread Sven Meier

You're right, the Ajax response isn't available in the done callback.
Regretfully I can't remember how I solved the same issue in one of my 
last projects.


But have you thought about utilizing the default Ajax indicator?

You could set attrs.i in AJAX_CALL_BEFORE and let Wicket show that 
markup. Then it will automatically remove it at the right moment (or not 
in case of a redirect).


Have fun
Sven


On 22.01.20 15:37, Entropy wrote:

That sounds great.  But as I look through the jqEvent and attributes objects
I don't see what element is the response headers.

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility

2020-01-21 Thread Sven Meier
Ah, our old friends 'enclosures'!

Problem is that a component inside an enclosure  is really inside it only 
during rendering of its markup.
But the strategy walking through the component hierarchy to render all headers 
doesn't know anything about that enclosure o_O

As it has been written many times on this list, enclosures are best avoided in 
anything than the simplest setup.

Have fun
Sven

Am 21. Januar 2020 09:14:28 MEZ schrieb Rob Audenaerde 
:
>Hi Sven,
>
>Thanks for double-checking!
>
>The weird thing is that I thought this solved my problem, but when I
>tried
>to create the quickstart; I couldn't reproduce it either :o. I seem to
>have
>been mistakenly assuming it was this piece of code that fixed the
>problem.
>
>So I tried to build it more towards our application and I saw a
> that causes this behavior (the
>isVisibleInHierarchy() is
>not working there).
>
>I attached the quickstart for those who want to experiment with it.
>
>-Rob
>
>On Mon, Jan 20, 2020 at 7:17 PM Sven Meier  wrote:
>
>> Hi Rob,
>>
>> actually I wasn't able to reproduce the problem on a second try (not
>> sure what I tested before).
>>
>> Can you create a a quickstart showing the problem?
>>
>> Sven
>>
>> On 20.01.20 13:18, Sven Meier wrote:
>> > Hi Rob,
>> >
>> >> the 'correct' way to solve this?
>> >
>> > the component is explicitly added to the Ajax request for an
>update,
>> > but decides to hide itself in onConfigure().
>> > Perfectly valid usecase IMHO, but the head will be rendered
>> > nevertheless :/
>> >
>> > Just tested with 7.x, 8.x and master, this seems to have been that
>way
>> > forever.
>> > But maybe we can improve that in Wicket core?
>> >
>> > Sven
>> >
>> >
>> > On 20.01.20 10:36, Rob Audenaerde wrote:
>> >> Hi all,
>> >>
>> >> I recently got some javascript errors that came from behaviors of
>> >> components that where triggered to be visible or invisible in the
>dom
>> >> (using onConfigure()) in an ajax request.
>> >>
>> >> Typically something like:
>> >>
>> >> Wicket.Ajax:  Cannot bind a listener for event "change" on element
>> >> "format1dd" because the element is not in the DOM
>> >>
>> >> I solve this by adding an isVisibleInHierarchy() check in the
>> >> renderHead()
>> >> like this:
>> >>
>> >> @Override
>> >>
>> >> public void renderHead(final Component component, final
>IHeaderResponse
>> >> response) {
>> >>  if (component.isVisibleInHierarchy()) {
>> >>  super.renderHead(component, response);
>> >>  }
>> >> }
>> >>
>> >> I was wondering if this is the 'correct' way to solve this? Or am
>I
>> >> doing
>> >> something wrong?
>> >>
>> >> Please advise :)
>> >>
>> >> -Rob
>> >>
>> >
>> >
>-
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>


Re: Need an event later than 'done'

2020-01-21 Thread Sven Meier

Hi Entropy,

the trick is do keep the veil up whenever a redirect happens as the 
result of an Ajax request.


Similar to what wicket-ajax-jquery.js is doing with it's Ajax indicator:

                        if (attrs.i && context.isRedirecting !== true) {
                            Wicket.DOM.hideIncrementally(attrs.i);
                        }

I have to look up how I solved that in one of my projects - regretfully 
Ajax listeners do not have access to that "isRedirecting" flag.


Hope this helps
Sven


On 21.01.20 21:19, Entropy wrote:

In our app we display a veil after any button click that goes to the server
to prevent users double-submitting.  Which they do.  Alot.  Double-submits
cause a variety of mischief for us ranging from StaleObjectExceptions in
hibernate to wicket exceptions about buttons not being enabled and others.

So we add the veil, and then (for ajax) close it thusly:

Wicket.Event.subscribe('/ajax/call/done',
function(jqEvent, attributes, jqXHR, errorThrown, textStatus) {
//  console.log("done");
if(attributes) {
if(attributes.event) {

if(isVeiled(attributes.event.currentTarget)) {
closeVeil();
}
}
}   
}
);

The problem is that this /ajax/call/done doesn't seem to fire when the
request is REALLY done, but rather a bit BEFORE it's done.  We're getting
the same behavior, especially when an ajax event transitions from one page
to the next.  The veil unloads, and there's a pause just before the redirect
kicks in during which the user assumes the same page is being seen and their
click was ignored...so they click again.

Is there a better/later event during which i can unload the veil?  A
/ajax/call/really_done?

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility

2020-01-20 Thread Sven Meier

Hi Rob,

actually I wasn't able to reproduce the problem on a second try (not 
sure what I tested before).


Can you create a a quickstart showing the problem?

Sven

On 20.01.20 13:18, Sven Meier wrote:

Hi Rob,


the 'correct' way to solve this?


the component is explicitly added to the Ajax request for an update, 
but decides to hide itself in onConfigure().
Perfectly valid usecase IMHO, but the head will be rendered 
nevertheless :/


Just tested with 7.x, 8.x and master, this seems to have been that way 
forever.

But maybe we can improve that in Wicket core?

Sven


On 20.01.20 10:36, Rob Audenaerde wrote:

Hi all,

I recently got some javascript errors that came from behaviors of
components that where triggered to be visible or invisible in the dom
(using onConfigure()) in an ajax request.

Typically something like:

Wicket.Ajax:  Cannot bind a listener for event "change" on element
"format1dd" because the element is not in the DOM

I solve this by adding an isVisibleInHierarchy() check in the 
renderHead()

like this:

@Override

public void renderHead(final Component component, final IHeaderResponse
response) {
 if (component.isVisibleInHierarchy()) {
 super.renderHead(component, response);
 }
}

I was wondering if this is the 'correct' way to solve this? Or am I 
doing

something wrong?

Please advise :)

-Rob



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility

2020-01-20 Thread Sven Meier

Hi Rob,


the 'correct' way to solve this?


the component is explicitly added to the Ajax request for an update, but 
decides to hide itself in onConfigure().
Perfectly valid usecase IMHO, but the head will be rendered nevertheless :/

Just tested with 7.x, 8.x and master, this seems to have been that way forever.
But maybe we can improve that in Wicket core?

Sven


On 20.01.20 10:36, Rob Audenaerde wrote:

Hi all,

I recently got some javascript errors that came from behaviors of
components that where triggered to be visible or invisible in the dom
(using onConfigure()) in an ajax request.

Typically something like:

Wicket.Ajax:  Cannot bind a listener for event "change" on element
"format1dd" because the element is not in the DOM

I solve this by adding an isVisibleInHierarchy() check in the renderHead()
like this:

@Override

public void renderHead(final Component component, final IHeaderResponse
response) {
 if (component.isVisibleInHierarchy()) {
 super.renderHead(component, response);
 }
}

I was wondering if this is the 'correct' way to solve this? Or am I doing
something wrong?

Please advise :)

-Rob



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Dealing with editing of nested objects in a multiple screens for a single entity

2020-01-17 Thread Sven Meier

Hi Bas,

>set of custom models that remembers what was provided in “setObject” 
and can later replay this


in my experience most attempts on putting to much logic into model 
implementations have failed.
Long class names (ahem NestedPropertyChangeListenerModel) or deeply 
nested model delegations are warning signs for me.


Change tracking is hard, so I'd advice to work directly on your entities.
I'd go with a) or c) "always keep a default variant in the product".

Have fun
Sven



On 16.01.20 11:41, Bas Gooren wrote:

Hi all!

I’m currently working on an editing system which has composite elements;

For example:

We store Products (e.g. an iPod 64GB) and those Products have Variants
(Blue).
Since a variant cannot exist without a product, and we want to enforce that
every product has at least one variant, we want to implement this in a
single screen.
So here the Product is a composite which contains one or more Variants.

To extend my example: a Variant has pricing based on Country, Website etc.
So the Variant is also a composite;

In all previous projects we either
a) relaxed the requirements, like don’t require a product to have at least
one variant, which means the creation of variants happens when the Product
already exists
b) perform all editing in a single form, so everything is committed in one
go

But since our composites are more complex in this project, the UI becomes a
bit crazy, so we want to break out the nested editors.
Essentially this requires us to build some sort of change tracking feature,
like a set of custom models that remembers what was provided in “setObject”
and can later replay this.
We can then track all changes that happen in editors, and replay those
changes later (e.g. when the Product editor is submitted).

Given that we want to support nested composites (Product -> List of Variant
-> List of VariantPrice), this can get quite complex.

So before embarking on this, I’d like to ask if others have implemented a
similar system, or if they have other suggestions.

I seem to recall that a long time ago there was discussion about this as
well, perhaps it was regarding a really complex
NestedPropertyChangeListenerModel (;-)) at topicus or hippo or similar.
I think it was ultimately refactored into something much simpler due to the
difficulty in maintaining it.
But alas, I cannot seem to find any mention of it anymore.

Thank you all for reading and any input you can provide.

Met vriendelijke groet,
Kind regards,

Bas Gooren



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: OOM: Direct buffer memory

2020-01-17 Thread Sven Meier

Hi,

I don't see anything related in the changes from 8.5 to 8.6.1

https://github.com/apache/wicket/blob/wicket-8.x/CHANGELOG-8.x

Are you sure these OOMs didn't happen before?

Sven


On 16.01.20 22:52, Илья Нарыжный wrote:

Sven,

It was 8.5 - so not so far away.

Thanks,
Ilya
-
Orienteer(http://orienteer.org) - open source Business Application Platform

On Thu, Jan 16, 2020 at 11:41 AM Sven Meier  wrote:

What was your previous version?

Sven

Am 16. Januar 2020 19:27:19 MEZ schrieb "Илья Нарыжный" :

Hello,

After upgrading to Wicket 8.6.1 we started seeing periodical OOMs in
logs like below.
I'm not 100% sure that it's due to Wicket, but we didn't change
containers parameters and etc - so at least it's quite suspicious.
Our startup flags:
-XX:+PerfDisableSharedMem -Xmx4G -Xms4G -XX:MaxDirectMemorySize=4G
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/app/runtime/heapdump.bin

Btw, except these exceptions in logs - no other negative effects (at
least we didn't reveal so far).

If you have ideas - I will really appreciate.

java.lang.OutOfMemoryError: Direct buffer memory
at java.nio.Bits.reserveMemory(Bits.java:666)
at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
at sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:241)
at sun.nio.ch.IOUtil.write(IOUtil.java:58)
at sun.nio.ch.FileChannelImpl.writeInternal(FileChannelImpl.java:778)
at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:764)
at
org.apache.wicket.pageStore.DiskDataStore$SessionEntry.savePage(DiskDataStore.java:352)
at
org.apache.wicket.pageStore.DiskDataStore.storeData(DiskDataStore.java:185)
at
org.apache.wicket.pageStore.AsynchronousDataStore.storeData(AsynchronousDataStore.java:217)
at
org.apache.wicket.pageStore.AbstractPageStore.storePageData(AbstractPageStore.java:119)
at
org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:66)

Thanks,
Ilya
-
Orienteer(http://orienteer.org) - open source Business Application
Platform

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: OOM: Direct buffer memory

2020-01-16 Thread Sven Meier
What was your previous version?

Sven

Am 16. Januar 2020 19:27:19 MEZ schrieb "Илья Нарыжный" :
>Hello,
>
>After upgrading to Wicket 8.6.1 we started seeing periodical OOMs in
>logs like below.
>I'm not 100% sure that it's due to Wicket, but we didn't change
>containers parameters and etc - so at least it's quite suspicious.
>Our startup flags:
>-XX:+PerfDisableSharedMem -Xmx4G -Xms4G -XX:MaxDirectMemorySize=4G
>-XX:+HeapDumpOnOutOfMemoryError
>-XX:HeapDumpPath=/app/runtime/heapdump.bin
>
>Btw, except these exceptions in logs - no other negative effects (at
>least we didn't reveal so far).
>
>If you have ideas - I will really appreciate.
>
>java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:666)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:241)
> at sun.nio.ch.IOUtil.write(IOUtil.java:58)
> at sun.nio.ch.FileChannelImpl.writeInternal(FileChannelImpl.java:778)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:764)
>at
>org.apache.wicket.pageStore.DiskDataStore$SessionEntry.savePage(DiskDataStore.java:352)
>at
>org.apache.wicket.pageStore.DiskDataStore.storeData(DiskDataStore.java:185)
>at
>org.apache.wicket.pageStore.AsynchronousDataStore.storeData(AsynchronousDataStore.java:217)
>at
>org.apache.wicket.pageStore.AbstractPageStore.storePageData(AbstractPageStore.java:119)
>at
>org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:66)
>
>Thanks,
>Ilya
>-
>Orienteer(http://orienteer.org) - open source Business Application
>Platform
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


Re: Converters for Date/Time

2020-01-13 Thread Sven Meier

Hi,

values in feedback messages get converted too of course, so if you want 
that, a converter is a good option.
Note that components can use a specific converter by overriding 
createConverter().


Many options to choose from :)

Sven


On 13.01.20 17:52, Martin Terra wrote:

How about feedback messages etc.?

**
Martin

ma 13. tammik. 2020 klo 18.46 Sven Meier (s...@meiers.net) kirjoitti:


Hi,

adapting to the client timezone can be done in the component, a
converter or a model. e.g.


https://github.com/apache/wicket/blob/master/wicket-extensions/src/main/java/org/apache/wicket/extensions/markup/html/form/datetime/ZonedToLocalDateTimeModel.java

Whatever fits your use-case. Maybe you want everything to be displayed
in the client timeZone -> register a global converter.

Have fun
Sven


On 13.01.20 06:05, Илья Нарыжный wrote:

Hello,

I have some fundamental question about Wicket:)
For users it's convenient when date-time has shown in their timezone.
So most of wicket devs, do that somehow like we did it here:


https://github.com/OrienteerBAP/Orienteer/blob/master/orienteer-core/src/main/java/org/orienteer/core/component/property/date/ODateLabel.java

But question is: does it make sense to put conversion per time-zone
into DateConverter or that might broke something wicket
best-practices?

Thanks,
Ilya
-
Orienteer(http://orienteer.org) - open source Business Application

Platform

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Converters for Date/Time

2020-01-13 Thread Sven Meier

Hi,

adapting to the client timezone can be done in the component, a 
converter or a model. e.g.


https://github.com/apache/wicket/blob/master/wicket-extensions/src/main/java/org/apache/wicket/extensions/markup/html/form/datetime/ZonedToLocalDateTimeModel.java

Whatever fits your use-case. Maybe you want everything to be displayed 
in the client timeZone -> register a global converter.


Have fun
Sven


On 13.01.20 06:05, Илья Нарыжный wrote:

Hello,

I have some fundamental question about Wicket:)
For users it's convenient when date-time has shown in their timezone.
So most of wicket devs, do that somehow like we did it here:
https://github.com/OrienteerBAP/Orienteer/blob/master/orienteer-core/src/main/java/org/orienteer/core/component/property/date/ODateLabel.java
But question is: does it make sense to put conversion per time-zone
into DateConverter or that might broke something wicket
best-practices?

Thanks,
Ilya
-
Orienteer(http://orienteer.org) - open source Business Application Platform

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Cookie SameSite issue

2019-12-15 Thread Sven Meier
Hi,

the Servlet spec doesn't support the "sameSite" attribute yet. You can 
explicitly set a cookie header instead.
Or instruct Tomcat to add the attribute for you:

https://stackoverflow.com/questions/57505939/how-to-set-samesite-cookie-in-tomcats-cookie-processor

Have fun
Sven


Am 16. Dezember 2019 03:19:10 MEZ schrieb ShengChe Hsiao :
>Dear all
>
>Recently, I found chrome's developer console shows alert about
>cookie SameSite...
>A cookie associated with a cross-site resource at
>https://xxx../
>was set without the `SameSite` attribute. A future release of Chrome
>will
>only deliver cookies with cross-site requests if they are set with
>`SameSite=None` and `Secure`. You can review cookies in developer tools
>under Application>Storage>Cookies and see more details at
>https://www.chromestatus.com/feature/5088147346030592 and
>https://www.chromestatus.com/feature/5633521622188032.
>
>Since servlet spec doesn't support this property, how can I deal with
>it?
>
>
>
>--->
>To boldly go where no man has gone before.
>
>--->
>We do this not because it is easy. We do this because it is hard.
>-
>-->
>If I have seen further it is by standing on the shoulders of giants.
>--
>->
>front...@gmail.com
>->


Re: Feedback messages not showing on first request

2019-12-02 Thread Sven Meier

Hi,

your isVisible() might be called to often or early.

FeedbackMessagesModel caches the messages during request, so the call to 
#anyMessage() might result in a premature collection of messages.


Try override #onConfigure() instead, this is preferred over overriding 
#isVisible():


            @Override
            protected void onConfigure()
            {
                super.onConfigure();
                setVisible(anyMessage());
            }

Have fun
Sven


On 02.12.19 14:32, Entropy wrote:

The isVisible():

assetLookupOptionsFP = new 
FeedbackPanel("assetLookupOptionsFP"){
private static final long serialVersionUID = 1L;

@Override
public boolean isVisible() {
if (anyMessage()){
return true;
} else {
return false;
}
}
};

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Feedback messages not showing on first request

2019-11-28 Thread Sven Meier

Hi,

hard to tell from your code snippet.

Could you remove the irrelevant part (the request attribute) and show us 
the visibility control instead?


A quickstart would help too.

Have fun
Sven


On 26.11.19 16:53, Entropy wrote:

We have a page where we are being required to have multiple feedback panels,
and to show messages in various ones depending on the error.  Our solution
was to use message filters and to put the messages against certain
containers to say 'any message in container X goes to feedback panel X'.

You can see the code below for example.  The request thing is just to set
the class of the feedbackpanel to a different value.  But we also control
the visibility of the panel by checking 'anyMessage()'.  So if there's no
errors, no feedback shows.

This all works...except on the first request.  For some reason when I click
the button, I can see the error (it's added during the onSubmit(), not
during the normal validation step if that makes a difference) added to the
assetLookupOptionsWMC, but then when anyMessage() runs, it doesn't find the
error.  Click the button a second time, and it works perfectly.

Any idea why?

assetLookupOptionsFP.setFilter(new IFeedbackMessageFilter(){
private static final long serialVersionUID = 1L;

@Override
public boolean accept(FeedbackMessage msg) {
Component reporter = msg.getReporter();
HttpServletRequest request = 
((HttpServletRequest)
getRequest().getContainerRequest());

if 
(reporter.getId().equals("assetLookupOptionsWMC")){
if(msg.isError())

request.setAttribute("assetLookupOptionsFeedbackPanelHasError",
"TRUE");
return true;
} else if
(reporter.getParent().getId().equals("assetLookupOptionsWMC")){
if(msg.isError())

request.setAttribute("assetLookupOptionsFeedbackPanelHasError",
"TRUE");
return true;
} else {
return false;
}
}

});

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Application # newSession # sessionUnbound - RuntimeException

2019-11-21 Thread Sven Meier

Hi Francois,

yes, that's a non-request thread.

IExceptionMapper isn't a general exception handler, it is a mapper from 
exceptions to request handlers.

Using it here does not make sense.

Have fun
Sven


On 21.11.19 18:12, Francois Meillet wrote:

WARNING [Catalina-utility-1] 
org.apache.catalina.core.StandardContext.backgroundProcess Exception lors du 
traitement d'arrière plan du gestionnaire de sessions 
[StandardManager[StandardEngine[Catalina].StandardHost[localhost].StandardContext[]]]
java.lang.RuntimeException
at 
baz.web.base.app.OfferApplication.sessionUnbound(OfferApplication.java:560)
at 
org.apache.wicket.session.HttpSessionStore$SessionBindingListener.valueUnbound(HttpSessionStore.java:444)
at 
org.apache.catalina.session.StandardSession.removeAttributeInternal(StandardSession.java:1784)
at 
org.apache.catalina.session.StandardSession.expire(StandardSession.java:856)
at 
org.apache.catalina.session.StandardSession.isValid(StandardSession.java:659)
at 
org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:573)
at 
org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:558)
at 
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5539)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1353)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1357)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1357)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1335)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at 
java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:305)
at 
java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)
at 
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

François




Le 21 nov. 2019 à 17:55, Sven Meier  a écrit :

Yes, I mean a non-web-request thread, i.e. when the session expires as you've 
written.

Sven

On 21.11.19 17:52, Martin Grigorov wrote:

On Thu, Nov 21, 2019 at 6:30 PM Sven Meier  wrote:


Hi,

actually #sessionUnbound() is called *on* the application instance, so
the ExceptionMapper is available.


oh, right. silly me!




But ExceptionMapper maps an exception to a requestHandler, this doesn't
make sense for an exception happening on a worker thread.


you meant on *non*-worker thread ?

Francois, please give us the stack trace.



Hope this helps
Sven


On 21.11.19 16:37, Martin Grigorov wrote:

Hi Francois,

#sessionUnbound() is called in two contexts:
1) the user clicked the Logout button - in this case the call is executed
in http worker thread where there is a ThreadContext, i.e.
Application.get(), Session.get() and RequestCycle.get() would work
here, I think, Wicket should use the ExceptionMapper
2) when the user session has timed out - in this case the web container
(Tomcat/Jetty) will execute this method in non-worker thread and
Application.get() would be null, so we cannot get a reference to the
ExceptionMapper

On Thu, Nov 21, 2019 at 5:01 PM Francois Meillet <

francois.meil...@gmail.com>

wrote:


Hi,

Any RuntimeException thrown in Application # newSession(Request request,
Response response) is handled by the DefaultExceptionMapper #
mapUnexpectedExceptions(Exception e, final Application application)

but

Any RuntimeException thrown in Application # sessionUnbound(String
sessionid) is not handled

Is that normal ?

François




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apac

Re: Application # newSession # sessionUnbound - RuntimeException

2019-11-21 Thread Sven Meier
Yes, I mean a non-web-request thread, i.e. when the session expires as 
you've written.


Sven

On 21.11.19 17:52, Martin Grigorov wrote:

On Thu, Nov 21, 2019 at 6:30 PM Sven Meier  wrote:


Hi,

actually #sessionUnbound() is called *on* the application instance, so
the ExceptionMapper is available.


oh, right. silly me!




But ExceptionMapper maps an exception to a requestHandler, this doesn't
make sense for an exception happening on a worker thread.


you meant on *non*-worker thread ?

Francois, please give us the stack trace.



Hope this helps
Sven


On 21.11.19 16:37, Martin Grigorov wrote:

Hi Francois,

#sessionUnbound() is called in two contexts:
1) the user clicked the Logout button - in this case the call is executed
in http worker thread where there is a ThreadContext, i.e.
Application.get(), Session.get() and RequestCycle.get() would work
here, I think, Wicket should use the ExceptionMapper
2) when the user session has timed out - in this case the web container
(Tomcat/Jetty) will execute this method in non-worker thread and
Application.get() would be null, so we cannot get a reference to the
ExceptionMapper

On Thu, Nov 21, 2019 at 5:01 PM Francois Meillet <

francois.meil...@gmail.com>

wrote:


Hi,

Any RuntimeException thrown in Application # newSession(Request request,
Response response) is handled by the DefaultExceptionMapper #
mapUnexpectedExceptions(Exception e, final Application application)

but

Any RuntimeException thrown in Application # sessionUnbound(String
sessionid) is not handled

Is that normal ?

François




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Opening a stateful page in a new window/tab with ajax

2019-11-21 Thread Sven Meier

Hi,

that's a perfectly valid usage.

Have fun
Sven


On 21.11.19 13:44, mscoon wrote:

Hi all,

We are using the following code inside an ajax callback to create a new
page and open it in a new window. Are there any gotchas with respect to how
we create MyPage and get the url for it? Is it guaranteed to be found in
the user's session when the request for it comes in?

void openPageInNewWindow(AjaxRequestTarget target) {
 Page pg = new MyPage();
 String url = urlFor(new RenderPageRequestHandler(new
PageProvider(pg))).toString();
  target.appendJavaScript("window.open(\"" + url + "\")");
}

Is there a better way to do this?

Note that we don't want to use a BookmarkablePage page as an alternative.
We want the new page to be instantiated inside the ajax callback.

Thank you in advance,
Marios



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Application # newSession # sessionUnbound - RuntimeException

2019-11-21 Thread Sven Meier

Hi,

actually #sessionUnbound() is called *on* the application instance, so 
the ExceptionMapper is available.


But ExceptionMapper maps an exception to a requestHandler, this doesn't 
make sense for an exception happening on a worker thread.


Hope this helps
Sven


On 21.11.19 16:37, Martin Grigorov wrote:

Hi Francois,

#sessionUnbound() is called in two contexts:
1) the user clicked the Logout button - in this case the call is executed
in http worker thread where there is a ThreadContext, i.e.
Application.get(), Session.get() and RequestCycle.get() would work
here, I think, Wicket should use the ExceptionMapper
2) when the user session has timed out - in this case the web container
(Tomcat/Jetty) will execute this method in non-worker thread and
Application.get() would be null, so we cannot get a reference to the
ExceptionMapper

On Thu, Nov 21, 2019 at 5:01 PM Francois Meillet 
wrote:


Hi,

Any RuntimeException thrown in Application # newSession(Request request,
Response response) is handled by the DefaultExceptionMapper #
mapUnexpectedExceptions(Exception e, final Application application)

but

Any RuntimeException thrown in Application # sessionUnbound(String
sessionid) is not handled

Is that normal ?

François




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: DynamicModel within ListView That Refreshes on ModalWindow Close

2019-09-26 Thread Sven Meier
You'll have to show us some code (quickstart?), without it it is difficult to 
understand your problem.

Have fun
Sven

Am 26. September 2019 16:41:47 MESZ schrieb dylanbozeman 
:
>Thank you Ernesto. I will look into this. 
>
>I didn't mean to be rude, I was thankful for the answer. I was just
>hopeful
>for a followup as the first response didn't address my specific
>situation,
>so I was trying to be direct.
>
>--
>Sent from:
>http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


  1   2   3   4   5   6   7   8   9   10   >