Re: upgrading Wicket

[Sven Meier]

Hi Steven,

I've send you a PM.

Sven


On 26.01.24 14:57, Nelligan, Steven M wrote:

Help,  I am new to Wicket...and have taken over a project with wicket version 
1.4.18, which is way out of date.
According to a consulting firm, this would be a multi-year project to update 
all of our projects to the latest version of Wicket; and they are recommending 
we just rewrite the front end code to React.

Does anyone have a program or script which would help with the updating of 
wicket components to a new Version?

Thanks,
Steven M Nelligan
SENIOR SOFTWARE DEVELOPER



-
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: RangeValidator and BigDecimal

[Sven Meier]

Hi Eric,

you can read in the javadoc, why your first solution is 'unpredictable':

https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/math/BigDecimal.html#%3Cinit%3E(double)

Sven

On 20.12.23 15:18, Eric Hamel wrote:

Hi Bas,

Thanks for the response.

I discovered the NumberTextField had its own RangeValidator 2 seconds after 
posting. With that said, I’m getting the same issue when using it.

To be clear, I’m not getting any Exceptions, everything seems to work fine, but 
the form validation fails if the user types in 0.01.


Form form = new Form<>(“form”, getModel());
add(form);

NumberTextField testField = new NumberTextField(“testField”, 
new PropertyModel(form.getModel(), “testProp”));
form.add(testField);


I’ve been digging and I found the oddity:

If I set the min value as follows:

testField.setMinimum(new BigDecimal(0.00));

When the user enters 0.01, the following feedback message is showed:

The value of ’testField’ must be between 0.01 and 999,999.99.

However, if I set the min value with:

testField.setMinimum(BigDecimal.valueOf(0.00));

The user can enter 0.01 and NO feedback message is showed.



-
Eric H.






On Dec 20, 2023, at 8:48 AM, Bas Gooren  wrote:

Hi Eric,

First off: according to the source of NumberTextField, it automatically adds a 
RangeValidator (see NumberTextField#onConfigure). So you shouldn’t need to add 
the RangeValidator yourself.

Regarding your problem: what kind of error messages are you getting?

The range validator (or more specifically: the AbstractRangeValidator class) 
handles the comparison between min, max and actual values using compareTo. So 
there should not be any issues with rounding.

Please share the code you use to initialize the relevant field, perhaps we can 
spot a mistake.

Met vriendelijke groet,
Kind regards,

Bas Gooren

Op 20 december 2023 bij 14:38:53, Eric Hamel (eric.ha...@albanyitg.com 
) schreef:


Good morning,

We encountered an issue this morning with our use of RangeValidator.

The customer requested a validation for amounts between 0.01 and 999,999.00.

We have a NumberTextField to which we added the RangeValidator. If 
the user enters 0.01 the validation fails.

If I set the min value to 0.009 I can get it to work but the error messages are 
off.

I’m wondering if it’s a rounding or scale issue but I cannot figure out how to 
make the RangeValidator work.

Anyone have any insight on this ?

Thank you.
Eric H.


-
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 - component not rendered.

[Sven Meier]

That HTML doesn't look valid to me:

Your THs belong inside a TR, and while you're at it move that one into a 
THEAD.


    https://www.w3schools.com/tags/tag_th.asp

Maybe this is just a problem with replacing the HTML in the browser, 
this is why I adviced you to check the response of the Ajax request in 
the Browser network tab.


Sven


On 03.11.22 08:11, Laurent Duparchy wrote:

You need more than that ?



   
   

   
 
 
 
 
 
 
  
...
  




*Laurent Duparchy
ESRF - The European Synchrotron
MIS Unit
04 76 88 22 56*
Sven Meier wrote on 02/11/2022 17:38:

Show us the relevant markup please.

Sven


On 02.11.22 15:13, Laurent Duparchy wrote:

Hi,

Yes, *devicesGroup *is initially visible. Everything seems fine in 
terms of Ajax request/response.


When I add only the *feedbackpanel*, it is correctly added and 
painted with the correct feedback message
When I add *devicesGroup*, nothing is repainted, including the 
*feedbackpanel*.


I tried to add only the *userDevicesListView *for repaint, but there 
is an error saying that it's not possible to add a repeater and to 
add its parent... which is devicesGroup.


There's probably a flaw in the devicesGroup design. Basically it 
contains a list of items w/ two possible ajax action : "check" and 
"delete".


"Check" will only gives a result in the feedback panel and is 
working fine.
"Delete" will, you guessed, delete the item and repaint the list. 
The item is truly deleted, in the database and /userDevices /list is 
reloaded.



it is designed as follow (worked fined w/ Wicket 1.4)
/
private class UserDevicesLoadableDetachableModel extends 
LoadableDetachableModel {


    private List userDevices ;
...
}

private class UserDevicesListView extends ListView {

    public UserDevicesListView(String id, 
UserDevicesLoadableDetachableModel imodel) {

        super(id, imodel);
    }
...
}
/

/userDevicesListView = new 
UserDevicesListView("userDevicesListView", 
userDevicesLoadableDetachableModel);//

/
/devicesGroup = new CheckGroup("devicesGroup", new 
ArrayList<>()){//

//    public boolean isVisible() {...}//
//} /
/devicesGroup.setOutputMarkupId(true);//
//devicesGroup.setOutputMarkupPlaceholderTag(true);//
//devicesGroup.setRenderBodyOnly(false);//
//devicesGroup.add(new CheckGroupSelector("devicesGroupSelector"));//
//devicesGroup.add(userDevicesListView);//
//

//
/
*Laurent Duparchy
ESRF - The European Synchrotron
MIS Unit
04 76 88 22 56*
Ernesto Reinaldo Barreiro wrote on 29/10/2022 04:06:

Hi,

is devicesGroup initially visible? if not you need to
setOutputMarkupplaceHolder(true) in it. Because otherwise wicket 
will not

output anything for it and AJAX replacement will fail at client side.

On Fri, Oct 28, 2022 at 4:27 PM Martin Grigorov
wrote:


Hi Laurent,

Few questions:
1) is the Ajax call actually executed ?
Set a breakpoint inside #onClick() and see whether it breaks
2) Is there any error (Java or JavaScript) ?
Check both the server logs and the browser console


On Fri, Oct 28, 2022 at 10:45 AM Laurent Duparchy
wrote:


Hi,

Sorry for the basic question If this is the wrong place to ask,

please

tell me.
If there is a relevant documentation to read, tell me as well.

I'm upgrading a very old & small app from Wicket 1.4 to Wicket 9.

Following an Ajax call, one component is not refreshed as it was 
before.


This is the "userDevicesListView" which is inside the "devicesGroup"
component. See below.



   
   

   
 
 
 
 
 
 
  
...
 
Upon the Ajax call the userDevicesListView is changed and 
devicesGroup is
added to the target and should be rendered / repainted but it is 
not.



public void onClick(Optional target) {
 Device deviceToRemove = (Device) getModelObject();
 try {
 removeDevice(deviceToRemove, user);
 info(deviceToRemove.getHostName() + " " +

getString("device.removed"));

 } catch (Exception e) {

 LOG.error("error while deleting" +

deviceToRemove.getHostName(), e);

 error(e);

 }

 target.get().add(devicesGroup);
 target.get().add(feedbackPanel);
 }



- 


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...@w

Re: Ajax - component not rendered.

[Sven Meier]

Show us the relevant markup please.

Sven


On 02.11.22 15:13, Laurent Duparchy wrote:

Hi,

Yes, *devicesGroup *is initially visible. Everything seems fine in 
terms of Ajax request/response.


When I add only the *feedbackpanel*, it is correctly added and painted 
with the correct feedback message
When I add *devicesGroup*, nothing is repainted, including the 
*feedbackpanel*.


I tried to add only the *userDevicesListView *for repaint, but there 
is an error saying that it's not possible to add a repeater and to add 
its parent... which is devicesGroup.


There's probably a flaw in the devicesGroup design. Basically it 
contains a list of items w/ two possible ajax action : "check" and 
"delete".


"Check" will only gives a result in the feedback panel and is working 
fine.
"Delete" will, you guessed, delete the item and repaint the list. The 
item is truly deleted, in the database and /userDevices /list is 
reloaded.



it is designed as follow (worked fined w/ Wicket 1.4)
/
private class UserDevicesLoadableDetachableModel extends 
LoadableDetachableModel {


    private List userDevices ;
...
}

private class UserDevicesListView extends ListView {

    public UserDevicesListView(String id, 
UserDevicesLoadableDetachableModel imodel) {

        super(id, imodel);
    }
...
}
/

/userDevicesListView = new UserDevicesListView("userDevicesListView", 
userDevicesLoadableDetachableModel);//

/
/devicesGroup = new CheckGroup("devicesGroup", new 
ArrayList<>()){//

//    public boolean isVisible() {...}//
//} /
/devicesGroup.setOutputMarkupId(true);//
//devicesGroup.setOutputMarkupPlaceholderTag(true);//
//devicesGroup.setRenderBodyOnly(false);//
//devicesGroup.add(new CheckGroupSelector("devicesGroupSelector"));//
//devicesGroup.add(userDevicesListView);//
//

//
/
*Laurent Duparchy
ESRF - The European Synchrotron
MIS Unit
04 76 88 22 56*
Ernesto Reinaldo Barreiro wrote on 29/10/2022 04:06:

Hi,

is devicesGroup initially visible? if not you need to
setOutputMarkupplaceHolder(true) in it. Because otherwise wicket will 
not

output anything for it and AJAX replacement will fail at client side.

On Fri, Oct 28, 2022 at 4:27 PM Martin Grigorov
wrote:


Hi Laurent,

Few questions:
1) is the Ajax call actually executed ?
Set a breakpoint inside #onClick() and see whether it breaks
2) Is there any error (Java or JavaScript) ?
Check both the server logs and the browser console


On Fri, Oct 28, 2022 at 10:45 AM Laurent Duparchy
wrote:


Hi,

Sorry for the basic question If this is the wrong place to ask,

please

tell me.
If there is a relevant documentation to read, tell me as well.

I'm upgrading a very old & small app from Wicket 1.4 to Wicket 9.

Following an Ajax call, one component is not refreshed as it was 
before.


