Wildfly: org.xnio.channels.FixedLengthOverflowException - java

Until now we used JBoss AS 7.1 which has a tomcat as front-server. We now upgraded to Wildfly (JBoss 8.0) which ships with undertow as a tomcat replacement.
For our filedownloads, we are reading the input stream of the file, and writing this to the external context's response output stream. This worked well in JBoss AS 7.1 - even for large files. In Undertow WE receive the following exception even for pretty "small" files:
13:04:43,292 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /project/getFile.xhtml}: java.lang.RuntimeException: org.xnio.channels.FixedLengthOverflowException
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: org.xnio.channels.FixedLengthOverflowException
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:97)
at org.xnio.conduits.Conduits.writeFinalBasic(Conduits.java:132) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.writeFinal(AbstractFixedLengthStreamSinkConduit.java:137)
at org.xnio.conduits.ConduitStreamSinkChannel.writeFinal(ConduitStreamSinkChannel.java:104) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.channels.DetachableStreamSinkChannel.writeFinal(DetachableStreamSinkChannel.java:172)
at io.undertow.servlet.spec.ServletOutputStreamImpl.writeBufferBlocking(ServletOutputStreamImpl.java:580)
at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:614)
at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
... 9 more
The getFile.xhtml is invoking the download and the following code is used to copy the stream:
(Try, catch, logs and error handling removed to save some space)
public void downloadFile(FileEntity fileEntity) {
FacesContext fc = FacesContext.getCurrentInstance();
ExternalContext ec = fc.getExternalContext();
ec.responseReset();
ec.setResponseContentType(getMimeType(fileEntity.getFile()));
ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue());
ec.setResponseHeader("Content-Disposition", "attachment; filename=\"" + ConversionHelper.validateFilename(fileEntity.getDisplayFileName()) + "\"");
OutputStream output = ec.getResponseOutputStream();
FileInputStream fis = new FileInputStream(fileEntity.getFile());
IOUtils.copy(fis, output);
fc.responseComplete();
}
I noticed that removing the line
ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue());
makes it work again. However the ResponseConentLength is "correct". Using
ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue() + 9);
(note the +9) solves this. Using +8 -> FixedLengthOverflow, using +10 -> FixedLengthUnderflow
The +9 is independent of the filesize. Any idea? Looks strange to me...

If you call output.close() it should have the effect you are after. This looks like an issue with JSF, and not related to Undertow.

Found the problem.
It has to do with the change of the server engine. Just not sure if it is directly related to undertow, or more an error with wildfly / JSF (or if it was an error in Jboss and now is working correctly):
To invoke the download, we used something like this in the getFile.xhtml:
<f:metadata>
<f:viewParam name="fileId" required="true"
value="#{getFileController.fileId}"></f:viewParam>
</f:metadata>
<h:outputLabel value="#{getFileController.download()}" />
this would usually produce:
<label>value</label>
if the value of the label would be a string.
since we reset the response inside download(), <label> is removed again. Then, using a fixed response size that's equal the file-length and calling responseComplete() basically ommits the trailing </label>. Undertow however seems to ignore the responseComplete()-Call and tries to append </label> to the response, notices, that the end of the (fixed) response stream is reached, and therefore throws the mentioned exception.
That's why providing a size of +9 solves this error - but causes corrupt files, cause </label>\n will be appended to the file.
obviously the usage of an output label was bad practice there. But since we reseted and manually filled the response stream and called responseComplete() that was working fine.
the fix is obviously to not produce any (not required) html tags on that page:
<f:metadata>
<f:viewParam name="fileId" required="true"
value="#{getFileController.fileId}"></f:viewParam>
<f:event listener="#{getFileController.dlNow()}" type="preRenderView"></f:event>
</f:metadata>
Beside the bad design there - shouldn't call responseComplete() ommit any additional writing to the response stream, including any write ATTEMPTS?
The docu says:
Signal the JavaServer Faces implementation that the HTTP response for
this request has already been generated (such as an HTTP redirect),
and that the request processing lifecycle should be terminated as soon
as the current phase is completed.
So, if the Faces Implementation is told that the Response has been send - why would it try to append something?

Related

ServletUnit RequestDispatcher forward() / include() methods AbstractMethodError

