On 2/1/06, Jason Vincent <[EMAIL PROTECTED]> wrote: > > Again... thanks for the quick replies... > > I found a fix to my problem. > > Apparently "header" is a reserved word and cannot be used as the name > of the managed bean. > Originally this was my bean definition: > <managed-bean> > <managed-bean-name>header</managed-bean-name> > <managed-bean-class>com.prenet.cpt.presentation.Header > </managed-bean-class> > <managed-bean-scope>request</managed-bean-scope> > </managed-bean> > > When I renamed it to header123... > <managed-bean> > <managed-bean-name>header123</managed-bean-name> > <managed-bean-class>com.prenet.cpt.presentation.Header > </managed-bean-class> > <managed-bean-scope>request</managed-bean-scope> > </managed-bean> > > Things all started working. Sheesh!
Yah, that one is definitely non-obvious :-). For the record, there is a whole set of reserved managed bean names, which correspond to the magic beans JSF knows about. In turn, these correspond to the magic names in JSTL and JSP 2.0 expressions as well. The entire list (from JSF spec, section 5.3.1.2): * applicationMap - Map of application scope attributes (read/write) * cookie - Map of included cookies * facesContext - The FacesContext instance for the current request * header - Map of HTTP headers (includes only first for each header name if there is more than one) * headerValues - Map of HTTP header name to String array containing all the included values * initParam - Map of context initialization parameters * param - Map of request parameters (includes only the first for each parameter name if there is more than one) * paramValues - Map of request parameter name to String array containing all of the values * requestScope - Map of request scope attributes (read/write) * sessionScope - Map of session scope attributes (read/write) * view - The UIViewRoot of the current view I wish JSF would have complained more loudly about the misconfiguration. +1 for the general sentiment. Thanks, > Jason Craig On 2/1/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > >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 > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