This is the "userDevicesListView" which is inside the "devicesGroup"
component. See below.



   
   

   
 
 
 
 
 
 
  
...
 
Upon the Ajax call the userDevicesListView is changed and 
devicesGroup is

added to the target and should be rendered / repainted but it is not.


public void onClick(Optional target) {
 Device deviceToRemove = (Device) getModelObject();
 try {
 removeDevice(deviceToRemove, user);
 info(deviceToRemove.getHostName() + " " +

getString("device.removed"));

 } catch (Exception e) {

 LOG.error("error while deleting" +

deviceToRemove.getHostName(), e);

 error(e);

 }

 target.get().add(devicesGroup);
 target.get().add(feedbackPanel);
 }



-
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 - component not rendered.

[Sven Meier]

Hi,

please check the Ajax response in your browser's network tab, do you see 
the "devicesGroup" in the response XML?


Maybe that "devicesGroup" bound to a  tag?

Have fun
Sven


On 28.10.22 09:43, Laurent Duparchy wrote:

Hi,

Sorry for the basic question If this is the wrong place to ask, 
please tell me.

If there is a relevant documentation to read, tell me as well.

I'm upgrading a very old & small app from Wicket 1.4 to Wicket 9.

Following an Ajax call, one component is not refreshed as it was before.

This is the "userDevicesListView" which is inside the "devicesGroup" 
component. See below.




      
      

          
            
            
            
            
            
        
                 
...
        


Upon the Ajax call the userDevicesListView is changed and devicesGroup 
is added to the target and should be rendered / repainted but it is not.



public void onClick(Optional target) {
            Device deviceToRemove = (Device) getModelObject();
            try {
                removeDevice(deviceToRemove, user);
                info(deviceToRemove.getHostName() + " " + 
getString("device.removed"));

            } catch (Exception e) {

                LOG.error("error while deleting" + 
deviceToRemove.getHostName(), e);

                error(e);

            }

            target.get().add(devicesGroup);
            target.get().add(feedbackPanel);
        }




-
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: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Sven Meier]

+1

Sven

On 28.06.22 18:54, Andrea Del Bene wrote:

I think we have enough work done for  9.11.0, so you shouldn't have to wait
too much to get it

On Tue, Jun 28, 2022 at 5:00 PM Wayne W  wrote:


Hi Sven,

So far so good. It seems to have fixed all issues.

Will there be a release for this anytime soon do you think?

Thanks

On Wed, Jun 22, 2022 at 8:45 PM Sven Meier  wrote:


Hi Wayne,

I pushed a fix to Wicket 9.x and 10.x.

Would be great if you could give this a test, your test application
works fine now.

Many thanks
Sven


On 20.06.22 18:19, Wayne W wrote:

Hello Sven,

Many thanks for looking into this. It's greatly appreciated that you
understand what is happening here.

Out of interest I just had a look at the RedissionSession setAttribute

and

it's just calling

org.apache.catalina.session.StandardSession.setAttribute(

name, value, notify)  and all the unBound calls are done in there. So
perhaps this is an issue with different versions of Tomcat?

FYI RedissionSession:

 *public* *void* setAttribute(String name, Object value, *boolean*

notify)

{

  *super*.setAttribute(name, value, notify);



  *if* (value == *null*) {

  *return*;

  }

  *if* (updateMode == UpdateMode.*DEFAULT* && map != *null*) {

  fastPut(name, value);

  }

  *if* (readMode == ReadMode.*REDIS*) {

  loadedAttributes.put(name, value);

  updatedAttributes.put(name, value);

  }

  *if* (updateMode == UpdateMode.*AFTER_REQUEST*) {

  removedAttributes.remove(name);

  }

  }

Either way looking forward to the fix.

On Sun, Jun 19, 2022 at 10:09 PM Sven Meier  wrote:


Hi again,

I found the cause of this bug:

RedissonSession exposes a behavior we've seen before, which seems not

to

be a problem with the default Tomcat session implementation:
When an attribute is set on the session, the previously set attribute

is

removed first - this leads to #valueUnbound() being called, signalling
PersistentPageStore to drop all store pages.

I'll perpare a fix tomorrow.

Thanks for your report.
Sven


On 18.06.22 15:24, Sven Meier wrote:

Hi,

I've stripped all pageManager related settings from your application.

Now the bug only appears with Tomcat's RedissonSessionManager,

without

it the detailPages open as expected.

I'm no expert in Redis, so I don't know what is going wrong there.

Can

you confirm my observation so far?

Regards
Sven


On 13.06.22 12:30, Wayne W wrote:

Hi Sven,

Ok here is a quickstart demonstrating the issue.


https://customerservices.glasscubes.com/share/s/1usch8t0hpjc4s5l3219he7s8f

To reproduce, open localhost:8080 and you will now also see a list

of

4

links. If you right click each link and open in a new window, you
will see
that only the first tab will render correctly. The other tabs just
refresh
the page.

If you change the wicket version to say 9.4.0 and do the same you
will see
that each page opens correctly in a new tab, and clicking on the

link

in

the page outputs "this" to the console correctly.

Let me know your thoughts
I will of course try and understand whats happening.


On Thu, Jun 9, 2022 at 8:45 AM Sven Meier  wrote:


Hi Wayne,

no idea on my side.

Please compare without InSessionPageStore and with different max

pages.

If the problem persists, please provide a quickstart.

Thanks
Sven


On 08.06.22 18:51, Wayne W wrote:

Hi Sven,

I'm having a new issue with this wicket version - I've yet had

time

to

dig

deep and try and make a quickstart to replicate it. However I
thought I
would describe it first to see if it rings any bells in your head!

In our app we have a file explorer like page that lists a bunch of
files.
Clicking one of these opens a popup over the page to see the
details. We
used to be able to open each of these files in a new browser tab.

However,

now when the new tabs are opened, the details load ok, but when

the

user
clicks on the wicket link to close the popup we are getting
componentsnotfound in the page.

Something about opening new browser tabs is messing up the session

and

loosing the components. I presume this is something to do with
InSessionPageStore. Opening a single new tab is fine, it when

there

are
more than 2 in total. I tried increasing the maxPages to 20 for
InSessionPageStore
but it made no difference.

Any idea?

On Wed, Jun 8, 2022 at 10:43 AM Sven Meier 

wrote:

Thanks Wayne!

The fix will be part of the next 9.x release.

Best regards
Sven


On 07.06.22 12:22, Wayne W wrote:

Hi Sven,

I can confirm your fix is working .

I suppose it will be a while before this reaches an official
release?
Thanks for your help - really appreciated.

Wayne

On Sun, May 29, 2022 at 10:47 PM Sven Meier 

wrote:

Hi Wayne,

the Eclipse .project still has 9.1.1 on the classpath:

  
path="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1.jar"
sourcepath="

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Sven Meier]

Hi Wayne,

I pushed a fix to Wicket 9.x and 10.x.

Would be great if you could give this a test, your test application 
works fine now.


Many thanks
Sven


On 20.06.22 18:19, Wayne W wrote:

Hello Sven,

Many thanks for looking into this. It's greatly appreciated that you
understand what is happening here.

Out of interest I just had a look at the RedissionSession setAttribute and
it's just calling org.apache.catalina.session.StandardSession.setAttribute(
name, value, notify)  and all the unBound calls are done in there. So
perhaps this is an issue with different versions of Tomcat?

FYI RedissionSession:

*public* *void* setAttribute(String name, Object value, *boolean* notify)
{

 *super*.setAttribute(name, value, notify);



 *if* (value == *null*) {

 *return*;

 }

 *if* (updateMode == UpdateMode.*DEFAULT* && map != *null*) {

 fastPut(name, value);

 }

 *if* (readMode == ReadMode.*REDIS*) {

 loadedAttributes.put(name, value);

 updatedAttributes.put(name, value);

 }

 *if* (updateMode == UpdateMode.*AFTER_REQUEST*) {

 removedAttributes.remove(name);

 }

 }

Either way looking forward to the fix.

On Sun, Jun 19, 2022 at 10:09 PM Sven Meier  wrote:


Hi again,

I found the cause of this bug:

RedissonSession exposes a behavior we've seen before, which seems not to
be a problem with the default Tomcat session implementation:
When an attribute is set on the session, the previously set attribute is
removed first - this leads to #valueUnbound() being called, signalling
PersistentPageStore to drop all store pages.

I'll perpare a fix tomorrow.

Thanks for your report.
Sven


On 18.06.22 15:24, Sven Meier wrote:

Hi,

I've stripped all pageManager related settings from your application.

Now the bug only appears with Tomcat's RedissonSessionManager, without
it the detailPages open as expected.

I'm no expert in Redis, so I don't know what is going wrong there. Can
you confirm my observation so far?

Regards
Sven


On 13.06.22 12:30, Wayne W wrote:

Hi Sven,

Ok here is a quickstart demonstrating the issue.


https://customerservices.glasscubes.com/share/s/1usch8t0hpjc4s5l3219he7s8f


To reproduce, open localhost:8080 and you will now also see a list of 4
links. If you right click each link and open in a new window, you
will see
that only the first tab will render correctly. The other tabs just
refresh
the page.

If you change the wicket version to say 9.4.0 and do the same you
will see
that each page opens correctly in a new tab, and clicking on the link in
the page outputs "this" to the console correctly.

Let me know your thoughts
I will of course try and understand whats happening.


On Thu, Jun 9, 2022 at 8:45 AM Sven Meier  wrote:


Hi Wayne,

no idea on my side.

Please compare without InSessionPageStore and with different max pages.

If the problem persists, please provide a quickstart.

Thanks
Sven


On 08.06.22 18:51, Wayne W wrote:

Hi Sven,

I'm having a new issue with this wicket version - I've yet had time to

dig

deep and try and make a quickstart to replicate it. However I
thought I
would describe it first to see if it rings any bells in your head!

In our app we have a file explorer like page that lists a bunch of
files.
Clicking one of these opens a popup over the page to see the
details. We
used to be able to open each of these files in a new browser tab.

However,

now when the new tabs are opened, the details load ok, but when the
user
clicks on the wicket link to close the popup we are getting
componentsnotfound in the page.

