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 10 years, 2 months ago.

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

    Big Pig

    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.ocpsoft.pretty.faces.el.resolver.FacesConfigBeanNameResolver.processFacesConfig(

    at com.ocpsoft.pretty.faces.el.resolver.FacesConfigBeanNameResolver.init(

    at com.ocpsoft.pretty.faces.el.LazyBeanNameFinder.<init>(

    at com.ocpsoft.pretty.faces.config.spi.AnnotationConfigurationProvider.loadConfiguration(

    at com.ocpsoft.pretty.faces.config.PrettyConfigurator.configure(

    at com.ocpsoft.pretty.PrettyFilter.init(

    at org.eclipse.jetty.servlet.FilterHolder.doStart(

    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(

    at org.eclipse.jetty.servlet.ServletHandler.initialize(

    at org.eclipse.jetty.servlet.ServletContextHandler.startContext(

    at org.eclipse.jetty.webapp.WebAppContext.startContext(

    at org.eclipse.jetty.server.handler.ContextHandler.doStart(

    at org.eclipse.jetty.webapp.WebAppContext.doStart(

    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(

    at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(

    at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(

    at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(

    at org.eclipse.jetty.deploy.DeploymentManager.addApp(

    at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(

    at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(

    at org.eclipse.jetty.util.Scanner.reportAddition(

    at org.eclipse.jetty.util.Scanner.reportDifferences(

    at org.eclipse.jetty.util.Scanner.scan(

    at org.eclipse.jetty.util.Scanner.doStart(

    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(

    at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(

    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(

    at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(

    at org.eclipse.jetty.deploy.DeploymentManager.doStart(

    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(

    at org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(

    at org.eclipse.jetty.server.handler.AbstractHandler.doStart(

    at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(

    at org.eclipse.jetty.server.Server.doStart(

    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(



    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.



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


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


    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.


    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 “”.

    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.


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

The forum ‘PrettyFaces Users’ is closed to new topics and replies.

Comments are closed.