In my earlier post there was a problem with JSF charset handling, but also the other part of the problem was MySQL connection parameters for inserting data into db. The problem was solved.
But, I migrated the same application from JSP to facelets and the same problem happened again. Characters from input fields are replaced when inserting to database (č is replaced with Ä), but data inserted into db from sql scripts with proper charset are displayed correctly. I'm still using registered filter and page templates are used with head meta tag as following:
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-2">
If I insert into h:form tag the following attribute:
acceptcharset="iso-8859-2"
I get correct characters in Firefox, but not in IE7.
Is there anything else I should do to make it work?
Thanks in advance.
Add the following line to the filter:
response.setContentType("text/html;charset=ISO-8859-2");
Don't use acceptcharset attribute. IE has serious bugs with it.
Also, when you're using a <?xml?> declaration in top of Facelets XHTML page, ensure that it's using the desired charset or just remove the whole declaration, it's not strictly required.
<?xml version="1.0" encoding="ISO-8859-2"?>
i think you can see the implementation of org.springframework.web.filter.CharacterEncodingFilter
and you can start your tomcat by adding -Dfile.encoding=ISO-8859-2 as jvm arguments
Related
Is there any <!doctype> for "HTML 4.01 Strict Markup + ARIA"?
Also am currently having HTML 4.01 Strict <!DOCTYPE>, I obviously get an error while validating my page with the W3C Validator.
Is there any solution to this problem?
Also when I use the Accessibilty Toolbar, I get the following error pointing to the line after the closing HTML tag:
Line 256, Column 1: character data is not allowed here
Content-Disposition: form-data; name="charset"
You have used character data somewhere it is not permitted to appear.
Mistakes that can cause this error include:
putting text directly in the body of the document without wrapping it in a container element (such as a <p>aragraph</p>), or
forgetting to quote an attribute value (where characters such as "%" and "/" are common, but cannot appear without surrounding quotes), or
using XHTML-style self-closing tags (such as <meta ... />) in HTML 4.01 or earlier. To fix, remove the extra slash ('/') character. For more information about the reasons for this, see Empty elements in SGML, HTML, XML, and XHTML.
There is no published DTD for HTML 4.01 + ARIA. It would be possible to write one, if only there were a stable, exact document that specifies the allowed ARIA attributes and the HTML 4.01 elements on which they may be used. Using WAI-ARIA in HTML is still a WD only, and calls itself “a practical guide”. And I’m not sure how it should be interpreted. I guess the simplest, and possibly the only realistic, approach would be to write a DTD that allows all ARIA attributes on all elements, with the same set of values for all elements, even thoughh this would violate many of the recommendations.
The other question seems to be unrelated, and should probably be asked as a separate question. And you should probably explain what accessibility toolbar you are referring to and what your HTML document contains.
In my mark-up I want to add a space ( ) between elements without always having to use CSS to do so. If I put in my markup, GWT throws errors. Is there a way around it?
For example:
<g:Label>One </g:Label><g:Label>Two</g:Label>
Should show:
One Two
And not:
OneTwo
As documented here, you just have to add this to the top of your XML file and it will work!
<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
Note that the GWT compiler won't actually visit this URL to fetch the file, because a copy of it is baked into the compiler. However, your IDE may fetch it.
Rather than use a Label, which to me shouldn't allow character entities at all, I use an HTML widget. In order to set the content, though, I find I have to do it as the HTML attribute, not the body content (note that the uppercase HTML is important here, since the set method is setHTML, not setHtml)
<g:HTML HTML="One " />
I've been a longtime user of XHTML 1.0 Strict, and I'm now trying to switch to XHTML5 in my new projects.
I'm confused that <?xml version='1.0' encoding='utf-8'?> is no longer considered valid, for HTML5, by http://validator.w3.org/. Why is that? Isn't that what all xml documents are supposed to start with?
And when I remove the standard <?xml…, my document still doesn't validate: now it's missing the encoding. I don't like those meta tags, but are they now effectively mandatory, to specify the encoding, in order to be valid (X)HTML5?
An XML declaration is valid and validates in XHTML serialization of HTML5. The following rather minimal document validates:
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title></title></head>
<body></body>
</html>
However, this only applies to XHTML serialization (XHTML syntax) of HTML5. In HTML serialization, it is not allowed. If you write the above document in a file and store it in a server that will send it with Content-Type: text/html (which normally happens if the filename ends with “.html”), then you get an error message:
Saw <?. Probable cause: Attempt to use an XML processing instruction in HTML.
(XML processing instructions are not supported in HTML.)
Here “HTML” means HTML serialization only.
Browsers do not care about an XML declaration in either syntax. In HTML syntax, it is just ignored, as a recoverable syntax error. In XHTML syntax, it does not matter, except for the encoding part.
Although XML 1.0 specification recommends (but does not require) an XML declaration, it would in practice matter (apart from the significance of encoding) only to software that is capable of processing different versions of XML. Browsers aren’t. And in addition to XML 1.0, there’s just XML 1.1, which is not used much. Besides, HTML5 is defined so that the XML version used in XHTML syntax is XML 1.0.
The encoding part may matter, but utf-8 is the default anyway for XML. If you use another encoding for some reason, then an XML declaration may be useful to prevent any conflicts. HTML5 CR says this in it discussion of encodings: “In XHTML, the XML declaration should be used for inline character encoding information, if necessary.” A meta tag cannot really help in XHTML when served with an XML content type, since the encoding has already been decided (by defaulting to UTF-8 or otherwise) when the tag is seen.
For HTML syntax, the <meta charset=...> tag may be used, but it is not needed for validity, and the encoding can be specified in HTTP headers (which override any meta tags). Using a meta tag may however be helpful, since a page might be saved locally, and then there won’t be any HTTP headers available when it is opened.
I'm facing the following exception in a very simple JSF 2 page after adding <h:form>:
java.lang.IllegalStateException: Cannot create a session after the response has been committed
at org.apache.catalina.connector.Request.doGetSession(Request.java:2758)
at org.apache.catalina.connector.Request.getSession(Request.java:2268)
I'm using Mojarra 2.1.3 and PrimeFaces3.0M4, on Tomcat 7.0.22 and JDK 7.
The page is a very basic data table:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:p="http://primefaces.org/ui">
<h:head>
</h:head>
<h:body>
<h:form>
<p:dataTable var="car" value="#{tableBean.cars}">
......
</p:dataTable>
</h:form>
</h:body>
</html>
The page shows correctly on the browser, but on the console I see the exception. The Exception does disappear if I remove the <h:form>.
How is this caused and how can I solve it?
This is a known problem and has been reported by yours truly as issue 2215. This will occur when the response buffer has overflowed (due to large content) and the response is been committed before the session is been created. This is result of bit overzealous attempts of Mojarra to postpone "unnecessary" session creation as much as possible (which is at its own a Good Thing though).
Until they get it fixed, there are several workarounds:
Create a Filter which does HttpServletRequest#getSession() before FilterChain#doFilter(). Advantage: no need to change JSF configuration/code. Disadvantage: when you want to avoid unnecessary session creation yourself as well.
Call ExternalContext#getSession() with true in bean's (post)constructor or preRenderView listener. Advantage: actually, nothing. Disadvantage: too hacky.
Add a context parameter with name of com.sun.faces.writeStateAtFormEnd and value of false to web.xml. Advantage: unnecessary session creation will be really avoided as opposed to #1 and #2. Disadvantage: response will now be fully buffered in memory until </h:form> is reached. If your forms are not extremely large, the impact should however be minimal. It would however still fail if your <h:form> starts relatively late in the view. This may be combined with #4.
Add a context parameter with name of javax.faces.FACELETS_BUFFER_SIZE and a value of the Facelets response buffer size in bytes (e.g. 65535 for 64KB) so that the entire HTML output or at least the <h:form> (see #3) fits in the response buffer. Advantage/disadvantage, see #3.
Add a context parameter with name of javax.faces.STATE_SAVING_METHOD and value of client to web.xml. Advantage: session will not be created at all unless you have session scoped beans. It also immediately solves potential ViewExpiredException cases. Disadvantage: increased network bandwidth usage. If you're using partial state saving, then the impact should however be minimal.
As to why the problem disappears when you remove <h:form>, this is because no session needs to be created in order to store the view state.
Update: this has as per the duplicate issue 2277 been fixed since Mojarra 2.1.8. So, you can also just upgrade to at least that version.
With the new version 2.1.21 released yesterday of javax.faces this problem seems to have disappeared.
Declare the new version:
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.1.21</version>
</dependency>
and replace the javax.faces.jar in the glassfish modules folder replacing the javax.faces.jar for the new version 2.1.21.
In my case (myfaces-2.2.8 & Tomcat 8.0.23) the Problem was a typo in the welcome-file of web.xml.
While debugging i saw, that Tomcat created as expected a 404, but somehow myfaces tried to access afterwards the Session, which caused then a java.lang.IllegalStateException: Cannot create a session after the response has been committed.
Using a valid page in welcome-file of web.xml fixed the Problem for me.
You may need to add an <f:view> and </f:view> before and after h:form elements, plus add the link to you html tag for jsf tags
<html xmlns:f="http://java.sun.com/jsf/core">
for this to work.
If you are using Spring MVC and call is made by Spring Forms then we should use GET method instead of POST(to fetch data) and there should be no input field we can use intead.
I have a legacy Struts 1.2.8 application that I'm maintaining and porting from Oracle Application Server (OAS) 10g to JBoss 4.2.3. I have a JSP that uses the Struts HTML tag library. The JSP page is backed by EJBs. The user enters an item number and the page displays the details of the item (e.g. item from a product catalog).
On the first 3 times I use this page, the item details are returned correctly. But for some reason, on the fourth submission of the page and on subsequent submissions, some of the item information is missing. I'm using
<html:hidden property="itemNumber"/>
<html:text property="itemNumber"/>
tags. The bizarre part of this problem is that I can't recreate the problem in OAS. In addition, if I replace the above html:text tag with
<input type="text" value="<%=itemForm.getItemNumber() %>" >
The code works correctly. My guess is that this is a session/request/scope problem. But I haven't found the correct configuration.
Is there special configuration required for Struts in JBoss?
Check the scope being used for the action in the struts-config.xml file. Most likely you probably want the scope to be request.
The problem was caching in the Jasper JSP engine. The default configuration is
enablePooling - Determines whether tag handler pooling is enabled. true or false,
default true.
I was able to set enablePooling to false and my problem was resolved. I assume this is a bug in Jasper. This bug appeared when a JSP custom tag (e.g. html:hidden) is followed by a jsp:attribute where the name is "value". See below.
<html:hidden property="itemNumber"/>
.
.
<html:text property="regularPrice" maxlength="9" readonly="<%=disabled%>"
tabindex="9" onkeyup="onRegularPriceChanged(this)">
<jsp:attribute name="value">
<webmodules:currency onlyDisplayValue="false">
<jsp:attribute name="currencyValue">
<bean:write name="updateItemForm" property="regularPrice"/>
</jsp:attribute>
</webmodules:currency>
</jsp:attribute>
</html:text>
There seems to be a namespace and caching conflict between the "value" that is set by the html:hidden and the "value" that is set by the jsp:attribute. After the JSP page was used twice the cached value set by the jsp:attribute was being used as the value for html:hidden.