Something about opening new browser tabs is messing up the session and
loosing the components. I presume this is something to do with
InSessionPageStore. Opening a single new tab is fine, it when there
are
more than 2 in total. I tried increasing the maxPages to 20 for
InSessionPageStore
but it made no difference.

Any idea?

On Wed, Jun 8, 2022 at 10:43 AM Sven Meier  wrote:


Thanks Wayne!

The fix will be part of the next 9.x release.

Best regards
Sven


On 07.06.22 12:22, Wayne W wrote:

Hi Sven,

I can confirm your fix is working .

I suppose it will be a while before this reaches an official
release?
Thanks for your help - really appreciated.

Wayne

On Sun, May 29, 2022 at 10:47 PM Sven Meier 

wrote:

Hi Wayne,

the Eclipse .project still has 9.1.1 on the classpath:

 
path="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1.jar"



sourcepath="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1-sources.jar"/>


Without that, flushing of the Session works fine here with my
fix on

9.x

BTW the workaround with HubInSessionCache subclassing

InSessionPageStore

(to use a separate MetaDataKey) is no longer needed.

Regards
Sven


On 26.05.22 19:19, Wayne W wrote:

Hello Sven,

So this particular issue I've been investigating might be a
lac

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Sven Meier]

Hi again,

I found the cause of this bug:

RedissonSession exposes a behavior we've seen before, which seems not to 
be a problem with the default Tomcat session implementation:
When an attribute is set on the session, the previously set attribute is 
removed first - this leads to #valueUnbound() being called, signalling 
PersistentPageStore to drop all store pages.


I'll perpare a fix tomorrow.

Thanks for your report.
Sven


On 18.06.22 15:24, Sven Meier wrote:

Hi,

I've stripped all pageManager related settings from your application.

Now the bug only appears with Tomcat's RedissonSessionManager, without 
it the detailPages open as expected.


I'm no expert in Redis, so I don't know what is going wrong there. Can 
you confirm my observation so far?


Regards
Sven


On 13.06.22 12:30, Wayne W wrote:

Hi Sven,

Ok here is a quickstart demonstrating the issue.
https://customerservices.glasscubes.com/share/s/1usch8t0hpjc4s5l3219he7s8f 



To reproduce, open localhost:8080 and you will now also see a list of 4
links. If you right click each link and open in a new window, you 
will see
that only the first tab will render correctly. The other tabs just 
refresh

the page.

If you change the wicket version to say 9.4.0 and do the same you 
will see

that each page opens correctly in a new tab, and clicking on the link in
the page outputs "this" to the console correctly.

Let me know your thoughts
I will of course try and understand whats happening.


On Thu, Jun 9, 2022 at 8:45 AM Sven Meier  wrote:


Hi Wayne,

no idea on my side.

Please compare without InSessionPageStore and with different max pages.

If the problem persists, please provide a quickstart.

Thanks
Sven


On 08.06.22 18:51, Wayne W wrote:

Hi Sven,

I'm having a new issue with this wicket version - I've yet had time to

dig
deep and try and make a quickstart to replicate it. However I 
thought I

would describe it first to see if it rings any bells in your head!

In our app we have a file explorer like page that lists a bunch of 
files.
Clicking one of these opens a popup over the page to see the 
details. We

used to be able to open each of these files in a new browser tab.

However,
now when the new tabs are opened, the details load ok, but when the 
user

clicks on the wicket link to close the popup we are getting
componentsnotfound in the page.

Something about opening new browser tabs is messing up the session and
loosing the components. I presume this is something to do with
InSessionPageStore. Opening a single new tab is fine, it when there 
are

more than 2 in total. I tried increasing the maxPages to 20 for
InSessionPageStore
but it made no difference.

Any idea?

On Wed, Jun 8, 2022 at 10:43 AM Sven Meier  wrote:


Thanks Wayne!

The fix will be part of the next 9.x release.

Best regards
Sven


On 07.06.22 12:22, Wayne W wrote:

Hi Sven,

I can confirm your fix is working .

I suppose it will be a while before this reaches an official 
release?

Thanks for your help - really appreciated.

Wayne

On Sun, May 29, 2022 at 10:47 PM Sven Meier  wrote:


Hi Wayne,

the Eclipse .project still has 9.1.1 on the classpath:

    path="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1.jar" 

sourcepath="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1-sources.jar"/> 



Without that, flushing of the Session works fine here with my 
fix on

9.x

BTW the workaround with HubInSessionCache subclassing

InSessionPageStore

(to use a separate MetaDataKey) is no longer needed.

Regards
Sven


On 26.05.22 19:19, Wayne W wrote:

Hello Sven,

So this particular issue I've been investigating might be a 
lack of

my
understanding of wicket as much as a session issue, but it 
seems odd

and I'm fairly sure it's not correct. It appears I need to call
getSession().dirty();
as well within the ajax request for wicket to flush the updated 
model

into

the session (in the onDetach -> internalDetach -> setAttribute )

otherwise
the model update is simply ignored. If I don't call dirty() 
then the

model

is never persisted to the httlpsession via setAttribute() and the

change

is

lost.

Is that right?

Interestingly if I remove this from the Application:

*final* ISerializer serializer = *new*

JavaSerializer(getApplicationKey());

getFrameworkSettings().setSerializer(serializer);

getStoreSettings().setAsynchronous(*false*);

setPageManagerProvider(*new* DefaultPageManagerProvider(*this*) {

    *protected* IPageStore newCachingStore(IPageStore

pageStore)

    {

    *return* *new* CachingPageStore(pageStore, *new*

HubInSessionCache(

serializer));

    }

    });

Then I do not need to call dirty(). Is this because the 
httpsession

is

not

used I presume?

If I do not use persisted tomcat session in redis it's ok 
though when

not
calling dirty() - this because as I explained before, 
setAttribute is

not

being called on the tomcat httpsessi

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Sven Meier]

Hi,

I've stripped all pageManager related settings from your application.

Now the bug only appears with Tomcat's RedissonSessionManager, without 
it the detailPages open as expected.


I'm no expert in Redis, so I don't know what is going wrong there. Can 
you confirm my observation so far?


Regards
Sven


On 13.06.22 12:30, Wayne W wrote:

Hi Sven,

Ok here is a quickstart demonstrating the issue.
https://customerservices.glasscubes.com/share/s/1usch8t0hpjc4s5l3219he7s8f

To reproduce, open localhost:8080 and you will now also see a list of 4
links. If you right click each link and open in a new window, you will see
that only the first tab will render correctly. The other tabs just refresh
the page.

If you change the wicket version to say 9.4.0 and do the same you will see
that each page opens correctly in a new tab, and clicking on the link in
the page outputs "this" to the console correctly.

Let me know your thoughts
I will of course try and understand whats happening.


On Thu, Jun 9, 2022 at 8:45 AM Sven Meier  wrote:


Hi Wayne,

no idea on my side.

Please compare without InSessionPageStore and with different max pages.

If the problem persists, please provide a quickstart.

Thanks
Sven


On 08.06.22 18:51, Wayne W wrote:

Hi Sven,

I'm having a new issue with this wicket version - I've yet had time to

dig

deep and try and make a quickstart to replicate it. However I thought I
would describe it first to see if it rings any bells in your head!

In our app we have a file explorer like page that lists a bunch of files.
Clicking one of these opens a popup over the page to see the details. We
used to be able to open each of these files in a new browser tab.

However,

now when the new tabs are opened, the details load ok, but when the user
clicks on the wicket link to close the popup we are getting
componentsnotfound in the page.

Something about opening new browser tabs is messing up the session and
loosing the components. I presume this is something to do with
InSessionPageStore. Opening a single new tab is fine, it when there are
more than 2 in total. I tried increasing the maxPages to 20 for
InSessionPageStore
but it made no difference.

Any idea?

On Wed, Jun 8, 2022 at 10:43 AM Sven Meier  wrote:


Thanks Wayne!

The fix will be part of the next 9.x release.

Best regards
Sven


On 07.06.22 12:22, Wayne W wrote:

Hi Sven,

I can confirm your fix is working .

I suppose it will be a while before this reaches an official release?
Thanks for your help - really appreciated.

Wayne

On Sun, May 29, 2022 at 10:47 PM Sven Meier  wrote:


Hi Wayne,

the Eclipse .project still has 9.1.1 on the classpath:


path="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1.jar"
sourcepath="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1-sources.jar"/>


Without that, flushing of the Session works fine here with my fix on

9.x

BTW the workaround with HubInSessionCache subclassing

InSessionPageStore

(to use a separate MetaDataKey) is no longer needed.

Regards
Sven


On 26.05.22 19:19, Wayne W wrote:

Hello Sven,

So this particular issue I've been investigating might be a lack of

my

understanding of wicket as much as a session issue, but it seems odd
and I'm fairly sure it's not correct. It appears I need to call
getSession().dirty();
as well within the ajax request for wicket to flush the updated model

into

the session (in the onDetach -> internalDetach -> setAttribute )

otherwise

the model update is simply ignored. If I don't call dirty() then the

model

is never persisted to the httlpsession via setAttribute() and the

change

is

lost.

Is that right?

Interestingly if I remove this from the Application:

*final* ISerializer serializer = *new*

JavaSerializer(getApplicationKey());

getFrameworkSettings().setSerializer(serializer);

getStoreSettings().setAsynchronous(*false*);

setPageManagerProvider(*new* DefaultPageManagerProvider(*this*) {

*protected* IPageStore newCachingStore(IPageStore

pageStore)

{

*return* *new* CachingPageStore(pageStore, *new*

HubInSessionCache(

serializer));

}

});

Then I do not need to call dirty(). Is this because the httpsession

is

not

used I presume?

If I do not use persisted tomcat session in redis it's ok though when

not

calling dirty() - this because as I explained before, setAttribute is

not

being called on the tomcat httpsession on the next request to the

AjaxLink.

The redis tomcat is looking for calls to the setAttribute to store

the

updated session into redis , and without that explicit dirty() call

it

doesn't happen.

Here is a quickstart if you want:


https://customerservices.glasscubes.com/share/s/mvecp90dlvqlp3p2b744q0gps4

You will need a bog standard redis instance running on your machine

though

to test. Check the path is correct in Start.java line 84.
Line 74 in HomePage.java has the dirty c

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Sven Meier]

