Great thanks!
On Tue, Jun 28, 2022 at 9:18 PM Sven Meier <s...@meiers.net> 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 <waynemailingli...@gmail.com>
> 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 <s...@meiers.net> 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 <s...@meiers.net> 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 <s...@meiers.net> 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 <s...@meiers.net>
> >> 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 <s...@meiers.net>
> >>>>> wrote:
> >>>>>>>>>>>> Hi Wayne,
> >>>>>>>>>>>>
> >>>>>>>>>>>> the Eclipse .project still has 9.1.1 on the classpath:
> >>>>>>>>>>>>
> >>>>>>>>>>>> <classpathentry kind="var"
> >>>>>>>>>>>>
> >> 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
> >>>>>>>>>>>>> <waynemailingli...@gmail.com
> >>>>>>>>>>>> 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 <s...@meiers.net
> >
> >>>>>>>>>>>>>> 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 <
> >> s...@meiers.net
> >>>>>>>>>> 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 <
> >>> s...@meiers.net>
> >>>>>>>>>> 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
> >>>>>>>>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>>>>> 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
> >>>>>
> >>>>>
> >>> ---------------------------------------------------------------------
> >>> 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
>
>
