Help with java.lang.IllegalStateException: Cannot change buffer size after data has been written
Not sure if this is this a MyFaces issue, but as I don't remember having it when my projects were running with with Mojarra, I'd like to see if you can help me. I'm eventually seeing this exception in my Tomcat 7.0.47 log: java.lang.IllegalStateException: Cannot change buffer size after data has been written at org.apache.catalina.connector.ResponseFacade.setBufferSize(ResponseFacade.java:254) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.setResponseBufferSize(ServletExternalContextImpl.java:620) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.createResponseWriter(FaceletViewDeclarationLanguage.java:2241) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1861) at org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:313) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:267) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:200) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:105) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at br.com.spdata.cliente.filter.LoginFilter.doFilter(LoginFilter.java:43) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at com.googlecode.psiprobe.Tomcat70AgentValve.invoke(Tomcat70AgentValve.java:38) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1721) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1679) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) It happens in different pages, but since the exception doesn't happen in any of my managed beans, I have no idea of what is happening. Currently I'm using MyFaces 2.2.4, but this was happening with previous 2.2.x releases too. Any ideas? Thanks in advance.
Re: Help with java.lang.IllegalStateException: Cannot change buffer size after data has been written
On Wed, Jul 16, 2014 at 7:52 AM, Felipe Jaekel fkjae...@gmail.com wrote: Not sure if this is this a MyFaces issue, but as I don't remember having it when my projects were running with with Mojarra, I'd like to see if you can help me. I'm eventually seeing this exception in my Tomcat 7.0.47 log: java.lang.IllegalStateException: Cannot change buffer size after data has been written at org.apache.catalina.connector.ResponseFacade.setBufferSize(ResponseFacade.java:254) Felipe, I think I saw that error long time ago and I discussed with BalusC on/via OmniFaces google-code project's issue tracker. anyway, I think it was caused by the largest XHTML page in my app, which has hundreds of UI components (input/, etc...). Below, is what I saved in my web.xml per that discussion with BalusC. !-- http://code.google.com/p/omnifaces/issues/detail?id=73 Comment 25 by project member balusc, Today (11 minutes ago) Just keep GZIP filter threshold size default. It has not the same meaning as Facelets buffer size. A large Facelets buffer size may be useful during development, to spot any bugs in the view which causes exceptions during render response. But I would not set it that large in production. http://code.google.com/p/omnifaces/issues/detail?id=51 It's technically not possible to change the response when it has already been committed. So if an exception occurs during rendering the response and the response has already been committed, then you'll end up with a broken response. In most default servletcontainer/webapp configurations, the response get committed when 2KB has already been written to the response. One of the ways to avoid this is to increase the response buffer size. In Facelets, you can do this using the following context parameter (which sets it to 64KB, you may if necessary need to adjust it to the size of the largest HTML output you have): context-param param-namejavax.faces.FACELETS_BUFFER_SIZE/param-name param-value65535/param-value /context-param Setting to 800KB, since /orders/pf_Add.xhtml (640+ KB) is the largest view; if this is not set, then OmniFaces 1.2 (OmniPartialViewContext) breaks pf_BrowsePayroll.xhtml, see OmniFaces issue 73 (URL above) context-param param-namejavax.faces.FACELETS_BUFFER_SIZE/param-name param-value819200/param-value /context-param -- context-param param-namejavax.faces.FACELETS_BUFFER_SIZE/param-name param-value65535/param-value /context-param
null Long values displayed as 0
Dear all,
I just finished to struggle with the display of nullable Long or Integer
values. I am using Primefaces 5.0.1 / MyFaces 2.2.4 / OpenWebBeans 1.2.2
/ Tomcat 7.0.39.
Those values are the result of the evaluation of EL expressions that I
create with the following function :
public static ValueExpression createValueExpression(String
expression, Class clazz) {
FacesContext fc = FacesContext.getCurrentInstance();
ELContext elContext = fc.getELContext();
FacesELContext felContext = (FacesELContext)fc.getELContext();
SenatFunctionMapper sfm = SenatFunctionMapper.getInstance();
felContext.setFunctionMapper(sfm);
ExpressionFactory expFactory =
fc.getApplication().getExpressionFactory();
ValueExpression ret = null;
if(clazz==null) {
clazz = Object.class;
}
try {
ret = expFactory.createValueExpression(elContext,
expression, clazz);
} catch (ELException ex) {
log.fatal(Erreur de compilation de l'expression EL :
' + expression + ', ex);
}
return ret;
}
Until now, I created those value expressions with the real expected
class as the third parameter of ExpressionFactory#createValueExpression.
The name of this parameter is expectedType, so it seems logical to me
to provide the best information I had. So, I provided
java.lang.Integer.class or java.lang.Long.class, etc.
But when I do that, null values are displayed as 0, either with
h:inputText (standard MyFaces control) or p:inputText (PrimeFaces version).
The reason being that
org.apache.el.ValueExpressionImpl#getValue
is implemented the following way
@Override
public Object getValue(ELContext context) throws
PropertyNotFoundException,
ELException {
EvaluationContext ctx = new EvaluationContext(context,
this.fnMapper,
this.varMapper);
Object value = this.getNode().getValue(ctx);
if (this.expectedType != null) {
return ELSupport.coerceToType(value, this.expectedType);
}
return value;
}
and that ELSupport.coerceToType of a Long or Integer null value is
defined as... 0
As those type are numeric, coerceToType calls coerceToNumber, which
starts with :
public static final Number coerceToNumber(final Object obj,
final Class? type) throws ELException {
if (obj == null || .equals(obj)) {
return coerceToNumber(ZERO, type);
}
...
}
thus, the ZERO value.
For the time being, I solved my «problem» by passing a null third
parameter to ExpressionFactory#createValueExpression. It works. It has
no apparent drawbacks. But I don't get the logic of it. Should'nt
ELSupport#coerceToNumber handles this differently ?
Thanks in advance for your explanations,
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: null Long values displayed as 0
Maybe you could try to add property
org.apache.el.parser.COERCE_TO_ZERO=false to your JVM
Denis/MTL
2014-07-16 13:00 GMT-04:00 l.pe...@senat.fr l.pe...@senat.fr:
Dear all,
I just finished to struggle with the display of nullable Long or Integer
values. I am using Primefaces 5.0.1 / MyFaces 2.2.4 / OpenWebBeans 1.2.2 /
Tomcat 7.0.39.
Those values are the result of the evaluation of EL expressions that I
create with the following function :
public static ValueExpression createValueExpression(String expression,
Class clazz) {
FacesContext fc = FacesContext.getCurrentInstance();
ELContext elContext = fc.getELContext();
FacesELContext felContext = (FacesELContext)fc.getELContext();
SenatFunctionMapper sfm = SenatFunctionMapper.getInstance();
felContext.setFunctionMapper(sfm);
ExpressionFactory expFactory = fc.getApplication().
getExpressionFactory();
ValueExpression ret = null;
if(clazz==null) {
clazz = Object.class;
}
try {
ret = expFactory.createValueExpression(elContext,
expression, clazz);
} catch (ELException ex) {
log.fatal(Erreur de compilation de l'expression EL : ' +
expression + ', ex);
}
return ret;
}
Until now, I created those value expressions with the real expected class
as the third parameter of ExpressionFactory#createValueExpression. The
name of this parameter is expectedType, so it seems logical to me to
provide the best information I had. So, I provided java.lang.Integer.class
or java.lang.Long.class, etc.
But when I do that, null values are displayed as 0, either with
h:inputText (standard MyFaces control) or p:inputText (PrimeFaces version).
The reason being that
org.apache.el.ValueExpressionImpl#getValue
is implemented the following way
@Override
public Object getValue(ELContext context) throws
PropertyNotFoundException,
ELException {
EvaluationContext ctx = new EvaluationContext(context,
this.fnMapper,
this.varMapper);
Object value = this.getNode().getValue(ctx);
if (this.expectedType != null) {
return ELSupport.coerceToType(value, this.expectedType);
}
return value;
}
and that ELSupport.coerceToType of a Long or Integer null value is defined
as... 0
As those type are numeric, coerceToType calls coerceToNumber, which starts
with :
public static final Number coerceToNumber(final Object obj,
final Class? type) throws ELException {
if (obj == null || .equals(obj)) {
return coerceToNumber(ZERO, type);
}
...
}
thus, the ZERO value.
For the time being, I solved my «problem» by passing a null third
parameter to ExpressionFactory#createValueExpression. It works. It has no
apparent drawbacks. But I don't get the logic of it. Should'nt
ELSupport#coerceToNumber handles this differently ?
Thanks in advance for your explanations,
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: null Long values displayed as 0
On 16/07/2014 19:15, titou10 titou10 wrote: Maybe you could try to add property org.apache.el.parser.COERCE_TO_ZERO=false to your JVM Denis/MTL No, COERCE_TO_ZERO is useful in the opposite way, when submitting the value. BTW, I already use it. Thx anyway. Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: null Long values displayed as 0
Hi All files from org.apache.el comes from the EL library, so it is out of MyFaces scope. I think you cannot override the EL coercion rules, unless you change the underlying EL library. regards, Leonardo 2014-07-16 12:20 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr: On 16/07/2014 19:15, titou10 titou10 wrote: Maybe you could try to add property org.apache.el.parser.COERCE_TO_ZERO=false to your JVM Denis/MTL No, COERCE_TO_ZERO is useful in the opposite way, when submitting the value. BTW, I already use it. Thx anyway. Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
