Full time remote Apache Wicket developer opportunity

[Wayne W]

Hello all,

We are looking for the above, if anyone is interested or knows of anyone
who might be interested.

This is a long term position.

Details of the job can be found here:  https://wellfound.com/l/2ArmgA

Salary depends on experience and to be discussed one on one.

Kind regards
Wayne

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Wayne W]

Great thanks!

On Tue, Jun 28, 2022 at 9:18 PM Sven Meier  wrote:

> +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
>

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Wayne W]

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

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Wayne W]

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 i

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Wayne W]

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* IS

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Wayne W]

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
> 

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Wayne W]

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 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
> >>>>&g

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Wayne W]

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

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Wayne W]

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

[Wayne W]

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

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Wayne W]

Ah thank you. Wasn't aware of that.

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

Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

[Wayne W]

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

FlushSession never called on AjaxFormComponentUpdatingBehavior

[Wayne W]

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?

Re: InSessionPageStore not storing page in http session

[Wayne W]

Ah,

please ignore. I was overriding the wrong method. It should be:

setPageManagerProvider(new DefaultPageManagerProvider(this) {
protected IPageStore newCachingStore(IPageStore pageStore)
{
return new CachingPageStore(pageStore, new InSessionPageStore( 2,
serializer));
}
});


This now seems to be working locally fine now.


On Tue, Apr 26, 2022 at 12:25 PM Wayne W 
wrote:

> Hello,
>
> Since migrating to 9.4 we have found that our app no longer supports
> session failover correctly. We use Redission tomcat to store the tomcat
> session in Redis. This works fine.
>
> However after a lot of debugging I can see that InSessionPageStore does
> not serialize the page into the http session, and that for the next request
> the page is always retrieved from the disk store.
>
> The reason it seems is that by default the serializer is null in
> InSessionPageStore and in the SessionData::writeObject if this is null then
> the page is not serialized and stored.
>
> So did this in the application:
>
> ISerializer serializer = new JavaSerializer(getApplicationKey());
> getFrameworkSettings().setSerializer(serializer);
> getStoreSettings().setAsynchronous(false);
> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> @Override
> protected IPageStore newPersistentStore() {
> return new InSessionPageStore( 2, serializer);
> }
> });
>
> However now I have lots of strange behaviour where the page is not found
> at all. This seems to stem from the fact that SessionData::get returns in
> instance of SerializedPage now. However in
> DefaultMapperContext::getPageInstance its expecting an instance of
> IRequestablePage which SerializedPage is not. Therefore the page is never
> found.
>
> How do I setup InSessionPageStore to actually serialize the page into the
> http session? as by default the page variable is always null on the next
> request?
>
> Many thanks
>

InSessionPageStore not storing page in http session

[Wayne W]

Hello,

Since migrating to 9.4 we have found that our app no longer supports
session failover correctly. We use Redission tomcat to store the tomcat
session in Redis. This works fine.

However after a lot of debugging I can see that InSessionPageStore does not
serialize the page into the http session, and that for the next request the
page is always retrieved from the disk store.

The reason it seems is that by default the serializer is null in
InSessionPageStore and in the SessionData::writeObject if this is null then
the page is not serialized and stored.

So did this in the application:

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

However now I have lots of strange behaviour where the page is not found at
all. This seems to stem from the fact that SessionData::get returns in
instance of SerializedPage now. However in
DefaultMapperContext::getPageInstance its expecting an instance of
IRequestablePage which SerializedPage is not. Therefore the page is never
found.

How do I setup InSessionPageStore to actually serialize the page into the
http session? as by default the page variable is always null on the next
request?

Many thanks

Re: Selenium testing

[Wayne W]

Thanks all for your replies.
Food for thought there.

WicketTester seems the 'better' solution, but I'm trying to hand this over
to a QA person who cannot program. Ernesto - I think it would be a massive
undertaking for use to get the css paths working well enough so that there
was some consistency for Selenium.



On Mon, Jan 31, 2022 at 2:37 PM Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi,
>
> Our app contains about 600 selenium tests... They are a pain to maintain
> even when we are trying to do things "the smart way". By this we mean:
>
>- We have some reusable wicket components. E.g. some AJAX table with
>lateral filtering facets. We roll in component marker CSS classes (e.g.
>.facets, .facet, .date-time-facet) + "use custom key attributes" (e.g
>facet-category="").
>- We mirror this component structure at client side selenium tests. i.e.
>we have a FacetsDriver that  hides low level complexity (e.g.
> FacetDriver
>xxx = tableWithFacets.getFacteDriverFof("xxx") and xxx.select("aaa")).
>
> The above works fine (mostly). Except people sometimes forget to use proper
> ways and reinvent the wheel. Sometimes tests do not pass or are shaky for
> no clear reason and a lot of time goes into stabilizing those. We are using
> global AJAX blocker div for pages, to prevent component not found issues,
> this makes very easy to have a global waitForAjaxFinished().
>
> In summary. We run our tests on a server running in production mode. Thus
> we do not use any wicket path or anything similar, we use custom CSS
> classes + custom element attributes to give a more precise context.
>
> Hope this helps?
>
>
> On Mon, Jan 31, 2022 at 8:38 AM Wayne W 
> wrote:
>
> > Hello all,
> >
> > Is anyone out there successfully using Selenium to do regression testing?
> > It seems with the latest version of Selenium you cannot add custom
> > selectors anymore (the idea turning on
> > getDebugSettings().setComponentPathAttributeName("wicketpath") ). So it
> > just uses css selectors and xpath now.
> >
> > Whilst I can had craft css selectors to use the wicketpath attribute I
> > cannot get the IDE to use this by default. The problem is I want to hand
> > this over to our QA person but she is not technical nature and would
> > struggle to understand the correct selector when looking at the code and
> > also it would really slow down the whole process of setting up tests.
> >
> > Anyone got Selenium working well, or can recommend another tool for web
> > regressing testing that works well with Wicket?
> >
> > thanks
> >
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>

Selenium testing

[Wayne W]

Hello all,

Is anyone out there successfully using Selenium to do regression testing?
It seems with the latest version of Selenium you cannot add custom
selectors anymore (the idea turning on
getDebugSettings().setComponentPathAttributeName("wicketpath") ). So it
just uses css selectors and xpath now.

Whilst I can had craft css selectors to use the wicketpath attribute I
cannot get the IDE to use this by default. The problem is I want to hand
this over to our QA person but she is not technical nature and would
struggle to understand the correct selector when looking at the code and
also it would really slow down the whole process of setting up tests.

Anyone got Selenium working well, or can recommend another tool for web
regressing testing that works well with Wicket?

thanks

Re: Page is being lost from Session intermittently

[Wayne W]

Thanks

On Thu, Sep 2, 2021 at 3:16 PM Martin Grigorov  wrote:

> On Thu, Sep 2, 2021 at 3:48 PM Wayne W 
> wrote:
>
> > Thanks for the replies.
> > >
> > >
> > > Have you logged everything from the servlet container's session manager
> > to
> > > wicket session management, to identify the logic where loss occurs?
> >
> >
> > Not yet.
> >
> > For example, did you try with different servlet containers if same
> > > problem occurs? Jetty, Tomcat, something else? Just to rule out the
> > servlet
> > > container.
> >
> >
> > I don't really want to go down that road (at least yet)  - the session is
> > not lost, just the page in the session so I would not think it's the
> > container. We've been using Tomcat for years in production.
> >
> >
> > Does it fail on the first ping (after 15 minutes) or later ?
> >
> >
> > No - anything from an hour to 15 hours . There does not seem to be any
> > rhyme to it.
> >
> > If you don't do anything (e.g. in another tab) with the application then
> > > Wicket should not overwrite/remove the disk store for your session.
> >
> >
> > Yes to confirm we are not interacting with the application whilst the
> page
> > is displayed and uploading elsewhere.
> >
> >  NotSerializableExceptions
> >
> >
> > Yes we don't have those so not that.
> >
> >
> > As a workaround you may do your ping to a Wicket Resource, or another
> > > servlet. This will be enough to keep the http session without the extra
> > > logic done in Wicket Ajax requests (resolve a page, resolve the
> component
> > > in the tree, execute the callback method, ...).
> >
> >
> > Thanks for the suggestion. There is a button on the end of the upload
> that
> > interacts with the page, so we would need to rethink the flow to do this.
> > It does feel like a bodge though.
> >
> > Where is the Wicket code is this logic done managing the page in the
> > session?
> >
>
>
> https://github.com/apache/wicket/blob/d1b17b53b3141082c038f4721836488cb38f9083/wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java#L401
>
>
> >
> > Many thanks
> >
> >
> >
> >
> >
> >
> > On Thu, Sep 2, 2021 at 9:41 AM Martin Grigorov 
> > wrote:
> >
> > > Hi,
> > >
> > > On Wed, Sep 1, 2021 at 7:31 PM Wayne W 
> > > wrote:
> > >
> > > > Hello there,
> > > >
> > > > We recently upgraded from Wicket 7.8.0 to 9.4.0 . We are experiencing
> > > > intermittent pages that are being lost from the session.
> > > >
> > > > I can reproduce in production but it takes time and is random. We
> have
> > a
> > > > page where some files can be uploaded to another microservice from
> the
> > > > webpage via an API. We have an AbstractDefaultAjaxBehavior in the
> page
> > > > which gets called every 15 minutes to keep the session alive. This
> has
> > > > always worked well.
> > > >
> > > > I can reproduce by uploading a very large file which can take say 4
> > > hours,
> > > > during this time I do not touch the page, or open any other tabs. The
> > > only
> > > > interaction during this process is the AbstractDefaultAjaxBehavior
> > being
> > > > called every 15 minutes to keep the session alive. We see that
> > > > intermittently the page cannot be found in the session and wicket
> > > > automatically recreates the page again. This coming  from the call to
> > > > the AbstractDefaultAjaxBehavior - we see in the HTTP response headers
> > > that
> > > > wicket adds 'ajax-location: /the-page-we-are-on' and the wicket ajax
> JS
> > > > does a redirect to recreate the page.
> > > >
> > >
> > > Does it fail on the first ping (after 15 minutes) or later ?
> > >
> > >
> > > >
> > > > This kills the upload obviously as the page is refreshed.
> > > >
> > > > What could be causing this and where can I look in the code to
> > understand
> > > > when wicket decides to eject the page from the session? FYI we have
> > > > setMaxSizePerSession
> > > > set at 10MB.
> > > >
> > >
> > > Wicket overwrites the oldest page(s) in the disk store if there are
> many
> > > interactions with other pages.
> > > If

Re: Page is being lost from Session intermittently

[Wayne W]

Thanks for the replies.
>
>
> Have you logged everything from the servlet container's session manager to
> wicket session management, to identify the logic where loss occurs?


Not yet.

For example, did you try with different servlet containers if same
> problem occurs? Jetty, Tomcat, something else? Just to rule out the servlet
> container.


I don't really want to go down that road (at least yet)  - the session is
not lost, just the page in the session so I would not think it's the
container. We've been using Tomcat for years in production.


Does it fail on the first ping (after 15 minutes) or later ?


No - anything from an hour to 15 hours . There does not seem to be any
rhyme to it.

If you don't do anything (e.g. in another tab) with the application then
> Wicket should not overwrite/remove the disk store for your session.


Yes to confirm we are not interacting with the application whilst the page
is displayed and uploading elsewhere.

 NotSerializableExceptions


Yes we don't have those so not that.


As a workaround you may do your ping to a Wicket Resource, or another
> servlet. This will be enough to keep the http session without the extra
> logic done in Wicket Ajax requests (resolve a page, resolve the component
> in the tree, execute the callback method, ...).


Thanks for the suggestion. There is a button on the end of the upload that
interacts with the page, so we would need to rethink the flow to do this.
It does feel like a bodge though.

Where is the Wicket code is this logic done managing the page in the
session?

Many thanks






On Thu, Sep 2, 2021 at 9:41 AM Martin Grigorov  wrote:

> Hi,
>
> On Wed, Sep 1, 2021 at 7:31 PM Wayne W 
> wrote:
>
> > Hello there,
> >
> > We recently upgraded from Wicket 7.8.0 to 9.4.0 . We are experiencing
> > intermittent pages that are being lost from the session.
> >
> > I can reproduce in production but it takes time and is random. We have a
> > page where some files can be uploaded to another microservice from the
> > webpage via an API. We have an AbstractDefaultAjaxBehavior in the page
> > which gets called every 15 minutes to keep the session alive. This has
> > always worked well.
> >
> > I can reproduce by uploading a very large file which can take say 4
> hours,
> > during this time I do not touch the page, or open any other tabs. The
> only
> > interaction during this process is the AbstractDefaultAjaxBehavior being
> > called every 15 minutes to keep the session alive. We see that
> > intermittently the page cannot be found in the session and wicket
> > automatically recreates the page again. This coming  from the call to
> > the AbstractDefaultAjaxBehavior - we see in the HTTP response headers
> that
> > wicket adds 'ajax-location: /the-page-we-are-on' and the wicket ajax JS
> > does a redirect to recreate the page.
> >
>
> Does it fail on the first ping (after 15 minutes) or later ?
>
>
> >
> > This kills the upload obviously as the page is refreshed.
> >
> > What could be causing this and where can I look in the code to understand
> > when wicket decides to eject the page from the session? FYI we have
> > setMaxSizePerSession
> > set at 10MB.
> >
>
> Wicket overwrites the oldest page(s) in the disk store if there are many
> interactions with other pages.
> If you don't do anything (e.g. in another tab) with the application then
> Wicket should not overwrite/remove the disk store for your session.
>
>
> >
> > When does wicket decide to return the ajax-location header?
> >
>
> Wicket does that when it needs to trigger a redirect in an Ajax response.
> The Ajax request cannot find the page instance for some reason and (by
> default) Wicket creates a new instance of the same page class and tells the
> browser to move to it.
>
>
> >
> > It is possible this issue was happening in 7.8 but was not on our radar
> so
> > is unknown.
> >
>
> Most of the time when a page cannot be found in the disk store is because
> there was a problem with its serialization, i.e. it was not stored on the
> disk at all. But in this case you should see some NotSerializableExceptions
> in the server logs.
>
> As a workaround you may do your ping to a Wicket Resource, or another
> servlet. This will be enough to keep the http session without the extra
> logic done in Wicket Ajax requests (resolve a page, resolve the component
> in the tree, execute the callback method, ...).
>
>
>
>
> >
> > Many thanks
> > Wayne
> >
>

Page is being lost from Session intermittently

[Wayne W]

Hello there,

We recently upgraded from Wicket 7.8.0 to 9.4.0 . We are experiencing
intermittent pages that are being lost from the session.

I can reproduce in production but it takes time and is random. We have a
page where some files can be uploaded to another microservice from the
webpage via an API. We have an AbstractDefaultAjaxBehavior in the page
which gets called every 15 minutes to keep the session alive. This has
always worked well.

I can reproduce by uploading a very large file which can take say 4 hours,
during this time I do not touch the page, or open any other tabs. The only
interaction during this process is the AbstractDefaultAjaxBehavior being
called every 15 minutes to keep the session alive. We see that
intermittently the page cannot be found in the session and wicket
automatically recreates the page again. This coming  from the call to
the AbstractDefaultAjaxBehavior - we see in the HTTP response headers that
wicket adds 'ajax-location: /the-page-we-are-on' and the wicket ajax JS
does a redirect to recreate the page.

This kills the upload obviously as the page is refreshed.

What could be causing this and where can I look in the code to understand
when wicket decides to eject the page from the session? FYI we have
setMaxSizePerSession
set at 10MB.

When does wicket decide to return the ajax-location header?

It is possible this issue was happening in 7.8 but was not on our radar so
is unknown.

Many thanks
Wayne

Any CSP migration tips??

[Wayne W]

HI,

We are now looking at migrating to Wicket9 and implementing CSP. However we
have 10,000s of pages on a 13 year old wicket project and the task almost
looks impossible. For example most of our components/panel/pages use inline
style some a fair amount of JS as this was chosen at the start as being the
most manageable way of development and also not downloading unnecessarily
to the end client CSS/JS due to the very large amount of diverse
pages/functionality. We are a very small team of 3.

Has anyone undertaken a similar migration and have any tips on how to make
it less painful or good ways of organizing the CSS/JS? Have to move JS/CSS
to Java, we really want to avoid as much as possible.

Any thoughts welcome.
Thanks

Re: 7.14.0 release

[Wayne W]

Ok thanks. So soon then hopefully!!

On Wed, May 22, 2019 at 3:37 PM Andrea Del Bene 
wrote:

> yes. 8.5.0 and 7.14.0 go hand in hand together :-)
>
> see
>
> http://apache-wicket.1842946.n4.nabble.com/Wicket-8-5-0-ready-td4682248.html
>
> On Wed, May 22, 2019 at 4:27 PM Wayne W 
> wrote:
>
> > Hi,
> >
> > Is there timeframe for this release?
> >
> > Thanks!
> > Wayne
> >
>
>
> --
> Andrea Del Bene.
> Apache Wicket committer.
>

7.14.0 release

[Wayne W]

Hi,

Is there timeframe for this release?

Thanks!
Wayne

Re: Possible memory leak with Tomcat?

[Wayne W]

Hi Martin,

Yes looks like the same issue at least one of them - perhaps the second is
a knock on effect.

When will 7.14.0 be released?

On Tue, May 21, 2019 at 8:44 AM Martin Grigorov 
wrote:

> Hi Wayne,
>
> I think you are facing https://issues.apache.org/jira/browse/WICKET-6639
> It is fixed in 7.14.0 and 8.4.0.
>
> On Mon, May 20, 2019 at 6:48 PM Wayne W 
> wrote:
>
> > Hi Sven,
> >
> > I'm having trouble replicating locally. We just saw it in production and
> > then had to roll back as it was effecting customers.  The log is full of
> > these:
> >
> > May 16, 2019 6:39:39 AM org.apache.catalina.session.StandardSession
> > setAttribute
> > SEVERE: Session binding event listener threw exception
> > java.lang.NullPointerException
> > at
> >
> >
> org.apache.wicket.page.PageStoreManager$SessionEntry.clear(PageStoreManager.java:351)
> > at
> >
> >
> org.apache.wicket.page.PageStoreManager$SessionEntry.valueUnbound(PageStoreManager.java:340)
> > at
> >
> >
> org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1496)
> > at
> >
> >
> org.redisson.tomcat.RedissonSession.superSetAttribute(RedissonSession.java:257)
> > at
> >
> >
> org.redisson.tomcat.RedissonSessionManager$2.onMessage(RedissonSessionManager.java:284)
> > at
> >
> >
> org.redisson.tomcat.RedissonSessionManager$2.onMessage(RedissonSessionManager.java:251)
> > at
> >
> org.redisson.PubSubMessageListener.onMessage(PubSubMessageListener.java:79)
> > at
> >
> >
> org.redisson.client.RedisPubSubConnection.onMessage(RedisPubSubConnection.java:78)
> > at
> >
> >
> org.redisson.client.handler.CommandPubSubDecoder.lambda$enqueueMessage$0(CommandPubSubDecoder.java:184)
> > at
> >
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > at
> >
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > at
> >
> >
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> > at java.lang.Thread.run(Thread.java:745)
> >
> >
> > Then about 2 hours later a huge number of these started to appear in the
> > logs:
> >
> > 2019-05-16 08:52:47,851 ERROR - Wicket-PageSavingThread
> >
> >
> org.apache.wicket.pageStore.DiskDataStore$SessionEntry.getFileChannel(DiskDataStore.java:434)
> > 434 DiskDataStore  -
> >
> >
> /ec/var/tomcat/gc1/work2/ROOT/wicket.hub-filestore/5168/1931/547BB9E7E255B16D5B2864F42B4F9C28.gc1/data
> > (No such file or directory)
> > java.io.FileNotFoundException:
> >
> >
> /ec/var/tomcat/gc1/work2/ROOT/wicket.hub-filestore/5168/1931/547BB9E7E255B16D5B2864F42B4F9C28.gc1/data
> > (No such file or directory)
> > at java.io.RandomAccessFile.open0(Native Method)
> > at java.io.RandomAccessFile.open(RandomAccessFile.java:316)
> > at java.io.RandomAccessFile.(RandomAccessFile.java:243)
> > at
> >
> >
> org.apache.wicket.pageStore.DiskDataStore$SessionEntry.getFileChannel(DiskDataStore.java:428)
> > at
> >
> >
> org.apache.wicket.pageStore.DiskDataStore$SessionEntry.savePage(DiskDataStore.java:346)
> > at
> >
> org.apache.wicket.pageStore.DiskDataStore.storeData(DiskDataStore.java:185)
> > at
> >
> >
> org.apache.wicket.pageStore.AsynchronousDataStore$PageSavingRunnable.run(AsynchronousDataStore.java:355)
> > at java.lang.Thread.run(Thread.java:745)
> >
> >
> > Whats odd is that it effected some user but not others at all. When we
> > rollback to 7.8.0 these go away. I'm not sure how I'm going to get the
> the
> > bottom of this
> >
> >
> >
> >
> > On Fri, May 17, 2019 at 11:03 PM Sven Meier  wrote:
> >
> > > Hi,
> > >
> > > WICKET-6564 was about applications explicitly calling #clear() on the
> > > PageStoreManager.
> > > This doesn't has anything to do with session expiration.
> > >
> > > Could you please explain what issues you're facing? A quickstart would
> > > be perfect, or at least some explanations how we're able to reproduce
> > > the problem.
> > >
> > > Regards
> > > Sven
> > >
> > >
> > > Am 17.05.19 um 13:23 schrieb Wayne W:
> > > > Hello Sven,
> > > >
> > > > the fix you did for WICKET-6564 (
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=wicket.git;a=commitdif

Re: Possible memory leak with Tomcat?

[Wayne W]

Hi Sven,

I'm having trouble replicating locally. We just saw it in production and
then had to roll back as it was effecting customers.  The log is full of
these:

May 16, 2019 6:39:39 AM org.apache.catalina.session.StandardSession
setAttribute
SEVERE: Session binding event listener threw exception
java.lang.NullPointerException
at
org.apache.wicket.page.PageStoreManager$SessionEntry.clear(PageStoreManager.java:351)
at
org.apache.wicket.page.PageStoreManager$SessionEntry.valueUnbound(PageStoreManager.java:340)
at
org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1496)
at
org.redisson.tomcat.RedissonSession.superSetAttribute(RedissonSession.java:257)
at
org.redisson.tomcat.RedissonSessionManager$2.onMessage(RedissonSessionManager.java:284)
at
org.redisson.tomcat.RedissonSessionManager$2.onMessage(RedissonSessionManager.java:251)
at
org.redisson.PubSubMessageListener.onMessage(PubSubMessageListener.java:79)
at
org.redisson.client.RedisPubSubConnection.onMessage(RedisPubSubConnection.java:78)
at
org.redisson.client.handler.CommandPubSubDecoder.lambda$enqueueMessage$0(CommandPubSubDecoder.java:184)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:745)


