It should be released tomorrow evening (CEST). If you feel brave enough :-) you can use the staging repository right now: https://repository.apache.org/content/repositories/orgapachewicket-1100
On Thu, Sep 7, 2017 at 1:56 PM, Brian Cullen <brian.cul...@cdl.co.uk> wrote: > Thanks for that... I was aware. Ironically that bug is the reason we > haven't moved to 7.8 yet. > > Hopefully the new version will be released soon. > > Brian. > > -----Original Message----- > From: Emond Papegaaij [mailto:emond.papega...@topicus.nl] > Sent: 07 September 2017 12:54 > To: users@wicket.apache.org > Subject: Re: Possible Issues with Page Store > > Before you spend another day on troubleshooting again: check WICKET-6457. > It's a regression caused by the fix for WICKET-6387 which will cause the > pagestore to keep growing on some containers (like wildfly). It is fixed in > 7.8.1 which is in the process of being released at this moment. > > Emond > > On donderdag 7 september 2017 11:45:19 CEST Brian Cullen wrote: > > As is the way with these things I find that this issue has already > > been addressed by WICKET-6387 and is fixed in Wicket 7.8. > > > I wish I had found that earlier. > > > > Brian. > > > > > > > > -----Original Message----- > > From: Brian Cullen [mailto:brian.cul...@cdl.co.uk] > > Sent: 07 September 2017 11:42 > > To: 'users@wicket.apache.org' <users@wicket.apache.org> > > Subject: Possible Issues with Page Store > > > > Hello, > > > > I'm working with Wicket 7.7 and have hit something I don't understand > > relating to how pages are written and retrieved from the > > DiskDataStore. I'm not sure if this is the correct list to post this > > but I would appreciate any assistance people can provide. > > > Essentially the issue I'm having is that as part of the end of the > > request cycle the commitRequest method is called on the PageManager. > > This eventually translates to a call to storeTouchedPages on the > > PageStoreManager. As I understand it this method creates a session > > entry if necessary and then stores the page instances with it - this, > > by default, leads to the DiskDataStore saving each page asynchronously. > > > The issue I have is where the setSessionAttributes method is called > > after storing the pages. This leads to the session attribute listeners > > being called. In this case the object is of type > > PageStoreManager$SessionEntry which clears the page store when the > valueUnbound method is invoked on it. > > If you are using the default asynch page store then there is always a > > chance that the page will be stored after the setSessionAttributes > > method call clears the page store but there doesn't seem to be any > > guarantee of this - if it was a synchronous store it will never work > > as far as I can tell. > > > Obviously this will only be an issue if the page isn't in the session > > cache for some reason but to my limited understanding of this area it > > doesn't seem like the functionality is correct. Can anyone advise, is > > this a bug or am I looking at this the wrong way? > > > Finally, on a related point, when I was investigating this issue I > > noticed that the asynchronous flag of the application StoreSettings is > never used. > > There is a check at DefaultPageManagerProvider:60 to make sure that > > the underlying data source can support asynchronous operation but I > > would have thought that the StoreSettings should also be checked as > > part of this if statement - is that the case? > > > Regards, > > > > Brian. > > <http://www.cdl.co.uk/> > > > > > > > > <http://twitter.com/CDL_Software> > > <http://www.facebook.com/CDL-Software> > > <http://www.linkedin.com/company/cdl-cheshire-datasystems-ltd-> > > > > > Please consider the environment - Do you really need to print this email? > > > > This email is intended only for the person(s) named above and may > > contain private and confidential information. If it has come to you in > > error, please destroy and permanently delete any copy in your > > possession, and contact us on +44 (0)161 480 4420. The information in > > this email is copyright (c) CDL Group Holdings Limited. We cannot accept > > liability for any loss or damage sustained as a result of software > > viruses. It is your responsibility to carry out such virus checking as > > is necessary before opening any attachment. > > > Cheshire Datasystems Limited uses software which automatically screens > > incoming emails for inappropriate content and attachments. If the > > software identifies such content or attachment, the email will be > > forwarded to our Technology department for checking. You should be > > aware that any email that you send to Cheshire Datasystems Limited is > subject to this procedure. > > ---------------------------------------------------------------------- > > ----- > > --- Cheshire Datasystems Limited, Strata House, Kings Reach Road, > > Stockport, > > SK4 2HD Registered in England and Wales with company number 3991057 > > VAT > > registration: 727 1188 33 > > > > --------------------------------------------------------------------- > 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 > >
