>From: Jason Vincent <[EMAIL PROTECTED]> > > Thanks for the response. > > The header.jsp does indeed have the page directive at the top. > > > the include.jsp has the taglib includes in it. > > There are other items in the header.jsp that are using the JSF-EL to > access attributes in the session that are rendering fine, so I know > the JSP is getting rendered as a jsp. hmmmm. > > for your other suggestion, using the include directive would "may" not > work for me as the header file is included by other jsps that are in > different levels of directories. I had chossen to do the jsp:include > over the directive, because of previous relative urls in the header, > that are now gone. I'll give it a shot - but I'd prefer to figure out > why the jsp:include isn't working as expected. >
Oh, I didn't know what level you were on. I was hoping it was something simple. > I think my issue is that the backing bean isn't getting instantiated > on the request for the subview. Is there some rule about how subviews > can't talk to different backing beans? Perhaps Shale is doing > something to the request? > There is no restriction on the number of backing beans for a view/subview. I don't think that Shale has anything to do with this issue and I suspect that if you removed Shale you would still have the same issue. You should be seeing an exception if JSF can't find the managed bean. That's why I asked about the quality of the JSP you are dynamically including. Is here a parent JSP tag that is not visible, rendered="false"? If a parent tag is not visible, the children will not be renderered and your callback won't be invoked. Gary > Any further ideas? > Jason >
