Re: IndicatorAware and BookmarkablePageLink
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=87917 ? On Fri, Oct 24, 2014 at 6:39 PM, msalman wrote: > Hi Martin > > Thanks for your response. And yes this explains the behavior I have seen. > Any way the busy indicator can be shown during the entire page unloading > and > unloading process? > > Thanks. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/IndicatorAware-and-BookmarkablePageLink-tp4668056p4668082.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Regards - Ernesto Reinaldo Barreiro
Re: Wicket error page runs twice
Hi, It seems like the error page is being rendered after a redirect. That's why the request cycle is empty, because it is a new one. On Oct 25, 2014 1:42 AM, "Entropy" wrote: > I have a requirement that when certain kinds of exceptions are thrown, I > want > to customize my exception error page. I stuffed the exception into the > requestcycle and retrieve it in the page like so: > > Exception exception = > getRequestCycle().getMetaData(ESPApplication.EXCEPTION_KEY); > > I watch through breakpoints or log statements and the exception is provided > the first time through, but after it processes it, the error page runs a > second time, this time with a null in that value. the result is that my > error page is not getting what it needs, and renders without the needed > info. > > Why would the error page run twice? I don't see any additional exceptions > in the log, and the error page does render...it just renders as if the > exception object were null. > > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Wicket-error-page-runs-twice-tp4668093.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Wicket error page runs twice
I have a requirement that when certain kinds of exceptions are thrown, I want to customize my exception error page. I stuffed the exception into the requestcycle and retrieve it in the page like so: Exception exception = getRequestCycle().getMetaData(ESPApplication.EXCEPTION_KEY); I watch through breakpoints or log statements and the exception is provided the first time through, but after it processes it, the error page runs a second time, this time with a null in that value. the result is that my error page is not getting what it needs, and renders without the needed info. Why would the error page run twice? I don't see any additional exceptions in the log, and the error page does render...it just renders as if the exception object were null. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-error-page-runs-twice-tp4668093.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: jquery DataTable + wicket Cannot bind a listener
I should add I'm using Wicket 6.17. Thanks, Jason On 10/24/14, 10:47 AM, Jason Novotny wrote: Hi, I'm using latest jquery DataTable with a ListView and in wicket:head of the page, I initiate the DataTable: $(function () { $('.datatable_executed').dataTable({ 'lengthChange': false, 'dom': '<"top"<"doc-filter"><"holder"ip>>t', "language": {"info": "_START_-_END_ of _TOTAL_"}, "aaSorting": [], 'iDisplayLength': 12 }); }); It all looks good, however because one of my columns contains AjaxLinks, I get an error from my wicket debug window with the following: "Wicket.Ajax: Cannot bind a listener for event "click" on element "elementId" because the element is not in the DOM" The thing is the links seem to actually work on the first page, but when I click -> to go to the next page the links don't work. Has anyone experienced this before or have any idea how I can debug this? Thanks, Jason - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
jquery DataTable + wicket Cannot bind a listener
Hi, I'm using latest jquery DataTable with a ListView and in wicket:head of the page, I initiate the DataTable: $(function () { $('.datatable_executed').dataTable({ 'lengthChange': false, 'dom': '<"top"<"doc-filter"><"holder"ip>>t', "language": {"info": "_START_-_END_ of _TOTAL_"}, "aaSorting": [], 'iDisplayLength': 12 }); }); It all looks good, however because one of my columns contains AjaxLinks, I get an error from my wicket debug window with the following: "Wicket.Ajax: Cannot bind a listener for event "click" on element "elementId" because the element is not in the DOM" The thing is the links seem to actually work on the first page, but when I click -> to go to the next page the links don't work. Has anyone experienced this before or have any idea how I can debug this? Thanks, Jason - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: IndicatorAware and BookmarkablePageLink
Hi Martin Thanks for your response. And yes this explains the behavior I have seen. Any way the busy indicator can be shown during the entire page unloading and unloading process? Thanks. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/IndicatorAware-and-BookmarkablePageLink-tp4668056p4668082.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Page Parameters logging
Ya, this is definitely a band-aid fix, but the application is a bit of a Frankenstein's monster so encrypting the parameter everywhere it's used is a colossal task, though it's definitely the proper solution. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Page-Parameters-logging-tp4668053p4668075.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Page Parameters logging
Thanks, this is what I'm doing now, just wanted to make sure it was an ok idea. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Page-Parameters-logging-tp4668053p4668074.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: KeyInSessionSunJceCryptFactory doesn't work in Wicket 6.0
I'll ask our release manager to cut 6.18 next Friday. If the testing passes then it will be released around Nov 5. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Oct 24, 2014 at 3:21 PM, tomask79 wrote: > Thanks a lot Martin for quick reply. > > Please when is the release date of 6.18? > > thanks and have a nice weekend > > T. > > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/KeyInSessionSunJceCryptFactory-doesn-t-work-in-Wicket-6-0-tp4668070p4668072.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: KeyInSessionSunJceCryptFactory doesn't work in Wicket 6.0
Thanks a lot Martin for quick reply. Please when is the release date of 6.18? thanks and have a nice weekend T. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/KeyInSessionSunJceCryptFactory-doesn-t-work-in-Wicket-6-0-tp4668070p4668072.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: KeyInSessionSunJceCryptFactory doesn't work in Wicket 6.0
Hi, It has been fixed with https://issues.apache.org/jira/browse/WICKET-5326. Will be released with 6.18.0. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Oct 24, 2014 at 2:37 PM, tomask79 wrote: > Hi guys, > > in order to protect our portal before CSRF attacks we were using > KeyInSessionSunJceCryptFactory as following: > > Application class: > . > . > > > Where PostUrlCryptMapper was just simple filter class ensuring that just > POST URLs will be encrypted: > > > > This was working perfectly in Wicket 1.5! > > But now we're migrating to Wicket 6.0 and this stopped working and I don't > see any note in migration guide about this. > > I was debugging it and ListenerInterfaceRequestHandler doesn't even > come into CryptoMapper which is why POST action URL still remains > uncrypted > > I even tried the following code in Application class: > > > Guys, the only URLs which wicket 6.0 is able to encrypt natively are the > Resource URLs, which is pointless in my case > > Yes, I can tweak POST URL's in onUrlMapped in RequestCycle Listener for > example, but I would rather prefer to stick with my previous solution > > Guys please, what is the prefered way of crypting URLs in Wicket 6.0 In > order to prevent CSFR attacks... > > thanks in advance > > Tomas > > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/KeyInSessionSunJceCryptFactory-doesn-t-work-in-Wicket-6-0-tp4668070.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
KeyInSessionSunJceCryptFactory doesn't work in Wicket 6.0
Hi guys, in order to protect our portal before CSRF attacks we were using KeyInSessionSunJceCryptFactory as following: Application class: . . Where PostUrlCryptMapper was just simple filter class ensuring that just POST URLs will be encrypted: This was working perfectly in Wicket 1.5! But now we're migrating to Wicket 6.0 and this stopped working and I don't see any note in migration guide about this. I was debugging it and ListenerInterfaceRequestHandler doesn't even come into CryptoMapper which is why POST action URL still remains uncrypted I even tried the following code in Application class: Guys, the only URLs which wicket 6.0 is able to encrypt natively are the Resource URLs, which is pointless in my case Yes, I can tweak POST URL's in onUrlMapped in RequestCycle Listener for example, but I would rather prefer to stick with my previous solution Guys please, what is the prefered way of crypting URLs in Wicket 6.0 In order to prevent CSFR attacks... thanks in advance Tomas -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/KeyInSessionSunJceCryptFactory-doesn-t-work-in-Wicket-6-0-tp4668070.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lock timeout per page class
If you have a base page then BasePage#onInitialize() should be a good place. Or you could add the pageIds of the special/slow pages only in the map. Otherwise you may use PageRequestHandlerTracker#getLastHandler in a custom IRequestCycleListener#onDetach(). Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet wrote: > Hi Martin, > > Yeah, I thought about that too but I'm not sure of the best place to > build the pageId -> pageClassName map. Any advice about this? > > Once I'll get this working, I'll build a PR for the few changes I made > in Wicket (based on what you proposed earlier). Would be nice to have > them in 6.18. > > On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov > wrote: > > Hi Guillaume, > > > > Sorry for not thinking more carefully about this the first time! > > I'm afraid it is not possible to do it the way I suggested. > > PageAccessSynchronizer is the entry point to start using a page and it > > works only with pageId! > > > > Here is a new hackish approach: > > Store pageId -> pageClassName map in the Session. Then when > > PageAccessSynchronizer is requested to lock a page by id use that id to > > resolve the class name and to decide what timeout to use. > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet < > guillaume.s...@gmail.com> > > wrote: > > > >> Hi Martin, > >> > >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov > >> wrote: > >> > I'd like to avoid moving the logic that gets the timeout from > >> > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer > because > >> > this way it will use Application.get() everytime and most apps don't > need > >> > to pay for this. > >> > > >> > A way to make it possible for you is to remove the 'final' > >> > from org.apache.wicket.Session#getPageManager and introduce > overridable > >> > PageAccessSynchronizer#getTimeout(). This way you can use your own > >> > PageAccessSynchronizer. > >> > http://pastie.org/9667070 > >> > >> After a few experiments, here I am! > >> > >> So, it mostly works: I thought it would be better to add something like: > >> protected IProvider > >> newPageAccessSynchronizerProvider() > >> { > >> return new PageAccessSynchronizerProvider(); > >> } > >> in Session and call it from the constructor instead of removing the > >> final so I did that in my code. > >> > >> It works pretty well BUT I haven't found a way to get the page class > >> in getTimeout without having the risk to trigger a resolvePageInstance > >> which will try to lock and then call getTimeout leading to a wonderful > >> stack overflow exception when dealing with > >> ListenerInterfaceRequestHandler. > >> > >> Obviously (...) what interests me the most is the getTimeout in > >> ListenerInterfaceRequestHandler as it's often actions on buttons which > >> are long to run. > >> > >> Here is what I have in mind for my Session class: > >> https://gist.github.com/gsmet/3b9e2775d25fadcef5ef > >> > >> I must admit that an advice would be welcome as I wouldn't like to > >> have stack overflow errors popping out in weird edge cases. > >> > >> Thanks! > >> > >> -- > >> Guillaume > >> > >> - > >> 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: Lock timeout per page class
Hi Martin, Yeah, I thought about that too but I'm not sure of the best place to build the pageId -> pageClassName map. Any advice about this? Once I'll get this working, I'll build a PR for the few changes I made in Wicket (based on what you proposed earlier). Would be nice to have them in 6.18. On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov wrote: > Hi Guillaume, > > Sorry for not thinking more carefully about this the first time! > I'm afraid it is not possible to do it the way I suggested. > PageAccessSynchronizer is the entry point to start using a page and it > works only with pageId! > > Here is a new hackish approach: > Store pageId -> pageClassName map in the Session. Then when > PageAccessSynchronizer is requested to lock a page by id use that id to > resolve the class name and to decide what timeout to use. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet > wrote: > >> Hi Martin, >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov >> wrote: >> > I'd like to avoid moving the logic that gets the timeout from >> > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer because >> > this way it will use Application.get() everytime and most apps don't need >> > to pay for this. >> > >> > A way to make it possible for you is to remove the 'final' >> > from org.apache.wicket.Session#getPageManager and introduce overridable >> > PageAccessSynchronizer#getTimeout(). This way you can use your own >> > PageAccessSynchronizer. >> > http://pastie.org/9667070 >> >> After a few experiments, here I am! >> >> So, it mostly works: I thought it would be better to add something like: >> protected IProvider >> newPageAccessSynchronizerProvider() >> { >> return new PageAccessSynchronizerProvider(); >> } >> in Session and call it from the constructor instead of removing the >> final so I did that in my code. >> >> It works pretty well BUT I haven't found a way to get the page class >> in getTimeout without having the risk to trigger a resolvePageInstance >> which will try to lock and then call getTimeout leading to a wonderful >> stack overflow exception when dealing with >> ListenerInterfaceRequestHandler. >> >> Obviously (...) what interests me the most is the getTimeout in >> ListenerInterfaceRequestHandler as it's often actions on buttons which >> are long to run. >> >> Here is what I have in mind for my Session class: >> https://gist.github.com/gsmet/3b9e2775d25fadcef5ef >> >> I must admit that an advice would be welcome as I wouldn't like to >> have stack overflow errors popping out in weird edge cases. >> >> Thanks! >> >> -- >> Guillaume >> >> - >> 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: Lock timeout per page class
Hi Guillaume, Sorry for not thinking more carefully about this the first time! I'm afraid it is not possible to do it the way I suggested. PageAccessSynchronizer is the entry point to start using a page and it works only with pageId! Here is a new hackish approach: Store pageId -> pageClassName map in the Session. Then when PageAccessSynchronizer is requested to lock a page by id use that id to resolve the class name and to decide what timeout to use. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet wrote: > Hi Martin, > > On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov > wrote: > > I'd like to avoid moving the logic that gets the timeout from > > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer because > > this way it will use Application.get() everytime and most apps don't need > > to pay for this. > > > > A way to make it possible for you is to remove the 'final' > > from org.apache.wicket.Session#getPageManager and introduce overridable > > PageAccessSynchronizer#getTimeout(). This way you can use your own > > PageAccessSynchronizer. > > http://pastie.org/9667070 > > After a few experiments, here I am! > > So, it mostly works: I thought it would be better to add something like: > protected IProvider > newPageAccessSynchronizerProvider() > { > return new PageAccessSynchronizerProvider(); > } > in Session and call it from the constructor instead of removing the > final so I did that in my code. > > It works pretty well BUT I haven't found a way to get the page class > in getTimeout without having the risk to trigger a resolvePageInstance > which will try to lock and then call getTimeout leading to a wonderful > stack overflow exception when dealing with > ListenerInterfaceRequestHandler. > > Obviously (...) what interests me the most is the getTimeout in > ListenerInterfaceRequestHandler as it's often actions on buttons which > are long to run. > > Here is what I have in mind for my Session class: > https://gist.github.com/gsmet/3b9e2775d25fadcef5ef > > I must admit that an advice would be welcome as I wouldn't like to > have stack overflow errors popping out in weird edge cases. > > Thanks! > > -- > Guillaume > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >