Error processing empty faces-config.xml file

Splash Forums PrettyFaces Users Error processing empty faces-config.xml file

This topic contains 5 replies, has 3 voices, and was last updated by  Christian Kaltepoth 5 years, 10 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #18103

    Big Pig
    Participant

    On startup PrettyFaces (3.3.2) throws an exception for each faces-config.xml file discovered that is empty (my project has some empty META-INF/faces-config.xml to trigger Mojarra bean annotation scanning). The workaround is to put an empty root tag in each faces-config.xml file.

    The exception thrown is:

    2011/11/20 15:58:41.977 [main] ERROR c.o.s.o.a.c.d.Digester – Parse Fatal Error at line 1 column 1: Premature end of file.

    org.xml.sax.SAXParseException: Premature end of file.

    at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)

    at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174)

    at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:388)

    at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1414)

    at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1059)

    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:511)

    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)

    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:119)

    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 com.ocpsoft.shade.org.apache.commons.digester.Digester.parse(Digester.java:1887)

    at com.ocpsoft.pretty.faces.el.resolver.FacesConfigBeanNameResolver.processFacesConfig(FacesConfigBeanNameResolver.java:275)

    at com.ocpsoft.pretty.faces.el.resolver.FacesConfigBeanNameResolver.init(FacesConfigBeanNameResolver.java:98)

    at com.ocpsoft.pretty.faces.el.LazyBeanNameFinder.<init>(LazyBeanNameFinder.java:90)

    at com.ocpsoft.pretty.faces.config.spi.AnnotationConfigurationProvider.loadConfiguration(AnnotationConfigurationProvider.java:59)

    at com.ocpsoft.pretty.faces.config.PrettyConfigurator.configure(PrettyConfigurator.java:63)

    at com.ocpsoft.pretty.PrettyFilter.init(PrettyFilter.java:316)

    at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:114)

    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)

    at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:756)

    at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:255)

    at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1212)

    at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:610)

    at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:453)

    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)

    at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:36)

    at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:183)

    at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:485)

    at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:138)

    at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:142)

    at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:53)

    at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:604)

    at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:535)

    at org.eclipse.jetty.util.Scanner.scan(Scanner.java:398)

    at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:332)

    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)

    at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:118)

    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)

    at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:546)

    at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:221)

    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)

    at org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:45)

    at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:53)

    at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:90)

    at org.eclipse.jetty.server.Server.doStart(Server.java:262)

    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)

    #21723

    Hello,

    thanks for reporting this. You are right. PrettyFaces will print error messages to the log if a faces-config.xml cannot be parsed. Of cause the parser will also fail for a completely empty file. Is there any reason you prefer an empty file over an file with an empty root tag (which would be a valid faces configuration file)? I just reproduced this and even MyFaces Core fails to parse such a file which completely breaks the application.

    I’m not sure if there is a nice way to fix this. And I for myself don’t think that creating an completely empty faces-config.xml file is a good way to trigger annotation scanning. IMHO creating an file with an empty root tag is much nicer.

    However. Thanks for reporting this. Maybe you information regarding the workaround will help other who run into that issue.

    Christian

    #21724

    I think we just need to trap exceptions from the config parser a little better :) We can do that.

    #21725

    I don’t know. It looks like Digester itself is logging the exception. In this case it will be difficult if Digester doesn’t have any options to configure the logging behavior. I’ll have a look at this tomorrow. Perhaps I’ll find a way. Fortunately we got rid of Digester in 4.0. :-)

    #21726

    Ahhh, it’s a logged exception, not a thrown one. Yea, not sure how much we can do about that except maybe surpress errors from digester, but that’s probably not a good idea for other reasons.

    #21727

    I just had a look at this issue. The exception is in fact logged twice. Once by Digester and once by us. I changed our log statement to a warning and it now doesn’t contain the stacktrace any more. I think that should be OK.

    Unfortunately there is no way for us to silence the Digester log statement. That has to be done by the users in their logging configuration. But as we are shading Digester into our JAR with a custom package name it should be OK to do so. Just disable logging for “com.ocpsoft.shade.org.apache.commons.digester.Digester”.

    For PrettyFaces 4.0 the situation is much more simple as we are using JAXB directly. I changed the logging statement so it won’t be so noisy as before.

    Christian

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

Comments are closed.