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
> >
> >
>
--
Andrea Del Bene.
Apache Wicket committer.