Hi Wayne,

no idea on my side.

Please compare without InSessionPageStore and with different max pages.

If the problem persists, please provide a quickstart.

Thanks
Sven


On 08.06.22 18:51, Wayne W wrote:

Hi Sven,

I'm having a new issue with this wicket version - I've yet had time to dig
deep and try and make a quickstart to replicate it. However I thought I
would describe it first to see if it rings any bells in your head!

In our app we have a file explorer like page that lists a bunch of files.
Clicking one of these opens a popup over the page to see the details. We
used to be able to open each of these files in a new browser tab. However,
now when the new tabs are opened, the details load ok, but when the user
clicks on the wicket link to close the popup we are getting
componentsnotfound in the page.

Something about opening new browser tabs is messing up the session and
loosing the components. I presume this is something to do with
InSessionPageStore. Opening a single new tab is fine, it when there are
more than 2 in total. I tried increasing the maxPages to 20 for
InSessionPageStore
but it made no difference.

Any idea?

On Wed, Jun 8, 2022 at 10:43 AM Sven Meier  wrote:


Thanks Wayne!

The fix will be part of the next 9.x release.

Best regards
Sven


On 07.06.22 12:22, Wayne W wrote:

Hi Sven,

I can confirm your fix is working .

I suppose it will be a while before this reaches an official release?
Thanks for your help - really appreciated.

Wayne

On Sun, May 29, 2022 at 10:47 PM Sven Meier  wrote:


Hi Wayne,

the Eclipse .project still has 9.1.1 on the classpath:

   
sourcepath="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1-sources.jar"/>



Without that, flushing of the Session works fine here with my fix on 9.x

BTW the workaround with HubInSessionCache subclassing InSessionPageStore
(to use a separate MetaDataKey) is no longer needed.

Regards
Sven


On 26.05.22 19:19, Wayne W wrote:

Hello Sven,

So this particular issue I've been investigating might be a lack of my
understanding of wicket as much as a session issue, but it seems odd
and I'm fairly sure it's not correct. It appears I need to call
getSession().dirty();
as well within the ajax request for wicket to flush the updated model

into

the session (in the onDetach -> internalDetach -> setAttribute )

otherwise

the model update is simply ignored. If I don't call dirty() then the

model

is never persisted to the httlpsession via setAttribute() and the

change

is

lost.

Is that right?

Interestingly if I remove this from the Application:

*final* ISerializer serializer = *new*

JavaSerializer(getApplicationKey());

getFrameworkSettings().setSerializer(serializer);

getStoreSettings().setAsynchronous(*false*);

setPageManagerProvider(*new* DefaultPageManagerProvider(*this*) {

   *protected* IPageStore newCachingStore(IPageStore

pageStore)

   {

   *return* *new* CachingPageStore(pageStore, *new*

HubInSessionCache(

serializer));

   }

   });

Then I do not need to call dirty(). Is this because the httpsession is

not

used I presume?

If I do not use persisted tomcat session in redis it's ok though when

not

calling dirty() - this because as I explained before, setAttribute is

not

being called on the tomcat httpsession on the next request to the

AjaxLink.

The redis tomcat is looking for calls to the setAttribute to store the
updated session into redis , and without that explicit dirty() call it
doesn't happen.

Here is a quickstart if you want:


https://customerservices.glasscubes.com/share/s/mvecp90dlvqlp3p2b744q0gps4

You will need a bog standard redis instance running on your machine

though

to test. Check the path is correct in Start.java line 84.
Line 74 in HomePage.java has the dirty commented out at the moment.

Enter some text into the textfield and you will see the model is

updated

(printed out). However when you click on the AjaxLink 'next' the model

is

null.

Let me know your thoughts
Many thanks.




On Wed, May 25, 2022 at 4:19 PM Wayne W 

wrote:

Hi Sven,

Many thanks.

I've built 9,x and the changes seem to be there, but I still have the
issue. I will try and create a quickstart reproducing this issue and

get

back to you.

Wayne

On Wed, May 25, 2022 at 8:34 AM Sven Meier  wrote:


Hi Wayne,

I've pushed a fix to



https://github.com/apache/wicket/tree/WICKET-6981-session-attributes-not-set

Are you able to test this on your setup?

Regards
Sven


On 24.05.22 10:43, Wayne W wrote:

Hello Sven,

Any update on this?
Many thanks

On Mon, May 16, 2022 at 11:40 AM Sven Meier 

wrote:

Hi Wayne,

not, because InSessionPageStore#canBeAsynchronous returns false,

thereby

preventing asynchronous adds.

Regards
Sven


On 16.05.22 09:37, Wayne W wrote:

Ah that's great Sven.

Just a question - is it necessary for me to call
getStoreSettings().setAsynchronous(false); when wanting to support

http

session setup?

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Sven Meier]

Thanks Wayne!

The fix will be part of the next 9.x release.

Best regards
Sven


On 07.06.22 12:22, Wayne W wrote:

Hi Sven,

I can confirm your fix is working .

I suppose it will be a while before this reaches an official release?
Thanks for your help - really appreciated.

Wayne

On Sun, May 29, 2022 at 10:47 PM Sven Meier  wrote:


Hi Wayne,

the Eclipse .project still has 9.1.1 on the classpath:

  



Without that, flushing of the Session works fine here with my fix on 9.x

BTW the workaround with HubInSessionCache subclassing InSessionPageStore
(to use a separate MetaDataKey) is no longer needed.

Regards
Sven


On 26.05.22 19:19, Wayne W wrote:

Hello Sven,

So this particular issue I've been investigating might be a lack of my
understanding of wicket as much as a session issue, but it seems odd
and I'm fairly sure it's not correct. It appears I need to call
getSession().dirty();
as well within the ajax request for wicket to flush the updated model

into

the session (in the onDetach -> internalDetach -> setAttribute )

otherwise

the model update is simply ignored. If I don't call dirty() then the

model

is never persisted to the httlpsession via setAttribute() and the change

is

lost.

Is that right?

Interestingly if I remove this from the Application:

*final* ISerializer serializer = *new*

JavaSerializer(getApplicationKey());

getFrameworkSettings().setSerializer(serializer);

getStoreSettings().setAsynchronous(*false*);

setPageManagerProvider(*new* DefaultPageManagerProvider(*this*) {

  *protected* IPageStore newCachingStore(IPageStore pageStore)

  {

  *return* *new* CachingPageStore(pageStore, *new*

HubInSessionCache(

serializer));

  }

  });

Then I do not need to call dirty(). Is this because the httpsession is

not

used I presume?

If I do not use persisted tomcat session in redis it's ok though when not
calling dirty() - this because as I explained before, setAttribute is not
being called on the tomcat httpsession on the next request to the

AjaxLink.

The redis tomcat is looking for calls to the setAttribute to store the
updated session into redis , and without that explicit dirty() call it
doesn't happen.

Here is a quickstart if you want:


https://customerservices.glasscubes.com/share/s/mvecp90dlvqlp3p2b744q0gps4

You will need a bog standard redis instance running on your machine

though

to test. Check the path is correct in Start.java line 84.
Line 74 in HomePage.java has the dirty commented out at the moment.

Enter some text into the textfield and you will see the model is updated
(printed out). However when you click on the AjaxLink 'next' the model is
null.

Let me know your thoughts
Many thanks.




On Wed, May 25, 2022 at 4:19 PM Wayne W 

wrote:

Hi Sven,

Many thanks.

I've built 9,x and the changes seem to be there, but I still have the
issue. I will try and create a quickstart reproducing this issue and get
back to you.

Wayne

On Wed, May 25, 2022 at 8:34 AM Sven Meier  wrote:


Hi Wayne,

I've pushed a fix to



https://github.com/apache/wicket/tree/WICKET-6981-session-attributes-not-set

Are you able to test this on your setup?

Regards
Sven


On 24.05.22 10:43, Wayne W wrote:

Hello Sven,

Any update on this?
Many thanks

On Mon, May 16, 2022 at 11:40 AM Sven Meier  wrote:


Hi Wayne,

not, because InSessionPageStore#canBeAsynchronous returns false,

thereby

preventing asynchronous adds.

Regards
Sven


On 16.05.22 09:37, Wayne W wrote:

Ah that's great Sven.

Just a question - is it necessary for me to call
getStoreSettings().setAsynchronous(false); when wanting to support

http

session setup?

I saw a post about this quite some time ago but I'm not sure.

Thanks for clarifying



On Sun, May 15, 2022 at 8:54 PM Sven Meier  wrote:


Hi Wayne,

I've create an issue for this bug:

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

I think I have a fix ready, but have to give it some more tests.

Thanks for reporting the issue.

Sven


On 10.05.22 23:25, Sven Meier wrote:

Hi Wayne,


Is this a bug?

could be, do we have a Jira issue already?

I think there might be a call to Session#setMetaData() missing.

Before

Wicket 9.x it seemed to have been called additionally when a page

is

stored in the session.

I'll take a deeper look into this tomorrow.

Best regards
Sven


On 10.05.22 18:47, Wayne W wrote:

Hi,

I am *still* trying to troubleshoot why migrating to 9.4 we have
found that
our app no longer supports session failover correctly. We use
Redission to
store the tomcat session in Redis.

After a lot of debugging it appears that for
AjaxFormComponentUpdatingBehavior.onEvent() calls,
HttpSessionStore.flushSession() is never called after. And

changes

to

the
model are not persisted in the HTTP Session and into Redis backed

store.

The reason is setAttribute is never called on the session and
therefore the
updated session with good model values is never persisted. And

when

the

next call a

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Sven Meier]

Hi Wayne,

the Eclipse .project still has 9.1.1 on the classpath:

    path="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1.jar" 
sourcepath="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1-sources.jar"/> 



Without that, flushing of the Session works fine here with my fix on 9.x

BTW the workaround with HubInSessionCache subclassing InSessionPageStore 
(to use a separate MetaDataKey) is no longer needed.


Regards
Sven


On 26.05.22 19:19, Wayne W wrote:

Hello Sven,