Then about 2 hours later a huge number of these started to appear in the
logs:

2019-05-16 08:52:47,851 ERROR - Wicket-PageSavingThread
org.apache.wicket.pageStore.DiskDataStore$SessionEntry.getFileChannel(DiskDataStore.java:434)
434 DiskDataStore  -
/ec/var/tomcat/gc1/work2/ROOT/wicket.hub-filestore/5168/1931/547BB9E7E255B16D5B2864F42B4F9C28.gc1/data
(No such file or directory)
java.io.FileNotFoundException:
/ec/var/tomcat/gc1/work2/ROOT/wicket.hub-filestore/5168/1931/547BB9E7E255B16D5B2864F42B4F9C28.gc1/data
(No such file or directory)
at java.io.RandomAccessFile.open0(Native Method)
at java.io.RandomAccessFile.open(RandomAccessFile.java:316)
at java.io.RandomAccessFile.(RandomAccessFile.java:243)
at
org.apache.wicket.pageStore.DiskDataStore$SessionEntry.getFileChannel(DiskDataStore.java:428)
at
org.apache.wicket.pageStore.DiskDataStore$SessionEntry.savePage(DiskDataStore.java:346)
at
org.apache.wicket.pageStore.DiskDataStore.storeData(DiskDataStore.java:185)
at
org.apache.wicket.pageStore.AsynchronousDataStore$PageSavingRunnable.run(AsynchronousDataStore.java:355)
at java.lang.Thread.run(Thread.java:745)


Whats odd is that it effected some user but not others at all. When we
rollback to 7.8.0 these go away. I'm not sure how I'm going to get the the
bottom of this




On Fri, May 17, 2019 at 11:03 PM Sven Meier  wrote:

> Hi,
>
> WICKET-6564 was about applications explicitly calling #clear() on the
> PageStoreManager.
> This doesn't has anything to do with session expiration.
>
> Could you please explain what issues you're facing? A quickstart would
> be perfect, or at least some explanations how we're able to reproduce
> the problem.
>
> Regards
> Sven
>
>
> Am 17.05.19 um 13:23 schrieb Wayne W:
> > Hello Sven,
> >
> > the fix you did for WICKET-6564 (
> >
> https://git-wip-us.apache.org/repos/asf?p=wicket.git;a=commitdiff;h=7665dc5;hp=3a1602d308a366e00948dbf91dbd96bc40cae167
> )
> > doesn't work for us. Its causing lots of issues. We use redisson for
> > managing our sessions in tomcat, so that we can failover without loosing
> > user session.
> >
> > When a session attribute is updated redisson calls setAttribute on the
> > session. Looking at the code for
> > org.apache.catalina.session.StandardSession.setAttribute I see:
> >
> > // Replace or add this attribute
> >
> >  Object unbound = attributes.put(name, value);
> >
> >
> >  // Call the valueUnbound() method if necessary
> >
> >  *if* (notify && (unbound != *null*) && (unbound != value) &&
> >
> >  (unbound *instanceof* HttpSessionBindingListener)) {
> >
> >  *try* {
> >
> >  ((HttpSessionBindingListener) unbound).valueUnbound
> >
> >  (*new* HttpSessionBindingEvent(getSession(), name));
> >
> >  } *catch* (Throwable t) {
> >
> >  ExceptionUtils.*handleThrowable*(t);
> >
> >  manager.getContext().getLogger().error
> >
> >  (*sm*.getString("standardSession.bindingEvent"), t);
> >
> >  }
> >
> >  }
> >
> > The valueUnbound is call to notify the object its no longer in the
> session.
> > However looking at the change you

Re: Possible memory leak with Tomcat?

[Wayne W]

Hello Sven,

the fix you did for WICKET-6564 (
https://git-wip-us.apache.org/repos/asf?p=wicket.git;a=commitdiff;h=7665dc5;hp=3a1602d308a366e00948dbf91dbd96bc40cae167)
doesn't work for us. Its causing lots of issues. We use redisson for
managing our sessions in tomcat, so that we can failover without loosing
user session.

When a session attribute is updated redisson calls setAttribute on the
session. Looking at the code for
org.apache.catalina.session.StandardSession.setAttribute I see:

// Replace or add this attribute

Object unbound = attributes.put(name, value);


// Call the valueUnbound() method if necessary

*if* (notify && (unbound != *null*) && (unbound != value) &&

(unbound *instanceof* HttpSessionBindingListener)) {

*try* {

((HttpSessionBindingListener) unbound).valueUnbound

(*new* HttpSessionBindingEvent(getSession(), name));

} *catch* (Throwable t) {

ExceptionUtils.*handleThrowable*(t);

manager.getContext().getLogger().error

(*sm*.getString("standardSession.bindingEvent"), t);

}

}

The valueUnbound is call to notify the object its no longer in the session.
However looking at the change you did for
PageStoreManager.valueUnbound its actually
removing the session by calling clear()

Doesn't seem correct?? or am I missing something?



On Fri, May 10, 2019 at 1:43 PM Wayne W  wrote:

> Thanks Sven.
>
> On Thu, May 9, 2019 at 8:24 PM Sven Meier  wrote:
>
>> Hi,
>>
>> we've had two fixed related to page stores (WICKET-6457, WICKET-6564) so
>> please upgrade to 7.13.0 first.
>>
>> Have fun
>> Sven
>>
>>
>> Am 09.05.19 um 21:10 schrieb Wayne W:
>> > Hi,
>> >
>> > I've take a memory dump of one of our production instances and I'm
>> seeing
>> > about 500MB of memory consumed just by the DiskDataStore which doesn't
>> seem
>> > correct to me. Here is a screen shot:
>> >
>> https://customerservices.glasscubes.com/share/s/qmvnvrdtm36amme6sdrqg4dp2g
>> >
>> > I've highlighted the item - 524,288 items doesn't seem correct for ~500
>> > http sessions?. It seems to me that removeData(*final* String
>> sessionId) is
>> > probably not being called and clearing up the sessionEntryMap. Looking
>> at
>> > the call hierarchy I can see how Jetty calls it but I cannot see how
>> tomcat
>> > is calling it.
>> >
>> > Any ideas whats happening?
>> > Wicket 7.8.0, Tomcat 8.0.32
>> >
>> > Thanks
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>

Re: Possible memory leak with Tomcat?

[Wayne W]

Thanks Sven.

On Thu, May 9, 2019 at 8:24 PM Sven Meier  wrote:

> Hi,
>
> we've had two fixed related to page stores (WICKET-6457, WICKET-6564) so
> please upgrade to 7.13.0 first.
>
> Have fun
> Sven
>
>
> Am 09.05.19 um 21:10 schrieb Wayne W:
> > Hi,
> >
> > I've take a memory dump of one of our production instances and I'm seeing
> > about 500MB of memory consumed just by the DiskDataStore which doesn't
> seem
> > correct to me. Here is a screen shot:
> >
> https://customerservices.glasscubes.com/share/s/qmvnvrdtm36amme6sdrqg4dp2g
> >
> > I've highlighted the item - 524,288 items doesn't seem correct for ~500
> > http sessions?. It seems to me that removeData(*final* String sessionId)
> is
> > probably not being called and clearing up the sessionEntryMap. Looking at
> > the call hierarchy I can see how Jetty calls it but I cannot see how
> tomcat
> > is calling it.
> >
> > Any ideas whats happening?
> > Wicket 7.8.0, Tomcat 8.0.32
> >
> > Thanks
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Possible memory leak with Tomcat?

[Wayne W]

Hi,

I've take a memory dump of one of our production instances and I'm seeing
about 500MB of memory consumed just by the DiskDataStore which doesn't seem
correct to me. Here is a screen shot:
https://customerservices.glasscubes.com/share/s/qmvnvrdtm36amme6sdrqg4dp2g

I've highlighted the item - 524,288 items doesn't seem correct for ~500
http sessions?. It seems to me that removeData(*final* String sessionId) is
probably not being called and clearing up the sessionEntryMap. Looking at
the call hierarchy I can see how Jetty calls it but I cannot see how tomcat
is calling it.

Any ideas whats happening?
Wicket 7.8.0, Tomcat 8.0.32

Thanks

getOutputStream() has already been called for this response

[Wayne W]

Hi,

we have a lot of these in our production logs:

java.lang.IllegalStateException: getOutputStream() has already been called
for this response
at
org.apache.catalina.connector.Response.getWriter(Response.java:578)
at
org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:212)
at
javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:109)
at
org.apache.wicket.protocol.http.servlet.ServletWebResponse.write(ServletWebResponse.java:110)
at
org.apache.wicket.protocol.http.HeaderBufferingWebResponse.write(HeaderBufferingWebResponse.java:179)
at
org.apache.wicket.protocol.http.BufferedWebResponse$WriteCharSequenceAction.invoke(BufferedWebResponse.java:171)
at
org.apache.wicket.protocol.http.BufferedWebResponse.writeTo(BufferedWebResponse.java:602)
at
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:198)
at
org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
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.executeExceptionRequestHandler(RequestCycle.java:314)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:237)
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.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)


What cab cause these and what should we do?

We also get lots of these (but not as many)

java.lang.IllegalStateException: Cannot call sendRedirect() after the
response has been committed
at
org.apache.catalina.connector.ResponseFacade.sendRedirect(ResponseFacade.java:494)
at
javax.servlet.http.HttpServletResponseWrapper.sendRedirect(HttpServletResponseWrapper.java:138)
at
hub.app.servlet.RelativeUrlFilter$RelativeUrlServletResponseFilter.sendRedirect(RelativeUrlFilter.java:111)
at
org.apache.wicket.protocol.http.servlet.ServletWebResponse.sendRedirect(ServletWebResponse.java:288)
at
org.apache.wicket.protocol.http.HeaderBufferingWebResponse.sendRedirect(HeaderBufferingWebResponse.java:117)
at
org.apache.wicket.request.handler.render.WebPageRenderer.redirectTo(WebPageRenderer.java:161)
at
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:280)
at
org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
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.executeExceptionRequestHandler(RequestCycle.java:314)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:237)
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.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at

Re: Very slow shutdown at org.apache.wicket.pageStore.AbstractPageStore.destroy

[Wayne W]

HI Martin,

no changes which is odd. I can;t be certain 100% when this behaviour
started. Perhaps when we changed to 7.8.0 a while back, but I'm pretty sure
its only be happening the last week or so.
Is this code basically saving all the sessions to disk on shutdown? Is this
necessary given replication is configured as all sessions are replicate
when it starts up?

thanks


On Tue, Sep 26, 2017 at 10:07 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> On Tue, Sep 26, 2017 at 10:35 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hi,
> >
> > we've started to experience very slow shutdown of our tomcat instances in
> > production. Doing a thread dump I see:
> >
> > "localhost-startStop-2" #14871 daemon prio=5 os_prio=64
> > tid=0x06700800 nid=0x3a37 runnable [0xfcffcc5fd000]
> >java.lang.Thread.State: RUNNABLE
> > at java.io.FileOutputStream.writeBytes(Native Method)
> > at java.io.FileOutputStream.write(FileOutputStream.java:326)
> > at
> > java.io.ObjectOutputStream$BlockDataOutputStream.drain(
> > ObjectOutputStream.java:1877)
> > at
> > java.io.ObjectOutputStream$BlockDataOutputStream.write(
> > ObjectOutputStream.java:1841)
> > at
> > java.io.ObjectOutputStream.defaultWriteFields(
> > ObjectOutputStream.java:1534)
> > at
> > java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> > at
> > java.io.ObjectOutputStream.writeOrdinaryObject(
> > ObjectOutputStream.java:1432)
> > at
> > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> > at
> > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> > at java.util.HashMap.internalWriteEntries(HashMap.java:1785)
> > at java.util.HashMap.writeObject(HashMap.java:1362)
> > at sun.reflect.GeneratedMethodAccessor299.invoke(Unknown Source)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:498)
> > at
> > java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
> > at
> > java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> > at
> > java.io.ObjectOutputStream.writeOrdinaryObject(
> > ObjectOutputStream.java:1432)
> > at
> > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> > at
> > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> > at
> > org.apache.wicket.pageStore.DiskDataStore.saveIndex(
> > DiskDataStore.java:270)
> > at
> > org.apache.wicket.pageStore.DiskDataStore.destroy(
> DiskDataStore.java:106)
> > at
> > org.apache.wicket.pageStore.AsynchronousDataStore.destroy(
> > AsynchronousDataStore.java:118)
> > at
> > org.apache.wicket.pageStore.AbstractPageStore.destroy(
> > AbstractPageStore.java:53)
> > at
> > org.apache.wicket.pageStore.AbstractCachingPageStore.destroy(
> > AbstractCachingPageStore.java:102)
> > at
> > org.apache.wicket.page.PageStoreManager.destroy(
> PageStoreManager.java:464)
> > at
> > org.apache.wicket.Application.internalDestroy(Application.java:798)
> > at
> > org.apache.wicket.protocol.http.WebApplication.internalDestroy(
> > WebApplication.java:703)
> > at
> > org.apache.wicket.protocol.http.WicketFilter.destroy(
> > WicketFilter.java:612)
> > at
> > org.apache.catalina.core.ApplicationFilterConfig.release(
> > ApplicationFilterConfig.java:313)
> > at
> > org.apache.catalina.core.StandardContext.filterStop(
> > StandardContext.java:4600)
> > - locked <0x000703c91570> (a java.util.HashMap)
> > at
> > org.apache.catalina.core.StandardContext.stopInternal(
> > StandardContext.java:5362)
> > - locked <0x000703c91368> (a
> > org.apache.catalina.core.StandardContext)
> > at
> > org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
> > - locked <0x000703c91368> (a
> > org.apache.catalina.core.StandardContext)
> > at
> > org.apache.catalina.core.ContainerBase$StopChild.call(
> > ContainerBase.java:1425)
> > at
> > org.apache.catalina.core.ContainerBase$StopChild.call(
> > ContainerBase.java:1414)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > at java.lang.Thread.run(Thread.java:745)
> >
> >
> > We do have replication setup, but I'm sure that this has only just
> started
> > happening in the last week or so. What could cause this and is there
> > anything I could do?
> >
>
> Did you change anything in the last week ?
> Did you upgrade Wicket ? To which version ?
>

Very slow shutdown at org.apache.wicket.pageStore.AbstractPageStore.destroy

[Wayne W]

Hi,

we've started to experience very slow shutdown of our tomcat instances in
production. Doing a thread dump I see:

"localhost-startStop-2" #14871 daemon prio=5 os_prio=64
tid=0x06700800 nid=0x3a37 runnable [0xfcffcc5fd000]
   java.lang.Thread.State: RUNNABLE
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:326)
at
java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1877)
at
java.io.ObjectOutputStream$BlockDataOutputStream.write(ObjectOutputStream.java:1841)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1534)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at java.util.HashMap.internalWriteEntries(HashMap.java:1785)
at java.util.HashMap.writeObject(HashMap.java:1362)
at sun.reflect.GeneratedMethodAccessor299.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at
org.apache.wicket.pageStore.DiskDataStore.saveIndex(DiskDataStore.java:270)
at
org.apache.wicket.pageStore.DiskDataStore.destroy(DiskDataStore.java:106)
at
org.apache.wicket.pageStore.AsynchronousDataStore.destroy(AsynchronousDataStore.java:118)
at
org.apache.wicket.pageStore.AbstractPageStore.destroy(AbstractPageStore.java:53)
at
org.apache.wicket.pageStore.AbstractCachingPageStore.destroy(AbstractCachingPageStore.java:102)
at
org.apache.wicket.page.PageStoreManager.destroy(PageStoreManager.java:464)
at
org.apache.wicket.Application.internalDestroy(Application.java:798)
at
org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:703)
at
org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:612)
at
org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:313)
at
org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:4600)
- locked <0x000703c91570> (a java.util.HashMap)
at
org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5362)
- locked <0x000703c91368> (a
org.apache.catalina.core.StandardContext)
at
org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
- locked <0x000703c91368> (a
org.apache.catalina.core.StandardContext)
at
org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1425)
at
org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1414)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)


We do have replication setup, but I'm sure that this has only just started
happening in the last week or so. What could cause this and is there
anything I could do?

Re: CsrfPreventionRequestCycleListener or alternative CSRF protection

[Wayne W]

Hi Maxim, what are you using? CsrfPreventionRequestCycleListener?

On Tue, Sep 19, 2017 at 2:23 PM, Maxim Solodovnik <solomax...@gmail.com>
wrote:

> It works for us, but we are not using *CryptMapper's ...
>
> On Tue, Sep 19, 2017 at 7:49 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
> > Hi,
> >
> > does anyone else have an ideas whats I could do here. Is there anyone out
> > there who's successfully got the CSRF protection up and running in
> > production?
> >
> > On Fri, Sep 8, 2017 at 10:31 AM, Wayne W <waynemailingli...@gmail.com>
> > wrote:
> >
> >> Thanks Martin,
> >>
> >> so I've used this:
> >>
> >> setRootRequestMapper(new PostUrlCryptMapper(getRootRequestMapper(), new
> >> KeyInSessionSunJceCryptFactory()));
> >>
> >>
> >> public class PostUrlCryptMapper extends CryptoMapper {
> >>
> >> /**
> >>
> >>  * @param wrappedMapper
> >>
> >>  * @param cryptFactory
> >>
> >>  */
> >>
> >> private static Log log = LogFactory.getLog(PostUrlCryptMapper.class);
> >>
> >> public PostUrlCryptMapper(IRequestMapper wrappedMapper,
> >>
> >>   final KeyInSessionSunJceCryptFactory
> >> cryptFactory) {
> >>
> >> super(wrappedMapper, new IProvider() {
> >>
> >> @Override
> >>
> >> public ICrypt get() {
> >>
> >> return cryptFactory.newCrypt();
> >>
> >> }
> >>
> >> });
> >>
> >> }
> >>
> >>
> >> public Url mapHandler(final IRequestHandler requestHandler)
> >>
> >> {
> >>
> >> if (isFormListenerInterfaceRequestHandler(requestHandler)) {
> >>
> >> return super.mapHandler(requestHandler);
> >>
> >> } else {
> >>
> >> return getDelegateMapper().mapHandler(requestHandler);
> >>
> >> }
> >>
> >> }
> >>
> >>
> >> public IRequestHandler mapRequest(final Request request)
> >>
> >> {
> >>
> >> final IRequestHandler requestHandler = getDelegateMapper().
> >> mapRequest(request);
> >>
> >> if (requestHandler == null) {
> >>
> >> return super.mapRequest(request);
> >>
> >> }
> >>
> >> return requestHandler;
> >>
> >> }
> >>
> >>
> >> /**
> >>
> >>  * Returns true, whether the attached component to
> >> ListenerInterfaceRequestHandler is in form container.
> >>
> >>  * @param requestHandler
> >>
> >>  * @return
> >>
> >>  */
> >>
> >> private boolean isFormListenerInterfaceRequestHandler(final
> >> IRequestHandler requestHandler) {
> >>
> >> if (requestHandler instanceof ListenerInterfaceRequestHandler)
> {
> >>
> >> ListenerInterfaceRequestHandler
> >> listenerInterfaceRequestHandler = (ListenerInterfaceRequestHandler)
> >> requestHandler;
> >>
> >> IRequestableComponent c = listenerInterfaceRequestHandler
> >> .getComponent();
> >>
> >> if (c instanceof Form) {
> >>
> >> log.info("Form found!");
> >>
> >> return true;
> >>
> >> }
> >>
> >> }
> >>
> >> //else  if (requestHandler instanceof
> >> BookmarkableListenerInterfaceRequestHandler) {
> >>
> >> //BookmarkableListenerInterfaceRequestHandler  handler = (
> >> BookmarkableListenerInterfaceRequestHandler) requestHandler;
> >>
> >> //IRequestableComponent c = handler.getComponent();
> >>
> >> //if (c instanceof Form) {
> >>
> >> //log.info("Form found!");
> >>
> >> //return true;
> >>
> >> //}
> >>
> >> //}
> >>
> >>
> >>
> >>
> >>
> >>
> >> return false;
> >>
> >> }
> >>
> >> }
> >>
> >>
> >> However what I am finding is

Re: CsrfPreventionRequestCycleListener or alternative CSRF protection

[Wayne W]

Hi,

does anyone else have an ideas whats I could do here. Is there anyone out
there who's successfully got the CSRF protection up and running in
production?

On Fri, Sep 8, 2017 at 10:31 AM, Wayne W <waynemailingli...@gmail.com>
wrote:

> Thanks Martin,
>
> so I've used this:
>
> setRootRequestMapper(new PostUrlCryptMapper(getRootRequestMapper(), new
> KeyInSessionSunJceCryptFactory()));
>
>
> public class PostUrlCryptMapper extends CryptoMapper {
>
> /**
>
>  * @param wrappedMapper
>
>  * @param cryptFactory
>
>  */
>
> private static Log log = LogFactory.getLog(PostUrlCryptMapper.class);
>
> public PostUrlCryptMapper(IRequestMapper wrappedMapper,
>
>   final KeyInSessionSunJceCryptFactory
> cryptFactory) {
>
> super(wrappedMapper, new IProvider() {
>
> @Override
>
> public ICrypt get() {
>
> return cryptFactory.newCrypt();
>
> }
>
> });
>
> }
>
>
> public Url mapHandler(final IRequestHandler requestHandler)
>
> {
>
> if (isFormListenerInterfaceRequestHandler(requestHandler)) {
>
> return super.mapHandler(requestHandler);
>
> } else {
>
> return getDelegateMapper().mapHandler(requestHandler);
>
> }
>
> }
>
>
> public IRequestHandler mapRequest(final Request request)
>
> {
>
> final IRequestHandler requestHandler = getDelegateMapper().
> mapRequest(request);
>
> if (requestHandler == null) {
>
> return super.mapRequest(request);
>
> }
>
> return requestHandler;
>
> }
>
>
> /**
>
>  * Returns true, whether the attached component to
> ListenerInterfaceRequestHandler is in form container.
>
>  * @param requestHandler
>
>  * @return
>
>  */
>
> private boolean isFormListenerInterfaceRequestHandler(final
> IRequestHandler requestHandler) {
>
> if (requestHandler instanceof ListenerInterfaceRequestHandler) {
>
> ListenerInterfaceRequestHandler
> listenerInterfaceRequestHandler = (ListenerInterfaceRequestHandler)
> requestHandler;
>
> IRequestableComponent c = listenerInterfaceRequestHandler
> .getComponent();
>
> if (c instanceof Form) {
>
> log.info("Form found!");
>
> return true;
>
> }
>
> }
>
> //else  if (requestHandler instanceof
> BookmarkableListenerInterfaceRequestHandler) {
>
> //BookmarkableListenerInterfaceRequestHandler  handler = (
> BookmarkableListenerInterfaceRequestHandler) requestHandler;
>
> //IRequestableComponent c = handler.getComponent();
>
> //if (c instanceof Form) {
>
> //log.info("Form found!");
>
> //return true;
>
> //}
>
> //}
>
>
>
>
>
>
> return false;
>
> }
>
> }
>
>
> However what I am finding is that any form on a stateless/bookmarkable
> page are not being encrypted. I tried to work around this with the section
> of code thats commented out (BookmarkableListenerInterfaceRequestHandler)
> . This then encrypts the form action fine, but then I get 2 bits of odd
> behaviour:
>
>
> - On pages that are bookmarkable, if there is a constructor that has
> PageParameters, the page is just recreated and the submit is ignored (when
> pressing submit).If I remove the PageParameter constructor then it works
> fine.
>
> - On stateless pages , again when submitting the form it just recreates
> the page
>
>
> public class SomeLoginPage extends WebPage {
>
>
> public SomeLoginPage() {
>
> setStatelessHint(true);
>
> add(new FeedbackPanel("feedback"));
>
> add(new SignInForm("signInForm").setOutputMarkupId(false));
>
>
> }
>
>
> public final class SignInForm extends StatelessForm {
>
>
> public SignInForm(final String id) {
>
> super(id, new CompoundPropertyModel(new ValueMap()));
>
>
> add(new TextField("username").setOutputMarkupId(false));
>
> add(new PasswordTextField("password").setOutputMarkupId(false));
>
> }
>
>
> /**
>
> *
>
> * @see org.apache.wicket.markup.html.form.Form#onSubmit()
>
> */
>
>
> public void onSubmit() {
>
> ValueMap values = getModelObject();
>
> String username = values.getString("username");
>
> String password = values.getString("

Re: CsrfPreventionRequestCycleListener or alternative CSRF protection

[Wayne W]

Thanks Martin,

so I've used this:

setRootRequestMapper(new PostUrlCryptMapper(getRootRequestMapper(), new
KeyInSessionSunJceCryptFactory()));


public class PostUrlCryptMapper extends CryptoMapper {

/**

 * @param wrappedMapper

 * @param cryptFactory

 */

private static Log log = LogFactory.getLog(PostUrlCryptMapper.class);

public PostUrlCryptMapper(IRequestMapper wrappedMapper,

  final KeyInSessionSunJceCryptFactory
cryptFactory) {

super(wrappedMapper, new IProvider() {

@Override

public ICrypt get() {

return cryptFactory.newCrypt();

}

});

}


public Url mapHandler(final IRequestHandler requestHandler)

{

if (isFormListenerInterfaceRequestHandler(requestHandler)) {

return super.mapHandler(requestHandler);

} else {

return getDelegateMapper().mapHandler(requestHandler);

}

}


public IRequestHandler mapRequest(final Request request)

{

final IRequestHandler requestHandler =
getDelegateMapper().mapRequest(request);

if (requestHandler == null) {

return super.mapRequest(request);

}

return requestHandler;

}


/**

 * Returns true, whether the attached component to
ListenerInterfaceRequestHandler is in form container.

 * @param requestHandler

 * @return

 */

private boolean isFormListenerInterfaceRequestHandler(final
IRequestHandler requestHandler) {

if (requestHandler instanceof ListenerInterfaceRequestHandler) {

ListenerInterfaceRequestHandler  listenerInterfaceRequestHandler
= (ListenerInterfaceRequestHandler) requestHandler;

IRequestableComponent c = listenerInterfaceRequestHandler
.getComponent();

if (c instanceof Form) {

log.info("Form found!");

return true;

}

}

//else  if (requestHandler instanceof
BookmarkableListenerInterfaceRequestHandler) {

//BookmarkableListenerInterfaceRequestHandler  handler =
(BookmarkableListenerInterfaceRequestHandler) requestHandler;

//IRequestableComponent c = handler.getComponent();

//if (c instanceof Form) {

//log.info("Form found!");

//return true;

//}

//}






return false;

}

}


However what I am finding is that any form on a stateless/bookmarkable page
are not being encrypted. I tried to work around this with the section of
code thats commented out (BookmarkableListenerInterfaceRequestHandler) .
This then encrypts the form action fine, but then I get 2 bits of odd
behaviour:


- On pages that are bookmarkable, if there is a constructor that has
PageParameters, the page is just recreated and the submit is ignored (when
pressing submit).If I remove the PageParameter constructor then it works
fine.

- On stateless pages , again when submitting the form it just recreates the
page


public class SomeLoginPage extends WebPage {


public SomeLoginPage() {

setStatelessHint(true);

add(new FeedbackPanel("feedback"));

add(new SignInForm("signInForm").setOutputMarkupId(false));


}


public final class SignInForm extends StatelessForm {


public SignInForm(final String id) {

super(id, new CompoundPropertyModel(new ValueMap()));


add(new TextField("username").setOutputMarkupId(false));

add(new PasswordTextField("password").setOutputMarkupId(false));

}


/**

*

* @see org.apache.wicket.markup.html.form.Form#onSubmit()

*/


public void onSubmit() {

ValueMap values = getModelObject();

String username = values.getString("username");

String password = values.getString("password");


if (signIn(username, password)) {

((HubSession) Session.get()).setAdminAthenticated(true);

ContextUtil.get().setUser(null);


setResponsePage(CompanyAdminPage.class);


} else {

// Try the component based localizer first. If not found try the

// application localizer. Else use the default

error(getLocalizer().getString("exception.login", this, "Illegal username
password combo"));

}

}


private boolean signIn(String username, String password) {

// TODO authentication

return false;

}


}


}



Any ideas?



On Thu, Sep 7, 2017 at 11:33 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandle
> r#getComponent()
> instanceOf Form
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Sep 7, 2017 at 11:04 AM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Thanks Martin,
> >
> > how can I tell for example if the IPageClassRequestHandler or
> > ListenerInterfaceRequestHandler is for a form?
> >
> > On Wed, Sep 6, 2017 at 12:39 PM, Martin Grigorov <mgrig

Re: CsrfPreventionRequestCycleListener or alternative CSRF protection

[Wayne W]

Thanks Martin,

how can I tell for example if the IPageClassRequestHandler or
ListenerInterfaceRequestHandler is for a form?

On Wed, Sep 6, 2017 at 12:39 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> I don't use any of these so I have no much experience in production with
> them!
>
> On Wed, Sep 6, 2017 at 12:07 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I've been trying to use CsrfPreventionRequestCycleListener in
> production.
> > However we are seeing in the logs that about 30 times a day we get the
> > request aborted because the clients browsers are not sending the referrer
> > header sometimes. Doing some research it seems we cannot rely on the
> > clients browser to send the referrer and it could be somewhat buggy in
> > older browsers.
> >
> > Does anyone else experience this trouble?
> >
> > Are there any alternatives?
> >
> > I did try:
> >
> > getSecuritySettings().setCryptFactory(new KeyInSessionSunJceCryptFactory
> > ());
> >
> > setRootRequestMapper(new CryptoMapper(getRootRequestMapperAsCompound(),
> > this));
> >
> > However this encrypts everything (resources, urls, etc). Is there a way
> of
> > just encrypting say forms and links or something?
> >
>
> You can override CryptoMapper#mapHandler() and call super.mapHandler() only
> when the IRequestHandler is not an instance of IPageClassRequestHandler or
> only when it is ListenerInterfaceRequestHandler.
>
>
> >
> > Anyone got a solution that works for them in production?
> >
> > many thanks
> >
>

CsrfPreventionRequestCycleListener or alternative CSRF protection

[Wayne W]

Hi,

I've been trying to use CsrfPreventionRequestCycleListener in production.
However we are seeing in the logs that about 30 times a day we get the
request aborted because the clients browsers are not sending the referrer
header sometimes. Doing some research it seems we cannot rely on the
clients browser to send the referrer and it could be somewhat buggy in
older browsers.

Does anyone else experience this trouble?

Are there any alternatives?

I did try:

getSecuritySettings().setCryptFactory(new KeyInSessionSunJceCryptFactory());

setRootRequestMapper(new CryptoMapper(getRootRequestMapperAsCompound(),
this));

However this encrypts everything (resources, urls, etc). Is there a way of
just encrypting say forms and links or something?

Anyone got a solution that works for them in production?

many thanks

Re: NPE in org.apache.wicket.request.http.handler.RedirectRequestHandler.respond

[Wayne W]

Thanks Martin,

I've put logging everywhere but still can't track it down. Its just this
jetty instance causing not, not sure why. I'm going to side step the issue
and upgrade to 7.8.10 as I need that replication fix live asap.

Many thanks

On Wed, Jul 26, 2017 at 11:51 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> I've added a check for 7.x and 8.x -
> https://git1-us-west.apache.org/repos/asf?p=wicket.git;a=
> commitdiff;h=5f3fc484;hp=3ec2c617f1e27f06df985032e233ca4799097b26
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Jul 26, 2017 at 1:48 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
> > https://github.com/apache/wicket/blob/wicket-6.17.0/
> > wicket-request/src/main/java/org/apache/wicket/request/http/handler/
> > RedirectRequestHandler.java#L99 says that getRedirectUrl() returns null.
> > So something calls RedirectRequestHandler's constructor with null url.
> > Wicket doesn't instantiate this class for its needs, so it should be your
> > application.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Wed, Jul 26, 2017 at 10:15 AM, Wayne W <waynemailingli...@gmail.com>
> > wrote:
> >
> >> Still on 6.17.0 Martin. Not had the time/resources to move to 6.18
> which I
> >> want because of that replication fix!!
> >>
> >> On Tue, Jul 25, 2017 at 7:55 PM, Martin Grigorov <mgrigo...@apache.org>
> >> wrote:
> >>
> >> > Which version of Wicket do you use ?
> >> >
> >> > Martin Grigorov
> >> > Wicket Training and Consulting
> >> > https://twitter.com/mtgrigorov
> >> >
> >> > On Tue, Jul 25, 2017 at 5:52 PM, Wayne W <waynemailingli...@gmail.com
> >
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > I've got a strange issue I cannot get to the bottom of. Basically we
> >> have
> >> > > our app deployed on jetty 9.2.1 with apache 2.4 in front. If I make
> >> calls
> >> > > to stateless pages its all good. However as soon as I try to make a
> >> call
> >> > to
> >> > > a stateful page it does a 302 to the login page for our app, but
> then
> >> > just
> >> > > gets stuck in a 302 loop redirection loop. Looking at the server
> logs
> >> its
> >> > > full of this with no other exception - each track trace corresponds
> to
> >> > > another 302 redirect. Each redirect is trying to get to our login
> >> page:
> >> > >
> >> > >
> >> > > 2017-07-25 14:40:18,989 ERROR -
> >> > > org.apache.wicket.DefaultExceptionMapper.internalMap(
> >> > > DefaultExceptionMapper.java:129)
> >> > > 129 DefaultExceptionMapper - Unexpected error occurred
> >> > > java.lang.NullPointerException
> >> > > at
> >> > > org.apache.wicket.request.http.handler.RedirectRequestHandle
> >> r.respond(
> >> > > RedirectRequestHandler.java:99)
> >> > > at
> >> > > org.apache.wicket.request.cycle.RequestCycle$
> HandlerExecutor.respond(
> >> > > RequestCycle.java:862)
> >> > > at
> >> > > org.apache.wicket.request.RequestHandlerStack.execute(
> >> > > RequestHandlerStack.java:64)
> >> > > at
> >> > > org.apache.wicket.request.RequestHandlerStack.execute(
> >> > > RequestHandlerStack.java:93)
> >> > > at
> >> > > org.apache.wicket.request.cycle.RequestCycle.execute(
> >> > > RequestCycle.java:261)
> >> > > at
> >> > > org.apache.wicket.request.cycle.RequestCycle.
> >> > processRequest(RequestCycle.
> >> > > java:218)
> >> > > at
> >> > > org.apache.wicket.request.cycle.RequestCycle.
> processRequestAndDetach(
> >> > > RequestCycle.java:289)
> >> > > at
> >> > > org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(
> >> > > WicketFilter.java:259)
> >> > > at
> >> > > org.apache.wicket.protocol.http.WicketFilter.
> >> > processRequest(WicketFilter.
> >> > > java:201)
> >> > > at
> >> > > org.apache.wicket.protocol.http.WicketFilter.doFilter(
> &

Re: NPE in org.apache.wicket.request.http.handler.RedirectRequestHandler.respond

[Wayne W]

Still on 6.17.0 Martin. Not had the time/resources to move to 6.18 which I
want because of that replication fix!!

On Tue, Jul 25, 2017 at 7:55 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Which version of Wicket do you use ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Jul 25, 2017 at 5:52 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I've got a strange issue I cannot get to the bottom of. Basically we have
> > our app deployed on jetty 9.2.1 with apache 2.4 in front. If I make calls
> > to stateless pages its all good. However as soon as I try to make a call
> to
> > a stateful page it does a 302 to the login page for our app, but then
> just
> > gets stuck in a 302 loop redirection loop. Looking at the server logs its
> > full of this with no other exception - each track trace corresponds to
> > another 302 redirect. Each redirect is trying to get to our login page:
> >
> >
> > 2017-07-25 14:40:18,989 ERROR -
> > org.apache.wicket.DefaultExceptionMapper.internalMap(
> > DefaultExceptionMapper.java:129)
> > 129 DefaultExceptionMapper - Unexpected error occurred
> > java.lang.NullPointerException
> > at
> > org.apache.wicket.request.http.handler.RedirectRequestHandler.respond(
> > RedirectRequestHandler.java:99)
> > at
> > org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(
> > RequestCycle.java:862)
> > at
> > org.apache.wicket.request.RequestHandlerStack.execute(
> > RequestHandlerStack.java:64)
> > at
> > org.apache.wicket.request.RequestHandlerStack.execute(
> > RequestHandlerStack.java:93)
> > at
> > org.apache.wicket.request.cycle.RequestCycle.execute(
> > RequestCycle.java:261)
> > at
> > org.apache.wicket.request.cycle.RequestCycle.
> processRequest(RequestCycle.
> > java:218)
> > at
> > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(
> > RequestCycle.java:289)
> > at
> > org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(
> > WicketFilter.java:259)
> > at
> > org.apache.wicket.protocol.http.WicketFilter.
> processRequest(WicketFilter.
> > java:201)
> > at
> > org.apache.wicket.protocol.http.WicketFilter.doFilter(
> > WicketFilter.java:282)
> > at
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> > doFilter(ServletHandler.java:1653)
> > at
> > hub.app.servlet.RelativeUrlFilter.doFilter(RelativeUrlFilter.java:54)
> > at
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> > doFilter(ServletHandler.java:1653)
> > at
> > com.wideplay.warp.persist.PersistenceFilter$3.run(
> > PersistenceFilter.java:141)
> > at
> > com.wideplay.warp.persist.internal.Lifecycles.
> > failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
> > at
> > com.wideplay.warp.persist.PersistenceFilter.doFilter(
> > PersistenceFilter.java:155)
> > at
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> > doFilter(ServletHandler.java:1645)
> > at
> > org.eclipse.jetty.servlet.ServletHandler.doHandle(
> ServletHandler.java:564)
> > at
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(
> > ScopedHandler.java:143)
> > at
> > org.eclipse.jetty.security.SecurityHandler.handle(
> > SecurityHandler.java:578)
> > at
> > org.eclipse.jetty.server.session.SessionHandler.
> > doHandle(SessionHandler.java:221)
> > at
> > org.eclipse.jetty.server.handler.ContextHandler.
> > doHandle(ContextHandler.java:)
> > at
> > org.eclipse.jetty.servlet.ServletHandler.doScope(
> ServletHandler.java:498)
> > at
> > org.eclipse.jetty.server.session.SessionHandler.
> > doScope(SessionHandler.java:183)
> > at
> > org.eclipse.jetty.server.handler.ContextHandler.
> > doScope(ContextHandler.java:1045)
> > at
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(
> > ScopedHandler.java:141)
> > at
> > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(
> > ContextHandlerCollection.java:199)
> > at
> > org.eclipse.jetty.server.handler.HandlerCollection.
> > handle(HandlerCollection.java:109)
> > at
> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(
> > HandlerWrapper.j

NPE in org.apache.wicket.request.http.handler.RedirectRequestHandler.respond

[Wayne W]

Hi,

I've got a strange issue I cannot get to the bottom of. Basically we have
our app deployed on jetty 9.2.1 with apache 2.4 in front. If I make calls
to stateless pages its all good. However as soon as I try to make a call to
a stateful page it does a 302 to the login page for our app, but then just
gets stuck in a 302 loop redirection loop. Looking at the server logs its
full of this with no other exception - each track trace corresponds to
another 302 redirect. Each redirect is trying to get to our login page:


2017-07-25 14:40:18,989 ERROR -
org.apache.wicket.DefaultExceptionMapper.internalMap(DefaultExceptionMapper.java:129)
129 DefaultExceptionMapper - Unexpected error occurred
java.lang.NullPointerException
at
org.apache.wicket.request.http.handler.RedirectRequestHandler.respond(RedirectRequestHandler.java:99)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:93)
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289)
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1653)
at
hub.app.servlet.RelativeUrlFilter.doFilter(RelativeUrlFilter.java:54)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1653)
at
com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141)
at
com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
at
com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1645)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:564)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:578)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:498)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1045)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:199)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:98)
at org.eclipse.jetty.server.Server.handle(Server.java:461)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:284)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:534)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536)
at java.lang.Thread.run(Thread.java:745)
2017-07-25 14:40:19,076 ERROR -
org.apache.wicket.DefaultExceptionMapper.internalMap(DefaultExceptionMapper.java:129)
129 DefaultExceptionMapper - Unexpected error occurred
java.lang.NullPointerException
at
org.apache.wicket.request.http.handler.RedirectRequestHandler.respond(RedirectRequestHandler.java:99)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
etc




Does any one have any idea what is causing this? Its fine on my local
machine and fine if I used tomcat behind apache.


My apache cons looks like this:


 ServerName X.com

 RequestHeader set X_FORWARDED_PROTO "https"
 RequestHeader set X-Forwarded-Proto "https"

 ErrorLog /home/wayne/error_log
 CustomLog /home/wayne/access_log combined

 SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH

 SSLEngine On
 SSLCertificateFile  

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Hi Martin,

Ok I've opened a ticket. I did some more debugging and I've described it to
the best of my understanding. I could try and make a patch but its complex
code and I don't want to mess anything up!! - not very confident with
Wicket.

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

thanks


On Mon, Apr 3, 2017 at 8:19 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> On Thu, Mar 30, 2017 at 11:21 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Please ignore my last email I have done a lot more debugging and I
> *think*
> > I understand why replication does not work for us:
> >
> >
> > Whenever a stateful pages is used (touched) the SessionEntry is updated,
> > > i.e. the page is put into it.
> > > The SessionEntry is stored as an attribute in the HTTP Session.
> > > The web container has logic to detect if the HTTP session has been
> > updated
> > > in a request and if it was then it replicates the whole session to the
> > > other nodes.
> > > Once the session is replicated it is deserialized. Here
> > > SessionEntry#readObject() comes to play. It reads the pages from the
> > > SessionEntry and stores them into the disk (via IDiskStore).
> > > So the stateful pages should be available in the disks of all nodes.
> > > Stateless pages are always recreated from scratch, so they are not
> > > replicated.
> >
> >
> > I think this is a little wrong. Yes the SessionEntry in stored as an
> > attribute in the http session and is replicated. However the pages in the
> > SessionEntry cache are not replicated as they are transient.
> >
> > private transient List sessionCache;
> >
>
> This looks like a bug!
> It shouldn't be transient.
> Please open a ticket!
> Could you please provide your Tomcat configuration related to replication
> too ?
> A patch / Pull Request is also very welcome!
>
> Thank you!
>
>
> >
> > private transient List afterReadObject
> >
> > Therefore the pages are *not* deserialised as you say. The only time
> > SessionEntry#readObject()
> > comes to play (at least with Tomcat) is when a node is first brought up
> and
> > the daltamanager replicates ALL sessions across, at this point all the
> > current SessionEntry's in the other nodes http sessions are written
> across.
> > After this is done SessionEntry#readObject() is not called anymore. Any
> new
> > pages/updates on the original instance are not replicated across (only
> the
> > sessionId in the SessionEntry).
> >
> > This means any new pages created on the old instance (after the new
> > instance has started up) are not available in the http session or the
> > second level page store on the new instance.
> > Therefore when the old instance in shut down the user is load balanced to
> > the new instance. At this point the link in the page Wicket is looking
> for
> > does not exist in the SessionEntry cache or the PageStore so it creates
> the
> > page and looks for the component/link.
> >
> > This causes a ComponentNotFoundException for us because the links are
> > either in a DataView which is never rendered so does not exist, or the
> > other links are actually added to the page in an Ajax request and again
> > because the page is not rendered are not there, Wicket then throws the
> > exception and it appears to the user the session is lost.
> >
> > This is at least what I am observing. I can provide a Quick start to
> > demonstrate if needed.
> >
> > many thanks for you time thus far.
> >
> >
> > On Thu, Mar 30, 2017 at 4:29 PM, Wayne W <waynemailingli...@gmail.com>
> > wrote:
> >
> > >
> > >
> > > On Thu, Mar 30, 2017 at 4:09 PM, Martin Grigorov <mgrigo...@apache.org
> >
> > > wrote:
> > >
> > >>
> > >>
> > >> Whenever a stateful pages is used (touched) the SessionEntry is
> updated,
> > >> i.e. the page is put into it.
> > >>
> > >
> > > Yes I can see that happening in PageStoreManager.storeTouchedPages()
> > >
> > >
> > >> The SessionEntry is stored as an attribute in the HTTP Session.
> > >>
> > >
> > > I'm not seeing this. In the wicket.Session class there is line :
> > >
> > > private transient ISessionStore sessionStore;
> > >
> > > Which is loaded from the Application each request. The SessionStore
> > > contains the SessionEntry's no???
> > >
> > >
> > >
> > &g

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Please ignore my last email I have done a lot more debugging and I *think*
I understand why replication does not work for us:


