I have yet to try this with the 1.5.x branch, but with the HEAD code and newest
Seam release, we get a totally different situation. Basically, the debug.seam
or debug.jsf page will show, but the output is garbled.
Comparing the dvdstore app (with ICEfaces) with the hibernate app (without
ICEfaces) shows that the stock JSF components, like h:outputText and
h:dataTable, are not being rendered. I found that
org.jboss.seam.debug.jsf.SeamDebugPhaseListener is responsible for serving out
the applications\jboss-seam-1.1.0.BETA2\src\debug\META-INF\debug.xhtml file
using Facelets directly, instead of using the ViewHandler mechanism. This
PhaseListener is auto-wired by
applications\jboss-seam-1.1.0.BETA2\src\debug\META-INF\faces-config.xml
I think that the easiest approach will be to make a Seam
com.sun.facelets.impl.ResourceResolver that knows how to get at this
debug.xhtml file, and just use the existing facelets.RESOURCE_RESOLVER
parameter to access it.
Some sort of chaining of ResourceResolvers should be done, so that apps with an
existing ResourceResolver will work. My preference would be for Facelets core
to alter its use of the facelets.RESOURCE_RESOLVER parameter, to treat it as
an ordered list of ResourceResolvers, much like how the facelets.LIBRARIES and
facelets.DECORATORS parameters work.
In the immediate term, to simplify my proof of concept code, I will add a second
parameter called seam.RESOURCE_RESOLVER which
org.jboss.seam.debug.jsf.SeamDebugResourceResolver will delegate to.
So, to recap, here are some configuration examples:
Current way, with a custom ResourceResolver:
web.xml
<context-param>
<param-name>facelets.RESOURCE_RESOLVER</param-name>
<param-value>com.mycompany.CustomResourceResolver</param-value>
</context-param>
Short-term solution, with Seam debug ResourceResolver, and no other custom
ResourceResolver:
web.xml
<context-param>
<param-name>facelets.RESOURCE_RESOLVER</param-name>
<param-value>org.jboss.seam.debug.jsf.SeamDebugResourceResolver</param-value>
</context-param>
Short-term solution, with Seam debug ResourceResolver, and a custom
ResourceResolver:
web.xml
<context-param>
<param-name>facelets.RESOURCE_RESOLVER</param-name>
<param-value>org.jboss.seam.debug.jsf.SeamDebugResourceResolver</param-value>
</context-param>
<context-param>
<param-name>seam.RESOURCE_RESOLVER</param-name>
<param-value>com.mycompany.CustomResourceResolver</param-value>
</context-param>
Long-term solution, with Seam debug ResourceResolver, and a custom
ResourceResolver, chained:
web.xml
<context-param>
<param-name>facelets.RESOURCE_RESOLVER</param-name>
<param-value>org.jboss.seam.debug.jsf.SeamDebugResourceResolver;com.mycompany.CustomResourceResolver</param-value>
</context-param>
I have yet to try this with the 1.5.x branch, but with the HEAD code and newest
Seam release, we get a totally different situation. Basically, the debug.seam
or debug.jsf page will show, but the output is garbled.
Comparing the dvdstore app (with ICEfaces) with the hibernate app (without
ICEfaces) shows that the stock JSF components, like h:outputText and
h:dataTable, are not being rendered. I found that
org.jboss.seam.debug.jsf.SeamDebugPhaseListener is responsible for serving out
the applications\jboss-seam-1.1.0.BETA2\src\debug\META-INF\debug.xhtml file
using Facelets directly, instead of using the ViewHandler mechanism. This
PhaseListener is auto-wired by
applications\jboss-seam-1.1.0.BETA2\src\debug\META-INF\faces-config.xml
I think that the easiest approach will be to make a Seam
com.sun.facelets.impl.ResourceResolver that knows how to get at this
debug.xhtml file, and just use the existing facelets.RESOURCE_RESOLVER
parameter to access it.
Some sort of chaining of ResourceResolvers should be done, so that apps with an
existing ResourceResolver will work. My preference would be for Facelets core
to alter its use of the facelets.RESOURCE_RESOLVER parameter, to treat it as
an ordered list of ResourceResolvers, much like how the facelets.LIBRARIES and
facelets.DECORATORS parameters work.
In the immediate term, to simplify my proof of concept code, I will add a second
parameter called seam.RESOURCE_RESOLVER which
org.jboss.seam.debug.jsf.SeamDebugResourceResolver will delegate to.
So, to recap, here are some configuration examples:
Current way, with a custom ResourceResolver:
web.xml
<context-param>
<param-name>facelets.RESOURCE_RESOLVER</param-name>
<param-value>com.mycompany.CustomResourceResolver</param-value>
</context-param>
Short-term solution, with Seam debug ResourceResolver, and no other custom
ResourceResolver:
web.xml
<context-param>
<param-name>facelets.RESOURCE_RESOLVER</param-name>
<param-value>org.jboss.seam.debug.jsf.SeamDebugResourceResolver</param-value>
</context-param>
Short-term solution, with Seam debug ResourceResolver, and a custom
ResourceResolver:
web.xml
<context-param>
<param-name>facelets.RESOURCE_RESOLVER</param-name>
<param-value>org.jboss.seam.debug.jsf.SeamDebugResourceResolver</param-value>
</context-param>
<context-param>
<param-name>seam.RESOURCE_RESOLVER</param-name>
<param-value>com.mycompany.CustomResourceResolver</param-value>
</context-param>
Long-term solution, with Seam debug ResourceResolver, and a custom
ResourceResolver, chained:
web.xml
<context-param>
<param-name>facelets.RESOURCE_RESOLVER</param-name>
<param-value>org.jboss.seam.debug.jsf.SeamDebugResourceResolver;com.mycompany.CustomResourceResolver</param-value>
</context-param>