So this particular issue I've been investigating might be a lack of my
understanding of wicket as much as a session issue, but it seems odd
and I'm fairly sure it's not correct. It appears I need to call
getSession().dirty();
as well within the ajax request for wicket to flush the updated model into
the session (in the onDetach -> internalDetach -> setAttribute ) otherwise
the model update is simply ignored. If I don't call dirty() then the model
is never persisted to the httlpsession via setAttribute() and the change is
lost.

Is that right?

Interestingly if I remove this from the Application:

*final* ISerializer serializer = *new* JavaSerializer(getApplicationKey());

getFrameworkSettings().setSerializer(serializer);

getStoreSettings().setAsynchronous(*false*);

setPageManagerProvider(*new* DefaultPageManagerProvider(*this*) {

 *protected* IPageStore newCachingStore(IPageStore pageStore)

 {

 *return* *new* CachingPageStore(pageStore, *new* HubInSessionCache(
serializer));

 }

 });

Then I do not need to call dirty(). Is this because the httpsession is not
used I presume?

If I do not use persisted tomcat session in redis it's ok though when not
calling dirty() - this because as I explained before, setAttribute is not
being called on the tomcat httpsession on the next request to the AjaxLink.
The redis tomcat is looking for calls to the setAttribute to store the
updated session into redis , and without that explicit dirty() call it
doesn't happen.

Here is a quickstart if you want:
https://customerservices.glasscubes.com/share/s/mvecp90dlvqlp3p2b744q0gps4
You will need a bog standard redis instance running on your machine though
to test. Check the path is correct in Start.java line 84.
Line 74 in HomePage.java has the dirty commented out at the moment.

Enter some text into the textfield and you will see the model is updated
(printed out). However when you click on the AjaxLink 'next' the model is
null.

Let me know your thoughts
Many thanks.




On Wed, May 25, 2022 at 4:19 PM Wayne W  wrote:


Hi Sven,

Many thanks.

I've built 9,x and the changes seem to be there, but I still have the
issue. I will try and create a quickstart reproducing this issue and get
back to you.

Wayne

On Wed, May 25, 2022 at 8:34 AM Sven Meier  wrote:


Hi Wayne,

I've pushed a fix to

https://github.com/apache/wicket/tree/WICKET-6981-session-attributes-not-set

Are you able to test this on your setup?

Regards
Sven


On 24.05.22 10:43, Wayne W wrote:

Hello Sven,

Any update on this?
Many thanks

On Mon, May 16, 2022 at 11:40 AM Sven Meier  wrote:


Hi Wayne,

not, because InSessionPageStore#canBeAsynchronous returns false,

thereby

preventing asynchronous adds.

Regards
Sven


On 16.05.22 09:37, Wayne W wrote:

Ah that's great Sven.

Just a question - is it necessary for me to call
getStoreSettings().setAsynchronous(false); when wanting to support

http

session setup?

I saw a post about this quite some time ago but I'm not sure.

Thanks for clarifying



On Sun, May 15, 2022 at 8:54 PM Sven Meier  wrote:


Hi Wayne,

I've create an issue for this bug:

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

I think I have a fix ready, but have to give it some more tests.

Thanks for reporting the issue.

Sven


On 10.05.22 23:25, Sven Meier wrote:

Hi Wayne,


Is this a bug?

could be, do we have a Jira issue already?

I think there might be a call to Session#setMetaData() missing.

Before

Wicket 9.x it seemed to have been called additionally when a page is
stored in the session.

I'll take a deeper look into this tomorrow.

Best regards
Sven


On 10.05.22 18:47, Wayne W wrote:

Hi,

I am *still* trying to troubleshoot why migrating to 9.4 we have
found that
our app no longer supports session failover correctly. We use
Redission to
store the tomcat session in Redis.

After a lot of debugging it appears that for
AjaxFormComponentUpdatingBehavior.onEvent() calls,
HttpSessionStore.flushSession() is never called after. And changes

to

the
model are not persisted in the HTTP Session and into Redis backed

store.

The reason is setAttribute is never called on the session and
therefore the
updated session with good model values is never persisted. And when

the

next call arrives, the page is pulled back out of Redis/Http

session

without the changes.

I had to do the following to get the wicket session to be stored in

the

session within our Applica

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Sven Meier]

Hi Wayne,

I've pushed a fix to 
https://github.com/apache/wicket/tree/WICKET-6981-session-attributes-not-set


Are you able to test this on your setup?

Regards
Sven


On 24.05.22 10:43, Wayne W wrote:

Hello Sven,

Any update on this?
Many thanks

On Mon, May 16, 2022 at 11:40 AM Sven Meier  wrote:


Hi Wayne,

not, because InSessionPageStore#canBeAsynchronous returns false, thereby
preventing asynchronous adds.

Regards
Sven


On 16.05.22 09:37, Wayne W wrote:

Ah that's great Sven.

Just a question - is it necessary for me to call
getStoreSettings().setAsynchronous(false); when wanting to support http
session setup?

I saw a post about this quite some time ago but I'm not sure.

Thanks for clarifying



On Sun, May 15, 2022 at 8:54 PM Sven Meier  wrote:


Hi Wayne,

I've create an issue for this bug:

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

I think I have a fix ready, but have to give it some more tests.

Thanks for reporting the issue.

Sven


On 10.05.22 23:25, Sven Meier wrote:

Hi Wayne,


Is this a bug?

could be, do we have a Jira issue already?

I think there might be a call to Session#setMetaData() missing. Before
Wicket 9.x it seemed to have been called additionally when a page is
stored in the session.

I'll take a deeper look into this tomorrow.

Best regards
Sven


On 10.05.22 18:47, Wayne W wrote:

Hi,

I am *still* trying to troubleshoot why migrating to 9.4 we have
found that
our app no longer supports session failover correctly. We use
Redission to
store the tomcat session in Redis.

After a lot of debugging it appears that for
AjaxFormComponentUpdatingBehavior.onEvent() calls,
HttpSessionStore.flushSession() is never called after. And changes to
the
model are not persisted in the HTTP Session and into Redis backed

store.

The reason is setAttribute is never called on the session and
therefore the
updated session with good model values is never persisted. And when

the

next call arrives, the page is pulled back out of Redis/Http session
without the changes.

I had to do the following to get the wicket session to be stored in

the

session within our Application:

ISerializer serializer = new JavaSerializer(getApplicationKey());
getFrameworkSettings().setSerializer(serializer);
getStoreSettings().setAsynchronous(false);
setPageManagerProvider(new DefaultPageManagerProvider(this) {
   protected IPageStore newCachingStore(IPageStore

pageStore)

   {
   return new CachingPageStore(pageStore, new
InSessionPageStore( 2,
serializer));
   }
   });

The objects are updated in the session page object instance correctly
with
AjaxFormComponentUpdatingBehavior , however this issue is they are

never

saved/persisted as setAttribute is not called. So the next request

comes

and a new page object instance is unserialized from the store without
the
changes.

Is this a bug?


-
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: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Sven Meier]

Hi Wayne,

not, because InSessionPageStore#canBeAsynchronous returns false, thereby 
preventing asynchronous adds.


Regards
Sven


On 16.05.22 09:37, Wayne W wrote:

Ah that's great Sven.

Just a question - is it necessary for me to call
getStoreSettings().setAsynchronous(false); when wanting to support http
session setup?

I saw a post about this quite some time ago but I'm not sure.

Thanks for clarifying



On Sun, May 15, 2022 at 8:54 PM Sven Meier  wrote:


Hi Wayne,

I've create an issue for this bug:

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

I think I have a fix ready, but have to give it some more tests.

Thanks for reporting the issue.

Sven


On 10.05.22 23:25, Sven Meier wrote:

Hi Wayne,


Is this a bug?

could be, do we have a Jira issue already?

I think there might be a call to Session#setMetaData() missing. Before
Wicket 9.x it seemed to have been called additionally when a page is
stored in the session.

I'll take a deeper look into this tomorrow.

Best regards
Sven


On 10.05.22 18:47, Wayne W wrote:

Hi,

I am *still* trying to troubleshoot why migrating to 9.4 we have
found that
our app no longer supports session failover correctly. We use
Redission to
store the tomcat session in Redis.

After a lot of debugging it appears that for
AjaxFormComponentUpdatingBehavior.onEvent() calls,
HttpSessionStore.flushSession() is never called after. And changes to
the
model are not persisted in the HTTP Session and into Redis backed store.
The reason is setAttribute is never called on the session and
therefore the
updated session with good model values is never persisted. And when the
next call arrives, the page is pulled back out of Redis/Http session
without the changes.

I had to do the following to get the wicket session to be stored in the
session within our Application:

ISerializer serializer = new JavaSerializer(getApplicationKey());
getFrameworkSettings().setSerializer(serializer);
getStoreSettings().setAsynchronous(false);
setPageManagerProvider(new DefaultPageManagerProvider(this) {
  protected IPageStore newCachingStore(IPageStore pageStore)
  {
  return new CachingPageStore(pageStore, new
InSessionPageStore( 2,
serializer));
  }
  });

The objects are updated in the session page object instance correctly
with
AjaxFormComponentUpdatingBehavior , however this issue is they are never
saved/persisted as setAttribute is not called. So the next request comes
and a new page object instance is unserialized from the store without
the
changes.

Is this a bug?


-
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: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Sven Meier]

Hi Wayne,

I've create an issue for this bug:

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

I think I have a fix ready, but have to give it some more tests.

Thanks for reporting the issue.

Sven


On 10.05.22 23:25, Sven Meier wrote:

Hi Wayne,

>Is this a bug?

could be, do we have a Jira issue already?

I think there might be a call to Session#setMetaData() missing. Before 
Wicket 9.x it seemed to have been called additionally when a page is 
stored in the session.


I'll take a deeper look into this tomorrow.

Best regards
Sven


On 10.05.22 18:47, Wayne W wrote:

Hi,

I am *still* trying to troubleshoot why migrating to 9.4 we have 
found that
our app no longer supports session failover correctly. We use 
Redission to

store the tomcat session in Redis.

After a lot of debugging it appears that for
AjaxFormComponentUpdatingBehavior.onEvent() calls,
HttpSessionStore.flushSession() is never called after. And changes to 
the

model are not persisted in the HTTP Session and into Redis backed store.
The reason is setAttribute is never called on the session and 
therefore the

