Liferay faces-config.xml SAXReader Validation fails

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: 6.0.5 GA
• Fix Version/s: --Sprint - SP, 6.1.0 CE RC1, --Sprint 11/12, 6.2.0 CE M2
• Component/s: WCM
• Labels: None
• Branch Version/s:
  6.0.x
• Similar Issues: Show 5 results ; ;

  LPS-14182	Missing xsd file causes portlet deploy to be slow
  LPS-28448	Condition node fails to validate
  LPS-4674	Inconsistent SAXReader instantiation by Dom4j causes lots of issues.
  LPS-29049	Incorrect FQCN for debug phase listener in JSF template
  LPS-15255	Using users.screen.name.allow.numeric=true, username validation fails with certain random numbers

In all our Liferay Project we're encountering the same problem since the last 12 - 15h. As soon as you try to deploy a JSF based portlet (Version 1.2), Liferay fails to do that. Here is the exception:

com.liferay.portal.kernel.xml.DocumentException: Error on line 5 of document http://download.oracle.com/javase/6/docs/technotes/guides/xml/index.html : s4s-elt-character: Non-whitespace characters are not allowed in schema elements other than 'xs:appinfo' and 'xs:documentation'. Saw 'JDK 6 XML-related APIs '. Nested exception: s4s-elt-character: Non-whitespace characters are not allowed in schema elements other than 'xs:appinfo' and 'xs:documentation'. Saw 'JDK 6 XML-related APIs '.
at com.liferay.portal.xml.SAXReaderImpl.read(SAXReaderImpl.java:338)
at com.liferay.portal.kernel.xml.SAXReaderUtil.read(SAXReaderUtil.java:115)
at com.liferay.portal.tools.deploy.PortletDeployer.setupJSF(PortletDeployer.java:480)
at com.liferay.portal.tools.deploy.PortletDeployer.getExtraContent(PortletDeployer.java:145)
at com.liferay.portal.tools.deploy.BaseDeployer.updateWebXml(BaseDeployer.java:1436)
at com.liferay.portal.tools.deploy.BaseDeployer.deployDirectory(BaseDeployer.java:494)
at com.liferay.portal.tools.deploy.BaseDeployer.deployFile(BaseDeployer.java:829)
at com.liferay.portal.tools.deploy.BaseDeployer.deployFile(BaseDeployer.java:766)
at com.liferay.portal.tools.deploy.BaseDeployer.deploy(BaseDeployer.java:455)
at com.liferay.portal.deploy.auto.PortletAutoDeployer.autoDeploy(PortletAutoDeployer.java:92)
at com.liferay.portal.deploy.auto.PortletAutoDeployListener.deploy(PortletAutoDeployListener.java:78)
at com.liferay.portal.kernel.deploy.auto.AutoDeployDir.processFile(AutoDeployDir.java:180)
at com.liferay.portal.kernel.deploy.auto.AutoDeployDir.scanDirectory(AutoDeployDir.java:221)
at com.liferay.portal.kernel.deploy.auto.AutoDeployScanner.run(AutoDeployScanner.java:49)
Caused by: org.dom4j.DocumentException: Error on line 5 of document http://download.oracle.com/javase/6/doc

seems like oracle is moving the XSD Schema files to new servers and thus they can't be found anymore....

Here is the faces-config.xml Header:
<?xml version="1.0" encoding="UTF-8"?>
<faces-config 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-facesconfig_1_2.xsd"
version="1.2">

....

A workaround is to change the faces-config.xml Header to:
<?xml version="1.0" encoding="UTF-8"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2">

Or to put the web-facesconfig_1_2.xsd into the portlet's classpath and change the Header to:
<?xml version="1.0" encoding="UTF-8"?>
<faces-config 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 web-facesconfig_1_2.xsd"
version="1.2">

However it would be good if we would have the possibility to disable the SAXReader Validation in the portel.properties or if we could integrate the web-facesconfig_1_2.xsd directly to the portal

[Neil Griffin]

We saw this problem too at portletfaces.org:
http://www.portletfaces.org/community/forums/-/message_boards/message/51377

Oracle's website caused this problem, but it has been fixed for many days now. Not sure why you're still seeing this error.

[Zsolt Balogh]

We'll fix this issue by providing a property to switch off validation completely in emergency issues: See LPS-15205

[Vilmos Papp]

Solved in LPS-15205