Community
Participate
Working Groups
I'm seeing the following exception in the log of an adopter environment. This occurs when using the flush cache button in the 'JavaServer Faces | Tag Registry' View. java.net.NoRouteToHostException: No route to host: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:519) at java.net.Socket.connect(Socket.java:469) at sun.net.NetworkClient.doConnect(NetworkClient.java:163) at sun.net.www.http.HttpClient.openServer(HttpClient.java:394) at sun.net.www.http.HttpClient.openServer(HttpClient.java:529) at sun.net.www.http.HttpClient.<init>(HttpClient.java:233) at sun.net.www.http.HttpClient.New(HttpClient.java:306) at sun.net.www.http.HttpClient.New(HttpClient.java:323) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:852) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:793) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:718) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1041) at org.eclipse.emf.ecore.resource.impl.URIHandlerImpl.createInputStream(URIHandlerImpl.java:178) at org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.createInputStream(ExtensibleURIConverterImpl.java:301) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.resolveEntity(XMLHandler.java:810) at com.sun.org.apache.xerces.internal.util.EntityResolverWrapper.resolveEntity(EntityResolverWrapper.java:107) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntityAsPerStax(XMLEntityManager.java:1018) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(XMLDocumentScannerImpl.java:1190) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(XMLDocumentScannerImpl.java:1089) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1002) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at javax.xml.parsers.SAXParser.parse(SAXParser.java:395) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:181) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:180) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1494) at org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.TagModelLoader.loadFromInputStream(TagModelLoader.java:64) at org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.JarFileFaceletTaglibLocator.processJar(JarFileFaceletTaglibLocator.java:145) at org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.JarFileFaceletTaglibLocator.doLocate(JarFileFaceletTaglibLocator.java:104) at org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.AbstractFaceletTaglibLocator.doLocate(AbstractFaceletTaglibLocator.java:1) at org.eclipse.jst.jsf.common.internal.locator.AbstractLocator.locate(AbstractLocator.java:94) at org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.ProjectTaglibDescriptor$1.run(ProjectTaglibDescriptor.java:80) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.ProjectTaglibDescriptor.initialize(ProjectTaglibDescriptor.java:68) at org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.ProjectTaglibDescriptor.getTagLibraries(ProjectTaglibDescriptor.java:90) at org.eclipse.jst.jsf.facelet.core.internal.registry.FaceletTagRegistry.initialize(FaceletTagRegistry.java:151) at org.eclipse.jst.jsf.facelet.core.internal.registry.FaceletTagRegistry.getAllTagLibraries(FaceletTagRegistry.java:106) at org.eclipse.jst.jsf.ui.internal.tagregistry.TaglibContentProvider$UpdateNamespacesListJob.run(TaglibContentProvider.java:351) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Could you list all of the jars on your classpath? It looks like a taglib has been found that we are failing to parse correctly.
JarFileFaceletTaglibLocator.processJar() fails on two entries for the Mojarra faces ext taglib in the jsf-impl.jar in a glassfishv3 installation (C:\glassfishv3\glassfish\modules\jsf-impl.jar) It fails on entry names of - com/sun/faces/metadata/taglib/mojarra_ext.taglib.xml - META-INF/mojarra_ext.taglib.xml but has no problem with the other entries in that jar, - com/sun/faces/metadata/taglib/jstl-core.taglib.xml - com/sun/faces/metadata/taglib/composite.taglib.xml - com/sun/faces/metadata/taglib/facelets_jsf_core.taglib.xml - com/sun/faces/metadata/taglib/html_basic.taglib.xml - com/sun/faces/metadata/taglib/ui.taglib.xml - com/sun/faces/metadata/taglib/jstl-fn.taglib.xml My project includes a JSF 2.0 user lib with the Glassfish JSF jars and JSTL 1.2 as shared lib from a server instance. The classpath jar files also include the JRE and other container jars. The JarFileFaceletTaglibLocator is processing the following jars, looking for tag lib entries... C:/wls/jrockit_160_14_R27.6.4-18/jre/lib/resources.jar C:/wls/jrockit_160_14_R27.6.4-18/jre/lib/rt.jar C:/wls/jrockit_160_14_R27.6.4-18/jre/lib/jsse.jar C:/wls/jrockit_160_14_R27.6.4-18/jre/lib/jce.jar C:/wls/jrockit_160_14_R27.6.4-18/jre/lib/charsets.jar C:/wls/jrockit_160_14_R27.6.4-18/jre/lib/ext/dnsns.jar C:/wls/jrockit_160_14_R27.6.4-18/jre/lib/ext/localedata.jar C:/wls/jrockit_160_14_R27.6.4-18/jre/lib/ext/sunjce_provider.jar C:/wls/jrockit_160_14_R27.6.4-18/jre/lib/ext/sunmscapi.jar C:/wls/jrockit_160_14_R27.6.4-18/jre/lib/ext/sunpkcs11.jar C:/wls/wlserver_10.3/server/lib/api.jar C:/wls/modules/glassfish.jstl_1.2.0.1.jar C:/wls/modules/javax.jsf_1.2.0.1.jar C:/wls/modules/javax.ejb_3.0.1.jar C:/wls/modules/javax.enterprise.deploy_1.2.jar C:/wls/modules/javax.interceptor_1.0.jar C:/wls/modules/javax.jms_1.1.1.jar C:/wls/modules/javax.jsp_1.1.0.0_2-1.jar C:/wls/modules/javax.jws_2.0.jar C:/wls/modules/javax.activation_1.1.0.0_1-1.jar C:/wls/modules/javax.mail_1.1.0.0_1-4-1.jar C:/wls/modules/javax.xml.soap_1.3.1.0.jar C:/wls/modules/javax.xml.rpc_1.2.1.jar C:/wls/modules/javax.xml.ws_2.1.1.jar C:/wls/modules/javax.management.j2ee_1.0.jar C:/wls/modules/javax.resource_1.5.1.jar C:/wls/modules/javax.servlet_1.0.0.0_2-5.jar C:/wls/modules/javax.transaction_1.0.0.0_1-1.jar C:/wls/modules/javax.xml.stream_1.1.1.0.jar C:/wls/modules/javax.security.jacc_1.0.0.0_1-1.jar C:/wls/modules/javax.xml.registry_1.0.0.0_1-0.jar C:/wls/wlserver_10.3/server/lib/wls-api.jar C:/wls/modules/com.bea.core.apache_1.2.0.0.jar C:/wls/modules/com.bea.core.i18n_1.6.0.0.jar C:/wls/modules/com.bea.core.logging_1.6.0.0.jar C:/wls/modules/com.bea.core.utils.full_1.7.0.0.jar C:/wls/modules/com.bea.core.utils.wrapper_1.4.0.0.jar C:/wls/modules/com.bea.core.utils.classloaders_1.6.0.0.jar C:/wls/modules/com.bea.core.common.security.providers.env_1.0.0.0_5-2-0-0.jar C:/wls/modules/com.bea.core.common.security.saml2.manage_1.0.0.0_5-2-0-0.jar C:/wls/modules/com.bea.core.weblogic.web.api_1.3.0.0.jar C:/wls/modules/com.bea.core.weblogic.rmi.client_1.6.0.0.jar C:/wls/modules/com.bea.core.transaction_2.6.0.0.jar C:/wls/modules/com.bea.core.workarea_1.6.0.0.jar C:/wls/modules/com.bea.core.xml.weblogic.xpath_1.3.0.0.jar C:/wls/modules/com.bea.core.datasource6_1.7.0.0.jar C:/wls/modules/com.bea.core.weblogic.stax_1.6.0.0.jar C:/wls/modules/javax.persistence_1.0.0.0_1-0-2.jar C:/glassfishv3/glassfish/modules/jsf-impl.jar C:/glassfishv3/glassfish/modules/jsf-api.jar C:/testWorkspaces/bug/.metadata/.plugins/oracle.eclipse.tools.weblogic/libraries/jstl_1.2_1.2.0.1/1/WEB-INF/lib/glassfish.jstl_1.2.0.1.jar
Both of the failing Mojarra tag lib entries have the facelet-taglib DOCTYPE in the XML doc. <!facelet-taglib PUBLIC "-//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN" "http://java.sun.com/dtd/facelet-taglib_1_0.dtd">
(In reply to comment #3) > Both of the failing Mojarra tag lib entries have the facelet-taglib DOCTYPE in > the XML doc. > > <!facelet-taglib PUBLIC > "-//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN" > "http://java.sun.com/dtd/facelet-taglib_1_0.dtd"> Thanks for the diagnostic Carlin. This is due to the fact that I'm discriminating between new style and old style taglibs correctly. We'll need to figure out whether or not to support this case. Minimally I think we need to suppress this exception.
Tentatively marking for consideration.
The worst scenario for this bug is that tag registry doesn't get created. I believe this is severe enough to require a fix in 3.2. Moving to RC3.
Created attachment 169520 [details] Adds a URIHandler to the ResourceSet of the TagModelLoader that resolves the Facelet DTD without a socket call
Created attachment 169521 [details] Regression test coverage
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This is a stop-ship defect that prevents the use of the Facelets DTD in an XHTML file in a disconnected mode. * Is there a work-around? If so, why do you believe the work-around is insufficient? No reasonable workaround * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Patch includes Junit test * Give a brief technical overview. Who has reviewed this fix? See comment 7 * What is the risk associated with this fix? low
This sound ok, but can you explain a bit more ... you say "Adds a URIHandler to the ResourceSet of the TagModelLoader that resolves the Facelet DTD without a socket call". Is it the case this should have always been the correct way to do it? Or is this some sort of work around for working offline or behind a proxy? Am I interpreting this correctly that it will always correctly resolve the facelet dtd now? (Or is this one of those handlers this just avoids the exception?) Thanks,
> Is it the case this should have always been the correct way to do it? Or is > this some sort of work around for working offline or behind a proxy? It appears that this is the "correct" way to do it inasmuch as otherwise the xerces parser will to try to connect out to the internet to try and resolve the dtd. Without this fix, offline/bad proxy behaviour can cause some or all of the facelet tag registry to fail to load. > Am I interpreting this correctly that it will always correctly resolve the > facelet dtd now? (Or is this one of those handlers this just avoids the > exception?) Yes, we now divert the request for this DTD to the XML catalog and it should never try to access "online" content.
Sounds great. Thanks.
Patches applied to HEAD (3.2M3).
