Doctype in JSF Mojarra - jsf-2

What Doctype should I use in JSF pages? The other day I'm trying to migrate from Mojarra 2.1.13 to 2.1.18 and it seems that the way the doc types are interpreted changed. In the root template I have following DOC TYPE
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Do I also have to include this?
<?xml version="1.0"?>
In composites (that use this template) I used to have following doctype
<!DOCTYPE composite PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
But it seems that Mojarra 2.1.18 doesn't really support that. Also I didn't find this in any JSF 2.0 reference, this we used to use in JSF 1.2. If I have this doctype in composite page, it will render composite doctype instead of html that is in the template. In the result, the css styles are messed up.
So what's the correct usage of doctypes in JSF 2.0. Or is this issues with Mojarra? I didn't find any reference regarding this.

I created a JIRA issue for this: http://java.net/jira/browse/JAVASERVERFACES-2820
and it has been closed as this is the expected behavior.
"The composite page is where you actually use the template. So it is the outer most file where you specified a doc type. As such it defines the doc type that will be rendered."
Just specify the doctype in a template and nowhere else

I also migrated Jboss 7.1 to JBoss EAP 6.1
I found not very nice workaround - to insert on each page (not template):
<!DOCTYPE html>
e. g.:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html" template="template.xhtml">
Is there any other way - for doctype to be read from master template?

Related

Grails import NetBeans error

I have this code in the top of my main.gsp file
<%# page import="com.somethingToImport"%>
NetBeans is giving me an error: expecting EOF, found 'import' # line 1, column 20
I think this is causing my app to crash in IE. What can I do to fix this?
This should help the IE issue but won't fix NetBeans complaining. Try including the DOCTYPE in the first line of the GSP.
Example:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<%# page import="com.somethingToImport" %>
<html xmlns="http://www.w3.org/1999/xhtml">
Note: I added a space between the import and the '%'

Apache MyFaces: VariableMapperWrapper.resolveVariable, StackOverflowError: Could not Resolve Variable [Overflow]

I wonder what's the reason for this exception having created new Facelets containing some includes. There is obviously a recursion inside the EL resolution. The debugging of the VariableMapperWrapper.resolveVariable method doesn't show anything special: EL resolution is happening ...
14.03.2013 17:20:13 org.apache.catalina.core.StandardWrapperValve invoke
SCHWERWIEGEND: Servlet.service() for servlet Faces Servlet threw exception
java.lang.StackOverflowError
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
at java.lang.StringBuilder.append(StringBuilder.java:119)
at org.apache.myfaces.view.facelets.el.VariableMapperWrapper.resolveVariable(VariableMapperWrapper.java:96)
at org.apache.myfaces.view.facelets.el.VariableMapperWrapper.resolveVariable(VariableMapperWrapper.java:89)
at org.apache.myfaces.view.facelets.el.VariableMapperWrapper.resolveVariable(VariableMapperWrapper.java:89)
... (recursion) ...
at org.apache.myfaces.view.facelets.el.VariableMapperWrapper.resolveVariable(VariableMapperWrapper.java:89)
at org.apache.myfaces.view.facelets.el.VariableMapperWrapper.resolveVariable(VariableMapperWrapper.java:89)
at org.apache.myfaces.view.facelets.el.VariableMapperWrapper.resolveVariable(VariableMapperWrapper.java:89)
at org.apache.myfaces.view.facelets.el.VariableMapperWrapper.resolveVariable(VariableMapperWrapper.java:89)
at com.sun.el.lang.VariableMapperFactory.resolveVariable(VariableMapperFactory.java:63)
at com.sun.el.lang.ExpressionBuilder.visit(ExpressionBuilder.java:234)
at com.sun.el.parser.SimpleNode.accept(SimpleNode.java:172)
at com.sun.el.parser.SimpleNode.accept(SimpleNode.java:175)
at com.sun.el.lang.ExpressionBuilder.prepare(ExpressionBuilder.java:186)
at com.sun.el.lang.ExpressionBuilder.build(ExpressionBuilder.java:197)
at com.sun.el.lang.ExpressionBuilder.createValueExpression(ExpressionBuilder.java:240)
at com.sun.el.ExpressionFactoryImpl.createValueExpression(ExpressionFactoryImpl.java:98)
at org.apache.myfaces.view.facelets.tag.TagAttributeImpl.getValueExpression(TagAttributeImpl.java:486)
at org.apache.myfaces.view.facelets.tag.jsf.ValueHolderRule$DynamicValueExpressionMetadata.applyMetadata(ValueHolderRule.java:99)
at org.apache.myfaces.view.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:45)
at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:66)
at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:93)
at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:237)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49)
...
It has finally emerged there was a special type of recursion inside the Facelets XHTML code. I noticed other people created such a recursion by inclusion of snippet chains like a.xhtml includes b.xhtml includes a.xhtml
In my case an included snippet contained a copy&paste error from the main XHTML page, the snippet header section:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">
<ui:composition template="xyz.xhtml">
...
--> template="xyz.xhtml" included the snippet above --> recursion.
The removal of the anyway wrong template attribute resolved the problem. In the end the exception above as the symptom of this problem was a bit far away from the error reason. The resolution was not at all obvious.

