my app seems to work correctly, but in the console it throws a lot of StalePageExceptions. I dont know why. How can i debug the cause for this exceptions? What are commons reasons for this Exception?
13:32:29,361 WARN [RequestCycleExtra] (default task-60) ********************************
13:32:29,362 WARN [RequestCycleExtra] (default task-60) Handling the following exception: org.apache.wicket.core.request.mapper.StalePageException
13:32:29,363 WARN [RequestCycleExtra] (default task-60) ********************************
13:32:35,626 WARN [RequestCycleExtra] (default task-64) ********************************
13:32:35,627 WARN [RequestCycleExtra] (default task-64) Handling the following exception: org.apache.wicket.core.request.mapper.StalePageException
I use the lastest Wicket version - 6.18 but i have this forever.
EDIT:
StatementGokListPanel.java
columns.add(new StatementLinkColumn(Model.of("")) {
#Override
public void onClick(IModel<StatementGokCommunity> model, AjaxRequestTarget target) {
ComponentMode componentMode = ComponentMode.EDIT;
MarkupContainer mc = StatementGokListPanel.this.getParent();
GokCommunityStatementPanel panel = new GokCommunityStatementPanel("panel", model.getObject(), componentMode, true);
StatementGokListPanel.this.replaceWith(panel);
target.add(mc);
}
});
The exception is being thrown if you try to use a page instance that has been rendered in another browser tab/window. Since Wicket cannot know whether you have changed the page structure in the other tab it just suppresses the action (e.g. link click, form submit, etc.) and re-renders the page instance with its latest state from the server.
The exception also may happen if you use browser's "View (page) source" functionality.
Related
I am wondering why Java Logging API is not displaying fine, finer, and finest messages.
Let's look at the following code:
logger.setLevel(Level.ALL);
logger.info("Level:" + logger.getLevel());
logger.severe("Some Fatal message%n");
logger.warning("Some WARN message%n");
logger.info("Some INFO message%n");
logger.fine("Some DEBUG message%n");
logger.finer("Some DEBUG message%n");
logger.finest("Some TRACE message%n");
I would expect this to display every log message, since I am specifying LogLevel.ALL in the first line.
However it is omitting the fine messages, this is what I see:
22-08-28 16:37:25.997 INFO [global] Level:ALL
22-08-28 16:37:26.025 SEVERE [global] Some Fatal message
22-08-28 16:37:26.025 WARNING [global] Some WARN message
22-08-28 16:37:26.026 INFO [global] Some INFO message
Why is it skipping the fine, finer, and finest, given that I have the level set to ALL?
You need to additionally set the level on the Handlers. Handlers are the things which take the actual log events and then push them to stdout, in your case.
logger.setLevel(Level.ALL);
for (Handler handler : logger.getParent().getHandlers()) {
handler.setLevel(Level.ALL);
}
in my app i can upload files (max size is 10MB). I created an exception handler for too big files, but console still shows warning that there was a try to upload too big file:
2020-09-30 01:38:59.306 WARN 2476 --- [nio-8080-exec-3] .m.m.a.ExceptionHandlerExceptionResolver : Resolved [org.springframework.web.multipart.MaxUploadSizeExceededException: Maximum upload size exceeded; nested exception is java.lang.IllegalStateException: org.apache.tomcat.util.http.fileupload.impl.SizeLimitExceededException: the request was rejected because its size (26937892) exceeds the configured maximum (10485760)]
Exception handler:
#ExceptionHandler(MaxUploadSizeExceededException.class)
public void oversizedFilesHandler(MaxUploadSizeExceededException e){
accountService.writeExceptionToFile(e);
}
Is it possible to disable these warnings?
You can achieve that by adding log level to your properties file:
RULE : logging.level.xxxx=LEVEL
where:
LEVEL is one of TRACE, DEBUG, INFO, WARN, ERROR, FATAL, OFF.
xxxx is a package/class.
We apply the rule to your case:
logging.level.org.springframework.web=ERROR
Or even thinner:
logging.level.org.springframework.web.multipart =ERROR
Hence, only ERROR, FATAL and OFF level will be logged to you console.
I usually don't post this kind of questions, but this one is driving me crazy. I am using SeleniumWebDriver to filling a form and submitting it. I did this from my computer and it works perfectly, but when I upload the app to OpenShift I get a StackOverflowError when I submit the form. Here's the stacktrace:
[0m[31m04:29:06,529 ERROR [stderr] (Thread-110) Exception in thread "Thread-110" java.lang.StackOverflowError
[0m[31m04:29:06,542 ERROR [stderr] (Thread-110) at net.sourceforge.htmlunit.corejs.javascript.regexp.NativeRegExp.emitREBytecode(NativeRegExp.java:1311)
[0m[31m04:29:06,547 ERROR [stderr] (Thread-110) at net.sourceforge.htmlunit.corejs.javascript.regexp.NativeRegExp.emitREBytecode(NativeRegExp.java:1281)
[0m[31m04:29:06,547 ERROR [stderr] (Thread-110) at net.sourceforge.htmlunit.corejs.javascript.regexp.NativeRegExp.emitREBytecode(NativeRegExp.java:1286)
[0m[31m04:29:06,548 ERROR [stderr] (Thread-110) at net.sourceforge.htmlunit.corejs.javascript.regexp.NativeRegExp.emitREBytecode(NativeRegExp.java:1286)
[0m[31m04:29:06,548 ERROR [stderr] (Thread-110) at net.sourceforge.htmlunit.corejs.javascript.regexp.NativeRegExp.emitREBytecode(NativeRegExp.java:1286)
[0m[31m04:29:06,564 ERROR [stderr] (Thread-110) at net.sourceforge.htmlunit.corejs.javascript.regexp.NativeRegExp.emitREBytecode(NativeRegExp.java:1286)
(he keeps going for a while but all the lines are the same...)
As you can see from the stacktrace, I am using HtmlUnit WebDriver. I googled this but I didn't find anybody with my exact problem, although it seems that HtmlUnit often gives StackOverflow errors...
Can anyone tell me if this is a bug or if am I missing something? Any help is really appreciated, thanks!
EDIT
Here's my code:
HtmlUnitDriver driver = new HtmlUnitDriver(BrowserVersion.CHROME);
driver.setJavascriptEnabled(true);
driver.get(myUrl);
//Finds the fields of the login form and fills it. Also removes the Remember me checkbox.
WebElement email = driver.findElement(By.id("email"));
email.clear();
email.sendKeys(username);
WebElement rememberMe = driver.findElement(By.name("persistent"));
if(rememberMe.isSelected())rememberMe.click();
WebElement pass = driver.findElement(By.id("pass"));
pass.clear();
pass.sendKeys(pass);
//HERE IS WHERE THE ERROR OCCURS:
pass.submit();
Instead of submit I've also tried to get the input manually from the button and click it like this:
WebElement button = driver.findElement(By.id("u_0_2"));
button.click();
but the problem is exactly the same...
Small gears have 512MB RAM and 1GB disk space each, so running such "resource intensive" applications might not be always possible and you might consider an upgrade to medium or large gear.
Also, trying to increase the stack size might be an option, see: How to increase the Java stack size?
You can check the Openshift Marketplace for monitoring cartridges.
So far I found two date-picker in wicket:
org.apache.wicket.extensions.yui.calendar.DatePicker
org.wicketstuff.dojo.markup.html.form.DojoDatePicker
The navigation for year is not present in the wicket-extensions' date-picker, also so far I found 1.3.0-beta version of wicket-stuff's date-picker, and perhaps this causes the following error messages in my console:
10:35:15,108 INFO [STDOUT] 2011-05-12 10:35:15,108 [http-127.0.0.1-8080-1] ERROR [org.apache.wicket.request.target.resource.SharedResourceRequestTarget] - shared resource org.wicketstuff.dojo.AbstractDefaultDojoBehavior/dojo-0.4/src/i18n/calendar/nls/en-us/gregorian.js not found
10:35:15,148 INFO [STDOUT] 2011-05-12 10:35:15,148 [http-127.0.0.1-8080-1] ERROR [org.apache.wicket.request.target.resource.SharedResourceRequestTarget] - shared resource org.wicketstuff.dojo.AbstractDefaultDojoBehavior/dojo-0.4/src/i18n/calendar/nls/en/gregorianExtras.js not found
10:35:15,165 INFO [STDOUT] 2011-05-12 10:35:15,165 [http-127.0.0.1-8080-1] ERROR [org.apache.wicket.request.target.resource.SharedResourceRequestTarget] - shared resource org.wicketstuff.dojo.AbstractDefaultDojoBehavior/dojo-0.4/src/i18n/calendar/nls/en-us/gregorianExtras.js not found
10:35:15,242 INFO [STDOUT] 2011-05-12 10:35:15,242 [http-127.0.0.1-8080-1] ERROR [org.apache.wicket.request.target.resource.SharedResourceRequestTarget] - shared resource org.wicketstuff.dojo.AbstractDefaultDojoBehavior/dojo-0.4/src/widget/nls/en/DropdownDatePicker.js not found
Also I heard a little about jQuery date-picker for wicket. But found no example/ demo.
I want to know is there any other date-picker for wicket available which has year navigation without bug?
Thanks and Regards.
I have an open source project for wicket components that includes a date picker component -
http://wicket.visural.net/examples/app/dateinput
If my code throws an exception, sometimes - not everytime - the jsf presents a blank page. I´m using facelets for layout.
A similar error were reported at this Sun forumn´s post, but without answers.
Anyone else with the same problem, or have a solution?
;)
Due to some requests. Here follow more datails:
web.xml
<error-page>
<exception-type>com.company.ApplicationResourceException</exception-type>
<location>/error.faces</location>
</error-page>
And the stack related to jsf is printed after the real exception:
####<Sep 23, 2008 5:42:55 PM GMT-03:00> <Error> <HTTP> <comp141> <AdminServer> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1222202575662> <BEA-101107> <[weblogic.servlet.internal.WebAppServletContext#6d46b9 - appName: 'ControlPanelEAR', name: 'ControlPanelWeb', context-path: '/Web'] Problem occurred while serving the error page.
javax.servlet.ServletException: viewId:/error.xhtml - View /error.xhtml could not be restored.
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:249)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:525)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:261)
at weblogic.servlet.internal.ForwardAction.run(ForwardAction.java:22)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.servlet.internal.ErrorManager.handleException(ErrorManager.java:144)
at weblogic.servlet.internal.WebAppServletContext.handleThrowableFromInvocation(WebAppServletContext.java:2201)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2053)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
javax.faces.application.ViewExpiredException: viewId:/error.xhtml - View /error.xhtml could not be restored.
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:180)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
I´m using the jsf version Mojarra 1.2_09, richfaces 3.2.1.GA and facelets 1.1.13.
Hope some help :(
I think this largely depends on your JSF implementation. I've heard that some will render blank screens.
The one we were using would throw error 500's with a stack trace. Other times out buttons wouldn't work without any error for the user. This was all during our development phase.
But the best advice I can give you is to catch the exceptions and log them in an error log so you have the stack trace for debugging later. For messages that we couldn't do anything about like a backend failing we would just add a fatal message to the FacesContext that gets displayed on the screen and log the stack trace.
I fixed a similar problem in my error.jsp page today. This won't be exactly the same as yours, but it might point someone in the right direction if they're having a similar problem. My problem seemed to be coming from two different sources.
First, the message exception property wasn't being set in some of the servlets that were throwing exceptions caught by the error page. The servlets were catching and rethrowing exceptions using the ServletException(Throwable rootCause) constructor.
Second, in the error page itself, the original author had used scriptlet code to parse the message using String.split(message, ";"); Since the message was null this failed. I was getting a NullPointerException in my error log, along with the message "Problem occurred while serving the error page."
These two things combined to give me a blank page at the URL of the servlet that was throwing the original exception. I fixed my problem by providing my own error message when I rethrow exceptions in my servlets using the ServletException(String message, Throwable rootCause) constructor, so the error message will no longer be null. I also rewrote the error.jsp page using EL instead of scriptlet code, but that wasn't strictly necessary.
For a blank page on JSF 2, place a breakpoint in ExceptionHandlerWrapper.handle or a class overriding this method. In my case it was due to custom code which was a too restrictive and the error was not logged.