Whenever a stateful pages is used (touched) the SessionEntry is updated,
> i.e. the page is put into it.
> The SessionEntry is stored as an attribute in the HTTP Session.
> The web container has logic to detect if the HTTP session has been updated
> in a request and if it was then it replicates the whole session to the
> other nodes.
> Once the session is replicated it is deserialized. Here
> SessionEntry#readObject() comes to play. It reads the pages from the
> SessionEntry and stores them into the disk (via IDiskStore).
> So the stateful pages should be available in the disks of all nodes.
> Stateless pages are always recreated from scratch, so they are not
> replicated.


I think this is a little wrong. Yes the SessionEntry in stored as an
attribute in the http session and is replicated. However the pages in the
SessionEntry cache are not replicated as they are transient.

private transient List sessionCache;

private transient List afterReadObject

Therefore the pages are *not* deserialised as you say. The only time
SessionEntry#readObject()
comes to play (at least with Tomcat) is when a node is first brought up and
the daltamanager replicates ALL sessions across, at this point all the
current SessionEntry's in the other nodes http sessions are written across.
After this is done SessionEntry#readObject() is not called anymore. Any new
pages/updates on the original instance are not replicated across (only the
sessionId in the SessionEntry).

This means any new pages created on the old instance (after the new
instance has started up) are not available in the http session or the
second level page store on the new instance.
Therefore when the old instance in shut down the user is load balanced to
the new instance. At this point the link in the page Wicket is looking for
does not exist in the SessionEntry cache or the PageStore so it creates the
page and looks for the component/link.

This causes a ComponentNotFoundException for us because the links are
either in a DataView which is never rendered so does not exist, or the
other links are actually added to the page in an Ajax request and again
because the page is not rendered are not there, Wicket then throws the
exception and it appears to the user the session is lost.

This is at least what I am observing. I can provide a Quick start to
demonstrate if needed.

many thanks for you time thus far.


On Thu, Mar 30, 2017 at 4:29 PM, Wayne W <waynemailingli...@gmail.com>
wrote:

