Re: RestartResponseAtInterceptPageException problem in 1.5
Hi,
This behavior is by design.
I cannot say why AccessDeniedException is being thrown without
debugging it but I can suggest you to try:
LoginLink {
onClick() {
if (notLoggedIn) {
throw new RestartResponseAtInterceptPageException(new
RedirectPage(getOAuthUrl()));
}
}
On Tue, Jan 3, 2012 at 2:04 AM, Zac Bedell wrote:
> Greetings all,
>
> I've run into some trouble using RestartResponseAtInterceptPageException
> since moving from Wicket 1.4.13 to 1.5.3. The flow I'm implementing is a
> login via an OAuth service, so the user is redirected by way of RedirectPage
> to the OAuth provider and eventually ends up back at my site where
> continueToOriginalDestination() would send them back to the original page.
> The problem is that RestartResponseAtInterceptPageException is capturing the
> URL to the Link object which triggers the login rather than the Page
> containing the link, and the URL the user is eventually redirected to is
> incorrect. They end up with an AccessDeniedException rather than the
> originally requested page.
>
> The Wicket object hierarchy looks like:
>
> MyBasePage extends WebPage {
> public MyBasePage() {
> add(new LoginLink(…));
> }
> }
>
> LoginLink {
> onClick() {
> throw new RestartResponseAtInterceptPageException(new
> RedirectPage(getOAuthUrl()));
> }
> }
>
> // User clicks LoginLink on SomePage which extends MyBasePage, redirect to
> OAuth provider works correctly, ends up back at:
> AuthCompletedPage extends WebPage {
> public AuthCompletedPage() {
> markSessionLoggedIn(…);
> continueToOriginalDestination();
> }
> }
>
>
> All of the redirect plumbing seems to work fine, but stepping through shows
> that the URL captured in
> RestartResponseAtInterceptPageException.InterceptData.set() is the URL to the
> LoginLink component itself, not to the Page which hosts it. Specially, the
> URL captured looks like
> "/site/home?0-1.ILinkListener-pnlLogin-lnkTwitterLogin-lnk" whereas I would
> expect something more like "/site/home". In cases where the requested page
> already had page parameters, the ILinkListener bit as appended to existing
> parameters.
>
> When the smoke clears, the user ends up at AccessDeniedPage under the
> "ILinkListener" URL rather than seeing the original page redisplayed.
> Editing the URL to remove the query string at that point shows the home page
> as expected with the user properly authenticated.
>
> Drilling in with the debugger a bit, it looks like
> RestartResponseAtInterceptPageException.InterceptData.set() calls
> RequestCycle.get().getRequest().getOriginalUrl() which eventually delegates
> down to ServletWebRequest.getUrl(). I can understand why that URL would
> reflect the LoginLink object as it's in the Link's onClick handler, but my
> expectation (and the behavior in 1.4.13) would be that the Page hosting the
> Link would be saved for the eventual continueToOriginalDestination() rather
> than the link to the component executing the handler. I'm not sure if the
> AccessDenied is indicative of some other problem that might otherwise make
> this whole thing work properly, but it seems like a change in behavior at
> this point.
>
>
> So… Any advice would be appreciated. If there's some more correct way to
> handle authentication via third party OAuth redirect, I'm certainly open to
> changing my code.
>
> Thanks in advance,
> Zac Bedell
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RestartResponseAtInterceptPageException problem in 1.5
Greetings all,
I've run into some trouble using RestartResponseAtInterceptPageException since
moving from Wicket 1.4.13 to 1.5.3. The flow I'm implementing is a login via
an OAuth service, so the user is redirected by way of RedirectPage to the OAuth
provider and eventually ends up back at my site where
continueToOriginalDestination() would send them back to the original page. The
problem is that RestartResponseAtInterceptPageException is capturing the URL to
the Link object which triggers the login rather than the Page containing the
link, and the URL the user is eventually redirected to is incorrect. They end
up with an AccessDeniedException rather than the originally requested page.
The Wicket object hierarchy looks like:
MyBasePage extends WebPage {
public MyBasePage() {
add(new LoginLink(…));
}
}
LoginLink {
onClick() {
throw new RestartResponseAtInterceptPageException(new
RedirectPage(getOAuthUrl()));
}
}
// User clicks LoginLink on SomePage which extends MyBasePage, redirect to
OAuth provider works correctly, ends up back at:
AuthCompletedPage extends WebPage {
public AuthCompletedPage() {
markSessionLoggedIn(…);
continueToOriginalDestination();
}
}
All of the redirect plumbing seems to work fine, but stepping through shows
that the URL captured in
RestartResponseAtInterceptPageException.InterceptData.set() is the URL to the
LoginLink component itself, not to the Page which hosts it. Specially, the URL
captured looks like "/site/home?0-1.ILinkListener-pnlLogin-lnkTwitterLogin-lnk"
whereas I would expect something more like "/site/home". In cases where the
requested page already had page parameters, the ILinkListener bit as appended
to existing parameters.
When the smoke clears, the user ends up at AccessDeniedPage under the
"ILinkListener" URL rather than seeing the original page redisplayed. Editing
the URL to remove the query string at that point shows the home page as
expected with the user properly authenticated.
Drilling in with the debugger a bit, it looks like
RestartResponseAtInterceptPageException.InterceptData.set() calls
RequestCycle.get().getRequest().getOriginalUrl() which eventually delegates
down to ServletWebRequest.getUrl(). I can understand why that URL would
reflect the LoginLink object as it's in the Link's onClick handler, but my
expectation (and the behavior in 1.4.13) would be that the Page hosting the
Link would be saved for the eventual continueToOriginalDestination() rather
than the link to the component executing the handler. I'm not sure if the
AccessDenied is indicative of some other problem that might otherwise make this
whole thing work properly, but it seems like a change in behavior at this point.
So… Any advice would be appreciated. If there's some more correct way to
handle authentication via third party OAuth redirect, I'm certainly open to
changing my code.
Thanks in advance,
Zac Bedell
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: ModalWindow does not close cleanly
I noticed also that if I add a dummy window closed call back to my page: 1) In the modal window, calling window.close() sets the "shown" flag to false 2) My dummy callback causes ModalWindow.WindowClosedBehavior to respond. The current value of this shown flag is still true! Then the behavior sets it to false again. I believed that calling "window.close()" from inside a window that uses page does not close the window cleanly. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ModalWindow does not close cleanly
On 01/03/2012 12:30 AM, Nelson Segura wrote: The "shown" flag is set up to false by window.close(), but it stays as true in the context of the parent page. This prevents the page from being opened a second time. Maybe something similar to how you cannot pass pages directly to a modal, but instead should pass a page reference. I agree with you. Your problem seems very similar to the one of passing page to modal. I think this issue has to do with page serialization: when we try to open modal window a second time, Wicket uses the "old" versions of both main page and modal window where "shown" flag is true. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ModalWindow does not close cleanly
:) A patch will be nice, but ... I think this has to do with my modal window using page instead of panel. Could it be? The window clears up the "shown" flag correctly if I press in the "x" for the modal window, because the CloseButtonBehavior gets called, but then the Ajax Target being used is in the context of the parent page. The "x" icon sits outside the window. My close/cancel button is calling window.close() directly, but that is being executed inside the context of the modal page. The "shown" flag is set up to false by window.close(), but it stays as true in the context of the parent page. This prevents the page from being opened a second time. Maybe something similar to how you cannot pass pages directly to a modal, but instead should pass a page reference. If I provide a dummy WindowClosedCallback, then the flag gets clear in the context of the parent page. I don't know if what I am saying is clear or correct, but I don't exactly know where to start to fix this :( -nelson - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Hide page version query parameters
add the nofollow attribute to such links. -igor On Mon, Jan 2, 2012 at 11:05 AM, Taneli Korri wrote: > On Mon, Jan 2, 2012 at 9:47 AM, Martin Grigorov wrote: >> On Mon, Jan 2, 2012 at 8:18 AM, Taneli Korri wrote: >>> On Sat, Dec 31, 2011 at 4:31 PM, Martin Grigorov >>> wrote: On Sat, Dec 31, 2011 at 2:29 PM, Taneli Korri wrote: > On Sat, Dec 31, 2011 at 9:09 AM, Martin Grigorov > wrote: >> On Fri, Dec 30, 2011 at 11:43 PM, martin.dilger >> wrote: >>> hi, >>> you could try to change your render strategy to redirect to render, that >>> would dismiss the page >>> parameters version. >> >> This is not correct. >> The page id is encoded in the url only for stateful pages. Make your >> page stateless and it wont be there. >> > > OK, thanks for the info. > > If I remember correctly, in Wicket 1.4 stateful pages had also clean > urls if the page was mounted to a certain path, i.e. the page version > number was stored somewhere behind the scenes. I'm guessing this isn't > possible anymore in Wicket 1.5? Everything is possible. The new IRequestMapper are easily extensible and you can even use your own one. By default this special parameter is set so when the user presses F5 (Refresh) the page Wicket will deliver the same version of the page. Otherwise a new instance will be created without the knowledge of the exact version. Why do you want to hide this parameter ? >>> >>> Plain and simple, I like clean urls that can be bookmarked. >> >> The urls with the page id can be bookmarked. If the requested version >> of the page is not available then a new version is created and >> delivered. >> > > Ok, I think I can live with that. :) > >>> >>> Also some of the search engine bots save the crawled urls (with >>> parameters) and try to access them at a later time. I found this out >>> when I updated one of my sites and now I'm seeing a lot of 500 >>> Internal error responses in my web server logs. >> >> Can you paste the stacktrace of an exception caused by such request ? >> > > I should have been more clear, this case wasn't directly related to > the page version parameter, but to clean urls. > > The thing is that I had a few stateful links in the frontpage which > changed the page stylesheet. Now when I have removed the links, I'm > seeing some crawlers still trying to request them. > > For example, a get request to > /?0-1.ILinkListener-stylechooser-style1&wicket:interface=:1:stylechooser:style2::ILinkListener:: > throws this with Wicket 1.5.3: > > ERROR org.apache.wicket.DefaultExceptionMapper - Unexpected error occurred > org.apache.wicket.request.handler.ComponentNotFoundException: Could > not find component 'stylechooser:style1' on page 'class > net.korri.www.page.blog.BlogPage > at > org.apache.wicket.request.handler.PageAndComponentProvider.getComponent(PageAndComponentProvider.java:167) > at > org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getComponent(ListenerInterfaceRequestHandler.java:92) > at > org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248) > at > org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234) > at > org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750) > at > org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) > at > org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252) > at > org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209) > at > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280) > at > org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162) > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218) > at > com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:87) > at > org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176) > at > org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145) > at > org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92) > at > org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:381) > at > com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:87) > at > com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187) > at > com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265) > at > com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273) > at com.caucho.server.port.TcpConnection.run(TcpConnection
signOut and port
We're running a wicket app on jetty and having an issue with signout. The app runs on port 8443 and we have iptables redirecting from port 443. This lets us go to https://ourap.lab without port numbers and without having the web app run as root. Everything is great until we do signout. We have a LogoutPage that does this: AuthenticatedWebSession.get().signOut(); setResponsePage(HomePage.class); Works fine, we get sent to the Login page. Only problem is that the url has the :8443 port number in it. For some reason, this is the end of the world for our users. Any ideas? Thanks -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/signOut-and-port-tp4254767p4254767.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
Infinite loop for user authentication when running on Apache2 as frontend server.
Happy new year folks, I have tomcat server running application war file serving only ajp protocol. Apache2 is configured to serve my application using ajp. This works - sometimes :( So far I have not able to figure out what breaks it or what makes it work and looking for help. The description of the problem is little complicated Authentication on tomcat directly works expected. Authentication using apache2 as frontend server does work sometimes. Whenever user tries to access the page that needs to be authenticated, it seems like wicket does not do redirect to login page, but serves the login page internally. Browser url does not change to login page. So if I try to access a page say mypage, wicket sends redirect /mypage - but next redirect actually serves the login page. I tried debugging tomcat instance and it seems like wicket does not get session cookie and creates a new session. So what firebug shows is number of redirects to the same url until firefox gets bored and shows up the error message. Things get especially interesting if remember me flag is checked. You are logged in to half of the page and other half (like ajax service calls) return the response that you need to login. I have spent many hours trying to narrow the problem. On fresh browser with history cleaned up - specifically cookies, it all works very nicely. So apache2 does pass the cookies and wicket does see it. On the other hand if had logged in once and session expires (my theory, no proof), it does get into infinite redirect loop. Any help/pointers are greatly appreciated. Niranjan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Hide page version query parameters
On Mon, Jan 2, 2012 at 9:47 AM, Martin Grigorov wrote: > On Mon, Jan 2, 2012 at 8:18 AM, Taneli Korri wrote: >> On Sat, Dec 31, 2011 at 4:31 PM, Martin Grigorov >> wrote: >>> On Sat, Dec 31, 2011 at 2:29 PM, Taneli Korri wrote: On Sat, Dec 31, 2011 at 9:09 AM, Martin Grigorov wrote: > On Fri, Dec 30, 2011 at 11:43 PM, martin.dilger > wrote: >> hi, >> you could try to change your render strategy to redirect to render, that >> would dismiss the page >> parameters version. > > This is not correct. > The page id is encoded in the url only for stateful pages. Make your > page stateless and it wont be there. > OK, thanks for the info. If I remember correctly, in Wicket 1.4 stateful pages had also clean urls if the page was mounted to a certain path, i.e. the page version number was stored somewhere behind the scenes. I'm guessing this isn't possible anymore in Wicket 1.5? >>> >>> Everything is possible. >>> The new IRequestMapper are easily extensible and you can even use your own >>> one. >>> By default this special parameter is set so when the user presses F5 >>> (Refresh) the page Wicket will deliver the same version of the page. >>> Otherwise a new instance will be created without the knowledge of the >>> exact version. >>> >>> Why do you want to hide this parameter ? >>> >> >> Plain and simple, I like clean urls that can be bookmarked. > > The urls with the page id can be bookmarked. If the requested version > of the page is not available then a new version is created and > delivered. > Ok, I think I can live with that. :) >> >> Also some of the search engine bots save the crawled urls (with >> parameters) and try to access them at a later time. I found this out >> when I updated one of my sites and now I'm seeing a lot of 500 >> Internal error responses in my web server logs. > > Can you paste the stacktrace of an exception caused by such request ? > I should have been more clear, this case wasn't directly related to the page version parameter, but to clean urls. The thing is that I had a few stateful links in the frontpage which changed the page stylesheet. Now when I have removed the links, I'm seeing some crawlers still trying to request them. For example, a get request to /?0-1.ILinkListener-stylechooser-style1&wicket:interface=:1:stylechooser:style2::ILinkListener:: throws this with Wicket 1.5.3: ERROR org.apache.wicket.DefaultExceptionMapper - Unexpected error occurred org.apache.wicket.request.handler.ComponentNotFoundException: Could not find component 'stylechooser:style1' on page 'class net.korri.www.page.blog.BlogPage at org.apache.wicket.request.handler.PageAndComponentProvider.getComponent(PageAndComponentProvider.java:167) at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getComponent(ListenerInterfaceRequestHandler.java:92) at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248) at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218) at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:87) at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176) at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145) at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92) at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:381) at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:87) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265) at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:682) at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743) at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:662) at java.lang.Thread.run(Thread.java:662) The request was valid earlier, but now since I'
Re: ModalWindow does not close cleanly
a patch is welcome :) -igor On Mon, Jan 2, 2012 at 10:24 AM, Nelson Segura wrote: > Any hope this can be fixed for 1.5.4? I will hate having to change all > our modals to have a dummy call back to get it to work :( > -Nelson > > On Wed, Dec 21, 2011 at 2:59 PM, Nelson Segura wrote: >> I have created a ticket, and attached a quick start to it >> >> https://issues.apache.org/jira/browse/WICKET-4311 >> >> Notice that if you uncomment the dummy callback code, you will be able >> to reopen the modal. > > - > 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: Can't build wicket from updated trunk
skip the tests with -Dmaven.test.skip=true -igor On Mon, Jan 2, 2012 at 10:11 AM, Chris Colman wrote: > Well it certainly works a lot better with Maven 3.0.3! ;) > > It still can't build core because of some test failures: > > Running org.apache.wicket.protocol.http.StoredResponsesMapTest > Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 19.351 sec > <<< FAILURE! > Running org.apache.wicket.VisitorTest > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec > Running org.apache.wicket.ajax.AjaxBehaviorAndMetaDataTest > Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0 sec > Running org.apache.wicket.page.PageAccessSynchronizerTest > Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 22.488 sec > <<< FAILURE! > > Results : > > Failed tests: > getExpiredValue(org.apache.wicket.protocol.http.StoredResponsesMapTest) > testBlocking(org.apache.wicket.page.PageAccessSynchronizerTest) > > Tests run: 1264, Failures: 2, Errors: 0, Skipped: 2 > > >>-Original Message- >>From: Martin Grigorov [mailto:mgrigo...@apache.org] >>Sent: Monday, 2 January 2012 6:44 PM >>To: users@wicket.apache.org >>Subject: Re: Can't build wicket from updated trunk >> >>I don't set any JVM settings to be able to build Wicket... >> >>@Chris: do you have some globally exported MAVEN_OPTS which may interfere ? >> >>On Mon, Jan 2, 2012 at 6:52 AM, Matthias Gasser >> wrote: >>> You need to increase the heap space for maven. >>> >>> Just run the following line prior building: >>> >>> snip >>> set MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=128m >>> snap >>> >>> That should bring you through. >>> >>> -matthias >>> >>> Am 02.01.2012 um 05:43 schrieb Chris Colman: >>> I cloned the wicket git repos and then checked out branch wicket-1.5.x >>branch and the build broke in a different place (it got a bit further this >>time :) ) The build was done on a Windows XP box with 4GB RAM so I wouldn't have >>thought it would have run out of memory. [INFO] 1 error [INFO] - [INFO] - >>--- [ERROR] BUILD FAILURE [INFO] - >>--- [INFO] Compilation failure Failure executing javac, but could not parse the error: The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: Java heap space at >>com.sun.tools.javac.code.Scope$ImportScope.makeEntry(Scope.java:385) at com.sun.tools.javac.code.Scope.enter(Scope.java:196) at com.sun.tools.javac.code.Scope.enter(Scope.java:183) at >>com.sun.tools.javac.comp.MemberEnter.importAll(MemberEnter.java:132) at >>com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:509) at >>com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:446) at >>com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:387) at >>com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:819) at com.sun.tools.javac.code.Symbol.complete(Symbol.java:386) at >>com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:758) at com.sun.tools.javac.comp.Enter.complete(Enter.java:451) at com.sun.tools.javac.comp.Enter.main(Enter.java:429) at >>com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:819) at >>com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727) at com.sun.tools.javac.main.Main.compile(Main.java:353) at com.sun.tools.javac.main.Main.compile(Main.java:279) at com.sun.tools.javac.main.Main.compile(Main.java:270) at com.sun.tools.javac.Main.compile(Main.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at >>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 >>9) at >>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp >>l.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at >>org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacComp >>iler.java:554) at >>org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java >>:161) at >>org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.j >>ava:605) at >>org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128) at >>org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManag >>er.java:490) at >>org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLif >>ecycleExecutor.java:694) at >>org.apache.maven.lifecycle.DefaultL
Re: Can't open modal popups in ie8 or under
I applied the patch to my local version of 1.5.3, and it seems to solve this issue. On Fri, Dec 30, 2011 at 12:09 AM, northar wrote: > Yes, tested with 1.5-snapshot now (not extensively), and it seems to work. My > project manager will be glad > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Can-t-open-modal-popups-in-ie8-or-under-tp4241461p4245134.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 > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ModalWindow does not close cleanly
Any hope this can be fixed for 1.5.4? I will hate having to change all our modals to have a dummy call back to get it to work :( -Nelson On Wed, Dec 21, 2011 at 2:59 PM, Nelson Segura wrote: > I have created a ticket, and attached a quick start to it > > https://issues.apache.org/jira/browse/WICKET-4311 > > Notice that if you uncomment the dummy callback code, you will be able > to reopen the modal. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: What is the cause for log entry "ModificationWatcher - Cannot track modifications to resource"
Thanks Allen, that's why i was asking in list first. So if you agree i will file a jira issue. Per Am 02.01.2012 18:14, schrieb Allen Gilbert: Per, I ran into this problem recently and solved it by removing spaces from directory names in my project path. I plan to file a Jira issue at some point, as it seems that ModificationWatcher should be able to handle file paths with spaces... -Allen On Mon, Jan 2, 2012 at 4:42 AM, Per Newgro wrote: Hi, If i test my app by using Start.java i get the log entry INFO - ModificationWatcher- Cannot track modifications to resource file:/D:/Dokumente%20und%**20Einstellungen/per.n/Eigene%** 20Dateien/workspaces/work/**whataschranz/target/classes/** ch/newgro/shop/whataschranz/**welcome/HomePage.html If i change the HP Markup it's not reloaded. Google only pops up an answer by igor "not sure you can do anything about the message...just disable the logger for that class/package..." But disabling the log message is not solving the problem, that my markup modifications are not re-loaded :-). As far as i investigated this issue is a problem with the encoded path string (%20) used to load the resource by org.apache.wicket.util.**resource.locator.**ResourceStreamLocator#**locateByResourceFinder. I'm not an expert but i think i've read a message that something changed here (URI class or servlet-api) but maybe someone else already solved this. My question is - Is this a bug or can i configure something to make resource modification watcher working? Thanks Per --**--**- To unsubscribe, e-mail: users-unsubscribe@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: Can't build wicket from updated trunk
Well it certainly works a lot better with Maven 3.0.3! ;) It still can't build core because of some test failures: Running org.apache.wicket.protocol.http.StoredResponsesMapTest Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 19.351 sec <<< FAILURE! Running org.apache.wicket.VisitorTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running org.apache.wicket.ajax.AjaxBehaviorAndMetaDataTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0 sec Running org.apache.wicket.page.PageAccessSynchronizerTest Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 22.488 sec <<< FAILURE! Results : Failed tests: getExpiredValue(org.apache.wicket.protocol.http.StoredResponsesMapTest) testBlocking(org.apache.wicket.page.PageAccessSynchronizerTest) Tests run: 1264, Failures: 2, Errors: 0, Skipped: 2 >-Original Message- >From: Martin Grigorov [mailto:mgrigo...@apache.org] >Sent: Monday, 2 January 2012 6:44 PM >To: users@wicket.apache.org >Subject: Re: Can't build wicket from updated trunk > >I don't set any JVM settings to be able to build Wicket... > >@Chris: do you have some globally exported MAVEN_OPTS which may interfere ? > >On Mon, Jan 2, 2012 at 6:52 AM, Matthias Gasser > wrote: >> You need to increase the heap space for maven. >> >> Just run the following line prior building: >> >> snip >> set MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=128m >> snap >> >> That should bring you through. >> >> -matthias >> >> Am 02.01.2012 um 05:43 schrieb Chris Colman: >> >>> I cloned the wicket git repos and then checked out branch wicket-1.5.x >branch and the build broke in a different place (it got a bit further this >time :) ) >>> >>> The build was done on a Windows XP box with 4GB RAM so I wouldn't have >thought it would have run out of memory. >>> >>> [INFO] 1 error >>> [INFO] - >>> [INFO] - >--- >>> [ERROR] BUILD FAILURE >>> [INFO] - >--- >>> [INFO] Compilation failure >>> Failure executing javac, but could not parse the error: >>> >>> >>> The system is out of resources. >>> Consult the following stack trace for details. >>> java.lang.OutOfMemoryError: Java heap space >>> at >com.sun.tools.javac.code.Scope$ImportScope.makeEntry(Scope.java:385) >>> at com.sun.tools.javac.code.Scope.enter(Scope.java:196) >>> at com.sun.tools.javac.code.Scope.enter(Scope.java:183) >>> at >com.sun.tools.javac.comp.MemberEnter.importAll(MemberEnter.java:132) >>> at >com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:509) >>> at >com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:446) >>> at >com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:387) >>> at >com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:819) >>> at com.sun.tools.javac.code.Symbol.complete(Symbol.java:386) >>> at >com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:758) >>> at com.sun.tools.javac.comp.Enter.complete(Enter.java:451) >>> at com.sun.tools.javac.comp.Enter.main(Enter.java:429) >>> at >com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:819) >>> at >com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727) >>> at com.sun.tools.javac.main.Main.compile(Main.java:353) >>> at com.sun.tools.javac.main.Main.compile(Main.java:279) >>> at com.sun.tools.javac.main.Main.compile(Main.java:270) >>> at com.sun.tools.javac.Main.compile(Main.java:87) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 >9) >>> at >sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp >l.java:25) >>> at java.lang.reflect.Method.invoke(Method.java:597) >>> at >org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacComp >iler.java:554) >>> at >org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java >:161) >>> at >org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.j >ava:605) >>> at >org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128) >>> at >org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManag >er.java:490) >>> at >org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLif >ecycleExecutor.java:694) >>> at >org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycl >e(DefaultLifecycleExecutor.java:556) >>> at >org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLife >cycleExecutor.java:535) >>> at >org.apache.maven.lifecycle.DefaultLi
RE: Can't build wicket from updated trunk
Dumping the environment variables shows only these maven related variables are set: M2 M2_HOME I can't see any other places where MAVEN_OPTS is being set. Nothing in maven's settings.xml that refers to any JVM heap size options. I noticed my version of maven is 2.2.1 dated 2009-08-07 so maybe I should update to the latest maven release and see if it establishes a larger default JVM heap size. >-Original Message- >From: Martin Grigorov [mailto:mgrigo...@apache.org] >Sent: Monday, 2 January 2012 6:44 PM >To: users@wicket.apache.org >Subject: Re: Can't build wicket from updated trunk > >I don't set any JVM settings to be able to build Wicket... > >@Chris: do you have some globally exported MAVEN_OPTS which may interfere ? > >On Mon, Jan 2, 2012 at 6:52 AM, Matthias Gasser > wrote: >> You need to increase the heap space for maven. >> >> Just run the following line prior building: >> >> snip >> set MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=128m >> snap >> >> That should bring you through. >> >> -matthias >> >> Am 02.01.2012 um 05:43 schrieb Chris Colman: >> >>> I cloned the wicket git repos and then checked out branch wicket-1.5.x >branch and the build broke in a different place (it got a bit further this >time :) ) >>> >>> The build was done on a Windows XP box with 4GB RAM so I wouldn't have >thought it would have run out of memory. >>> >>> [INFO] 1 error >>> [INFO] - >>> [INFO] - >--- >>> [ERROR] BUILD FAILURE >>> [INFO] - >--- >>> [INFO] Compilation failure >>> Failure executing javac, but could not parse the error: >>> >>> >>> The system is out of resources. >>> Consult the following stack trace for details. >>> java.lang.OutOfMemoryError: Java heap space >>> at >com.sun.tools.javac.code.Scope$ImportScope.makeEntry(Scope.java:385) >>> at com.sun.tools.javac.code.Scope.enter(Scope.java:196) >>> at com.sun.tools.javac.code.Scope.enter(Scope.java:183) >>> at >com.sun.tools.javac.comp.MemberEnter.importAll(MemberEnter.java:132) >>> at >com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:509) >>> at >com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:446) >>> at >com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:387) >>> at >com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:819) >>> at com.sun.tools.javac.code.Symbol.complete(Symbol.java:386) >>> at >com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:758) >>> at com.sun.tools.javac.comp.Enter.complete(Enter.java:451) >>> at com.sun.tools.javac.comp.Enter.main(Enter.java:429) >>> at >com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:819) >>> at >com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727) >>> at com.sun.tools.javac.main.Main.compile(Main.java:353) >>> at com.sun.tools.javac.main.Main.compile(Main.java:279) >>> at com.sun.tools.javac.main.Main.compile(Main.java:270) >>> at com.sun.tools.javac.Main.compile(Main.java:87) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 >9) >>> at >sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp >l.java:25) >>> at java.lang.reflect.Method.invoke(Method.java:597) >>> at >org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacComp >iler.java:554) >>> at >org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java >:161) >>> at >org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.j >ava:605) >>> at >org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128) >>> at >org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManag >er.java:490) >>> at >org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLif >ecycleExecutor.java:694) >>> at >org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycl >e(DefaultLifecycleExecutor.java:556) >>> at >org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLife >cycleExecutor.java:535) >>> at >org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFai >lures(DefaultLifecycleExecutor.java:387) >>> at >org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(Def >aultLifecycleExecutor.java:348) >>> -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Monday, 2 January 2012 2:50 PM To: users@wicket.apache.org Subject: Re: Can't build wicket from updated trunk already moved. -igor
Re: What is the cause for log entry "ModificationWatcher - Cannot track modifications to resource"
Per, I ran into this problem recently and solved it by removing spaces from directory names in my project path. I plan to file a Jira issue at some point, as it seems that ModificationWatcher should be able to handle file paths with spaces... -Allen On Mon, Jan 2, 2012 at 4:42 AM, Per Newgro wrote: > Hi, > > If i test my app by using Start.java i get the log entry > INFO - ModificationWatcher- Cannot track modifications to > resource file:/D:/Dokumente%20und%**20Einstellungen/per.n/Eigene%** > 20Dateien/workspaces/work/**whataschranz/target/classes/** > ch/newgro/shop/whataschranz/**welcome/HomePage.html > If i change the HP Markup it's not reloaded. > > Google only pops up an answer by igor > "not sure you can do anything about the message...just disable the logger > for that class/package..." > > But disabling the log message is not solving the problem, that my markup > modifications are not re-loaded :-). > As far as i investigated this issue is a problem with the encoded path > string (%20) used to load the resource by > org.apache.wicket.util.**resource.locator.**ResourceStreamLocator#**locateByResourceFinder. > > I'm not an expert but i think i've read a message that something changed > here (URI class or servlet-api) > but maybe someone else already solved this. > > My question is - Is this a bug or can i configure something to make > resource modification watcher working? > > Thanks > Per > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@wicket.**apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
What is the cause for log entry "ModificationWatcher - Cannot track modifications to resource"
Hi, If i test my app by using Start.java i get the log entry INFO - ModificationWatcher- Cannot track modifications to resource file:/D:/Dokumente%20und%20Einstellungen/per.n/Eigene%20Dateien/workspaces/work/whataschranz/target/classes/ch/newgro/shop/whataschranz/welcome/HomePage.html If i change the HP Markup it's not reloaded. Google only pops up an answer by igor "not sure you can do anything about the message...just disable the logger for that class/package..." But disabling the log message is not solving the problem, that my markup modifications are not re-loaded :-). As far as i investigated this issue is a problem with the encoded path string (%20) used to load the resource by org.apache.wicket.util.resource.locator.ResourceStreamLocator#locateByResourceFinder. I'm not an expert but i think i've read a message that something changed here (URI class or servlet-api) but maybe someone else already solved this. My question is - Is this a bug or can i configure something to make resource modification watcher working? Thanks Per - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