I'm doing a java web app with a servlet and I wanted to write some tests to check its functionality (ex. authorization form). I hadn't been using any framework, just bare java in eclipse with tomcat 7.0
I've run into an error while trying to test authorization input. The app would check the login-password pair and then redirect using RequestDispatcher.forward() or RequestDispatcher.include() methods. But when executing them it throws an error with the following stack trace:
java.lang.reflect.Inv­ocationTargetExceptio­n
at su­n.reflect.NativeMetho­dAccessorImpl.invoke0­(Native Method)
at su­n.reflect.NativeMetho­dAccessorImpl.invoke(­Unknown Source)
at su­n.reflect.DelegatingM­ethodAccessorImpl.inv­oke(Unknown Source)
at ja­va.lang.reflect.Metho­d.invoke(Unknown Sour­ce)
at en­tryPoint.Dispatcher.d­ispatch(Dispatcher.ja­va:166)
at en­tryPoint.Dispatcher.s­ervice(Dispatcher.jav­a:49)
at ja­vax.servlet.http.Http­Servlet.service(HttpS­ervlet.java:728)
at co­m.meterware.servletun­it.InvocationContextI­mpl.service(Invocatio­nContextImpl.java:76)
at co­m.meterware.servletun­it.ServletUnitClient.­newResponse(ServletUn­itClient.java:126)
at co­m.meterware.httpunit.­WebClient.createRespo­nse(WebClient.java:64­7)
at co­m.meterware.httpunit.­WebWindow.getResource­(WebWindow.java:220)
at co­m.meterware.httpunit.­WebWindow.getSubframe­Response(WebWindow.ja­va:181)
at co­m.meterware.httpunit.­WebWindow.getResponse­(WebWindow.java:158)
at co­m.meterware.httpunit.­WebWindow.updateWindo­w(WebWindow.java:199)
at co­m.meterware.httpunit.­WebWindow.getSubframe­Response(WebWindow.ja­va:183)
at co­m.meterware.httpunit.­WebWindow.getResponse­(WebWindow.java:158)
at co­m.meterware.httpunit.­WebClient.getResponse­(WebClient.java:122)
at te­st.Authorization.test­AuthCorrectInput_Wron­gPassword(Authorizati­on.java:102)
at su­n.reflect.NativeMetho­dAccessorImpl.invoke0­(Native Method)
at su­n.reflect.NativeMetho­dAccessorImpl.invoke(­Unknown Source)
at su­n.reflect.DelegatingM­ethodAccessorImpl.inv­oke(Unknown Source)
at ja­va.lang.reflect.Metho­d.invoke(Unknown Sour­ce)
at or­g.junit.runners.model­.FrameworkMethod$1.ru­nReflectiveCall(Frame­workMethod.java:45)
at or­g.junit.internal.runn­ers.model.ReflectiveC­allable.run(Reflectiv­eCallable.java:15)
at or­g.junit.runners.model­.FrameworkMethod.invo­keExplosively(Framewo­rkMethod.java:42)
at or­g.junit.internal.runn­ers.statements.Invoke­Method.evaluate(Invok­eMethod.java:20)
at or­g.junit.internal.runn­ers.statements.RunBef­ores.evaluate(RunBefo­res.java:28)
at or­g.junit.runners.Paren­tRunner.runLeaf(Paren­tRunner.java:263)
at or­g.junit.runners.Block­JUnit4ClassRunner.run­Child(BlockJUnit4Clas­sRunner.java:68)
at or­g.junit.runners.Block­JUnit4ClassRunner.run­Child(BlockJUnit4Clas­sRunner.java:47)
at or­g.junit.runners.Paren­tRunner$3.run(ParentR­unner.java:231)
at or­g.junit.runners.Paren­tRunner$1.schedule(Pa­rentRunner.java:60)
at or­g.junit.runners.Paren­tRunner.runChildren(P­arentRunner.java:229)
at or­g.junit.runners.Paren­tRunner.access$000(Pa­rentRunner.java:50)
at or­g.junit.runners.Paren­tRunner$2.evaluate(Pa­rentRunner.java:222)
at or­g.junit.internal.runn­ers.statements.RunBef­ores.evaluate(RunBefo­res.java:28)
at or­g.junit.internal.runn­ers.statements.RunAft­ers.evaluate(RunAfter­s.java:30)
at or­g.junit.runners.Paren­tRunner.run(ParentRun­ner.java:300)
at or­g.eclipse.jdt.interna­l.junit4.runner.JUnit­4TestReference.run(JU­nit4TestReference.jav­a:50)
at or­g.eclipse.jdt.interna­l.junit.runner.TestEx­ecution.run(TestExecu­tion.java:38)
at or­g.eclipse.jdt.interna­l.junit.runner.Remote­TestRunner.runTests(R­emoteTestRunner.java:­467)
at or­g.eclipse.jdt.interna­l.junit.runner.Remote­TestRunner.runTests(R­emoteTestRunner.java:­683)
at or­g.eclipse.jdt.interna­l.junit.runner.Remote­TestRunner.run(Remote­TestRunner.java:390)
at or­g.eclipse.jdt.interna­l.junit.runner.Remote­TestRunner.main(Remot­eTestRunner.java:197)
Caused by: javax.serv­let.ServletException:­ java.lang.AbstractMe­thodError: com.meterw­are.servletunit.Servl­etUnitServletContext.­getClassLoader()Ljava­/lang/ClassLoader;
at or­g.apache.jasper.servl­et.JspServlet.service­(JspServlet.java:343)
at ja­vax.servlet.http.Http­Servlet.service(HttpS­ervlet.java:728)
at co­m.meterware.servletun­it.RequestDispatcherI­mpl.forward(RequestDi­spatcherImpl.java:54)
at co­ntrollers.Auth.index(­Auth.java:78)
... 4­4 more
Caused by: java.lang.­AbstractMethodError: ­com.meterware.servlet­unit.ServletUnitServl­etContext.getClassLoa­der()Ljava/lang/Class­Loader;
at or­g.apache.jasper.compi­ler.TagPluginManager.­init(TagPluginManager­.java:72)
at or­g.apache.jasper.compi­ler.TagPluginManager.­apply(TagPluginManage­r.java:56)
at or­g.apache.jasper.compi­ler.Compiler.generate­Java(Compiler.java:24­0)
at or­g.apache.jasper.compi­ler.Compiler.compile(­Compiler.java:373)
at or­g.apache.jasper.compi­ler.Compiler.compile(­Compiler.java:353)
at or­g.apache.jasper.compi­ler.Compiler.compile(­Compiler.java:340)
at or­g.apache.jasper.JspCo­mpilationContext.comp­ile(JspCompilationCon­text.java:646)
at or­g.apache.jasper.servl­et.JspServletWrapper.­service(JspServletWra­pper.java:357) ­
at or­g.apache.jasper.servl­et.JspServlet.service­JspFile(JspServlet.ja­va:390)
at or­g.apache.jasper.servl­et.JspServlet.service­(JspServlet.java:334)
... 4­7 more
The first block represents an invocation error caught by central controller (Dispatcher) servlet while invoking method in which an AbstractMethodError had been thrown. The second and third ones are about that error.
The code of the test method is as follows:
#Test
publi­c void testAuthIncorr­ectInput_Long() throw­s Exception {
W­ebRequest request = n­ew PostMethodWebReque­st("http://localhost:­8080/CenralReportDL/D­ispatcher?query=auth"­);
S­tring longString = ne­w String();
f­or (int i = 0; i < 52­; i++) {
­ longString­ += "aA_ba";
}
reque­st.setParameter("user­name", longString);
reque­st.setParameter("pass­word", longString);
W­ebResponse response =­ client.getResponse(r­equest);
a­ssertNotNull("No resp­onse received", respo­nse);
}
How can I get rid of this error? Is there a workaround? Should I maybe use some other means of servlet testing?
Also please do not suggest framework-specific testing utils such as strutstest, I want an actual solution for bare java web application.
UPDATE: In response to #JekinKalariya - I had a JasperException before. It complained about files not being in /WEB-INF folder, but due to my project structure they all were in /WebContent/WEB-INF. I was so frustrated because of that I just copied entire folder. Silly thing to do. I deleted it and now I'm back to that JasperException.
UPDATE: Now, I've done some research and found some answers on this issue. Didn't work for me though. I also found a suggestion to change a target runtime to J2EE Preview, which raised a different kind of exception:
com.meterware.httpuni­t.HttpNotFoundExcepti­on: Error on HTTP req­uest: 404 java.lang.C­lassNotFoundException­: org.apache.jasper.s­ervlet.JspServlet [http://localhost/WEB-­INF/jsp/auth.jsp]

Tomcat 7 exception when cookie contain umlaut characters

I'm a developer and I face the exception below when Cookie contain umlaut characters (ä,ö,ü), I tried many solutions and configurations without any result.
I use Tomcat7
Any solution please
Feb 21, 2013 6:29:16 AM org.apache.coyote.http11.AbstractHttp11Processor process
SEVERE: Error processing request
java.lang.IllegalArgumentException: Control character in cookie value or attribute.
at org.apache.tomcat.util.http.CookieSupport.isHttpSeparator(CookieSupport.java:193)
at org.apache.tomcat.util.http.Cookies.getTokenEndPosition(Cookies.java:488)
at org.apache.tomcat.util.http.Cookies.processCookieHeader(Cookies.java:291)
at org.apache.tomcat.util.http.Cookies.processCookies(Cookies.java:168)
at org.apache.tomcat.util.http.Cookies.getCookieCount(Cookies.java:106)
at org.apache.catalina.connector.CoyoteAdapter.parseSessionCookiesId(CoyoteAdapter.java:919)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:688)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:402)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1600)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
According to a comment on another question you need to upgrade to tomcat 8.0.15 (or higher) and enable the RFC 6455 cookie processor.
Documented here: http://tomcat.apache.org/tomcat-8.0-doc/config/cookie-processor.html
Enable it in your conf/context.xml via:
<Context>
<CookieProcessor className="org.apache.tomcat.util.http.Rfc6265CookieProcessor" />
</Context>
Use UTF-8 Encoding.
You can either set it globally:
java -Dfile.encoding=UTF-8
Or locally:
System.setProperty("file.encoding", "UTF-8");
byte inbytes[] = new byte[1024];
FileInputStream fis = new FileInputStream("the.location.of.your.cookie");
fis.read(inbytes);
Also, if you are editing the cookies manually, don't save Ä. Instead use the UTF-8 equivalent, which is
System.out.println("\u00c4");
Chars Unicode
------------------------------
Ä, ä \u00c4, \u00e4
Ö, ö \u00d6, \u00f6
Ü, ü \u00dc, \u00fc
ß \u00df
Right now I have met the same problem, First I have tried upgraded tomcat 7 to tomcat 8.5.51 it work but it raised new problem
java.lang.IllegalArgumentException: An invalid domain [.foo.bar.com] was specified for this cookie
because I do not need the cookie in my case, so I just exclude cookie at Nginx level, and it also could resolve this problem
proxy_set_header Cookie "";