>
>
> On Thu, Mar 30, 2017 at 4:09 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
>>
>>
>> Whenever a stateful pages is used (touched) the SessionEntry is updated,
>> i.e. the page is put into it.
>>
>
> Yes I can see that happening in PageStoreManager.storeTouchedPages()
>
>
>> The SessionEntry is stored as an attribute in the HTTP Session.
>>
>
> I'm not seeing this. In the wicket.Session class there is line :
>
> private transient ISessionStore sessionStore;
>
> Which is loaded from the Application each request. The SessionStore
> contains the SessionEntry's no???
>
>
>
>> The web container has logic to detect if the HTTP session has been updated
>> in a request and if it was then it replicates the whole session to the
>> other nodes.
>>
>
> Yes I'm seeing the http session replicated no issues.
>
>
>> Once the session is replicated it is deserialized. Here
>> SessionEntry#readObject() comes to play. It reads the pages from the
>> SessionEntry and stores them into the disk (via IDiskStore).
>> So the stateful pages should be available in the disks of all nodes.
>> Stateless pages are always recreated from scratch, so they are not
>> replicated.
>>
>
>
> If this is the case why is wicket saying this page is stateless as the
> SessionEntry is never replicated across?:
>
>
>
> public class HomePage extends WebPage {
>
> private static final long serialVersionUID = 1L;
>
>
> public HomePage() {
>
> super();
>
>
> Session s= Session.get();
>
> s.bind();
>
> Integer i = (Integer)s.getAttribute("foo");
>
> if (i == null) {
>
> i = new Integer(0);
>
> }
>
> i++;
>
> s.setAttribute("foo",i);
>
> add(new Label("version", (Integer)s.getAttribute("foo")));
>
>
> add(new Link("link1") {
>
> @Override
>
> public void onClick()
>
> {
>
> setResponsePage(new NextPage());
>
> }
>
> });
>
> add(new Link("link2") {
>
> @Override
>
> public void onClick()
>
> {
>
> setResponsePage(new HomePage());
>
> }

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

On Thu, Mar 30, 2017 at 4:09 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

>
>
> Whenever a stateful pages is used (touched) the SessionEntry is updated,
> i.e. the page is put into it.
>

Yes I can see that happening in PageStoreManager.storeTouchedPages()


> The SessionEntry is stored as an attribute in the HTTP Session.
>

I'm not seeing this. In the wicket.Session class there is line :

private transient ISessionStore sessionStore;

Which is loaded from the Application each request. The SessionStore
contains the SessionEntry's no???



> The web container has logic to detect if the HTTP session has been updated
> in a request and if it was then it replicates the whole session to the
> other nodes.
>

Yes I'm seeing the http session replicated no issues.


> Once the session is replicated it is deserialized. Here
> SessionEntry#readObject() comes to play. It reads the pages from the
> SessionEntry and stores them into the disk (via IDiskStore).
> So the stateful pages should be available in the disks of all nodes.
> Stateless pages are always recreated from scratch, so they are not
> replicated.
>


If this is the case why is wicket saying this page is stateless as the
SessionEntry is never replicated across?:



public class HomePage extends WebPage {

private static final long serialVersionUID = 1L;


public HomePage() {

super();


Session s= Session.get();

s.bind();

Integer i = (Integer)s.getAttribute("foo");

if (i == null) {

i = new Integer(0);

}

i++;

s.setAttribute("foo",i);

add(new Label("version", (Integer)s.getAttribute("foo")));


add(new Link("link1") {

@Override

public void onClick()

{

setResponsePage(new NextPage());

}

});

add(new Link("link2") {

@Override

public void onClick()

{

setResponsePage(new HomePage());

}

});

add(new AbstractDefaultAjaxBehavior() {

@Override

protected void respond(AjaxRequestTarget target) {

getSession().setAttribute("someKey", UUID.randomUUID().toString());

System.out.println("SLEEEPING");

try {

Thread.sleep(3000);

}catch(Exception e) {

}

System.out.println("DONE");

}

@Override

public void renderHead(Component component, IHeaderResponse response) {

super.renderHead(component, response);

String js = "(" + getCallbackFunction().toString() +")();";

response.render(OnDomReadyHeaderItem.forScript(js));

}

});

// TODO Add your page's components here


}

}



Sorry for all these questions but I must get to the bottom of this (5 days
work so far). Many thanks



>
>
> >
> >
> > thanks
> >
> > On Tue, Mar 28, 2017 at 9:39 PM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > Did you mention already which version of Wicket you use ?
> > > There was an improvement related to reusing the page parameters when
> > > constructing a new page instance in 7.0.0.
> > > I have the feeling you are using 6.x. Am I correct ?
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Tue, Mar 28, 2017 at 7:22 PM, Wayne W <waynemailingli...@gmail.com>
> > > wrote:
> > >
> > > > Hello Martin,
> > > >
> > > > so I've been trying to still get to the bottom of this days later. So
> > my
> > > > understanding is getting better and it appears that the session
> itself
> > is
> > > > replicated fine. However I've tracked my issue down to the following:
> > > >
> > > > - If I have a page that has 2 links at the top. Link A is a
> > Bookmarkable
> > > > link back to the same page - it is also mounted thus:  mountPage(
> > > > "/cube/documents/${0}", CubeDocumentPage.class); It has a Long page
> > param
> > > > needed to construct the page ( i.e. /cube/documents/12345 ). The
> second
> > > > link B is just a simple new Link("B")  .
> > > > - If both instances are up and running , lets say I am on instance
> A. I
> > > > visit link A 3 times. I then kill instance A and I am balanced over
> to
> > > > instance B. If I visit link B ,  the PageStoreManager cannot find the
> > > page
> > > > that contains link B in the store and then tries to create a new
> > instance
> > > > of the page - the problem is then for some reason the page parameters
> > are
> > > > always null and the Long is never passed. Why is the page parameter
> > > always
> > > > null here? Trying to debug it, is seems the IPageManager is got from
> &

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Hi Martin,

yes we are on 6. I've just spent the day upgrading to 7 and got it running
ok. I've been debugging and I'm confused to one aspect:

The PageManager is stored in the Application. The page manger has the
RequestAdaptor/PageStoreManager stored within that holds the pages and
components. I observe that when a new instance joins the cluster this
pagestoremanager SessionEntry is serialized across to the new instance.
However further requests do NOT serialise the session entry across.
If the original node is then shutdown, on the new instance the page (from
the further requests) cannot be found in the pagestoremanager (its
bookmarkable page) and a new instance must be constructed instead. This is
where I get the problem as it can't find the component on the new instance
(I'm still debugging why this is the case).

However my question is whats the point of serialising across the
SessionEntry if its not done on each session commit? Its only of use if the
node is stop straight after the new instance is started.


thanks

On Tue, Mar 28, 2017 at 9:39 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> Did you mention already which version of Wicket you use ?
> There was an improvement related to reusing the page parameters when
> constructing a new page instance in 7.0.0.
> I have the feeling you are using 6.x. Am I correct ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Mar 28, 2017 at 7:22 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hello Martin,
> >
> > so I've been trying to still get to the bottom of this days later. So my
> > understanding is getting better and it appears that the session itself is
> > replicated fine. However I've tracked my issue down to the following:
> >
> > - If I have a page that has 2 links at the top. Link A is a Bookmarkable
> > link back to the same page - it is also mounted thus:  mountPage(
> > "/cube/documents/${0}", CubeDocumentPage.class); It has a Long page param
> > needed to construct the page ( i.e. /cube/documents/12345 ). The second
> > link B is just a simple new Link("B")  .
> > - If both instances are up and running , lets say I am on instance A. I
> > visit link A 3 times. I then kill instance A and I am balanced over to
> > instance B. If I visit link B ,  the PageStoreManager cannot find the
> page
> > that contains link B in the store and then tries to create a new instance
> > of the page - the problem is then for some reason the page parameters are
> > always null and the Long is never passed. Why is the page parameter
> always
> > null here? Trying to debug it, is seems the IPageManager is got from the
> > wicket Application instance and not the Session, and this IPageManager
> > looks for a RequestAdaptor. Somewhere the page parameters are lost?.
> >
> > However I can get it to work this way:
> > - start instance A, visit the page and say click link A 3 times.
> > - Now start up instance B
> > - Kill instance A
> > - Click on the link B and this time the PageStoreManager finds the page
> and
> > there the link B and everything works fine.
> > It only works if I don't visit another page just after instance B starts
> > up.
> >
> >
> > I will do some more debugging tomorrow to try and understand this
> > PageStoreManager/request adaptor bit more. But if you have any ideas I'd
> > appreciate it.
> > Thanks
> >
> >
> >
> > On Fri, Mar 24, 2017 at 12:48 PM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > On Fri, Mar 24, 2017 at 1:31 PM, Wayne W <waynemailingli...@gmail.com>
> > > wrote:
> > >
> > > > Thanks Martin,
> > > >
> > > > I have a theory what this is, perhaps you could confirm?
> > > >
> > > > What I observe is the following with the replication: If I visit
> page A
> > > and
> > > > then visit page B, then kill the instance I am on the session is
> > > > successfully failed over to the other node. Now I'm still looking at
> > > page B
> > > > in the browser - if I hit back on the browser I get
> > PageExpiredException.
> > > > Is this the expected behaviour?
> > > >
> > >
> > > No.
> > > The expected behavior is to see the latest state of page A.
> > >
> > >
> > > >
> > > > If it IS the expected behaviour, then the reason I think that I have
> an
> > > > issue with the page with the AbstractDefaultAjaxBehavior is because
&g

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Hello Martin,

so I've been trying to still get to the bottom of this days later. So my
understanding is getting better and it appears that the session itself is
replicated fine. However I've tracked my issue down to the following:

- If I have a page that has 2 links at the top. Link A is a Bookmarkable
link back to the same page - it is also mounted thus:  mountPage(
"/cube/documents/${0}", CubeDocumentPage.class); It has a Long page param
needed to construct the page ( i.e. /cube/documents/12345 ). The second
link B is just a simple new Link("B")  .
- If both instances are up and running , lets say I am on instance A. I
visit link A 3 times. I then kill instance A and I am balanced over to
instance B. If I visit link B ,  the PageStoreManager cannot find the page
that contains link B in the store and then tries to create a new instance
of the page - the problem is then for some reason the page parameters are
always null and the Long is never passed. Why is the page parameter always
null here? Trying to debug it, is seems the IPageManager is got from the
wicket Application instance and not the Session, and this IPageManager
looks for a RequestAdaptor. Somewhere the page parameters are lost?.

However I can get it to work this way:
- start instance A, visit the page and say click link A 3 times.
- Now start up instance B
- Kill instance A
- Click on the link B and this time the PageStoreManager finds the page and
there the link B and everything works fine.
It only works if I don't visit another page just after instance B starts up.


I will do some more debugging tomorrow to try and understand this
PageStoreManager/request adaptor bit more. But if you have any ideas I'd
appreciate it.
Thanks



On Fri, Mar 24, 2017 at 12:48 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> On Fri, Mar 24, 2017 at 1:31 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Thanks Martin,
> >
> > I have a theory what this is, perhaps you could confirm?
> >
> > What I observe is the following with the replication: If I visit page A
> and
> > then visit page B, then kill the instance I am on the session is
> > successfully failed over to the other node. Now I'm still looking at
> page B
> > in the browser - if I hit back on the browser I get PageExpiredException.
> > Is this the expected behaviour?
> >
>
> No.
> The expected behavior is to see the latest state of page A.
>
>
> >
> > If it IS the expected behaviour, then the reason I think that I have an
> > issue with the page with the AbstractDefaultAjaxBehavior is because the
> > code in the AbstractDefaultAjaxBehaviour.respond is adding components to
> > the page which in turn marks the Session dirty which in turn replicates
> the
> > session. If only the last page/session commit is only replicated it could
> > explain why I get a ComponentNotFound exception from the page as
> > it overwriten by the update from the AbstractDefaultAjaxBehavior
> >
>
> Any time the page is marked as dirty Wicket will store it in 1) the HTTP
> session and 2) on the disk
> 1) will notify the web server (e.g. Tomcat) that it has to replicate the
> session because some attribute has been modified
> At node2 Wicket will detect the replicated session in #readObject() and
> store it on the disk.
> From now on node2 will have the same history for that page as node1, i.e.
> PageA and PageB.
>
> In addition:
> Updates made in an Ajax requests do not add a new entry in the history
> (storages) but overrides the previous entry for that page instance!
> I.e. when PageA is rendered Wicket will assign a pageId for it, e.g. 5, and
> store it in the disk.
> Later when you make a change to PageA:5 in Ajax request then Wicket will
> override the entry on the disk.
> If you make a change in non-Ajax request then Wicket will assign a new
> pageId, e.g. 6, and add a new entry in the history (disk), so you will have
> two entries for this session.
> Later when you open PageB then this will be pageId 7, etc.
>
>
> >
> > What do you think?
> >
> >
> >
> > On Fri, Mar 24, 2017 at 9:31 AM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > Once the http session is replicated this method should be executed on
> the
> > > node that did not process the request
> > > org.apache.wicket.page.PageStoreManager.SessionEntry#readObject().
> > > Here Wicket will either store the page(s) on the disk or will schedule
> > them
> > > for storing.
> > > There is no much usage of Loggers here so you will have to attach a
> > > debugger and see what happens.
> > >
> > > Martin Grigorov

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Thanks Martin,

I have a theory what this is, perhaps you could confirm?

What I observe is the following with the replication: If I visit page A and
then visit page B, then kill the instance I am on the session is
successfully failed over to the other node. Now I'm still looking at page B
in the browser - if I hit back on the browser I get PageExpiredException.
Is this the expected behaviour?

If it IS the expected behaviour, then the reason I think that I have an
issue with the page with the AbstractDefaultAjaxBehavior is because the
code in the AbstractDefaultAjaxBehaviour.respond is adding components to
the page which in turn marks the Session dirty which in turn replicates the
session. If only the last page/session commit is only replicated it could
explain why I get a ComponentNotFound exception from the page as
it overwriten by the update from the AbstractDefaultAjaxBehavior

What do you think?



On Fri, Mar 24, 2017 at 9:31 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> Once the http session is replicated this method should be executed on the
> node that did not process the request
> org.apache.wicket.page.PageStoreManager.SessionEntry#readObject().
> Here Wicket will either store the page(s) on the disk or will schedule them
> for storing.
> There is no much usage of Loggers here so you will have to attach a
> debugger and see what happens.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Mar 23, 2017 at 6:11 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > If I put the AbstractDefaultAjaxBehavior back in, it always fails. If I
> > remove the AbstractDefaultAjaxBehavior most of the time it works, but
> every
> > now and then it fails to replicate. Its really inconsistent.
> >
> > I have no idea how to get to the bottom of this. Any pointers or help is
> > much appreciated.
> >
> > On Thu, Mar 23, 2017 at 4:53 PM, Wayne W <waynemailingli...@gmail.com>
> > wrote:
> >
> > > So it seems the homepage is not the only page. However removing the
> > > AbstractDefaultAjaxBehavior makes no difference I still get the same
> > > issues. Just don;t know where to start with this one. Is there a way I
> > can
> > > turn on the logging around replication in wicket?
> > >
> > > On Thu, Mar 23, 2017 at 4:27 PM, Wayne W <waynemailingli...@gmail.com>
> > > wrote:
> > >
> > >> Hi Martin,
> > >>
> > >> no - I still get the ComponentNotFoundException in the new instance.
> :-/
> > >>
> > >> On Thu, Mar 23, 2017 at 3:57 PM, Martin Grigorov <
> mgrigo...@apache.org>
> > >> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> On Thu, Mar 23, 2017 at 4:20 PM, Wayne W <
> waynemailingli...@gmail.com>
> > >>> wrote:
> > >>>
> > >>> > Hi Martin,
> > >>> >
> > >>> > that was a typo on my part. I've been doing a lot more testing
> > before I
> > >>> > replied to make sure things are as I say. This is what I am
> > observing:
> > >>> >
> > >>> >
> > >>> >- I have a 2 node tomcat cluster setup with apache balancing
> > between
> > >>> >them locally on my machine.
> > >>> >- Testing with a very simple Wicket app I can see the
> replication
> > is
> > >>> >working fine when shutting down either instance.
> > >>> >- Testing with our very heavy weight wicket app it sometimes
> work
> > >>> and
> > >>> >sometimes does not.
> > >>> >
> > >>> > Now the last point above I have narrowed down to our homepage. If I
> > am
> > >>> not
> > >>> > on the homepage the replication seems to work ok. However if I am
> on
> > >>> the
> > >>> > homepage I always get a ComponentNotFoundException when failing
> over
> > >>> to the
> > >>> > other instance.
> > >>> > The homepage has an AbstractDefaultAjaxBehavior which is called
> once
> > >>> the
> > >>> > page is rendered, this in turn adds to the the page a DataView
> > >>> containing a
> > >>> > lot of content and links. The user needs to be logged in before
> they
> > >>> see
> > >>> > the homepage, so the session is already setup.
> > >>> >
> > >>> > I don't know wh

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

If I put the AbstractDefaultAjaxBehavior back in, it always fails. If I
remove the AbstractDefaultAjaxBehavior most of the time it works, but every
now and then it fails to replicate. Its really inconsistent.

I have no idea how to get to the bottom of this. Any pointers or help is
much appreciated.

On Thu, Mar 23, 2017 at 4:53 PM, Wayne W <waynemailingli...@gmail.com>
wrote:

> So it seems the homepage is not the only page. However removing the
> AbstractDefaultAjaxBehavior makes no difference I still get the same
> issues. Just don;t know where to start with this one. Is there a way I can
> turn on the logging around replication in wicket?
>
> On Thu, Mar 23, 2017 at 4:27 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
>> Hi Martin,
>>
>> no - I still get the ComponentNotFoundException in the new instance. :-/
>>
>> On Thu, Mar 23, 2017 at 3:57 PM, Martin Grigorov <mgrigo...@apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> On Thu, Mar 23, 2017 at 4:20 PM, Wayne W <waynemailingli...@gmail.com>
>>> wrote:
>>>
>>> > Hi Martin,
>>> >
>>> > that was a typo on my part. I've been doing a lot more testing before I
>>> > replied to make sure things are as I say. This is what I am observing:
>>> >
>>> >
>>> >- I have a 2 node tomcat cluster setup with apache balancing between
>>> >them locally on my machine.
>>> >- Testing with a very simple Wicket app I can see the replication is
>>> >working fine when shutting down either instance.
>>> >- Testing with our very heavy weight wicket app it sometimes work
>>> and
>>> >sometimes does not.
>>> >
>>> > Now the last point above I have narrowed down to our homepage. If I am
>>> not
>>> > on the homepage the replication seems to work ok. However if I am on
>>> the
>>> > homepage I always get a ComponentNotFoundException when failing over
>>> to the
>>> > other instance.
>>> > The homepage has an AbstractDefaultAjaxBehavior which is called once
>>> the
>>> > page is rendered, this in turn adds to the the page a DataView
>>> containing a
>>> > lot of content and links. The user needs to be logged in before they
>>> see
>>> > the homepage, so the session is already setup.
>>> >
>>> > I don't know what it is about this page that breaks the replication. Is
>>> > there anything around the ajax part that could do this? Any pointers
>>> would
>>> > be most welcome as it will be a long long task to break that page down
>>> and
>>> > do rounds and rounds of cluster testing
>>> >
>>>
>>> Let's try something!
>>> In you Ajax callback method do something like:
>>> getSession().setAttribute("someKey", UUID.randomUUID().toString())
>>> Does this trigger replication ?
>>>
>>>
>>> >
>>> > many thanks
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Mar 22, 2017 at 12:34 PM, Martin Grigorov <
>>> mgrigo...@apache.org>
>>> > wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > "I can stop one of the instances and I'm not logged in"
>>> > > This statement says that you don't really have a properly configured
>>> > > failover.
>>> > > If those two Tomcat instances are in a cluster then the http sessions
>>> > > should be replicated and you should stay logged in no matter which
>>> one is
>>> > > serving the request.
>>> > > Wicket will store the used stateful page at the disks for all
>>> Tomcats in
>>> > > the cluster, if it the replication is actually working!
>>> > >
>>> > >
>>> > > On Wed, Mar 22, 2017 at 1:02 PM, Wayne W <
>>> waynemailingli...@gmail.com>
>>> > > wrote:
>>> > >
>>> > > > Hi,
>>> > > >
>>> > > > We have 2 instances of Tomcat running with Apache sitting in front
>>> > > > balancing between the Tomcat instances. I have session replication
>>> > setup
>>> > > > which seems to work for basic bookmarkable links on the pages. I
>>> can
>>> > stop
>>> > > > one of the instances and I'm not logged in as it failover to the
>>> other
>>> > > > instance.
>>> > > >
>>> > > > However for normal Link and ajax links etc I get
>>> > > > ComponentNotFoundException  thrown as the new instance cannot find
>>> it
>>> > in
>>> > > > the session it seems.
>>> > > >
>>> > > > Clearly I'm not understanding how wicket manages the page state or
>>> I've
>>> > > > configured something wrong.
>>> > > >
>>> > > > Does wicket support full session failover ?
>>> > > >
>>> > > > Many thanks
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

So it seems the homepage is not the only page. However removing the
AbstractDefaultAjaxBehavior
makes no difference I still get the same issues. Just don;t know where to
start with this one. Is there a way I can turn on the logging around
replication in wicket?

On Thu, Mar 23, 2017 at 4:27 PM, Wayne W <waynemailingli...@gmail.com>
wrote:

> Hi Martin,
>
> no - I still get the ComponentNotFoundException in the new instance. :-/
>
> On Thu, Mar 23, 2017 at 3:57 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
>> Hi,
>>
>> On Thu, Mar 23, 2017 at 4:20 PM, Wayne W <waynemailingli...@gmail.com>
>> wrote:
>>
>> > Hi Martin,
>> >
>> > that was a typo on my part. I've been doing a lot more testing before I
>> > replied to make sure things are as I say. This is what I am observing:
>> >
>> >
>> >- I have a 2 node tomcat cluster setup with apache balancing between
>> >them locally on my machine.
>> >- Testing with a very simple Wicket app I can see the replication is
>> >working fine when shutting down either instance.
>> >- Testing with our very heavy weight wicket app it sometimes work and
>> >sometimes does not.
>> >
>> > Now the last point above I have narrowed down to our homepage. If I am
>> not
>> > on the homepage the replication seems to work ok. However if I am on the
>> > homepage I always get a ComponentNotFoundException when failing over to
>> the
>> > other instance.
>> > The homepage has an AbstractDefaultAjaxBehavior which is called once the
>> > page is rendered, this in turn adds to the the page a DataView
>> containing a
>> > lot of content and links. The user needs to be logged in before they see
>> > the homepage, so the session is already setup.
>> >
>> > I don't know what it is about this page that breaks the replication. Is
>> > there anything around the ajax part that could do this? Any pointers
>> would
>> > be most welcome as it will be a long long task to break that page down
>> and
>> > do rounds and rounds of cluster testing
>> >
>>
>> Let's try something!
>> In you Ajax callback method do something like:
>> getSession().setAttribute("someKey", UUID.randomUUID().toString())
>> Does this trigger replication ?
>>
>>
>> >
>> > many thanks
>> >
>> >
>> >
>> >
>> > On Wed, Mar 22, 2017 at 12:34 PM, Martin Grigorov <mgrigo...@apache.org
>> >
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > "I can stop one of the instances and I'm not logged in"
>> > > This statement says that you don't really have a properly configured
>> > > failover.
>> > > If those two Tomcat instances are in a cluster then the http sessions
>> > > should be replicated and you should stay logged in no matter which
>> one is
>> > > serving the request.
>> > > Wicket will store the used stateful page at the disks for all Tomcats
>> in
>> > > the cluster, if it the replication is actually working!
>> > >
>> > >
>> > > On Wed, Mar 22, 2017 at 1:02 PM, Wayne W <waynemailingli...@gmail.com
>> >
>> > > wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > We have 2 instances of Tomcat running with Apache sitting in front
>> > > > balancing between the Tomcat instances. I have session replication
>> > setup
>> > > > which seems to work for basic bookmarkable links on the pages. I can
>> > stop
>> > > > one of the instances and I'm not logged in as it failover to the
>> other
>> > > > instance.
>> > > >
>> > > > However for normal Link and ajax links etc I get
>> > > > ComponentNotFoundException  thrown as the new instance cannot find
>> it
>> > in
>> > > > the session it seems.
>> > > >
>> > > > Clearly I'm not understanding how wicket manages the page state or
>> I've
>> > > > configured something wrong.
>> > > >
>> > > > Does wicket support full session failover ?
>> > > >
>> > > > Many thanks
>> > > >
>> > >
>> >
>>
>
>

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Hi Martin,

no - I still get the ComponentNotFoundException in the new instance. :-/

On Thu, Mar 23, 2017 at 3:57 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> On Thu, Mar 23, 2017 at 4:20 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hi Martin,
> >
> > that was a typo on my part. I've been doing a lot more testing before I
> > replied to make sure things are as I say. This is what I am observing:
> >
> >
> >- I have a 2 node tomcat cluster setup with apache balancing between
> >them locally on my machine.
> >- Testing with a very simple Wicket app I can see the replication is
> >working fine when shutting down either instance.
> >- Testing with our very heavy weight wicket app it sometimes work and
> >sometimes does not.
> >
> > Now the last point above I have narrowed down to our homepage. If I am
> not
> > on the homepage the replication seems to work ok. However if I am on the
> > homepage I always get a ComponentNotFoundException when failing over to
> the
> > other instance.
> > The homepage has an AbstractDefaultAjaxBehavior which is called once the
> > page is rendered, this in turn adds to the the page a DataView
> containing a
> > lot of content and links. The user needs to be logged in before they see
> > the homepage, so the session is already setup.
> >
> > I don't know what it is about this page that breaks the replication. Is
> > there anything around the ajax part that could do this? Any pointers
> would
> > be most welcome as it will be a long long task to break that page down
> and
> > do rounds and rounds of cluster testing
> >
>
> Let's try something!
> In you Ajax callback method do something like:
> getSession().setAttribute("someKey", UUID.randomUUID().toString())
> Does this trigger replication ?
>
>
> >
> > many thanks
> >
> >
> >
> >
> > On Wed, Mar 22, 2017 at 12:34 PM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > "I can stop one of the instances and I'm not logged in"
> > > This statement says that you don't really have a properly configured
> > > failover.
> > > If those two Tomcat instances are in a cluster then the http sessions
> > > should be replicated and you should stay logged in no matter which one
> is
> > > serving the request.
> > > Wicket will store the used stateful page at the disks for all Tomcats
> in
> > > the cluster, if it the replication is actually working!
> > >
> > >
> > > On Wed, Mar 22, 2017 at 1:02 PM, Wayne W <waynemailingli...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > We have 2 instances of Tomcat running with Apache sitting in front
> > > > balancing between the Tomcat instances. I have session replication
> > setup
> > > > which seems to work for basic bookmarkable links on the pages. I can
> > stop
> > > > one of the instances and I'm not logged in as it failover to the
> other
> > > > instance.
> > > >
> > > > However for normal Link and ajax links etc I get
> > > > ComponentNotFoundException  thrown as the new instance cannot find it
> > in
> > > > the session it seems.
> > > >
> > > > Clearly I'm not understanding how wicket manages the page state or
> I've
> > > > configured something wrong.
> > > >
> > > > Does wicket support full session failover ?
> > > >
> > > > Many thanks
> > > >
> > >
> >
>

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Hi Martin,

that was a typo on my part. I've been doing a lot more testing before I
replied to make sure things are as I say. This is what I am observing:


   - I have a 2 node tomcat cluster setup with apache balancing between
   them locally on my machine.
   - Testing with a very simple Wicket app I can see the replication is
   working fine when shutting down either instance.
   - Testing with our very heavy weight wicket app it sometimes work and
   sometimes does not.

Now the last point above I have narrowed down to our homepage. If I am not
on the homepage the replication seems to work ok. However if I am on the
homepage I always get a ComponentNotFoundException when failing over to the
other instance.
The homepage has an AbstractDefaultAjaxBehavior which is called once the
page is rendered, this in turn adds to the the page a DataView containing a
lot of content and links. The user needs to be logged in before they see
the homepage, so the session is already setup.

I don't know what it is about this page that breaks the replication. Is
there anything around the ajax part that could do this? Any pointers would
be most welcome as it will be a long long task to break that page down and
do rounds and rounds of cluster testing

many thanks




On Wed, Mar 22, 2017 at 12:34 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> "I can stop one of the instances and I'm not logged in"
> This statement says that you don't really have a properly configured
> failover.
> If those two Tomcat instances are in a cluster then the http sessions
> should be replicated and you should stay logged in no matter which one is
> serving the request.
> Wicket will store the used stateful page at the disks for all Tomcats in
> the cluster, if it the replication is actually working!
>
>
> On Wed, Mar 22, 2017 at 1:02 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hi,
> >
> > We have 2 instances of Tomcat running with Apache sitting in front
> > balancing between the Tomcat instances. I have session replication setup
> > which seems to work for basic bookmarkable links on the pages. I can stop
> > one of the instances and I'm not logged in as it failover to the other
> > instance.
> >
> > However for normal Link and ajax links etc I get
> > ComponentNotFoundException  thrown as the new instance cannot find it in
> > the session it seems.
> >
> > Clearly I'm not understanding how wicket manages the page state or I've
> > configured something wrong.
> >
> > Does wicket support full session failover ?
> >
> > Many thanks
> >
>

ComponentNotFoundException and Clustering failover

[Wayne W]

Hi,

We have 2 instances of Tomcat running with Apache sitting in front
balancing between the Tomcat instances. I have session replication setup
which seems to work for basic bookmarkable links on the pages. I can stop
one of the instances and I'm not logged in as it failover to the other
instance.

However for normal Link and ajax links etc I get
ComponentNotFoundException  thrown as the new instance cannot find it in
the session it seems.

Clearly I'm not understanding how wicket manages the page state or I've
configured something wrong.

Does wicket support full session failover ?

Many thanks

Re: Web sockets support clarification

[Wayne W]

Many thanks Martin

On Mon, Mar 20, 2017 at 8:45 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> On Fri, Mar 17, 2017 at 6:00 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hi,
> >
> > we are currently using Wicket 6.17 and use a version of Atmosphere jar
> > libraries (not the wicket version). Its never been great and have had
> lots
> > of production issues with it. I'm looking to replace it with straight web
> > sockets as the fall back long polling etc we never could get to work.
> >
>
> The integration with Atmosphere has been dropped for Wicket 8.x.
> There were way too many bugs with it.
>
>
> >
> > Looking at wicket documentation around web sockets am I correct in the
> > following:
> >
> > If the servlet container supports JSR356 (ie. tomcat 8) we only need to
> use
> > *wicket-native-websocket* which comprises of
> *wicket-native-websocket-core
> > *
> >  and *wicket-native-websocket-native?*
> >
>
> wicket-native-websocket-native is actually named wicket-native-websocket-
> javax.
>
>
> >
> > If we are on non JSR356 containers we need to use
> > *wicket-native-websocket-jetty/wicket-native-websocket-tomcat* ?
> >
>
> Correct!
>
>
> >
> > Is *wicket-native-websocket *production ready?
> >
>
> Yes, we think so!
> People use it successfully in their applications!
>
>
> > Is there any compatibility issues with Wicket 6.17?
> >
>
> 6.17 is not supported since a long time!
> You are recommended to upgrade to 6.26.0 or even better to 7.6.0.
>
>
> >
> >
> > Finally on a separate note where can I find a 'Whats new in Wicket 7.0' -
> > specifically new features etc? The change log is not very clear for me.
> >
>
> The migration guide has the most full information about the changes and
> improvements in 7.0.0:
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+7.0
> Any improvements in the following releases (like 7.1.0, 7.2.0, etc.) are in
> the JIRA release notes.
>
>
> >
> > Many thanks
> >
>

Web sockets support clarification

[Wayne W]

Hi,

we are currently using Wicket 6.17 and use a version of Atmosphere jar
libraries (not the wicket version). Its never been great and have had lots
of production issues with it. I'm looking to replace it with straight web
sockets as the fall back long polling etc we never could get to work.

Looking at wicket documentation around web sockets am I correct in the
following:

If the servlet container supports JSR356 (ie. tomcat 8) we only need to use
*wicket-native-websocket* which comprises of *wicket-native-websocket-core *
 and *wicket-native-websocket-native?*

If we are on non JSR356 containers we need to use
*wicket-native-websocket-jetty/wicket-native-websocket-tomcat* ?

Is *wicket-native-websocket *production ready?
Is there any compatibility issues with Wicket 6.17?


Finally on a separate note where can I find a 'Whats new in Wicket 7.0' -
specifically new features etc? The change log is not very clear for me.

Many thanks

Re: Single Page Applications (SPA), Wicket and the history ajax back issue

[Wayne W]

Hi Martin,

many thanks for this - I will have a look (just got back from a trip hence
delay!)


On Sun, Jul 17, 2016 at 9:05 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> You might be also interested in Wicketstuff UrlFragment project (
>
> https://github.com/wicketstuff/core/blob/723bf245a7a9619c670fa493d541fcd9feae92bd/urlfragment-parent/README.md
> )
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Sat, Jul 16, 2016 at 10:31 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
> > Hi,
> >
> > Here is a small demo application:
> > https://github.com/martin-g/blogs/tree/master/ajax-history
> > It uses HTML5 History API directly, so it won't work on old Internet
> > Explorers!
> > If you need to support old IE, good luck finding a decent JS library.
> > AFAIK https://github.com/browserstate/history.js is one of the best out
> > there, but looking at the number of open issues and PRs I wouldn't use it
> > in my applications.
> >
> > The demo application shows how to support Ajax history for "Ajax menu"
> use
> > case from the earlier mails in this thread. In the past I have used
> > something similar for Ajax pagination functionality.
> > The menu items show how to change the url's path, query string and/or
> > fragment
> > The impl just triggers the respective JS event on the respective Ajax
> > component for the history event. The rest is normal Wicket Ajax request.
> As
> > noted in the previous mail by clicking the browser's back button you will
> > not ask Wicket to load an old version of the page! From Wicket point of
> > view the navigation in the page always goes forward!
> >
> > This implementation is not in Wicket itself because I am sure it is not
> > generic enough for everyone's use cases (and because History API is not
> > available in old IEs!).
> > if you need help with a use case that doesn't work with this impl then
> > please create a demo application and I'll try to help!
> > If one day the implementation is generic enough it may land in Wicket!
> >
> > Have fun!
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Wed, Jul 13, 2016 at 10:55 AM, Wayne W <waynemailingli...@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> On Thu, Jul 7, 2016 at 11:28 PM, Martin Grigorov <
> >> martin.grigo...@gmail.com>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > It seems you use Wicket for several years now and you have no idea how
> >> to
> >> > use it!
> >> >
> >>
> >>
> >> Yes perhaps Martin, I do try but there's a lot too it.
> >>
> >>
> >> >
> >> > I have done this for a client of mine 4 years ago.
> >> > And I have explained how to do it few times in the mailing lists.
> >> > You could use HTML5 History API to manipulate the browser url on each
> >> Ajax
> >> > call. If you need to support old browsers (why?! almost no one does
> >> these
> >> > days) then you should use some JS library that falls back to using the
> >> > location fragment/hash.
> >> > The support of "back/forward" buttons is just registering an
> >> > AjaxEventBehavior that listens for "popState"/"hashchange" event.
> >> >
> >> >
> >> I did some extensive searching and only found a couple of threads about
> >> this:
> >>
> >>
> >>
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-td4660502.html
> >>
> >>
> >> The main issue seems that the page map is not updated (just overriden)
> for
> >> ajax requests from my reading before. I came to the conclusion trying to
> >> get wicket to support the back button would be difficult and somewhat
> >> hacky. It seems we'd end up with unknown behaviour and issues possibly
> >> occurring and therefore too much of a risk. Hence this thread.
> >>
> >>
> >>
> >> >
> >> > I will try to find time to write a blog article with a demo app at
> >> > wicketinaction.com soon.
> >> >
> >> >
> >>
> >> That would be great.
> >>
> >>
> >>
> >>
> >> >
> >> >
> >>
> >
> >
>

Re: Single Page Applications (SPA), Wicket and the history ajax back issue

[Wayne W]

Hi,

On Thu, Jul 7, 2016 at 11:28 PM, Martin Grigorov 
wrote:

> Hi,
>
> It seems you use Wicket for several years now and you have no idea how to
> use it!
>


Yes perhaps Martin, I do try but there's a lot too it.


>
> I have done this for a client of mine 4 years ago.
> And I have explained how to do it few times in the mailing lists.
> You could use HTML5 History API to manipulate the browser url on each Ajax
> call. If you need to support old browsers (why?! almost no one does these
> days) then you should use some JS library that falls back to using the
> location fragment/hash.
> The support of "back/forward" buttons is just registering an
> AjaxEventBehavior that listens for "popState"/"hashchange" event.
>
>
I did some extensive searching and only found a couple of threads about
this:

http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-td4660502.html


The main issue seems that the page map is not updated (just overriden) for
ajax requests from my reading before. I came to the conclusion trying to
get wicket to support the back button would be difficult and somewhat
hacky. It seems we'd end up with unknown behaviour and issues possibly
occurring and therefore too much of a risk. Hence this thread.



>
> I will try to find time to write a blog article with a demo app at
> wicketinaction.com soon.
>
>

That would be great.




>
>

Re: Single Page Applications (SPA), Wicket and the history ajax back issue

[Wayne W]

> So you don't use Ajax because of missing back button support?
> We have a feature request for that, but it didn't spark much interest:
>
> https://issues.apache.org/jira/browse/WICKET-5290




Yes in a lot of cases unfortunately. It confuses a lot of non tech users
who are used to using the navigation back button - we did some user testing
and a fair number of people still use it, from from a UX perspective its
not great dropping it. I did't see that request unfortunately




>
>
> Have fun
> Sven
>
>
>
> On 07.07.2016 14:13, Wayne W wrote:
>
>> Hi Sven,
>>
>> of course: Ok so this is simplified somewhat: lets say we have 4 main tab
>> areas of the application: Contacts, Files, Calendar, Tasks. When a user
>> navigates from one area to the next we need to currently do a whole page
>> refresh, where in fact all we really need to do is refresh a sub panel via
>> ajax. This already is more 'old school' as I put it in the fact the user
>> experiences the whole page refreshing rather than say a loading/spinner in
>> the main panel. We want to make the web pp fell more 'app like' rather
>> than
>> a succession of web pages. Another example is say we are in the "File" tab
>> and we want to drill down through some folders, at the moment we need to
>> refresh the page if we want to support the back button rather than load
>> via
>> ajax.
>>
>> It just gives a much less slick experience as the page reloads visually,
>> and there is more data sent over the wire - slower page loads. But
>> ultimately it about the users impression of the app and feeling like an
>> app
>> rather than a bunch of pages.
>>
>>
>> On Thu, Jul 7, 2016 at 1:01 PM, Sven Meier <s...@meiers.net> wrote:
>>
>> Hi,
>>>
>>> it would be interesting to hear what limitations you're fighting against.
>>> As a server-side rendered framework Wicket surely isn't the new kid on
>>> the
>>> block, but I can't think of anything forcing your application to be 'old
>>> school'.
>>>
>>> Can you be more specific?
>>>
>>> Sven
>>>
>>>
>>>
>>> Am 7. Juli 2016, 13:23, um 13:23, Wayne W <waynemailingli...@gmail.com>
>>> schrieb:
>>>
>>>> Hi,
>>>>
>>>> we're been using wicket for some time now and we have a very
>>>> established
>>>> application used by many clients. It is however feeling some what
>>>> dated,
>>>> due to the fact the we have to constantly reload pages to access
>>>> different
>>>> functionality/areas if the app. We use ajax fairly heavily within each
>>>> functional area.
>>>>
>>>> The problem is we are starting to 'feel' old school and we're loosing
>>>> out
>>>> to the competition that are based on the lasted SPA type JS frameworks
>>>> talking to APIs. They just feel more slick and more responsive.
>>>>
>>>> Doing some research it seems thats it not possible to transform our
>>>> current
>>>> wicket app into this form, mainly due to the issues around wicket ajax
>>>> state storage and history URL support in older browsers.
>>>>
>>>> Is this something the Wicket is never going to to attempt to support? I
>>>> cannot find anything around this subject.
>>>>
>>>> Having a huge investment in our Wicket based application, its going to
>>>> be
>>>> very very painful to move away from which we must do if we cannot keep
>>>> up
>>>> with the competition due to framework limitations.
>>>>
>>>> many thanks
>>>>
>>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Single Page Applications (SPA), Wicket and the history ajax back issue

[Wayne W]

Hi Sven,

of course: Ok so this is simplified somewhat: lets say we have 4 main tab
areas of the application: Contacts, Files, Calendar, Tasks. When a user
navigates from one area to the next we need to currently do a whole page
refresh, where in fact all we really need to do is refresh a sub panel via
ajax. This already is more 'old school' as I put it in the fact the user
experiences the whole page refreshing rather than say a loading/spinner in
the main panel. We want to make the web pp fell more 'app like' rather than
a succession of web pages. Another example is say we are in the "File" tab
and we want to drill down through some folders, at the moment we need to
refresh the page if we want to support the back button rather than load via
ajax.

It just gives a much less slick experience as the page reloads visually,
and there is more data sent over the wire - slower page loads. But
ultimately it about the users impression of the app and feeling like an app
rather than a bunch of pages.


On Thu, Jul 7, 2016 at 1:01 PM, Sven Meier <s...@meiers.net> wrote:

> Hi,
>
> it would be interesting to hear what limitations you're fighting against.
> As a server-side rendered framework Wicket surely isn't the new kid on the
> block, but I can't think of anything forcing your application to be 'old
> school'.
>
> Can you be more specific?
>
> Sven
>
>
>
> Am 7. Juli 2016, 13:23, um 13:23, Wayne W <waynemailingli...@gmail.com>
> schrieb:
> >Hi,
> >
> >we're been using wicket for some time now and we have a very
> >established
> >application used by many clients. It is however feeling some what
> >dated,
> >due to the fact the we have to constantly reload pages to access
> >different
> >functionality/areas if the app. We use ajax fairly heavily within each
> >functional area.
> >
> >The problem is we are starting to 'feel' old school and we're loosing
> >out
> >to the competition that are based on the lasted SPA type JS frameworks
> >talking to APIs. They just feel more slick and more responsive.
> >
> >Doing some research it seems thats it not possible to transform our
> >current
> >wicket app into this form, mainly due to the issues around wicket ajax
> >state storage and history URL support in older browsers.
> >
> >Is this something the Wicket is never going to to attempt to support? I
> >cannot find anything around this subject.
> >
> >Having a huge investment in our Wicket based application, its going to
> >be
> >very very painful to move away from which we must do if we cannot keep
> >up
> >with the competition due to framework limitations.
> >
> >many thanks
>

Single Page Applications (SPA), Wicket and the history ajax back issue

[Wayne W]

Hi,

we're been using wicket for some time now and we have a very established
application used by many clients. It is however feeling some what dated,
due to the fact the we have to constantly reload pages to access different
functionality/areas if the app. We use ajax fairly heavily within each
functional area.

The problem is we are starting to 'feel' old school and we're loosing out
to the competition that are based on the lasted SPA type JS frameworks
talking to APIs. They just feel more slick and more responsive.

Doing some research it seems thats it not possible to transform our current
wicket app into this form, mainly due to the issues around wicket ajax
state storage and history URL support in older browsers.

Is this something the Wicket is never going to to attempt to support? I
cannot find anything around this subject.

Having a huge investment in our Wicket based application, its going to be
very very painful to move away from which we must do if we cannot keep up
with the competition due to framework limitations.

many thanks

Re: ListenerInvocationNotAllowedException question / help

[Wayne W]

Hi Sven,

yes it was something else in the hierarchy - many thanks for the help.

On Mon, Nov 16, 2015 at 8:52 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> OK, I see.
> You are right!
>
>
> On Mon, Nov 16, 2015 at 9:48 PM, Sven Meier <s...@meiers.net> wrote:
>
> > Hi Martin,
> >
> > to my knowledge the usual pattern is to override #onConfigure() and set
> up
> > the visibility and enabling of the component for the next rendering *and*
> > the following 'ACTION phase':
> >
> >
> >
> http://wicketinaction.com/2011/11/implement-wicket-component-visibility-changes-properly/
> >
> > Usually I don't see any need to override #canCallListenerInterface(),
> > except in very special cases. I would not advice to override it
> > lightheartedly.
> >
> > From Wayne's description I deduced that he used the 'old' pattern to
> > override #isVisible(), which leads to
> ListenerInvocationNotAllowedException
> > if the condition for visibility and/or enabling changes between rendering
> > and the next incoming request.
> >
> > Regards
> > Sven
> >
> >
> >
> > On 16.11.2015 21:38, Martin Grigorov wrote:
> >
> >> Hi Sven,
> >>
> >> What I'm saying is that Wicket uses Component#canCallListenerInterface()
> >> to
> >> decide whether the listener interface method could be executed or not.
> >> See
> >>
> >>
> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/RequestListenerInterface.java#L207
> >>
> >> So overriding #onConfigure() won't help him because #onConfigure() is
> >> called later, after successful #onClick().
> >>
> >> He needs to override #canCallListenerInterface() if he needs to call
> >> onClick even on invisible/disabled component.
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Mon, Nov 16, 2015 at 9:31 PM, Sven Meier <s...@meiers.net> wrote:
> >>
> >> Hi Martin,
> >>>
> >>> I didn't understand your comment.
> >>>
> >>> Do you think Wayne might have overriden #canCallListenerInterface()?
> >>>
> >>> Regards
> >>> Sven
> >>>
> >>>
> >>>
> >>> On 16.11.2015 19:32, Martin Grigorov wrote:
> >>>
> >>> Hi,
> >>>>
> >>>> Actually org.apache.wicket.Component#canCallListenerInterface() is
> >>>> responsible for the ACTION phase.
> >>>> #onConfigure() is called in the RENDER phase, i.e. after onClick().
> >>>>
> >>>> Martin Grigorov
> >>>> Wicket Training and Consulting
> >>>> https://twitter.com/mtgrigorov
> >>>>
> >>>> On Mon, Nov 16, 2015 at 7:27 PM, Sven Meier <s...@meiers.net> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>>
> >>>>> this should work.
> >>>>>
> >>>>> Do you have #isVisible() or #isEnabled() overridden in one of the
> >>>>> component's parents?
> >>>>>
> >>>>> Have fun
> >>>>> Sven
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 16.11.2015 18:08, Wayne W wrote:
> >>>>>
> >>>>> Hi Sven,
> >>>>>
> >>>>>>
> >>>>>> I tried overriding :
> >>>>>>
> >>>>>> @Override
> >>>>>>
> >>>>>> protected void onConfigure()
> >>>>>>
> >>>>>> {
> >>>>>>
> >>>>>> setVisible(documentModel.getObject().isLocked());
> >>>>>>
> >>>>>> super.onConfigure();
> >>>>>>
> >>>>>> }
> >>>>>>
> >>>>>>
> >>>>>> and removing the isVisible() override but I still get the same
> >>>>>> exception.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
> >>>>>> Component rejected interface invocationComponent: 

Re: Pagemap help

[Wayne W]

Ok thanks Martijn for the clarification.

On Mon, Nov 16, 2015 at 2:06 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:

> Well, you can create a Wicket resource for the updates to avoid a
> pagemap lock, but it is essentially the price we pay for having a
> singe-threaded access to the component hierarchy.
>
> You can also create a servlet, but both options will block a thread on
> your server waiting for the processing to finish if you don't want
> polling. That is effectively a kill switch for your application (some
> users will double, triple or N-click links if things are not going
> fast enough).
>
> Martijn
>
>
> On Mon, Nov 16, 2015 at 2:57 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
> > Hi Martijn,
> >
> > are you basically saving that with wicket there is no way I can not avoid
> > the pagemap locking for a given ajax or iframe request when needed?
> >
> > BTW web sockets aren't supported in IE8.
> >
> > On Mon, Nov 16, 2015 at 1:47 PM, Martijn Dashorst <
> > martijn.dasho...@gmail.com> wrote:
> >
> >> you probably should look into websockets if you don't want polling.
> >>
> >> Martijn
> >>
> >> On Mon, Nov 16, 2015 at 12:50 PM, Wayne W <waynemailingli...@gmail.com>
> >> wrote:
> >> > Hi,
> >> >
> >> > I have a page that has a AbstractDefaultAjaxBehavior which adds a new
> >> panel
> >> > in the ajax request. This new panel can be a long running process to
> >> > generate some data. I'm find this is locking the page map so other
> >> requests
> >> > on that page get locked.
> >> >
> >> > How could I get around this aside from re-enginering the panel to
> >> > poll/notify? Is is possible to create a new page map? I looked at the
> >> > inline frame code but it doesn't seem to look any different regarding
> >> the
> >> > page map. I'd really like to avoid the polling solution if possible
> for
> >> > various reasons.
> >> >
> >> >
> >> > thanks
> >>
> >>
> >>
> >> --
> >> Become a Wicket expert, learn from the best: http://wicketinaction.com
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

ListenerInvocationNotAllowedException question / help

[Wayne W]

Hi,

I have a org.apache.wicket.markup.html.link.Link within a page this is
visible only if a certain criteria is met.

If user A visits this page the changes the criteria the link is visible.
The user can then click on the link for some other functionality.

However I'm finding is User B (in a different session) visits the same page
and changes the criteria so that the link is no longer visible but the user
A still has this page open and user A then clicks on the link
a ListenerInvocationNotAllowedException is thrown which I just don't
understand.

I would get it if user B somehow got the hit the url that represents that
link, but why does this link component in another session throw the
exception? Would it be because wicket is checking boolean isVisible() when
making this decision? (as we override the links isVisible() to show
depending on the criteria.

thanks

Re: Pagemap help

[Wayne W]

Hi Martijn,

are you basically saving that with wicket there is no way I can not avoid
the pagemap locking for a given ajax or iframe request when needed?

BTW web sockets aren't supported in IE8.

On Mon, Nov 16, 2015 at 1:47 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:

> you probably should look into websockets if you don't want polling.
>
> Martijn
>
> On Mon, Nov 16, 2015 at 12:50 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
> > Hi,
> >
> > I have a page that has a AbstractDefaultAjaxBehavior which adds a new
> panel
> > in the ajax request. This new panel can be a long running process to
> > generate some data. I'm find this is locking the page map so other
> requests
> > on that page get locked.
> >
> > How could I get around this aside from re-enginering the panel to
> > poll/notify? Is is possible to create a new page map? I looked at the
> > inline frame code but it doesn't seem to look any different regarding
> the
> > page map. I'd really like to avoid the polling solution if possible for
> > various reasons.
> >
> >
> > thanks
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: ListenerInvocationNotAllowedException question / help

[Wayne W]

Hi Sven,

I tried overriding :

@Override

protected void onConfigure()

{

setVisible(documentModel.getObject().isLocked());

super.onConfigure();

}


and removing the isVisible() override but I still get the same exception.


org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
Component rejected interface invocationComponent: [Link [Component id =
unlock2]] Listener: [RequestListenerInterface name=ILinkListener,
method=public abstract void
org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]

at org.apache.wicket.RequestListenerInterface.invoke(
RequestListenerInterface.java:212)

at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(
ListenerInterfaceRequestHandler.java:243)

at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(
ListenerInterfaceRequestHandler.java:236)

at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(
RequestCycle.java:862)

at org.apache.wicket.request.RequestHandlerStack.execute(
RequestHandlerStack.java:64)





any ideas?



On Mon, Nov 16, 2015 at 4:54 PM, Sven Meier <s...@meiers.net> wrote:

> Hi,
>
> >Would it be because wicket is checking boolean isVisible() when
> >making this decision? (as we override the links isVisible()
>
> indeed.
>
> You should override #onConfigure() and call #setVisible() instead of
> overriding #isVisible().
>
> Regards
> Sven
>
>
>
> On 16.11.2015 16:59, Wayne W wrote:
>
>> Hi,
>>
>> I have a org.apache.wicket.markup.html.link.Link within a page this is
>> visible only if a certain criteria is met.
>>
>> If user A visits this page the changes the criteria the link is visible.
>> The user can then click on the link for some other functionality.
>>
>> However I'm finding is User B (in a different session) visits the same
>> page
>> and changes the criteria so that the link is no longer visible but the
>> user
>> A still has this page open and user A then clicks on the link
>> a ListenerInvocationNotAllowedException is thrown which I just don't
>> understand.
>>
>> I would get it if user B somehow got the hit the url that represents that
>> link, but why does this link component in another session throw the
>> exception? Would it be because wicket is checking boolean isVisible() when
>> making this decision? (as we override the links isVisible() to show
>> depending on the criteria.
>>
>> thanks
>>
>>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Pagemap help

[Wayne W]

Hi,

I have a page that has a AbstractDefaultAjaxBehavior which adds a new panel
in the ajax request. This new panel can be a long running process to
generate some data. I'm find this is locking the page map so other requests
on that page get locked.

How could I get around this aside from re-enginering the panel to
poll/notify? Is is possible to create a new page map? I looked at the
inline frame code but it doesn't seem to look any different regarding  the
page map. I'd really like to avoid the polling solution if possible for
various reasons.


thanks

Re: Anyone know a Wiki component?

[Wayne W]

I suppose what I am asking is, does anyone know of a wiki markup engine
that plays well with wicket. I need to create wiki pages from within a
wicket application. I'm not looking for a WYSIWG editor. Basically I'd like
to create a (wicket) page that once you land there, enables the user to
create wiki pages. So really I'm looking for a some form of wiki
engine/markup thats going to be able to handle links jumping from user
generate content page to other user generated content. At the moment wicket
would not be able to handle the URLs I don't think. I'd like to wrap these
user generated pages within a wicket page (that has other wicket
components/panels such as header and main menu, search etc).

On Mon, Jun 1, 2015 at 11:02 AM, Martin Grigorov mgrigo...@apache.org
wrote:

 Hi,

 What functionality exactly do you need ?
 A Wiki is more a product than a component.
 Maybe you need a WYSIWYG editor ?

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Mon, Jun 1, 2015 at 12:55 PM, Wayne W waynemailingli...@gmail.com
 wrote:

  Hi,
 
  I'm looking for a wiki like component(s) as we need to add some wiki type
  functionality to a product. Anyone know of any projects or open source
  projects? I'd rather not start from scratch if there is something already
  out there. I see alots of full java based wiki apps but they are all
 based
  on JPS or struts,etc. Trying to find something that is wicket based, or
  just something reasonably simple that I can embed more easy.
 
  thanks
 

Anyone know a Wiki component?

[Wayne W]

Hi,

I'm looking for a wiki like component(s) as we need to add some wiki type
functionality to a product. Anyone know of any projects or open source
projects? I'd rather not start from scratch if there is something already
out there. I see alots of full java based wiki apps but they are all based
on JPS or struts,etc. Trying to find something that is wicket based, or
just something reasonably simple that I can embed more easy.

thanks

Re: ListenerInvocationNotAllowedException and InlineFrames

[Wayne W]

Hi Tobias,

no the InlineFrame is never disabled (or anything in the hierarchy) so I
don't know why this happens. I've overridden the isEnabledInHierarchy() to
return true to side step the issue for now. I will perhaps try and get
a quick start together to show the issue.

thanks

On Wed, Feb 18, 2015 at 5:48 PM, Tobias Soloschenko 
tobiassolosche...@googlemail.com wrote:

 Hi again,

 I had a look at the method isEnabledInHierarchy() in Component and it
 hasn't changed for about 2 years. Even the places the flags are used
 (RFLAG_ENABLED_IN_HIERARCHY_SET, RFLAG_ENABLED_IN_HIERARCHY_VALUE)
 haven't changed.

 kind regards

 Tobias

 Am 18.02.15 um 18:06 schrieb Wayne W:

 Wicket seems to think its not enabled  isEnabledInHierarchy() returns
 false

 randomly

 On Wed, Feb 18, 2015 at 4:48 PM, Wayne W waynemailingli...@gmail.com
 wrote:

  Hi,

 we're still stuck on this. I can reproduce it - it seems a bit random but
 I suspect it to do when the browser makes the request. I can hit the same
 page and sometimes its good and sometimes this exception is thrown.
 There's
 definitely something wrong here.

 org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedEx
 ception:
 Component rejected interface invocationComponent: [InlineFrame [Component
 id = customContent]] Listener: [RequestListenerInterface
 name=ILinkListener, method=public abstract void
 org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
  at
 org.apache.wicket.RequestListenerInterface.invoke(
 RequestListenerInterface.java:212)
  at
 org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandle
 r.invokeListener(ListenerInterfaceRequestHandler.java:243)
  at
 org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandle
 r.respond(ListenerInterfaceRequestHandler.java:236)
  at
 org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(
 RequestCycle.java:862)
  at
 org.apache.wicket.request.RequestHandlerStack.execute(
 RequestHandlerStack.java:64)
  at
 org.apache.wicket.request.cycle.RequestCycle.execute(
 RequestCycle.java:261)
  at
 org.apache.wicket.request.cycle.RequestCycle.
 processRequest(RequestCycle.java:218)
  at
 org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(
 RequestCycle.java:289)
  at
 org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(
 WicketFilter.java:259)
  at
 org.apache.wicket.protocol.http.WicketFilter.
 processRequest(WicketFilter.java:201)
  at
 org.apache.wicket.protocol.http.WicketFilter.doFilter(
 WicketFilter.java:282)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
 ApplicationFilterChain.java:239)
  at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(
 ApplicationFilterChain.java:206)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
 ApplicationFilterChain.java:239)
  at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(
 ApplicationFilterChain.java:206)
  at
 com.wideplay.warp.persist.PersistenceFilter$3.run(
 PersistenceFilter.java:141)
  at
 com.wideplay.warp.persist.internal.Lifecycles.
 failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
  at
 com.wideplay.warp.persist.PersistenceFilter.doFilter(
 PersistenceFilter.java:155)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
 ApplicationFilterChain.java:239)
  at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(
 ApplicationFilterChain.java:206)
  at
 org.apache.catalina.core.StandardWrapperValve.invoke(
 StandardWrapperValve.java:219)
  at
 org.apache.catalina.core.StandardContextValve.invoke(
 StandardContextValve.java:106)
  at
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(
 AuthenticatorBase.java:501)
  at
 org.apache.catalina.core.StandardHostValve.invoke(
 StandardHostValve.java:142)
  at
 org.apache.catalina.valves.ErrorReportValve.invoke(
 ErrorReportValve.java:79)
  at
 org.apache.catalina.core.StandardEngineValve.invoke(
 StandardEngineValve.java:88)
  at
 org.apache.catalina.connector.CoyoteAdapter.service(
 CoyoteAdapter.java:516)
  at
 org.apache.coyote.ajp.AbstractAjpProcessor.process(
 AbstractAjpProcessor.java:831)
  at
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.
 process(AbstractProtocol.java:659)
  at
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
 doRun(NioEndpoint.java:1558)
  at
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
 run(NioEndpoint.java:1515)
  at
 java.util.concurrent.ThreadPoolExecutor.runWorker(
 ThreadPoolExecutor.java:1145)
  at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(
 ThreadPoolExecutor.java:615)
  at
 org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
 TaskThread.java:61

Re: ListenerInvocationNotAllowedException and InlineFrames

[Wayne W]

Wicket seems to think its not enabled  isEnabledInHierarchy() returns false
randomly

On Wed, Feb 18, 2015 at 4:48 PM, Wayne W waynemailingli...@gmail.com
wrote:

 Hi,

 we're still stuck on this. I can reproduce it - it seems a bit random but
 I suspect it to do when the browser makes the request. I can hit the same
 page and sometimes its good and sometimes this exception is thrown. There's
 definitely something wrong here.

 org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
 Component rejected interface invocationComponent: [InlineFrame [Component
 id = customContent]] Listener: [RequestListenerInterface
 name=ILinkListener, method=public abstract void
 org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
 at
 org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:212)
 at
 org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:243)
 at
 org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:236)
 at
 org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
 at
 org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
 at
 org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261)
 at
 org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218)
 at
 org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289)
 at
 org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)
 at
 org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
 at
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at
 com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141)
 at
 com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
 at
 com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
 at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
 at
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
 at
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
 at
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
 at
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
 at
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516)
 at
 org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:831)
 at
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659)
 at
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558)
 at
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515)
 at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at
 org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.lang.Thread.run(Thread.java:744)

 On Fri, Dec 19, 2014 at 1:36 PM, Wayne W waynemailingli...@gmail.com
 wrote:

 Hi,

 we're trying to clear up our production logs at the moment and are going
 through errors. I cannot understand what is happen here. We're getting :

 org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
 Component rejected interface invocationComponent: [InlineFrame [Component
 id = customContent]] Listener: [RequestListenerInterface
 name=ILinkListener, method=public abstract void
 org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]

 Couple of points. The user can see and access this page no problem which
 has an inline frame which is displaying some html. However sometimes this
 exception is thrown. I don't understand why

