I saw this post. This was how I was navigating and how I ended up in the ditch. When I do exactly as he says, I get the crazy loop I reported. It is resolving the bean properly, which is a JSF managed bean. I am sure of that.
The reason I'm sure of it is when you suggested Tiles I figured I would plug that in since I was planning on using it anyway. Well, Tiles was not the answer for this. I got it setup, and I was going to follow the example from the Core book that shows the ability to dynamically select a book from a menu and the tile will update itself. Lo and behold, look what the core of that example has in it:
<x-tad-bigger> <%@ </x-tad-bigger><x-tad-bigger>taglib </x-tad-bigger><x-tad-bigger>"http://java.sun.com/jstl/core_rt" </x-tad-bigger><x-tad-bigger>"c" </x-tad-bigger><x-tad-bigger>%></x-tad-bigger><x-tad-bigger>
</x-tad-bigger><x-tad-bigger> <</x-tad-bigger><x-tad-bigger>c:import </x-tad-bigger><x-tad-bigger>/></x-tad-bigger><x-tad-bigger>
</x-tad-bigger>
(this is adapted to my problem but you can see David's version on page 347 of the Core book.) So once I got this all plugged in and working, now I get the following error:
<x-tad-bigger>java.lang.IllegalStateException: Cannot forward after response has been committed</x-tad-bigger><x-tad-bigger>
</x-tad-bigger><x-tad-bigger> at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:324)</x-tad-bigger><x-tad-bigger>
</x-tad-bigger><x-tad-bigger> at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:312)</x-tad-bigger><x-tad-bigger>
</x-tad-bigger><x-tad-bigger> at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:405)</x-tad-bigger><x-tad-bigger>
</x-tad-bigger><x-tad-bigger> at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:280)</x-tad-bigger><x-tad-bigger>
</x-tad-bigger><x-tad-bigger> at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300)</x-tad-bigger><x-tad-bigger>
</x-tad-bigger><x-tad-bigger> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:110)</x-tad-bigger>
Of course, the difference between my example and David's is that his is only including html. I am trying to dynamically include pages that have JSF components in them. Again, somehow people on the sun newsgroups seem to think they got that working. I am pretty convinced this is not going to work in MyFaces. I think as a final exercise in futility I am going to try and get it running against the RI. The people on that thread I quoted earlier today seemed to claim they got it to work.
On Mar 21, 2005, at 11:12 PM, Matthias Wessendorf wrote:
Sergey.Smirnov from Exadel says:
<snip>
#{} is a propritory notation working only with the jsf tags. jsp:include is not a jsf tag, so you cannot use it in such manner.
If your run-time environment supports Servlet 2.4 specification, you can use ${} notation to have an access to the same bean.
Try the following code:
<f:subview id="includeExample" rendered="#{SomeBean != null}">
<jsp:include page="${SomeBean.jsfFileName}" />
</f:subview>
Note, rendered="#{SomeBean != null}" is an important part here. It guarantees that the SomeBean is loaded before you use it in the jsp:include
</snip>
So, are you in Servlet2.4 environment? (e.g. Tomcat5.xx)
I haven't tried it, but it looks like, that the backing bean, that
contains your page names must be created *first* via a JSF tag.
in this <snip/> the rendered="#{SomeBean != null}"> checks if it is
be created *before* that "include".
What kind of bean is behind
${sessionScope.labApplicationWizard.currentPanel}?
Is it a *normal* (<jsp:useBean/>) or a backing / managed bean?
-Matthias
Rob Williams wrote:
Matthias:
I went back and looked this over again. Turns out that the people on this thread:
http://forum.java.sun.com/thread.jspa?threadID=584037&tstart=360
got it to work using the RI and dynamically including jsf files. ??
Thanks.
On Mar 21, 2005, at 6:45 AM, Rob Williams wrote:
First off, guilty as charged: I am trying to dynamically include a file that contains JSF code.
I reviewed the Core book again today to look at the Tiles section. Looks like I am going to have
to make the WizardController in my scenario (which is deciding which panel to include in the
wizard layout, which stays the same) into a TilesController and then it should be ok.
My question is why on Earth do we have to do this? What is the point of having an EL if you
can't use it for something like this? Tiles looks like a good solution to other problems, but
for this I would prefer that dynamic content inclusion through a simple include tag and EL
would just work!
Thanks.
On Mar 20, 2005, at 11:41 PM, Matthias Wessendorf wrote:
Amit Modi wrote:
Try putting the <f:subview> tag inside the jsp you want to import.
No, that should not be the reason.
In tiles example we also have <f:subview/> only in *template* JSP file.
One hint could be, that inside of JSTL you can't access faces-config.xml
So why not using Tiles with Apache MyFaces?
-Matthias
-----Original Message-----
From: Rob Williams [mailto:[EMAIL PROTECTED] Sent: Monday, March 21, 2005 4:42 AM
To: MyFaces User List
Subject: EL w/<c:import/>
Here's the part of the page I am trying to get working:
<f:subview id="labApplicationPanelInfo">
<c:import url="${sessionScope.labApplicationWizard.currentPanel}"/>
</f:subview>
I did some reading about using EL and found the pieces that would allow me
to stipulate the URL dynamically. When I first got the pieces in place and
tried it with MyFaces, it blew up with an error saying it couldn't find the
servlet path for the URL (but w/jsp on the end). I did some searches and
there was some talk of a fix for it (I even found a diff of the source
checked in on 3/10 to fix this problem). So I synced with CVS and built
everything and tried it again. The results this time are much more
spectacular failure, including some of the craziest stack traces I've ever
seen (looks like an endless loop). Here's an excerpt:
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:110)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl ication
FilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterCh
ain.java:157)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp atcher.
java:704)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD ispatch
er.java:590)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis patcher
.java:510)
at
org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireStri ng(Impo
rtSupport.java:314)
at
org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag(Im portSup
port.java:179)
at
org.apache.jsp.pages.labApplication_jsp._jspx_meth_c_import_0(labAppl ication
_jsp.java:295)
at
org.apache.jsp.pages.labApplication_jsp._jspx_meth_f_subview_0(labApp licatio
n_jsp.java:271)
at
org.apache.jsp.pages.labApplication_jsp._jspx_meth_h_form_0(labApplic ation_j
sp.java:225)
at
org.apache.jsp.pages.labApplication_jsp._jspx_meth_f_view_0(labApplic ation_j
sp.java:141)
at
org.apache.jsp.pages.labApplication_jsp._jspService(labApplication_js p.java:
90)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper .java:3
24)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java: 292)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl ication
FilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterCh
ain.java:157)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp atcher.
java:704)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(Applica tionDis
patcher.java:474)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationD ispatch
er.java:409)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDis patcher
.java:312)
at
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatc h(Servl
etExternalContextImpl.java:405)
at
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspV iewHand
lerImpl.java:280)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java: 300)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:110)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl ication
FilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterCh
ain.java:157)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp atcher.
java:704)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD ispatch
er.java:590)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis patcher
.java:510)
at
org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireStri ng(Impo
rtSupport.java:314)
at
org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag(Im portSup
port.java:179)
at
org.apache.jsp.pages.labApplication_jsp._jspx_meth_c_import_0(labAppl ication
_jsp.java:295)
at
org.apache.jsp.pages.labApplication_jsp._jspx_meth_f_subview_0(labApp licatio
n_jsp.java:271)
at
org.apache.jsp.pages.labApplication_jsp._jspx_meth_h_form_0(labApplic ation_j
sp.java:225)
at
org.apache.jsp.pages.labApplication_jsp._jspx_meth_f_view_0(labApplic ation_j
sp.java:141)
at
org.apache.jsp.pages.labApplication_jsp._jspService(labApplication_js p.java:
90)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
I stuck my head into some of the code to see what was causing this but no
luck yet. Any thoughts appreciated.....
