Good afternoon,
I posted this as a bug here: https://issues.apache.org/jira/browse/MYFACES-3988 At the request of Mike I am resposting the question here to elicit some feedback. Here were his other comments: Also, is your Glassfish/Wildfly container using Mojarra as the JSF implementation? If nothing else, MyFaces could provide a configuration parameter which would ignore empty render type tag contents and continue onward. Do you mind submitting a patch to provide such behavior? To answer Mike's questions: I tested this on Glassfish 4.1 using Mojarra 2.2.7: [2015-04-29T15:18:19.896-0400] [glassfish 4.1] [INFO] [jsf.config.listener.version] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=87 _ThreadName=Thread-26] [timeMillis: 1430335099896] [levelValue: 800] [[ Initializing Mojarra 2.2.7 ( 20140610-1547 https://svn.java.net/svn/mojarra~svn/tags/2.2.7@13362) for context '']] Using my simple test a text box is displayed using Mojarra, but it isn't displayed with MyFaces. For reference, here is my original post: While developing a custom tag library we added an empty renderer-type tag like this: <tag> <tag-name>myinput</tag-name> <component> <component-type>my.test.MyInput</component-type> <renderer-type></renderer-type> </component> </tag> This causes the following exception: Caused by: java.lang.Exception: Value Cannot be Empty at org.apache.myfaces.view.facelets.compiler.TagLibraryConfigUnmarshallerImpl $LibraryHandler.endElement(TagLibraryConfigUnmarshallerImpl.java:395) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl $FragmentContentDispatcher.dispatch(Unknown Source) ... This appears to be expected based on the code in TagLibraryConfigUnmarshallerImpl. From what I can see the exception appears to be thrown on elements which are used in another spot. If any of them are empty they will throw the above exception. Wildfly/Glassfish does not have the same behavior, so my assumption is they just ignore it. Should the MyFaces code be modified to just continue on without the exception, based on the reference implementation? I can quickly create something if so, I just wanted to bring this up to the community at large since I don't know the reasoning behind the difference of the implementations. Christopher Meyer Software Developer (919) 543-9782 T/L: 441-9782