Re: ListenerInvocationNotAllowedException and InlineFrames

[Wayne W]

Hi,

we're still stuck on this. I can reproduce it - it seems a bit random but I
suspect it to do when the browser makes the request. I can hit the same
page and sometimes its good and sometimes this exception is thrown. There's
definitely something wrong here.

org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
Component rejected interface invocationComponent: [InlineFrame [Component
id = customContent]] Listener: [RequestListenerInterface
name=ILinkListener, method=public abstract void
org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
at
org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:212)
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:243)
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:236)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289)
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141)
at
com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
at
com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516)
at
org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:831)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:744)

On Fri, Dec 19, 2014 at 1:36 PM, Wayne W waynemailingli...@gmail.com
wrote:

 Hi,

 we're trying to clear up our production logs at the moment and are going
 through errors. I cannot understand what is happen here. We're getting :

 org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
 Component rejected interface invocationComponent: [InlineFrame [Component
 id = customContent]] Listener: [RequestListenerInterface
 name=ILinkListener, method=public abstract void
 org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]

 Couple of points. The user can see and access this page no problem which
 has an inline frame which is displaying some html. However sometimes this
 exception is thrown. I don't understand why this is being thrown as the
 inline frame is not enable to disabled at any point and why does an inline
 frame have an onLinkClicked event? Looking at the source it seems it using
 this to load the actual content. Is this something to do with perhaps

Re: AttributeModifier not updated in Ajax request

[Wayne W]

Any ideas on this one?

On Thu, Jan 15, 2015 at 2:31 PM, Wayne W waynemailingli...@gmail.com
wrote:

 Hi,

 we have a list which gets updated via ajax. This works fine. I'm trying to
 get it so that the style attribute is updated as well. However even though
 I put break points in the getObject() and I can see its got the new User
 object the style attribute sent back via ajax is the old one even though
 the new user label is the correct one.

 Any ideas ?


 getAssignlistContainer().add( new DataViewUser(assignlist, provider)

 {

  @Override

 protected void populateItem(final ItemUser item)

 {

 item.setDefaultModel(new CompoundPropertyModelUser((IModelUser)
 item.getDefaultModel()));

 Label name = new Label(name);

 item.add(name);

 if (item.getModelObject() != null)

 name.add(AttributeModifier.replace(style, new ModelString()

 {

 @Override

 public String getObject()

 {

 User u = item.getModelObject();

 String f = background-color:  +
 LabelColourProvider.getColour(u.getInitials());

 return f;

 }

 }));

  }

 });

AttributeModifier not updated in Ajax request

[Wayne W]

Hi,

we have a list which gets updated via ajax. This works fine. I'm trying to
get it so that the style attribute is updated as well. However even though
I put break points in the getObject() and I can see its got the new User
object the style attribute sent back via ajax is the old one even though
the new user label is the correct one.

Any ideas ?


getAssignlistContainer().add( new DataViewUser(assignlist, provider)

{

 @Override

protected void populateItem(final ItemUser item)

{

item.setDefaultModel(new CompoundPropertyModelUser((IModelUser)
item.getDefaultModel()));

Label name = new Label(name);

item.add(name);

if (item.getModelObject() != null)

name.add(AttributeModifier.replace(style, new ModelString()

{

@Override

public String getObject()

{

User u = item.getModelObject();

String f = background-color:  +
LabelColourProvider.getColour(u.getInitials());

return f;

}

}));

 }

});

ListenerInvocationNotAllowedException and InlineFrames

[Wayne W]

Hi,

we're trying to clear up our production logs at the moment and are going
through errors. I cannot understand what is happen here. We're getting :

org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
Component rejected interface invocationComponent: [InlineFrame [Component
id = customContent]] Listener: [RequestListenerInterface
name=ILinkListener, method=public abstract void
org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]

Couple of points. The user can see and access this page no problem which
has an inline frame which is displaying some html. However sometimes this
exception is thrown. I don't understand why this is being thrown as the
inline frame is not enable to disabled at any point and why does an inline
frame have an onLinkClicked event? Looking at the source it seems it using
this to load the actual content. Is this something to do with perhaps the
session not being available? any ideas?

Does wicket instantiate a page even if the session has expired?

[Wayne W]

We have lots of really odd exceptions in our logs in production where
essentially the session is empty but pages are still being created.

Does wicket do this? and if so how do we handle the situation knowing that
data in the session is needed to build the page

thanks

Re: IPageRendererProvider - HTTP 500 issue

[Wayne W]

Hi Sven,

Well that might explain a lot then!

We hired someone to do the migration from wicket 1.4 to 6 for us as we
didn't have time or the expertise with the latest version.

Previously we used :

getRequestCycle().setRequestTarget(new RedirectRequestTarget())


and the consultant replaced that everywhere with:


getRequestCycle().scheduleRequestHandlerAfterCurrent(new
RedirectRequestHandler())


I will test with RedirectToUrlException




On Wed, Nov 19, 2014 at 1:02 PM, Sven Meier s...@meiers.net wrote:

 Hi,

 I'm not exactly sure what you're trying to do, but the following is just
 wrong:

 getRequestCycle().scheduleRequestHandlerAfterCurrent(new
 RedirectRequestHandler(http://localhost:8080/wicket/
 bookmarkable/com.mycompany.Foo2?ff=gg));

 This will result in two responses written to the client, one redirect to
 the currently requested page and one to the url you have provided.

 Why aren't you using a RedirectToUrlException?

 Regards
 Sven



 On 11/18/2014 08:35 PM, Wayne W wrote:

 Hi Sven,

 Kind of - however its seems to happen only in 6.17. In 6.18 it seems to
 work ok with the quick start, but with our code base it still happens even
 with 6.18. I see this fix https://issues.apache.org/
 jira/browse/WICKET-5689
 which seems somewhat related (nested redirects). Its still very odd that
 just changing the  setPageRendererProvider would change  the behaviour.

 For you reference here is the quick start can be found here:

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


 It produces this:

 WARN  - ServletHandler - /

 java.lang.IllegalStateException: Committed

 at org.eclipse.jetty.server.Response.resetBuffer(Response.java:1141)

 at org.eclipse.jetty.server.Response.sendRedirect(Response.java:493)

 at org.apache.wicket.protocol.http.servlet.ServletWebResponse.
 sendRedirect(
 ServletWebResponse.java:297)

 at
 org.apache.wicket.protocol.http.BufferedWebResponse$
 SendRedirectAction.invoke(
 BufferedWebResponse.java:400)

 at org.apache.wicket.protocol.http.BufferedWebResponse.writeTo(
 BufferedWebResponse.java:588)

 at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.
 stopBuffering(
 HeaderBufferingWebResponse.java:60)

 at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush(
 HeaderBufferingWebResponse.java:97)

 at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(
 WicketFilter.java:269)

 at org.apache.wicket.protocol.http.WicketFilter.processRequest(
 WicketFilter.java:201)

 at org.apache.wicket.protocol.http.WicketFilter.doFilter(
 WicketFilter.java:282)

 at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(
 ServletHandler.java:1291)

 at org.eclipse.jetty.servlet.ServletHandler.doHandle(
 ServletHandler.java:443
 )

 at org.eclipse.jetty.server.handler.ScopedHandler.handle(
 ScopedHandler.java:137)

 at org.eclipse.jetty.security.SecurityHandler.handle(
 SecurityHandler.java:556)

 at org.eclipse.jetty.server.session.SessionHandler.doHandle(
 SessionHandler.java:227)

 at org.eclipse.jetty.server.handler.ContextHandler.doHandle(
 ContextHandler.java:1044)

 at org.eclipse.jetty.servlet.ServletHandler.doScope(
 ServletHandler.java:372)

 at org.eclipse.jetty.server.session.SessionHandler.doScope(
 SessionHandler.java:189)

 at org.eclipse.jetty.server.handler.ContextHandler.doScope(
 ContextHandler.java:978)

 at org.eclipse.jetty.server.handler.ScopedHandler.handle(
 ScopedHandler.java:135)

 at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
 HandlerWrapper.java:116)

 at org.eclipse.jetty.server.Server.handle(Server.java:369)

 at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(
 AbstractHttpConnection.java:486)

 at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(
 BlockingHttpConnection.java:53)

 at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(
 AbstractHttpConnection.java:933)

 at
 org.eclipse.jetty.server.AbstractHttpConnection$
 RequestHandler.headerComplete(
 AbstractHttpConnection.java:995)

 at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)

 at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)

 at org.eclipse.jetty.server.BlockingHttpConnection.handle(
 BlockingHttpConnection.java:72)

 at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(
 SocketConnector.java:264)

 at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
 QueuedThreadPool.java:608)

 at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(
 QueuedThreadPool.java:543)

 at java.lang.Thread.run(Thread.java:680)

 Why in production it produces this is not yet clear but seems related:
 HTTP Status 500 - Cannot call sendRedirect() after the response has been
 committed
 --

 *type* Exception report

 *message* *Cannot call sendRedirect() after the response has been
 committed*

 *description* *The server encountered an internal error that prevented it
 from fulfilling this request

Re: IPageRendererProvider - HTTP 500 issue

[Wayne W]

)

org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282)

com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141)

com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)

com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155)


On Mon, Nov 17, 2014 at 7:16 PM, Sven Meier s...@meiers.net wrote:

 Can you reproduce the problem in a quickstart?

 Sven


 On 11/17/2014 06:46 PM, Wayne W wrote:

 Hi,

 We had the requirement that we needed to use
 RedirectPolicy.NEVER_REDIRECT for
 a single page in our app .
 We used this code:


 setPageRendererProvider(new IPageRendererProvider() {

 @Override

 public PageRenderer get(final RenderPageRequestHandler context) {

 return new WebPageRenderer(context) {

 @Override

 protected RedirectPolicy getRedirectPolicy() {

 RedirectPolicy result;

 if (!((WebRequest) RequestCycle.get().getRequest()).isAjax()

   context.getPage() instanceof ExternalShareDocumentPage) {

 result = RedirectPolicy.NEVER_REDIRECT;

 } else {

 result = super.getRedirectPolicy();

 }

 return result;

 }

 };

}

 });

 This seemed to work fine. However we made it live in production and we
 noticed that we where getting HTTP Status 500 - Cannot call
 sendRedirect()
 after the response has been committed  a lot. It seemed to happen with a
 flow like the following which was nothing to do with the
 ExternalShareDocumentPage
 tweak:

 User clicks on link which does a setResponcePage(foo1.class)
 in the constructor of foo1.class there is:
 if (certainCondition) {

 throw new RestartResponseException(foo2.class)
 }


 What I don't understand is why this is happening. It seems that by setting
 the PageRenderProvider the way the redirects/commit seems to change.
 Any ideas?



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

IPageRendererProvider - HTTP 500 issue

[Wayne W]

Hi,

We had the requirement that we needed to use RedirectPolicy.NEVER_REDIRECT for
a single page in our app .
We used this code:


setPageRendererProvider(new IPageRendererProvider() {

@Override

public PageRenderer get(final RenderPageRequestHandler context) {

return new WebPageRenderer(context) {

@Override

protected RedirectPolicy getRedirectPolicy() {

RedirectPolicy result;

if (!((WebRequest) RequestCycle.get().getRequest()).isAjax()

  context.getPage() instanceof ExternalShareDocumentPage) {

result = RedirectPolicy.NEVER_REDIRECT;

} else {

result = super.getRedirectPolicy();

}

return result;

}

};

  }

});

This seemed to work fine. However we made it live in production and we
noticed that we where getting HTTP Status 500 - Cannot call sendRedirect()
after the response has been committed  a lot. It seemed to happen with a
flow like the following which was nothing to do with the
ExternalShareDocumentPage
tweak:

User clicks on link which does a setResponcePage(foo1.class)
in the constructor of foo1.class there is:
if (certainCondition) {

throw new RestartResponseException(foo2.class)
}


What I don't understand is why this is happening. It seems that by setting
the PageRenderProvider the way the redirects/commit seems to change.
Any ideas?

Re: RenderStrategy.ONE_PASS_RENDER possible for single page?

[Wayne W]

Hi,

it looks like we cannot make the page stateless as we have many links that
require the model etc.

Martin- regarding RedirectPolicy#Never - is there any way we can 'mark' the
page to use that? As people are coming to this page from a mount url (with
a parameter), so we never get a chance to do something like:


 scheduleRequestHandlerAfterCurrent(new RenderPageRequestHandler(new
PageProvider(page),

RenderPageRequestHandler.RedirectPolicy.NEVER_REDIRECT));




On Thu, Nov 13, 2014 at 8:15 PM, Martin Grigorov mgrigo...@apache.org
wrote:

 See how RequestCycle#setResponsePage() works.
 You need to use RedirectPolicy#Never.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Thu, Nov 13, 2014 at 4:56 PM, Sven Meier s...@meiers.net wrote:

  Hi,
 
  your page doesn't become stateless, just by claiming it to be.
  #setStatelessHint() is just a hint.
 
  Here's a real stateless page:
 
 http://www.wicket-library.com/wicket-examples/stateless/foo
 
  Regards
  Sven
 
 
 
  On 11/13/2014 03:27 PM, Wayne W wrote:
 
  Hi Sven,
 
  I tried setting setStatelessHint(true); but it always does a 302
 redirect.
  I see something like this in the Net panel in Firebug:
 
  https://www.example.com/share/df43f  302
  https://www.example.com/share/df43f?1  200
 
  Any idea?
  thanks
 
  On Thu, Nov 13, 2014 at 11:07 AM, Sven Meier s...@meiers.net wrote:
 
   Hi,
 
  make your page stateless, then no redirection will occur.
 
  Sven
 
 
  On 11/13/2014 11:55 AM, Wayne W wrote:
 
   Hi,
 
  We have an issue with hyperlinks Microsoft Word and Excel documents.
 Its
  seems to vary from version and OS, but the long and short of it is
 that
  Word when a user clicks on a link it uses an internal library to try
 and
  access the page, and once it gets a HTTP 200 it will open the default
  browser. We have a page that is used for sharing files so it gets
 added
  to
  documents.
 
  We have several customers complaining they cannot open these links,
 and
  I
  can verify this seems to happen depending on OS (Mac is worse for
  example).
  After doing a lot of digging about the only thing we can do is make
 sure
  we
  return a HTTP 200 from the first request, as anything else seems to
  sometimes work, sometimes not.
 
  So to my question:
 
  Is it possible to set RenderStrategy.ONE_PASS_RENDER for a single page
  only? We don't really want to loose the advantages of the 302 redirect
  elsewhere
 
  Any ideas?
 
  many thanks
  Wayne
 
 
   -
  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: RenderStrategy.ONE_PASS_RENDER possible for single page?

[Wayne W]

Ah yes, brilliant - didn't think of that. Thanks Martin - that works a
treat.


On Fri, Nov 14, 2014 at 11:00 AM, Martin Grigorov mgrigo...@apache.org
wrote:

 You can setup your own PageRenderer
 via org.apache.wicket.Application#setPageRendererProvider.
 It should return the correct redirect policy per page type.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Fri, Nov 14, 2014 at 12:57 PM, Wayne W waynemailingli...@gmail.com
 wrote:

  Hi,
 
  it looks like we cannot make the page stateless as we have many links
 that
  require the model etc.
 
  Martin- regarding RedirectPolicy#Never - is there any way we can 'mark'
 the
  page to use that? As people are coming to this page from a mount url
 (with
  a parameter), so we never get a chance to do something like:
 
 
   scheduleRequestHandlerAfterCurrent(new RenderPageRequestHandler(new
  PageProvider(page),
 
  RenderPageRequestHandler.RedirectPolicy.NEVER_REDIRECT));
 
 
 
 
  On Thu, Nov 13, 2014 at 8:15 PM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   See how RequestCycle#setResponsePage() works.
   You need to use RedirectPolicy#Never.
  
   Martin Grigorov
   Wicket Training and Consulting
   https://twitter.com/mtgrigorov
  
   On Thu, Nov 13, 2014 at 4:56 PM, Sven Meier s...@meiers.net wrote:
  
Hi,
   
your page doesn't become stateless, just by claiming it to be.
#setStatelessHint() is just a hint.
   
Here's a real stateless page:
   
   http://www.wicket-library.com/wicket-examples/stateless/foo
   
Regards
Sven
   
   
   
On 11/13/2014 03:27 PM, Wayne W wrote:
   
Hi Sven,
   
I tried setting setStatelessHint(true); but it always does a 302
   redirect.
I see something like this in the Net panel in Firebug:
   
https://www.example.com/share/df43f  302
https://www.example.com/share/df43f?1  200
   
Any idea?
thanks
   
On Thu, Nov 13, 2014 at 11:07 AM, Sven Meier s...@meiers.net
 wrote:
   
 Hi,
   
make your page stateless, then no redirection will occur.
   
Sven
   
   
On 11/13/2014 11:55 AM, Wayne W wrote:
   
 Hi,
   
We have an issue with hyperlinks Microsoft Word and Excel
 documents.
   Its
seems to vary from version and OS, but the long and short of it is
   that
Word when a user clicks on a link it uses an internal library to
 try
   and
access the page, and once it gets a HTTP 200 it will open the
  default
browser. We have a page that is used for sharing files so it gets
   added
to
documents.
   
We have several customers complaining they cannot open these
 links,
   and
I
can verify this seems to happen depending on OS (Mac is worse for
example).
After doing a lot of digging about the only thing we can do is
 make
   sure
we
return a HTTP 200 from the first request, as anything else seems
 to
sometimes work, sometimes not.
   
So to my question:
   
Is it possible to set RenderStrategy.ONE_PASS_RENDER for a single
  page
only? We don't really want to loose the advantages of the 302
  redirect
elsewhere
   
Any ideas?
   
many thanks
Wayne
   
   
   
  -
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 + jsessionid and 302 issues

[Wayne W]

Perhaps your tomcats are not getting the session id? make sure your apache
is passing the JSESSION to the tomcat instance

ie ProxyPass / balancer://cluster/ stickysession=JSESSIONID nofailover=Off


On Thu, Nov 13, 2014 at 12:37 AM, Jason Novotny jason.novo...@gmail.com
wrote:

 Hi,

 I figured more detailed config info would be helpful. I want my production
 app to be accessible via https only. The connection is SSL to our Apache
 load balancer which is then http to our Tomcat7 instance.
 The Tomcat 7 connector is default:

  Connector port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 /

 Just not sure how to config the web.xml or if my tomcat config needs
 changing.

 Thanks, Jason


 On 11/12/14, 1:40 PM, Jason Novotny wrote:

 Hi wicketeers,

 I was hoping to get rid of the jsessionid that appears in the
 browsewr bar when running my wicket app under Tomcat 7, and I added the
 following to web.xml:

 session-config
 session-timeout30/session-timeout
 tracking-modeCOOKIE/tracking-mode
 /session-config

 However, now in production we get all these 302 redirects which are
 causing an infinite recursion. What is the best way to handle this? I also
 found a wiki page https://cwiki.apache.org/confluence/display/WICKET/SEO+
 -+Search+Engine+Optimization but wasn't sure if this also applied to
 using Wicket 6.

 Thanks, Jason



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

RenderStrategy.ONE_PASS_RENDER possible for single page?

[Wayne W]

Hi,

We have an issue with hyperlinks Microsoft Word and Excel documents. Its
seems to vary from version and OS, but the long and short of it is that
Word when a user clicks on a link it uses an internal library to try and
access the page, and once it gets a HTTP 200 it will open the default
browser. We have a page that is used for sharing files so it gets added to
documents.

We have several customers complaining they cannot open these links, and I
can verify this seems to happen depending on OS (Mac is worse for example).
After doing a lot of digging about the only thing we can do is make sure we
return a HTTP 200 from the first request, as anything else seems to
sometimes work, sometimes not.

So to my question:

Is it possible to set RenderStrategy.ONE_PASS_RENDER for a single page
only? We don't really want to loose the advantages of the 302 redirect
elsewhere

Any ideas?

many thanks
Wayne

Re: RenderStrategy.ONE_PASS_RENDER possible for single page?

[Wayne W]

Hi Sven,

I tried setting setStatelessHint(true); but it always does a 302 redirect.
I see something like this in the Net panel in Firebug:

https://www.example.com/share/df43f  302
https://www.example.com/share/df43f?1  200

Any idea?
thanks

On Thu, Nov 13, 2014 at 11:07 AM, Sven Meier s...@meiers.net wrote:

 Hi,

 make your page stateless, then no redirection will occur.

 Sven


 On 11/13/2014 11:55 AM, Wayne W wrote:

 Hi,

 We have an issue with hyperlinks Microsoft Word and Excel documents. Its
 seems to vary from version and OS, but the long and short of it is that
 Word when a user clicks on a link it uses an internal library to try and
 access the page, and once it gets a HTTP 200 it will open the default
 browser. We have a page that is used for sharing files so it gets added to
 documents.

 We have several customers complaining they cannot open these links, and I
 can verify this seems to happen depending on OS (Mac is worse for
 example).
 After doing a lot of digging about the only thing we can do is make sure
 we
 return a HTTP 200 from the first request, as anything else seems to
 sometimes work, sometimes not.

 So to my question:

 Is it possible to set RenderStrategy.ONE_PASS_RENDER for a single page
 only? We don't really want to loose the advantages of the 302 redirect
 elsewhere

 Any ideas?

 many thanks
 Wayne



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

Re: Wicket 6 Session issue

[Wayne W]

Hi Martin,

I think this might have solved it . Many thanks :-)

On Wed, Nov 5, 2014 at 1:49 PM, Martin Grigorov mgrigo...@apache.org
wrote:

 Thanks ! It is more clear now !


 On Wed, Nov 5, 2014 at 3:44 PM, Wayne W waynemailingli...@gmail.com
 wrote:

  Sorry Martin its not clear enough. This any better?
 
 
 1. Tomcat1 / Session A / Thread 1: User goes to :
 my.example.com/login
  (LoginPage.java)
 2. Tomcat1 / Session A / Thread 2: They log in
 3. Tomcat 1 / Session A / Thread 2 : We invalidate the session and do
 a
 redirect to : foo.example.com/login passing some parameters
 4. Tomcat 2 / Session B / Thread 1: In the constructor of LoginPage we
 verify the parameters and if valid setup up the new current session
 with
 the user's details (Session.setUser(user))
 5. Tomcat 2/ Session B / Thread 1: LoginPage then does
 a setResponsePage(Application.get().getHomePage());
 

 try by adding getSession().bind(); at step 5


 6. Tomcat 2/Session B / Thread
 1:  MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized()
 finds
 null in the Session (Session.getUser() )
 
 
 
 
  On Wed, Nov 5, 2014 at 11:22 AM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   Then your first mail misleads.
   Would you please explain again the steps with more details which step
 on
   which node happens.
  
   Martin Grigorov
   Wicket Training and Consulting
   https://twitter.com/mtgrigorov
  
   On Wed, Nov 5, 2014 at 1:01 PM, Wayne W waynemailingli...@gmail.com
   wrote:
  
Hi Martin,
   
I don't think this is anything to do with session replication, as we
invalidate the session at step 3 and its not about trying to pick the
session up on a different instance. Its about creating a new session
   from a
redirect where the issue seems. We do use sticky session load
 balancing
   via
the JSESSION cookie on apache.
   
   
   
On Wed, Nov 5, 2014 at 10:56 AM, Martin Grigorov 
 mgrigo...@apache.org
  
wrote:
   
 Hi,

 As far as I know the session replication supporting code is the
 same
since
 Wicket 1.4.1 (or 1.4.2).

 The Wicket Session object is saved as an attribute in the
  HttpSession.
The
 HttpSession is replicated by Tomcat itself. What is your Tomcat
  config
 related to replication ?
 Do you use sticky sessions ? It seems you don't but I have to ask.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Wed, Nov 5, 2014 at 12:43 PM, Wayne W 
  waynemailingli...@gmail.com
 wrote:

  Hi,
 
  we recently migrated to 6.17 from 4.x. Something we are now
experiencing
 is
  an odd session problem in production.
 
  We have 2 tomcats load balance running the front end wicket code.
  We
 have a
  certain flow that goes like this:
 
 
 1. User goes to : my.example.com/login (LoginPage.java)
 2. They log in
 3. We invalidate the session and do a redirect to :
  foo.example.com/login
 passing some parameters
 4. In the constructor of LoginPage we verify the parameters
 and
  if
 valid
 setup up the new current session with the user's details
 5. LoginPage then does
 a setResponsePage(Application.get().getHomePage());
 
  This on a single node/machine/instance of tomcat works great and
  with
  Wicket 4 it also worked great in a 2 node/instance load balanced
 situation
  however we have a problem.
 
  Problem:
  If at step 3 the redirect gets load balances to a different
  instance
   of
  tomcat, step 4 works fine (the request is read the the new
 session
  is
got
  and the user info set on it). But this is when it gets really
 odd.
Step 5
  is executed fine, but when the home page is constructed
  our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized()
  is
  called as normal, and when we check the session to see if the
 users
 details
  are ok, there is no user in the session at all and we have a
   different
  session !
 
  Any ideas at all what is happening here? Did something change
  around