Changes to a Lotus Domino xpages java application do not propagate to the server

Using Lotus Domino 8.5.2 Fixpack 3
The title sums it up. I have an xpages application that uses java. It seems that any java changes I make, never become visible on the server. It sounds a dead ringer for a cache issue of some kind. The application runs on the server and I see System.out.println statements in the server log, but do not any of the changes I've made to those statements or any new ones I've added.
The code is set to Rebuild Automatically. Still, it never looks like the server sees the changes. Is there some special way I need to build the database (aside from the typical Rebuild All)? Do I need to reset or restart some process on the domino server for it to see the changes?
Any thoughts or ideas would be greatly appreciated.
EDIT 1
I'm returning to this project and, hence, this question. The specific error message I'm getting is:
[6815810:00012-05659] 03/19/2013 09:27:01 HTTP JVM: Managedbean Calendar could not be created Can't instantiate class: 'calendar.CalendarServices'.. java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices. For more detailed inform
ation, please consult error-log-0
[6815810:00012-05659] 03/19/2013 09:27:01 HTTP JVM: xml located in /local/notesdata/domino/workspace/logs
[6815810:00012-05659] 03/19/2013 09:27:01 HTTP JVM: com.ibm.xsp.exception.EvaluationExceptionEx: Error while executing JavaScript action expression
I've tried unchecking automatic build and doing a clean --> rebuild all. I've tried signing the nsf again. I've ensured that I'm on the acl. And, as recommended, I've tried the
restart task http
Command via live console. No matter what I do I'm getting this error. The odd thing is that this project is just a copy --> paste (with rename) of another one that works fine. So, the project works...until I change and recompile...
The log that exception above points to wasn't very helpful. It reads:
<CommonBaseEvent creationTime="2013-03-05T09:01:03.254-06:00" globalInstanceId="EL0a04a8b800013d3af27da200000008" msg="Managedbean Calendar could not be created Can&apos;t instantiate class: &apos;calendar.CalendarServices&apos;.. java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices" severity="50" version="1.0.1">
<extendedDataElements name="CommonBaseEventLogRecord:level" type="noValue">
<children name="CommonBaseEventLogRecord:name" type="string">
<values>SEVERE</values>
</children>
</extendedDataElements>
<extendedDataElements name="CommonBaseEventLogRecord:sourceClassName" type="string">
<values>com.sun.faces.application.ApplicationAssociate</values>
</extendedDataElements>
<extendedDataElements name="CommonBaseEventLogRecord:sourceMethodName" type="string">
<values>createAndMaybeStoreManagedBeans</values>
</extendedDataElements>
<extendedDataElements name="CommonBaseEventLogRecord:Exception" type="string">
<values>javax.faces.FacesException: Can&apos;t instantiate class: &apos;calendar.CalendarServices&apos;.. java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices
at com.sun.faces.config.ManagedBeanFactory.newInstance(ManagedBeanFactory.java:234)
at com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(ApplicationAssociate.java:291)
at com.sun.faces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:135)
at com.ibm.xsp.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:71)
at com.ibm.xsp.javascript.ServerSideLocalObject.resolveVariable(ServerSideLocalObject.java:97)
at com.ibm.xsp.javascript.ServerSideLocalObject.resolveAttribute(ServerSideLocalObject.java:73)
at com.ibm.xsp.javascript.AbstractLocalObject._get(AbstractLocalObject.java:119)
at com.ibm.xsp.javascript.AbstractLocalObject.getPropertyReference(AbstractLocalObject.java:101)
at com</values>
<values>.ibm.jscript.engine.ProgramContext.findGlobalScopeIdentifier(ProgramContext.java:143)
at com.ibm.jscript.engine.ProgramContext.findIdentifier(ProgramContext.java:134)
at com.ibm.jscript.ASTTree.ASTIdentifier.interpret(ASTIdentifier.java:105)
at com.ibm.jscript.ASTTree.ASTMember.interpret(ASTMember.java:106)
at com.ibm.jscript.ASTTree.ASTCall.interpret(ASTCall.java:88)
at com.ibm.jscript.ASTTree.ASTArgumentList.interpretArguments(ASTArgumentList.java:63)
at com.ibm.jscript.types.FBSObject.call(FBSObject.java:153)
at com.ibm.jscript.ASTTree.ASTCall.interpret(ASTCall.java:175)
at com.ibm.jscript.ASTTree.ASTIf.interpret(ASTIf.java:85)
at com.ibm.jscript.ASTTree.ASTTry.interpret(ASTTry.java:109)
at com.ibm.jscript.ASTTree.ASTProgram.interpret(ASTProgram.java:119)
at com.ibm.jscript.ASTTree.ASTProgram.interpretEx(ASTProgram.java:139)
at com.ibm.jscript.JSExpression._interpretExpression(JSExpression.java:435)</values>
<values>
at com.ibm.jscript.JSExpression.access$1(JSExpression.java:424)
at com.ibm.jscript.JSExpression$2.run(JSExpression.java:414)
at java.security.AccessController.doPrivileged(AccessController.java:284)
at com.ibm.jscript.JSExpression.interpretExpression(JSExpression.java:410)
at com.ibm.jscript.JSExpression.evaluateValue(JSExpression.java:251)
at com.ibm.jscript.JSExpression.evaluateValue(JSExpression.java:234)
at com.ibm.xsp.javascript.JavaScriptInterpreter.interpret(JavaScriptInterpreter.java:220)
at com.ibm.xsp.binding.javascript.JavaScriptMethodBinding.invoke(JavaScriptMethodBinding.java:111)
at com.ibm.xsp.component.UIViewRootEx.invokePhaseMethodBinding(UIViewRootEx.java:1705)
at com.ibm.xsp.controller.FacesControllerImpl.invokePhaseMethodBinding(FacesControllerImpl.java:444)
at com.ibm.xsp.controller.FacesControllerImpl.access$0(FacesControllerImpl.java:438)
at com.ibm.xsp.controller.FacesControllerImpl$</values>
<values>ViewPhaseListener.afterPhase(FacesControllerImpl.java:506)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:218)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:120)
at com.ibm.xsp.controller.FacesControllerImpl.render(FacesControllerImpl.java:264)
at com.ibm.xsp.webapp.FacesServlet.serviceView(FacesServlet.java:219)
at com.ibm.xsp.webapp.FacesServletEx.serviceView(FacesServletEx.java:193)
at com.ibm.xsp.webapp.FacesServlet.service(FacesServlet.java:154)
at com.ibm.xsp.webapp.FacesServletEx.service(FacesServletEx.java:137)
at com.ibm.xsp.webapp.DesignerFacesServlet.service(DesignerFacesServlet.java:86)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet(ComponentModule.java:538)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1151)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServl</values>
<values>et(ComponentModule.java:803)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:758)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:527)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1135)
at com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:523)
at com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:352)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:304)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:261)
at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:291)
Caused by: java.security.PrivilegedActionException: java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices
at java.security.AccessController</values>
<values>.doPrivileged(AccessController.java:255)
at com.sun.faces.config.ManagedBeanFactory.newInstance(ManagedBeanFactory.java:216)
... 51 more
Caused by: java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices
at java.beans.Beans.instantiate(Beans.java:194)
at java.beans.Beans.instantiate(Beans.java:75)
at com.sun.faces.config.ManagedBeanFactory$1.run(ManagedBeanFactory.java:222)
at java.security.AccessController.doPrivileged(AccessController.java:251)
... 52 more
</values>
</extendedDataElements>
<sourceComponentId component="Expeditor 6.2" componentIdType="ProductName" instanceId="" location="<server here>" locationType="Hostname" subComponent="com.sun.faces.application.ApplicationImpl" threadId="0" componentType="http://www.w3.org/2001/XMLSchema-instance"/>
<situation categoryName="ReportSituation">
<situationType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ReportSituation" reasoningScope="INTERNAL" reportCategory="LOG"/>
</situation>
</CommonBaseEvent>
As ever, penny for your thoughts.
Also, thank you all for your feedback. I'm sorry I've been away for a bit and neglected this question. I really would like to figure this out.
You didn't mention Project -> Clean so try that first.
I had once similar problem that was caused by an underscore in class or package name.
If the problem exists also for XPages then it's a a general build problem. This can occur at least when developers with different Designer and/or ExtLib versions modify the application. When I had this problem the only way to fix it was to create a new application and copy paste everything there. In our case the other developer never had the problem.
This is just silly. My src folder wasn't on the build path. That was causing all the issues.