updated session with good model values is never persisted. And when the
next call arrives, the page is pulled back out of Redis/Http session
without the changes.

I had to do the following to get the wicket session to be stored in the
session within our Application:

ISerializer serializer = new JavaSerializer(getApplicationKey());
getFrameworkSettings().setSerializer(serializer);
getStoreSettings().setAsynchronous(false);
setPageManagerProvider(new DefaultPageManagerProvider(this) {
 protected IPageStore newCachingStore(IPageStore pageStore)
 {
 return new CachingPageStore(pageStore, new 
InSessionPageStore( 2,

serializer));
 }
 });

The objects are updated in the session page object instance correctly 
with

AjaxFormComponentUpdatingBehavior , however this issue is they are never
saved/persisted as setAttribute is not called. So the next request comes
and a new page object instance is unserialized from the store without 
the

changes.

Is this a bug?



-
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: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Sven Meier]

Hi Wayne,

>Is this a bug?

could be, do we have a Jira issue already?

I think there might be a call to Session#setMetaData() missing. Before 
Wicket 9.x it seemed to have been called additionally when a page is 
stored in the session.


I'll take a deeper look into this tomorrow.

Best regards
Sven


On 10.05.22 18:47, Wayne W wrote:

Hi,

I am *still* trying to troubleshoot why migrating to 9.4 we have found that
our app no longer supports session failover correctly. We use Redission to
store the tomcat session in Redis.

After a lot of debugging it appears that for
AjaxFormComponentUpdatingBehavior.onEvent() calls,
HttpSessionStore.flushSession() is never called after. And changes to the
model are not persisted in the HTTP Session and into Redis backed store.
The reason is setAttribute is never called on the session and therefore the
updated session with good model values is never persisted. And when the
next call arrives, the page is pulled back out of Redis/Http session
without the changes.

I had to do the following to get the wicket session to be stored in the
session within our Application:

ISerializer serializer = new JavaSerializer(getApplicationKey());
getFrameworkSettings().setSerializer(serializer);
getStoreSettings().setAsynchronous(false);
setPageManagerProvider(new DefaultPageManagerProvider(this) {
 protected IPageStore newCachingStore(IPageStore pageStore)
 {
 return new CachingPageStore(pageStore, new InSessionPageStore( 2,
serializer));
 }
 });

The objects are updated in the session page object instance correctly with
AjaxFormComponentUpdatingBehavior , however this issue is they are never
saved/persisted as setAttribute is not called. So the next request comes
and a new page object instance is unserialized from the store without the
changes.

Is this a bug?



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

Re: how does DownloadLink lock the page?

[Sven Meier]

Hi Lucio,

only the *page instance* containing the DownloadLink is locked by the 
download.


Each user gets his own page instances, and these do not affect each other.

Best regards
Sven


On 22.03.22 18:00, Lucio Crusca wrote:

The API docs here

https://nightlies.apache.org/wicket/apidocs/9.x/org/apache/wicket/markup/html/link/DownloadLink.html 



state that DownloadLink locks the page. I assume it means the user who 
is downloading something cannot access the webapp until the download 
has finished.


But what about other users? Does that notice about other threads also 
being blocked mean that even other users won't be able to access that 
page? Or even the whole webapp?


-
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: Compoment.setVisible(IModel) ?

[Sven Meier]

Hi,

Models are not support for visible/enabled state.

The recommended pattern is overriding onConfigure()

onConfigure() {
  setVisible(/*... lazy evaluated ...*/)
}

Regards
Sven


On 10.03.22 00:31, smallufo wrote:

Currently , component visible is defined by a eager evaluated boolean value

public final Component setVisible(final boolean visible)

Is it able to make it accept IModel ?
(so that we can lazy evaluated the value)

Thanks.



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

Re: How to use the JavaScriptDeferHeaderResponse correctly?

[Sven Meier]

As a workaround you could use this:

    getHeaderResponseDecorators().add( (response) -> {
        if (RequestCycle.get().find(AjaxRequestTarget.class) == null) {
            response = new JavaScriptDeferHeaderResponse(response);
        }
        return response;
    });

Regards
Sven


On 01.02.22 17:16, Sven Meier wrote:

Hi Bas,

that seems to be broken since 
https://issues.apache.org/jira/browse/WICKET-6703


The JS is correctly collected by PartialPageUpdate, but then sent 
through the response decorators once again, thus being wrapped in a 
'DOMContentLoaded' listener.


Please open a Jira issue.

Regards
Sven


On 01.02.22 16:28, Sven Meier wrote:

Hi Bas,

your attachment didn't make it through the mailing list.

Can you point me to where I can download it from?

Thanks
Sven


On 31.01.22 14:51, Bas Gooren wrote:

Hi,

We are experimenting with the JavaScriptDeferHeaderResponse, but out 
of the box it doesn’t work correctly for us.

We are on wicket 9.7.0.

On an Ajax call (e.g. link click), the response includes a 
‘DOMContentLoaded’ event listener (which is not needed there). Since 
that never fires, any javascript handlers that are in the Ajax 
response are not registered.
Please have a look at the attached Quickstart, which demonstrates 
the issue.


Once the AJAX link is clicked, this evaluate node is added to the 
Ajax response (relevant part shown):


document.addEventListener('DOMContentLoaded', function() { 
(function(){console.log('test');})();(function(){Wicket.Log.enabled=true;})();(function(){Wicket.Ajax.baseUrl="?0";})();(function(){Wicket.Ajax.ajax({"u":"./?0-1.0-ajax","c":"ajax1","e":"click","pd":true});})();(function(){console.log('click');})();; 
});


The Ajax handler (Wicket.Ajax.ajax()) is inside the DOMContentLoaded 
event handler.


I’m not sure if we should be using the JavaScriptDeferHeaderResponse 
differently. We tried registering it using the three different 
methods provided by the header response decorators collection (add, 
add pre, add post).


Any help would be appreciated :-)

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


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

Re: How to use the JavaScriptDeferHeaderResponse correctly?

[Sven Meier]

Hi Bas,

that seems to be broken since 
https://issues.apache.org/jira/browse/WICKET-6703


The JS is correctly collected by PartialPageUpdate, but then sent 
through the response decorators once again, thus being wrapped in a 
'DOMContentLoaded' listener.


Please open a Jira issue.

Regards
Sven


On 01.02.22 16:28, Sven Meier wrote:

Hi Bas,

your attachment didn't make it through the mailing list.

Can you point me to where I can download it from?

Thanks
Sven


On 31.01.22 14:51, Bas Gooren wrote:

Hi,

We are experimenting with the JavaScriptDeferHeaderResponse, but out 
of the box it doesn’t work correctly for us.

We are on wicket 9.7.0.

On an Ajax call (e.g. link click), the response includes a 
‘DOMContentLoaded’ event listener (which is not needed there). Since 
that never fires, any javascript handlers that are in the Ajax 
response are not registered.
Please have a look at the attached Quickstart, which demonstrates the 
issue.


Once the AJAX link is clicked, this evaluate node is added to the 
Ajax response (relevant part shown):


document.addEventListener('DOMContentLoaded', function() { 
(function(){console.log('test');})();(function(){Wicket.Log.enabled=true;})();(function(){Wicket.Ajax.baseUrl="?0";})();(function(){Wicket.Ajax.ajax({"u":"./?0-1.0-ajax","c":"ajax1","e":"click","pd":true});})();(function(){console.log('click');})();; 
});


The Ajax handler (Wicket.Ajax.ajax()) is inside the DOMContentLoaded 
event handler.


I’m not sure if we should be using the JavaScriptDeferHeaderResponse 
differently. We tried registering it using the three different 
methods provided by the header response decorators collection (add, 
add pre, add post).


Any help would be appreciated :-)

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


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

Re: How to use the JavaScriptDeferHeaderResponse correctly?

[Sven Meier]

Hi Bas,

your attachment didn't make it through the mailing list.

Can you point me to where I can download it from?

Thanks
Sven


On 31.01.22 14:51, Bas Gooren wrote:

Hi,

We are experimenting with the JavaScriptDeferHeaderResponse, but out 
of the box it doesn’t work correctly for us.

We are on wicket 9.7.0.

On an Ajax call (e.g. link click), the response includes a 
‘DOMContentLoaded’ event listener (which is not needed there). Since 
that never fires, any javascript handlers that are in the Ajax 
response are not registered.
Please have a look at the attached Quickstart, which demonstrates the 
issue.


Once the AJAX link is clicked, this evaluate node is added to the Ajax 
response (relevant part shown):


document.addEventListener('DOMContentLoaded', function() { 
(function(){console.log('test');})();(function(){Wicket.Log.enabled=true;})();(function(){Wicket.Ajax.baseUrl="?0";})();(function(){Wicket.Ajax.ajax({"u":"./?0-1.0-ajax","c":"ajax1","e":"click","pd":true});})();(function(){console.log('click');})();; 
});


The Ajax handler (Wicket.Ajax.ajax()) is inside the DOMContentLoaded 
event handler.


I’m not sure if we should be using the JavaScriptDeferHeaderResponse 
differently. We tried registering it using the three different methods 
provided by the header response decorators collection (add, add pre, 
add post).


Any help would be appreciated :-)

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: RequestLogger - Different Page Memory Addresses

[Sven Meier]

Hi,

session size is calculated by serializing the session.

During session serializing your cached page is thrown away, see 
InSessionPageStore#writeObject().
So the next request will acquire the page from the persistent store: 
it's the identical page, just on a different memory location.


This is expected when sessions are serialized/deserialized - usually 
when the container decides to do so.

In your case it's a side effect of the request logger doing it.

Have fun
Sven


On 31.01.22 19:41, Drummer, Matthias wrote:


Hello all,

I stumbled across the following issue.

If the RequestLogger is activated, I get a new page object with every 
request (including AjaxRequests). If disabled then the page object 
will remain the same across multiple requests.


I am wondering why this is the case.

I attached a quickstart for reproducing the problem and made an 
ExamplePage (http://localhost:8080/example) which logs the Memory 
Address of the Page.


In my expectation the RequestLogger should log the request and 
additional informations but should not change the behavior of the 
application. It still works, but something is different which caughts 
my interest.


The behavior is as expected if I set the recordSessionSize property to 
false.


getRequestLoggerSettings().setRequestLoggerEnabled(true).setRecordSessionSize(false);

This setting affects the processing of 
org.apache.wicket.protocol.http.AbstractRequestLogger#requestTime 
where 
Application.get().getRequestLoggerSettings().getRecordSessionSize() is 
evaluated, but I have no idea why this leads to new objects.


Perhaps someone has an idea why this happens and which setting has to 
be made to get the expected behavior.


Thanks.

Greetings Matthias Drummer


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

Re: initialializers documentation

[Sven Meier]

Hi Ernesto,

yes, that is outdated, see

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

Sven


On 19.01.22 16:10, Ernesto Reinaldo Barreiro wrote:

Hi,

A colleague pointed me to

https://nightlies.apache.org/wicket/guide/9.x/single.html#_initializers

and remarked that we are using them differently. I digged the source code
and it seems this is  now working by means of

https://docs.oracle.com/javase/9/docs/api/java/util/ServiceLoader.html

Is the documentation outdated?



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

Re: [DISCUSSION] drop wicketstuff-jwicket-ui*

[Sven Meier]

+1 for dropping them

Sven

Am 12. Januar 2022 07:29:19 MEZ schrieb Martin Grigorov :
>+1 to drop them !
>
>On Wed, Jan 12, 2022 at 8:19 AM Maxim Solodovnik 
>wrote:
>
>> Hello All,
>>
>> I've just noticed:
>>
>> wicketstuff-jwicket-ui-datepicker
>> Contains `jQuery UI Datepicker 1.10.3` ( more than 160 js/css files)
>> wicketstuff-jwicket-ui-tooltip
>> Contains `jQuery UI Tooltip 1.10.3`
>>
>> wicketstuff-jwicket-ui-accordion
>> wicketstuff-jwicket-ui-dragdrop
>> wicketstuff-jwicket-ui-effects
>> wicketstuff-jwicket-ui-menu
>> wicketstuff-jwicket-ui-resize
>> wicketstuff-jwicket-ui-sort
>>   Contains `jQuery UI * 1.8.6`
>>
>> these components seems to very much outdated
>> maybe we can drop them?
>>
>>
>> --
>> Best regards,
>> Maxim
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>

Re: exception in windows while using FilePageStore

[Sven Meier]

Hi Ernesto,

I've tested FilePageStore without TRUNCATE_EXISTING - in that case the 
file will not shrink, when the page has reduced its size.


Luckily this doesn't disturb Java's default deserialization, the excess 
is just ignored.

But what if a project uses another serializer?

Regards

Sven


On 17.11.21 10:57, Ernesto Reinaldo Barreiro wrote:

Hi Sven,

Getting rid of the StandardOpenOption.TRUNCATE_EXISTING here

https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/pageStore/FilePageStore.java#L189

seems to "fix" the problem in windows and I also do not see problems in
linux. To be honest I have no idea of the full implications of this change.



On Tue, Nov 16, 2021 at 11:40 PM Sven Meier  wrote:


Hi Ernesto,

I'm no expert in this, but as I understood it FileChannel should be save
to be written to in parallel:


https://docs.oracle.com/javase/1.5.0/docs/api/java/nio/channels/FileChannel.html

"File channels are safe for use by multiple concurrent threads. ...
Only one operation that involves the channel's position or can change
its file's size may be in progress at any given time; attempts to
initiate a second such operation while the first is still in progress
will block until the first operation completes. ... The view of a file
provided by an instance of this class is guaranteed to be consistent
with other views of the same file provided by other instances in the
same program."

This sounds related though:


https://stackoverflow.com/questions/45441249/why-does-java-filechannel-truncate-fail-predictably-on-windows-only

Regards
Sven


On 16.11.21 19:56, Ernesto Reinaldo Barreiro wrote:

Hi Sven,

Many thanks for your answer. Main problem is I do not have Windows
around... this happens only in our Jenkins (which needs to be a windows
machine). I did some googling around and it seems it can be the operating
system itself if you access the same file in a very fast sequence: this
might be our case, as we are generating many web sockets messages

(pushing

components) and this seems to trigger page serialization.

On Linux and Mac we have no problems at all.


On Tue, Nov 16, 2021 at 7:28 PM Sven Meier  wrote:


Hi Ernesto,

maybe an issue with concurrent file writes?

I've tested the new FilePageStore on Linux only, and as it seems I
didn't add any synchronization to it.

Could you try out FilePageStoreTest?

Regards
Sven


On 16.11.21 16:18, Ernesto Reinaldo Barreiro wrote:

Hi,

We are trying to use FilePageStore and we are getting following
exception (a lot of them actually)

he requested operation cannot be performed on a file with a user-mapped
section open
[2021-11-16T07:34:00.699Z] at


sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)

~[?:?]
[2021-11-16T07:34:00.699Z] at


sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)

~[?:?]
[2021-11-16T07:34:00.699Z] at


sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)

~[?:?]
[2021-11-16T07:34:00.699Z] at


sun.nio.fs.WindowsFileSystemProvider.newFileChannel(WindowsFileSystemProvider.java:121)

~[?:?]
[2021-11-16T07:34:00.699Z] at
java.nio.channels.FileChannel.open(FileChannel.java:298) ~[?:?]
[2021-11-16T07:34:00.699Z] at
java.nio.channels.FileChannel.open(FileChannel.java:357) ~[?:?]
[2021-11-16T07:34:00.699Z] at


org.apache.wicket.pageStore.FilePageStore.writeFile(FilePageStore.java:188)

[wicket-core-9.6.0.jar:9.6.0]
[2021-11-16T07:34:00.699Z] at


org.apache.wicket.pageStore.FilePageStore.addPersistedPage(FilePageStore.java:178)

[wicket-core-9.6.0.jar:9.6.0]
[2021-11-16T07:34:00.699Z] at


org.apache.wicket.pageStore.AbstractPersistentPageStore.addPage(AbstractPersistentPageStore.java:128)

[wicket-core-9.6.0.jar:9.6.0]
[2021-11-16T07:34:00.699Z] at


org.apache.wicket.pageStore.AsynchronousPageStore$PageAddingRunnable.run(AsynchronousPageStore.java:292)

[wicket-core-9.6.0.jar:9.6.0]
[2021-11-16T07:34:00.699Z] at java.lang.Thread.run(Thread.java:833)

[?:?]

This does not happen for other operating systems. Is this a known
limitation? Is there anything else that needs to be configured at

operating

system level?

Thanks in advance.


-
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: exception in windows while using FilePageStore

[Sven Meier]

Hi Ernesto,

I'm no expert in this, but as I understood it FileChannel should be save 
to be written to in parallel:


https://docs.oracle.com/javase/1.5.0/docs/api/java/nio/channels/FileChannel.html

"File channels are safe for use by multiple concurrent threads. ...  
Only one operation that involves the channel's position or can change 
its file's size may be in progress at any given time; attempts to 
initiate a second such operation while the first is still in progress 
will block until the first operation completes. ... The view of a file 
provided by an instance of this class is guaranteed to be consistent 
with other views of the same file provided by other instances in the 
same program."


This sounds related though:

https://stackoverflow.com/questions/45441249/why-does-java-filechannel-truncate-fail-predictably-on-windows-only

Regards
Sven


On 16.11.21 19:56, Ernesto Reinaldo Barreiro wrote:

Hi Sven,

Many thanks for your answer. Main problem is I do not have Windows
around... this happens only in our Jenkins (which needs to be a windows
machine). I did some googling around and it seems it can be the operating
system itself if you access the same file in a very fast sequence: this
might be our case, as we are generating many web sockets messages (pushing
components) and this seems to trigger page serialization.

On Linux and Mac we have no problems at all.


On Tue, Nov 16, 2021 at 7:28 PM Sven Meier  wrote:


Hi Ernesto,

maybe an issue with concurrent file writes?

I've tested the new FilePageStore on Linux only, and as it seems I
didn't add any synchronization to it.

Could you try out FilePageStoreTest?

Regards
Sven


On 16.11.21 16:18, Ernesto Reinaldo Barreiro wrote:

Hi,

We are trying to use FilePageStore and we are getting following
exception (a lot of them actually)

he requested operation cannot be performed on a file with a user-mapped
section open
[2021-11-16T07:34:00.699Z] at


sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)

~[?:?]
[2021-11-16T07:34:00.699Z] at


sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)

~[?:?]
[2021-11-16T07:34:00.699Z] at


sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)

~[?:?]
[2021-11-16T07:34:00.699Z] at


sun.nio.fs.WindowsFileSystemProvider.newFileChannel(WindowsFileSystemProvider.java:121)

~[?:?]
[2021-11-16T07:34:00.699Z] at
java.nio.channels.FileChannel.open(FileChannel.java:298) ~[?:?]
[2021-11-16T07:34:00.699Z] at
java.nio.channels.FileChannel.open(FileChannel.java:357) ~[?:?]
[2021-11-16T07:34:00.699Z] at


org.apache.wicket.pageStore.FilePageStore.writeFile(FilePageStore.java:188)

[wicket-core-9.6.0.jar:9.6.0]
[2021-11-16T07:34:00.699Z] at


org.apache.wicket.pageStore.FilePageStore.addPersistedPage(FilePageStore.java:178)

[wicket-core-9.6.0.jar:9.6.0]
[2021-11-16T07:34:00.699Z] at


org.apache.wicket.pageStore.AbstractPersistentPageStore.addPage(AbstractPersistentPageStore.java:128)

[wicket-core-9.6.0.jar:9.6.0]
[2021-11-16T07:34:00.699Z] at


org.apache.wicket.pageStore.AsynchronousPageStore$PageAddingRunnable.run(AsynchronousPageStore.java:292)

[wicket-core-9.6.0.jar:9.6.0]
[2021-11-16T07:34:00.699Z] at java.lang.Thread.run(Thread.java:833) [?:?]

This does not happen for other operating systems. Is this a known
limitation? Is there anything else that needs to be configured at

operating

system level?

Thanks in advance.


-
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: exception in windows while using FilePageStore

[Sven Meier]

Hi Ernesto,

maybe an issue with concurrent file writes?

I've tested the new FilePageStore on Linux only, and as it seems I 
didn't add any synchronization to it.