the
  session handling? I'm wondering if its something to do with the
 302
  redirect to the new URL with parameters?
 
  many thanks
 

   
  
 

Wicket 6 Session issue

[Wayne W]

Hi,

we recently migrated to 6.17 from 4.x. Something we are now experiencing is
an odd session problem in production.

We have 2 tomcats load balance running the front end wicket code. We have a
certain flow that goes like this:


   1. User goes to : my.example.com/login (LoginPage.java)
   2. They log in
   3. We invalidate the session and do a redirect to : foo.example.com/login
   passing some parameters
   4. In the constructor of LoginPage we verify the parameters and if valid
   setup up the new current session with the user's details
   5. LoginPage then does
   a setResponsePage(Application.get().getHomePage());

This on a single node/machine/instance of tomcat works great and with
Wicket 4 it also worked great in a 2 node/instance load balanced situation
however we have a problem.

Problem:
If at step 3 the redirect gets load balances to a different instance of
tomcat, step 4 works fine (the request is read the the new session is got
and the user info set on it). But this is when it gets really odd. Step 5
is executed fine, but when the home page is constructed
our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized()  is
called as normal, and when we check the session to see if the users details
are ok, there is no user in the session at all and we have a different
session !

Any ideas at all what is happening here? Did something change around the
session handling? I'm wondering if its something to do with the 302
redirect to the new URL with parameters?

many thanks

Re: Wicket 6 Session issue

[Wayne W]

Hi Martin,

I don't think this is anything to do with session replication, as we
invalidate the session at step 3 and its not about trying to pick the
session up on a different instance. Its about creating a new session from a
redirect where the issue seems. We do use sticky session load balancing via
the JSESSION cookie on apache.



On Wed, Nov 5, 2014 at 10:56 AM, Martin Grigorov mgrigo...@apache.org
wrote:

 Hi,

 As far as I know the session replication supporting code is the same since
 Wicket 1.4.1 (or 1.4.2).

 The Wicket Session object is saved as an attribute in the HttpSession. The
 HttpSession is replicated by Tomcat itself. What is your Tomcat config
 related to replication ?
 Do you use sticky sessions ? It seems you don't but I have to ask.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Wed, Nov 5, 2014 at 12:43 PM, Wayne W waynemailingli...@gmail.com
 wrote:

  Hi,
 
  we recently migrated to 6.17 from 4.x. Something we are now experiencing
 is
  an odd session problem in production.
 
  We have 2 tomcats load balance running the front end wicket code. We
 have a
  certain flow that goes like this:
 
 
 1. User goes to : my.example.com/login (LoginPage.java)
 2. They log in
 3. We invalidate the session and do a redirect to :
  foo.example.com/login
 passing some parameters
 4. In the constructor of LoginPage we verify the parameters and if
 valid
 setup up the new current session with the user's details
 5. LoginPage then does
 a setResponsePage(Application.get().getHomePage());
 
  This on a single node/machine/instance of tomcat works great and with
  Wicket 4 it also worked great in a 2 node/instance load balanced
 situation
  however we have a problem.
 
  Problem:
  If at step 3 the redirect gets load balances to a different instance of
  tomcat, step 4 works fine (the request is read the the new session is got
  and the user info set on it). But this is when it gets really odd. Step 5
  is executed fine, but when the home page is constructed
  our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized()  is
  called as normal, and when we check the session to see if the users
 details
  are ok, there is no user in the session at all and we have a different
  session !
 
  Any ideas at all what is happening here? Did something change around the
  session handling? I'm wondering if its something to do with the 302
  redirect to the new URL with parameters?
 
  many thanks
 

Re: Wicket 6 Session issue

[Wayne W]

Sorry Martin its not clear enough. This any better?


   1. Tomcat1 / Session A / Thread 1: User goes to : my.example.com/login
(LoginPage.java)
   2. Tomcat1 / Session A / Thread 2: They log in
   3. Tomcat 1 / Session A / Thread 2 : We invalidate the session and do a
   redirect to : foo.example.com/login passing some parameters
   4. Tomcat 2 / Session B / Thread 1: In the constructor of LoginPage we
   verify the parameters and if valid setup up the new current session with
   the user's details (Session.setUser(user))
   5. Tomcat 2/ Session B / Thread 1: LoginPage then does
   a setResponsePage(Application.get().getHomePage());
   6. Tomcat 2/Session B / Thread
   1:  MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized() finds
   null in the Session (Session.getUser() )




On Wed, Nov 5, 2014 at 11:22 AM, Martin Grigorov mgrigo...@apache.org
wrote:

 Then your first mail misleads.
 Would you please explain again the steps with more details which step on
 which node happens.

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Wed, Nov 5, 2014 at 1:01 PM, Wayne W waynemailingli...@gmail.com
 wrote:

  Hi Martin,
 
  I don't think this is anything to do with session replication, as we
  invalidate the session at step 3 and its not about trying to pick the
  session up on a different instance. Its about creating a new session
 from a
  redirect where the issue seems. We do use sticky session load balancing
 via
  the JSESSION cookie on apache.
 
 
 
  On Wed, Nov 5, 2014 at 10:56 AM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   Hi,
  
   As far as I know the session replication supporting code is the same
  since
   Wicket 1.4.1 (or 1.4.2).
  
   The Wicket Session object is saved as an attribute in the HttpSession.
  The
   HttpSession is replicated by Tomcat itself. What is your Tomcat config
   related to replication ?
   Do you use sticky sessions ? It seems you don't but I have to ask.
  
   Martin Grigorov
   Wicket Training and Consulting
   https://twitter.com/mtgrigorov
  
   On Wed, Nov 5, 2014 at 12:43 PM, Wayne W waynemailingli...@gmail.com
   wrote:
  
Hi,
   
we recently migrated to 6.17 from 4.x. Something we are now
  experiencing
   is
an odd session problem in production.
   
We have 2 tomcats load balance running the front end wicket code. We
   have a
certain flow that goes like this:
   
   
   1. User goes to : my.example.com/login (LoginPage.java)
   2. They log in
   3. We invalidate the session and do a redirect to :
foo.example.com/login
   passing some parameters
   4. In the constructor of LoginPage we verify the parameters and if
   valid
   setup up the new current session with the user's details
   5. LoginPage then does
   a setResponsePage(Application.get().getHomePage());
   
This on a single node/machine/instance of tomcat works great and with
Wicket 4 it also worked great in a 2 node/instance load balanced
   situation
however we have a problem.
   
Problem:
If at step 3 the redirect gets load balances to a different instance
 of
tomcat, step 4 works fine (the request is read the the new session is
  got
and the user info set on it). But this is when it gets really odd.
  Step 5
is executed fine, but when the home page is constructed
our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized()  is
called as normal, and when we check the session to see if the users
   details
are ok, there is no user in the session at all and we have a
 different
session !
   
Any ideas at all what is happening here? Did something change around
  the
session handling? I'm wondering if its something to do with the 302
redirect to the new URL with parameters?
   
many thanks
   
  
 

Re: Is this possible?

[Wayne W]

Many thanks - I will have a look.

On Thu, Oct 16, 2014 at 7:21 PM, Zala Pierre GOUPIL goupilpie...@gmail.com
wrote:

 You can try wicket-quickview, which is based on the stuff in the link
 Martin provided. It works pretty well IMHO, and it is Wicket 6.0 compliant:

 https://github.com/vineetsemwal/quickview

 Regards,

 Pierre





 On Thu, Oct 16, 2014 at 6:28 PM, Martin Grigorov mgrigo...@apache.org
 wrote:

  Hi,
 
  I'd recommend you to use JS for something like this.
  See
 
 
 http://wicketinaction.com/2008/10/repainting-only-newly-created-repeater-items-via-ajax/
  .
  Additionally I'd recommend to use event delegation, i.e. one change
  listener on the dataview that handles 'change' for all items.
 
  Martin Grigorov
  Wicket Training and Consulting
  https://twitter.com/mtgrigorov
 
  On Thu, Oct 16, 2014 at 7:09 PM, Wayne W waynemailingli...@gmail.com
  wrote:
 
   We have a page that has a rather big DataView list. We need to be able
 to
   make insertions and removals of this list without sending back the
 whole
   list via AJAX as its a bit slow over the wire.
  
   Is it possible to add a new element and return and insert that into the
   list? Obviously we could insert in new item with JS on the page but we
   still want to take advantage to any handlers in wicket for that new
 item
   inserted into the list.
  
   So something like:
  
   onSubmit(AjaxRequestTarget target)
  
   {
  
   ItemMyModel item = new Item(); //!!
  
   item.add(new AjaxFormComponentUpdatingBehavior(onchange)
  
   { protected void onUpdate(AjaxRequestTarget target) {...}});
  
  
   thelist.add(item); //!!
  
   ...
  
   target.appendJavaScript(js);
  
   }
  
  
  
   thanks
  
   Wayne
  
 



 --
 La vie est source de joie, la mort est source de paix, seule la transition
 est difficile.

Re: Anyway of stopping this?

[Wayne W]

Hi Sven,

We don't set the RenderStrategy so we should (in wicket 6) be using this
default strategy.

Any other idea?

On Thu, Oct 16, 2014 at 8:28 PM, Sven Meier s...@meiers.net wrote:

 Hi,

 what RenderStrategy are you using?

 WIth REDIRECT_TO_BUFFER Wicket should send a redirect to the search
 results page after your form's submit.

 Sven


 On 10/16/2014 07:16 PM, Wayne W wrote:

 Hi,

 we have a simple search form:

 FormString form = new FormString(searchForm) {

 @Override

 protected void onSubmit() {

 PageParameters params = new PageParameters();

 params.add(0, search);

 setResponsePage(SearchResultsPage.class, params);

 }


   };


 This displays a list of results with each row having a
 BookmarkablePageLink
 to another page. If the user uses the form , the results are displayed.
 Then they click on any of the links they are taken to the next page.


 However when they click 'Back' on the browser they always get 'Confirm
 Form
 Resubmission' in Chrome, 'Document Expired' in Firefox etc. How can we
 stop
 this and just display the result page?


 What I actually see in the URLs is:

 server.com/searchFormPage

 server.com?34-1.IFormSubmitListener-baseCont-search-searchForm

 server.com/specificPage/842978

 Then they click on back and you get

 server.com?34-1.IFormSubmitListener-baseCont-search-searchForm



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

Re: Anyway of stopping this?

[Wayne W]

Ah sorry please ignore me. It seems we had this in the code:

// use this page renderer provider to avoid useless 302 redirections

setPageRendererProvider(new IPageRendererProvider() {

@Override

public PageRenderer get(RenderPageRequestHandler context) {

return new WebPageRenderer(context) {

@Override

protected RedirectPolicy getRedirectPolicy() {

RedirectPolicy result;

if (!((WebRequest) RequestCycle.get().getRequest()).isAjax()) {

result = RedirectPolicy.NEVER_REDIRECT;

} else {

result = super.getRedirectPolicy();

}

return result;

}

};

}

});

On Fri, Oct 17, 2014 at 4:28 PM, Wayne W waynemailingli...@gmail.com
wrote:

 Hi Sven,

 We don't set the RenderStrategy so we should (in wicket 6) be using this
 default strategy.

 Any other idea?

 On Thu, Oct 16, 2014 at 8:28 PM, Sven Meier s...@meiers.net wrote:

 Hi,

 what RenderStrategy are you using?

 WIth REDIRECT_TO_BUFFER Wicket should send a redirect to the search
 results page after your form's submit.

 Sven


 On 10/16/2014 07:16 PM, Wayne W wrote:

 Hi,

 we have a simple search form:

 FormString form = new FormString(searchForm) {

 @Override

 protected void onSubmit() {

 PageParameters params = new PageParameters();

 params.add(0, search);

 setResponsePage(SearchResultsPage.class, params);

 }


   };


 This displays a list of results with each row having a
 BookmarkablePageLink
 to another page. If the user uses the form , the results are displayed.
 Then they click on any of the links they are taken to the next page.


 However when they click 'Back' on the browser they always get 'Confirm
 Form
 Resubmission' in Chrome, 'Document Expired' in Firefox etc. How can we
 stop
 this and just display the result page?


 What I actually see in the URLs is:

 server.com/searchFormPage

 server.com?34-1.IFormSubmitListener-baseCont-search-searchForm

 server.com/specificPage/842978

 Then they click on back and you get

 server.com?34-1.IFormSubmitListener-baseCont-search-searchForm



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

Is this possible?

[Wayne W]

We have a page that has a rather big DataView list. We need to be able to
make insertions and removals of this list without sending back the whole
list via AJAX as its a bit slow over the wire.

Is it possible to add a new element and return and insert that into the
list? Obviously we could insert in new item with JS on the page but we
still want to take advantage to any handlers in wicket for that new item
inserted into the list.

So something like:

onSubmit(AjaxRequestTarget target)

{

ItemMyModel item = new Item(); //!!

item.add(new AjaxFormComponentUpdatingBehavior(onchange)

{ protected void onUpdate(AjaxRequestTarget target) {...}});


thelist.add(item); //!!

...

target.appendJavaScript(js);

}



thanks

Wayne

Anyway of stopping this?

[Wayne W]

Hi,

we have a simple search form:

FormString form = new FormString(searchForm) {

@Override

protected void onSubmit() {

PageParameters params = new PageParameters();

params.add(0, search);

setResponsePage(SearchResultsPage.class, params);

}


 };


This displays a list of results with each row having a BookmarkablePageLink
to another page. If the user uses the form , the results are displayed.
Then they click on any of the links they are taken to the next page.


However when they click 'Back' on the browser they always get 'Confirm Form
Resubmission' in Chrome, 'Document Expired' in Firefox etc. How can we stop
this and just display the result page?


What I actually see in the URLs is:

server.com/searchFormPage

server.com?34-1.IFormSubmitListener-baseCont-search-searchForm

server.com/specificPage/842978

Then they click on back and you get

server.com?34-1.IFormSubmitListener-baseCont-search-searchForm

Double submit with AjaxFormSubmitBehavior

[Wayne W]

Hi,

I have basically the following:

Form f = new Form('form) {

}

Double submit with AjaxFormSubmitBehavior

[Wayne W]

Hi,

I have basically the following

FormString typeInForm = new FormString(typeInForm) {
  @Override
  protected void onSubmit()
  {
doSubmit(this);
  }
};

AjaxFormSubmitBehavior ajax = new AjaxFormSubmitBehavior(onkeyup) {

  @Override
  protected void onSubmit(AjaxRequestTarget target) {
target.add(resultList);

  }
}
textField.add(ajax);

When the user just enter something in the the text field the both the form
onSubmit gets called once and the AjaxFormSubmitBehavior onSubmit  also
gets called. So far so good. However when the user hits return on the page
the forms onSubmit gets called twice. Looking at the call stack the second
call is coming from the AjaxFormSubmitBehavior.onEvent which intern calls
Form.onFormSubmitted


We need the form onSubmits because if the  user hits return  the
AjaxFormSubmitBehavior onSubmit never gets called.

How can I stop onSubmit getting called twice? I looked for a
'markformsubmitdone' or something but didn't see anything

many thanks

Error page for AJAX requests

[Wayne W]

Hi all,

we've recently moved to Wicket 6.17 from 1.4 and I'm having trouble with
NOT showing the default wicket error page when a runtime exception is
thrown from an AjaxLink.

I've set the following in the application:

getApplicationSettings().setInternalErrorPage(ErrorPage.class);

getExceptionSettings().setUnexpectedExceptionDisplay(IExceptionSettings.
SHOW_INTERNAL_ERROR_PAGE);


but it does't seem to have any effect. We override
AbstractRequestCycleListener and specifically IRequestHandler
onException(RequestCycle cycle, Exception e) to perform different error
pages depending on the nature of the exception (for example entitynotfound
exception). We check here to see if its an ajax request like this:


if(cycle.getRequest() instanceof WebRequest  ((WebRequest)
cycle.getRequest()).isAjax()) {

return null; // let wicket take care of it.

}


Is there anyway for ajax requests I can do something like this (which is
what we return for non-ajax requests):


return new RenderPageRequestHandler(new PageProvider(new ErrorPage(page,
e)));


many thanks

UploadProgressBar Wicket 6 issues

[Wayne W]

Hi,

we've just migrated from 1.4 to the 6.13 and I have to say its been very
painful! So many API breaks. We're also experiencing many UI issues mainly
brought about by how resources are now included. Anyhow we're though most
of them, however I cannot get the UploadProgressBar to work at all. I've
read just about everything I can find on the subject including adding
setUploadProgressUpdatesEnabled
in the Application.

I couldn't find anything about this setting, but presume I need it.

Any ideas what else I need to get this to work again?

XSS vulnerability

[Wayne W]

Hi

Its been brought to my attention that wicket seems to be XSS vulnerable. We
have a public internet facing form, and by simply putting

img src=x onerror=prompt(1);

In the fields you can get a js prompt appearing. As add the fields have
validators on them, all code is passing through the wicket based code. If
there any way to stop this?

We're using wicket 1.4.21 but I've also just tried with the latest version
of wicket with the same response.

Its a standard form and we're not setting setEscapeModelStrings or anything.

How can we sanitise the fields on an onError?

thanks

Re: XSS vulnerability

[Wayne W]

Hi All,


please ignore this. We found the issue - it was due to AbstractBehavior
that was being added to the textfields that outputs the raw value in a div
before escaping it.




On Wed, May 7, 2014 at 11:23 AM, Wayne W waynemailingli...@gmail.comwrote:

 Hi

 Its been brought to my attention that wicket seems to be XSS vulnerable.
 We have a public internet facing form, and by simply putting

 img src=x onerror=prompt(1);

 In the fields you can get a js prompt appearing. As add the fields have
 validators on them, all code is passing through the wicket based code. If
 there any way to stop this?

 We're using wicket 1.4.21 but I've also just tried with the latest version
 of wicket with the same response.

 Its a standard form and we're not setting setEscapeModelStrings or
 anything.

 How can we sanitise the fields on an onError?

 thanks

Re: Migrating from 1.4.21 to 6

[Wayne W]

I have about 200,000 lines of code. I don't have time to rewrite the app.
Is there a fundamental difference the requires a rewrite?


On Tue, Dec 31, 2013 at 4:34 PM, Martin Sachs sachs.mar...@gmail.comwrote:

 Hi,

 i would mirgate to 6 directly, if your application is relativ small and
 without special requesthandlings, webtrackings and last but not least
 javascript dependencies to other framework than wicket.

 e.g. for an application with round about 5.000 lines of code its easier
 to update. For big applications (20.000 LoC) an rewrite with wicket-6
 could be better and cleaner with the same effort as updating.

 cheers and good luck ;)

 Am 30.12.2013 17:45, schrieb Wayne W:
  Hi All,
 
  I'm wanting to upgrade to the latest version of wicket but am worried
 about
  the possible impact. Also I'm wanting to know the best migration plan. Do
  you think it would be best to jump straight to 6 or first upgrade to 5?
 
  Any tips or ideas would be much appreciated.
 
  thanks
 


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

Migrating from 1.4.21 to 6

[Wayne W]

Hi All,

I'm wanting to upgrade to the latest version of wicket but am worried about
the possible impact. Also I'm wanting to know the best migration plan. Do
you think it would be best to jump straight to 6 or first upgrade to 5?

Any tips or ideas would be much appreciated.

thanks

Could not find root ajax-response element . Wicket 1.5.3

[Wayne W]

Hi,

this is something I have found - I'm getting a consistent ajax error
in this scenario:

I have a page that has an AjaxLink (Add Product), that displays a
panel that contains a form. If I use AjaxFormSubmitBehavior to perform
the submit on the form the sequence of events is:
 - Communication problem
-  Could not find root ajax-response element (in the ajax window)
- onError called (or onSubmit if form contents ok)
- page refreshed.

If I use AjaxSubmitLink all works as expected.


Any idea why this happens?


Wayne

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

Re: Model problem with my own component

[Wayne W]

thanks Sven

On Wed, Jan 11, 2012 at 6:46 PM, Sven Meier s...@meiers.net wrote:
 Hi,


 add(new ProductImage(image, getDefaultModel());

 this line is causing the null product.


 I thought when setting the default model all the children are visited and
 model updated.?

 No, not at all. Either you have to do that by yourself or you have to give
 ProductImage a more intelligent model:

     add(new ProductImage(image, new AbstractReadOnlyModelProduct() {
          public Product getObject() {
              return getDefaultModel().getObject();
          }
     });

 Hope this helps
 Sven

 Am 11.01.2012 08:01, schrieb Wayne W:

 Hello,

 I cannot get my component model to update correctly when being set. I
 have list of products and when I click on the name via ajax I update a
 Product panel to display the info. In that panel I have my component
 that displays the image of the product. sudo code:

 ProductPanel(id, IModelProduct  model) {
   super(id, new CompoundPropertyModel(model));

   add(new Label(name);
   add(new ProductImage(image, getDefaultModel());
 }

 ProductImage extends Image {
   ProductImage(id, IModelProduct  model) {
     super( id, model);

    Product p = getDefaultModelObject();
    // p always null

 }


 AjaxLink() {
   onclick(target) {
     productPanel.setDefaultModel(getModel());
     target.add(productPanel);
 }}


 When I click on the link the name is updated and displayed correctly.
 However in the ProductImage component the product is always null. I
 thought when setting the default model all the children are visited
 and model updated.? I;ve tried debugging but get cannot figure it out.

 Any ideas?

 -
 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

Model problem with my own component

[Wayne W]

Hello,

I cannot get my component model to update correctly when being set. I
have list of products and when I click on the name via ajax I update a
Product panel to display the info. In that panel I have my component
that displays the image of the product. sudo code:

ProductPanel(id, IModelProduct model) {
  super(id, new CompoundPropertyModel(model));

  add(new Label(name);
  add(new ProductImage(image, getDefaultModel());
}

ProductImage extends Image {
  ProductImage(id, IModelProduct model) {
super( id, model);

   Product p = getDefaultModelObject();
   // p always null

}


AjaxLink() {
  onclick(target) {
productPanel.setDefaultModel(getModel());
target.add(productPanel);
}}


When I click on the link the name is updated and displayed correctly.
However in the ProductImage component the product is always null. I
thought when setting the default model all the children are visited
and model updated.? I;ve tried debugging but get cannot figure it out.

Any ideas?

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