Avoid multiple DOCTYPE and html tags when using ui:include

we are using several ui:include tags in the "main" page. The page that is to be included looks like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns=".." xmlns:ui="..." ...>
<ui:fragment rendered="${foo}">
some html code
</ui:fragement>
<ui:fragment rendered="${!foo || bar}">
some more html code
</ui:fragement>
</html>
Using the ui:include for templating results in repeating the DOCTYPE and html tag several times in the source code, which is pretty ugly. (Sure, the user doesn't see, but I'm a fan of tidy html)
However, if I remove the DOCTYPE and html tag from the to-be-included-xhtml, the Faces Servlet throws an exception stating that the prefix ui for ui:fragment is not bound.
Does anybody know, how I can include another XHTML page without the multiple DOCTYPEs and htmls?
You should take a look at the ui:composition tag.
We also use ui:include to include jsf2 pages, and to solve the problem you have I believe you could alter your included page by adding the ui:composition tag as follows:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns=".." xmlns:ui="..." ...>
<ui:composition>
<ui:fragment rendered="${foo}">
some html code
</ui:fragement>
<ui:fragment rendered="${!foo || bar}">
some more html code
</ui:fragement>
</ui:composition>
</html>

JSF2.0: EL are not resolved in a Composite Component taglib

I'm trying to create a custom composite component taglib in my office but i get a strange issue with EL. It seems expressions as #{cc.attrs.[var] } are already resolve as empty.
I try to create my taglib in a jar. In my jar i have my files ordered as following:
|_ /
.....|_ META-INF
..........|_ compo.taglib.xml
..........|_ resources
...............|_ components
....................|_ hello.xhtml
compo.taglib.xml contains:
<facelet-taglib xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd"
version="2.0">
<namespace>http://www.example.com/jsf/compo</namespace>
<composite-library-name>compo</composite-library-name>
<tag>
<tag-name>hello</tag-name>
<source>./components/hello.xhtml</source>
</tag>
</facelet-taglib>
hello.xhtml contains:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:composite="http://java.sun.com/jsf/composite">
<composite:interface name="hello" displayName="hello">
<composite:attribute name="name" required="true" type="String"/>
</composite:interface>
<composite:implementation >
hello #{cc.attrs.name}!
</composite:implementation>
</html>
My web project contains in WEB-INF lib my taglib as a jar, jsf-impl.jar and jsf-api.jar (from Mojarra) my page is simply that:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:comp="http://www.example.com/jsf/compo" >
<body>
<comp:hello name="John"></comp:hello>
</body>
</html>
At rendering i see "hello !" but not "hello John!". Attributes values seems be lost somewhere. I try this sample on tomcat 6.0.29 and Websphere 7.
I made something wrong?
Have you tested your control in web application rather than from taglib (jar file)?
I can only guess but I think your attribute is not showing because you named it name. In some cases "name" attribute is beeing used by JSF (for example in f:attribute or f:param or even ui:param uses attribute name). Try to replace attribute name with oder word.
You need to look here and check if attribute name is available.
Yes this case appears also with other attributes.
I tried with the component in web application and issue doesn't appear.
I also tried with the component in a jar with default namespace: issue doesn't appear. I think there is bug when using composite component in a jar with custom namespace.

Why does nginx + memcache corrupt my response body?

I'm caching some web pages in memcache. When I read the page directly from the cache, the page is well formed like this ...
!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"-:-- 0
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="content-type" content="text/html;charset=UTF-8" />
but when I use a browser or curl to read it from nginx (version 0.8.50), it looks like response headers are ending up in the body of the response like this ...
�{
" ETag"'"16bb9f51667d334aa4e7663ca28d308a""X-Runtime177"Content-Type"text/html; charset=utf-8"Content-Length"5428"Set-Cookie""Cache-Control"(private, max-age=0, must-revalidate"4<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
My nginx config is pretty simple ...
set $memcached_key $cookie__app_session$uri;
memcached_pass localhost:11211;
default_type text/html;
error_page 404 502 /fallback$uri;
Does anyone have an idea why the response is corrupt?
Do! Stupid developer problem!
There were two mistakes
(a) I was storing the response header and body in memcache, then adding headers in an nginx rule. Storing only the response body in memcache removed the bulk of the problems
(b) I was storing the response in Ruby's marshal format (the default setting in memcache-client) - reading the contents of memcache using a simple Ruby client was hiding the fact that the format was not directly usable by nginx.
Hope that helps someone sometime!
Chris

Resources