Could you try out FilePageStoreTest?

Regards
Sven


On 16.11.21 16:18, Ernesto Reinaldo Barreiro wrote:

Hi,

We are trying to use FilePageStore and we are getting following
exception (a lot of them actually)

he requested operation cannot be performed on a file with a user-mapped
section open
[2021-11-16T07:34:00.699Z] at
sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
~[?:?]
[2021-11-16T07:34:00.699Z] at
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
~[?:?]
[2021-11-16T07:34:00.699Z] at
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
~[?:?]
[2021-11-16T07:34:00.699Z] at
sun.nio.fs.WindowsFileSystemProvider.newFileChannel(WindowsFileSystemProvider.java:121)
~[?:?]
[2021-11-16T07:34:00.699Z] at
java.nio.channels.FileChannel.open(FileChannel.java:298) ~[?:?]
[2021-11-16T07:34:00.699Z] at
java.nio.channels.FileChannel.open(FileChannel.java:357) ~[?:?]
[2021-11-16T07:34:00.699Z] at
org.apache.wicket.pageStore.FilePageStore.writeFile(FilePageStore.java:188)
[wicket-core-9.6.0.jar:9.6.0]
[2021-11-16T07:34:00.699Z] at
org.apache.wicket.pageStore.FilePageStore.addPersistedPage(FilePageStore.java:178)
[wicket-core-9.6.0.jar:9.6.0]
[2021-11-16T07:34:00.699Z] at
org.apache.wicket.pageStore.AbstractPersistentPageStore.addPage(AbstractPersistentPageStore.java:128)
[wicket-core-9.6.0.jar:9.6.0]
[2021-11-16T07:34:00.699Z] at
org.apache.wicket.pageStore.AsynchronousPageStore$PageAddingRunnable.run(AsynchronousPageStore.java:292)
[wicket-core-9.6.0.jar:9.6.0]
[2021-11-16T07:34:00.699Z] at java.lang.Thread.run(Thread.java:833) [?:?]

This does not happen for other operating systems. Is this a known
limitation? Is there anything else that needs to be configured at operating
system level?

Thanks in advance.



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

Re: migration from wicket 8 to 9 -> PageManagerProvider

[Sven Meier]

Indeed, flush-before-detach (WICKET-6831) was a huge performance 
improvement.


Sven


On 11.11.21 08:55, Korbinian Bachl wrote:

Hi Sven,

thanks a lot!

I've looked into that GaePageManagerProvider and adapted it myself. However, 
during test I somehow observed that the reason why I did use the HTTPSession 
store some long time ago (wicket 1.5/6?) doesn't seem to be existing anymore. 
Reason was that the underlying storage of our prod server has the typical small 
cloud latency. Now with wicket 9 all doing async I didnt see any benefit after 
all with having or not having the custom provider. I even suspect the 
HTTPSession solution to be a tad slower (1 to 10ms) from observation, but cant 
really pinpoint it down.

Its really nice to see how good wicket got here so that speed is quite well 
without the need for custom optimisation.

If you have any idea how to even speed things more up I'm always happy to hear 
;)

Best,

KB

- Ursprüngliche Mail -

Von: "Sven Meier" 
An: "users" 
Gesendet: Mittwoch, 10. November 2021 20:31:52
Betreff: Re: migration from wicket 8 to 9 -> PageManagerProvider
Hi Korbinian,


it was a real breeze. I'm very impressed!

thanks, glad to hear that.

You application is persisting pages in the Http session instead of disk.
Essentially what the wicketstuff's gae-initializer does too:

https://github.com/wicketstuff/core/blob/master/gae-initializer-parent/gae-initializer/src/main/java/org/wicketstuff/gae/GaePageManagerProvider.java

InsessionPageStore has a maxBytes constructor too.
Watch out for the override of the #getKey() method - I'm not happy with
that, but your question triggers me to look into that once again.

Have fun
Sven


On 10.11.21 12:05, Korbinian Bachl wrote:

Hi,

Im currently migrating our applications from wicket 8 to wicket 9.6 and so far
it was a real breeze. I'm very impressed!

One thing however that puzzles me is the following code I had in the application
init();


setPageManagerProvider(new DefaultPageManagerProvider(this) {
  protected IDataStore newDataStore() {
  return new HttpSessionDataStore(getPageManagerContext(),
  new MemorySizeEvictionStrategy(Bytes.megabytes(24)));
  }
  });
getStoreSettings().setInmemoryCacheSize(0);



I honestly dont know from when this originated but I had to disable it as it
doesnt seem to exist anymore accorting to the migration guide.

So I just let de default settings now apply. The original solution was aimed at
maximum page delivery speed and didnt care much about RAM as we got plenty of
it. Any idea if I should let the default or can I squeeze out some milliseconds
by going pure in memory again?

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

-
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: migration from wicket 8 to 9 -> PageManagerProvider

[Sven Meier]

Hi Korbinian,

> it was a real breeze. I'm very impressed!

thanks, glad to hear that.

You application is persisting pages in the Http session instead of disk. 
Essentially what the wicketstuff's gae-initializer does too:


https://github.com/wicketstuff/core/blob/master/gae-initializer-parent/gae-initializer/src/main/java/org/wicketstuff/gae/GaePageManagerProvider.java

InsessionPageStore has a maxBytes constructor too.
Watch out for the override of the #getKey() method - I'm not happy with 
that, but your question triggers me to look into that once again.


Have fun
Sven


On 10.11.21 12:05, Korbinian Bachl wrote:

Hi,

Im currently migrating our applications from wicket 8 to wicket 9.6 and so far 
it was a real breeze. I'm very impressed!

One thing however that puzzles me is the following code I had in the 
application init();


setPageManagerProvider(new DefaultPageManagerProvider(this) {
 protected IDataStore newDataStore() {
 return new HttpSessionDataStore(getPageManagerContext(),
 new MemorySizeEvictionStrategy(Bytes.megabytes(24)));
 }
 });
getStoreSettings().setInmemoryCacheSize(0);



I honestly dont know from when this originated but I had to disable it as it 
doesnt seem to exist anymore accorting to the migration guide.

So I just let de default settings now apply. The original solution was aimed at 
maximum page delivery speed and didnt care much about RAM as we got plenty of 
it. Any idea if I should let the default or can I squeeze out some milliseconds 
by going pure in memory again?

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: wicket clickable image with tooltips map

[Sven Meier]

Hi,

the solution from the wiki keeps the buffered image in the component 
tree, that's not a good idea (probably this is why it's transient).


The actual problem is, that all markup (including your refreshingView) 
is rendered first. Then the browser pulls the image data in a second 
request.


Simplest solution is to render twice, once just to get the 
ChartRenderingInfo, and a second time for the actual request for the 
image data.


Another possibility is to:

- leave the area list empty at first
- render the chart image in the dynamic resource *and* keep the 
ChartRenderingInfo in an instance variable (non-transient)
- have an AjaxEventBehavior("load") on the image, which re-renders the 
refreshingView and updates the area with the kept ChartRenderingInfo


Have fun
Sven


On 03.11.21 18:38, C.S. wrote:

Dear wicket developers,

i try to integrate wicket with jfreechart. Wicket wiki contains an example
under
https://cwiki.apache.org/confluence/display/WICKET/JFreeChart+with+clickable+imagemap
but this code is 11 yrs old and does not work with current versions.

Speaking of versions: i must stick with jdk 1.8, which means i cannot
upgrade to wicket 9+
Using wicket version 8.12.0

Goal is to create a usemap list to an image, so image is clickable
(contains tooltips).
For image i use a NonCachingImage and for the usemap i use a RefreshingView.

Trouble is, when the RefreshingView renders, the image has no rendering
info yet. So the RefreshingView model is empty. Image creates its rendering
info very late - during onRequest(). RefreshingView is rendered long ago at
this time.

I tried to create the image rendering info before rendering the
RefreshingView.
This is how it works in the old wiki example. Unfortunately, the new
versions throw a StackOverflowException. During Serialization, some
JFreeChart methods interact with some Wicket serialization methods. They
call each other (via reflexion) some 100s of times until StackOverflow
occurs.

What would you suggest? Is there a way to refresh the RefreshingView
without ajax?
Or somehow render the RefreshingView after the image produced its rendering
info?
Or should i use different wicket components? Or wrap/enclose these
components under another component (which one? ).

Thank you for your help

Christos Stieglitz

My code:

HTML:


   


Java:
RefreshingView mapAreas = new RefreshingView<>("area") {
   @Override
   protected Iterator> getItemModels() {
 ...
 // This is called during onRender(). List model is empty
 return models.iterator();
   }

   @Override
   protected void populateItem(Item item) {
 ChartEntity entity = item.getModelObject();
 item.add(new AttributeAppender("shape", entity.getShapeType()));
 item.add(new AttributeAppender("coords", entity.getShapeCoords()));
 item.add(new AttributeAppender("href", "#"));
 item.add(new TooltipBehavior(entity.getToolTipText()));
   }
 };
mapAreas.setOutputMarkupId(Boolean.TRUE);
add(mapAreas);

NonCachingImage ch = new NonCachingImage("livedata", Model.of(chart)) {
   @Override
   protected DynamicImageResource getImageResource() {
 return new DynamicImageResource() {
   @Override
   protected byte[] getImageData(IResource.Attributes attributes) {
 ChartRenderingInfo renderingInfo = new ChartRenderingInfo();
 // chart is a JFreeChart
 BufferedImage imgbytes = chart.createBufferedImage(imgwidth,
imgheight, renderingInfo);

 EntityCollection entities = renderingInfo.getEntityCollection();
 // This is called very late, during onRequest().
 // EntityCollection contains now everything is needed,
 // but how to call
 // RefreshingView.onRender() from here?
 // If i put this code anywhere else i get
StackOverflowException.
 return toImageData(imgbytes);
   }
 };
   }
 };
 add(ch);



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

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

[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 ?

[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

[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

[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

[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

[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

[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

[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

[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)

[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

[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

[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

[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

[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)

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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?

[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

[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.

[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

[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.

[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.

[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

[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

[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.

[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.

[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

[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

[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?

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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?

[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?

[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

[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?

[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

[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

[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

[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

[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