NestedRuntimeException: Cannot parse POST parameters of request

As part of an application, we have a JSP page (parent page) in which we are calling another JSP page (child page), where all the parameters of the child page has been assigned to the form of the parent page and then trying to submit the page.
At the time of submission, we are getting the following error on the frontend...
(I) Front end error
=====================
Error 500--Internal Server Error
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
And on the backend we get the following error...
(II) Application server Error log
<Error> <HTTP> <BEA-101019> <[ServletContext(id=29607640,name=test,c
ontext-path=/Test)] Servlet failed with IOException
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at weblogic.servlet.internal.PostInputStream.read(PostInputStream.java:170)
at weblogic.servlet.internal.ServletInputStreamImpl$1.read(ServletInputStreamImpl.java:115)
at weblogic.servlet.internal.ServletInputStreamImpl.read(ServletInputStreamImpl.java:180)
at weblogic.servlet.internal.ServletRequestImpl.mergePostParams(ServletRequestImpl.java:1339
)
at weblogic.servlet.internal.ServletRequestImpl.parseQueryParams(ServletRequestImpl.java:120
6)
at weblogic.servlet.internal.ServletRequestImpl.getParameter(ServletRequestImpl.java:1409)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:446)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletC
ontext.java:7047)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:39
02)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2773)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
**--------------- nested within: ------------------
weblogic.utils.NestedRuntimeException: Cannot parse POST parameters of request: '/Test/test1.jsp
' - with nested exception:
[java.net.SocketTimeoutException: Read timed out]**
at weblogic.servlet.internal.ServletRequestImpl.mergePostParams(ServletRequestImpl.java:1364
)
at weblogic.servlet.internal.ServletRequestImpl.parseQueryParams(ServletRequestImpl.java:120
6)
at weblogic.servlet.internal.ServletRequestImpl.getParameter(ServletRequestImpl.java:1409)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:446)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletC
ontext.java:7047)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:39
02)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2773)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
Could you please offer a suggestion as to the cause of the problem.
You are getting a SocketTimeoutException, so there is probably something wrong with your POST. For example, you might not be sending through enough bytes of data, or you might not be closing off the connection once you're finished with it - basically its sitting there waiting for more information until it eventually times out.
Could you please post some of your JSP code, especially where you're creating and running your POST, so that we can provide some better feedback.

Blank Page in JSF

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.

Categories

Resources