>> javax.servlet.jsp.JspException
>> at
>> com.sun.faces.taglib.jsf_core.ViewTag.doStartTag(ViewTag.java:137)
>> at com
>> .icesoft.faces.webapp.parser.Parser.executeJspLifecycle(Parser.java: 188)
>> at com
>> .icesoft.faces.webapp.parser.Parser.executeJspLifecycle(Parser.java: 212)
>> at com.icesoft.faces.webapp.parser.Parser.parse(Parser.java: 157)
>> at com .icesoft
>> .faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:
>> 497)
>> at com .icesoft
>> .faces.application.D2DViewHandler.renderView(D2DViewHandler.java:161)
>> at com .sun .faces
>> .lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107)
>> at
>> com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:268)
>> at
>> com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:137)
>> at com .icesoft .faces .webapp
>> .http.core.JsfLifecycleExecutor.apply(JsfLifecycleExecutor.java:18)
>> at com.icesoft.faces.webapp.http.core.PageServer
>> $1.respond(PageServer.java:25)
>> at com .icesoft .faces .webapp .http .servlet
>> .ServletRequestResponse.respondWith(ServletRequestResponse.java:162)
>> at
>> com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet $
>> ThreadBlockingRequestResponse
>> .respondWith(ThreadBlockingAdaptingServlet.java:36)
>> at com
>> .icesoft.faces.webapp.http.core.PageServer.service(PageServer.java:30)
>> at com .icesoft .faces
>> .webapp.http.core.SingleViewServer.service(SingleViewServer.java:48)
>> at
>> com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer
>> $Matcher.serviceOnMatch(PathDispatcherServer.java:50)
>> at com .icesoft .faces .webapp .http .common
>> .standard.PathDispatcherServer.service(PathDispatcherServer.java:19)
>> at com .icesoft .faces .webapp .http .servlet
>> .ThreadBlockingAdaptingServlet
>> .service(ThreadBlockingAdaptingServlet.java:19)
>> at com .icesoft .faces .webapp .http .servlet
>> .EnvironmentAdaptingServlet.service(EnvironmentAdaptingServlet.java: 29)
>> at com .icesoft .faces .webapp .http .servlet
>> .MainSessionBoundServlet.service(MainSessionBoundServlet.java:105)
>> at com .icesoft .faces .webapp
>> .http.servlet.SessionDispatcher.service(SessionDispatcher.java:37)
>> at com.icesoft.faces.webapp.http.servlet.PathDispatcher
>> $Matcher.serviceOnMatch(PathDispatcher.java:52)
>> at com .icesoft .faces
>> .webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
>> at com .icesoft
>> .faces.webapp.http.servlet.MainServlet.service(MainServlet.java:76)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java: 803)
>> at org .apache .catalina .core
>> .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
>> 269)
>> at org .apache .catalina
>> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>> at org .apache
>> .catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
>> 204)
>> at org .apache
>> .catalina.core.StandardContextValve.invoke(StandardContextValve.java:
>> 174)
>> at org .apache
>> .catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>> at org .apache
>> .catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>> at org .apache
>> .catalina.core.StandardEngineValve.invoke(StandardEngineValve.java: 108)
>> at org
>> .apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: 151)
>> at org
>> .apache.coyote.http11.Http11Processor.process(Http11Processor.java: 874)
>> at org.apache.coyote.http11.Http11BaseProtocol
>> $Http11ConnectionHandler.processConnection(Http11BaseProtocol.java: 665)
>> at org .apache
>> .tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java: 528)
>> at org .apache .tomcat .util .net
>> .LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
>> at org.apache.tomcat.util.threads.ThreadPool
>> $ControlRunnable.run(ThreadPool.java:689)
>> at java.lang.Thread.run(Thread.java:595)

Need to see if we can avoid the failures and support this to the same degree we did prior to ICE-2551.

To reproduce the problem, check out:
http://server:8888/svn/repo/qa/trunk/component/application
and build the application with "ant" and deploy it to tomcat.

To access the page, use the following url:
http://localhost:8080/componentTest/validatorTest.iface?test=inputhidden

This is not a valid test case. This following snippet is from the JSF 1.2 specification;

"main.jsp"

<f:view>
<f:subview id="aaa">
<c:import url="foo.jsp"/>
</f:subview>

<f:subview id="bbb">
<c:import url="foo.jsp"/>
</f:subview>
</f:view>

"foo.jsp"
... components and other content ...

Following this is the key bit.

unique identifiers:
In all of the above examples, note that foo.jsp and bar.jsp may not contain
<f:view>

I'm not sure it's in anyone's best interest to support invalid markup.

And further in the description of <f:subview>

<f:subview>
Container action for all JSF core and component custom actions used on a nested page
included via <jsp:include> or any custom action that dynamically includes another page
from the same web application, such as JSTL's <c:import>.

Syntax
Body Content
JSP. May contain any combination of template text, other JSF custom actions, and custom
actions from other custom tag libraries.
Attributes

Constraints
? Must be nested inside a <f:view> custom action (although this custom action might be
in a page that is including the page containing the <f:subview> custom action.

? Must not contain an <f:view> custom action. <-- Here

? Must have an id attribute whose value is unique within the scope of the parent naming
container.
? May be placed in a parent page (with <jsp:include> or <c:import> nested inside),
or within the nested page.
<f:subview id="componentIdOrImmediateExpression"
[binding="componentReference"]
[rendered="

"]>

The example in this page incorrectly shows a view tag in the included page:

http://www.jsftoolbox.com/documentation/help/12-TagReference/core/f_subview.html

This is not a bug, as the spec states no included file can have a <f:view> tag. We are going to add some more debugging output code in an effort to help the user diagnose the tag parsing exception though.