I have been working on adding a custom JSF application to the portal. I have looked carefully now at both jsf-demo and jsf-demo-myfaces and here is what I have found:
You cannot hit greeting.jsp for either of them from outside the portal. If you try to hit either of: http://locahost:8080/jsf-demo/greeting.jsp http://localhost:8080/jsf-demo-myfaces/greeting.jsp You get the following exception: java.lang.NullPointerException javax.faces.webapp.UIComponentTag.setupResponseWriter(UIComponentTag.java:634) javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:244) org.apache.myfaces.taglib.core.ViewTag.doStartTag(ViewTag.java:90) My question here is why? (Although this may be due to my lack of knowledge around JSF). However, when you configure portlet.xml, I believe you MUST use the .jsp extension (have to check on this though). If you try to hit greeting.jsf outside of the portal for either app *initially* you will get root cause java.lang.NoClassDefFoundError: org/apache/commons/fileupload/FileUpload org.apache.myfaces.component.html.util.ExtensionsFilter. doFilter(ExtensionsFilter.java:107) This is because the apps are missing commons-fileupload.jar but jetspeed provides this (which raises some interesting class loader questions and appropriate places to keep some of the jars). If you then put commons-fileupload.jar in $CATALINA_HOME/common/lib and restarttomcat then: You CAN hit jsf-demo-myfaces outside of the portal by using the .jsf extension instead. But you CANNOT hit jsf-demo outside of the portal at all (even using the .jsf extension). You will get the following exception: javax.faces.FacesException: Unsupported context type org.apache.catalina.core.ApplicationContextFacade org.apache.portals.bridges.jsf.FacesContextFactoryImpl .getFacesContext(FacesContextFactoryImpl.java:58) javax.faces.webapp.FacesServlet.service(FacesServlet.java:102) org.apache.myfaces.component.html.util.ExtensionsFilter .doFilter(ExtensionsFilter.java:119) Here are the main differences between these apps in terms of their WEB-INF/lib and portlet configuration: jsf-demo portlet-class is: org.apache.portals.bridges.jsf.FacesPortlet *contains*the jar portals-bridges-jsf-0.4-SNAPSHOT.jar in WEB-INF/lib jsf-demo-myfaces portlet-class is: org.apache.myfaces.portlet.MyFacesGenericPortlet *does not contain* portals-bridges-jsf-0.4-SNAPSHOT.jar in WEB-INF/lib It seems as though the latter uses a myfaces portlet interface and does NOT use the bridge. It allows me to use the application from outside the portal. For this reason, I have been using this implementation thus far for my custom JSF application because I can then debug it outside of jetspeed. However, now I am running into other issues where I believe I am losing request scoped data in some instances when I use my application through jetspeed, but it is fine when I use the application directly. I am now going to try the bridge implementation and see if I can get that working through the portal and see if that solves my problem, but it is unfortunate that I cannot use it outside the portal. I will post a follow-up with any findings. I believe the fact that you cannot use the application outside of jetspeed may be a bug with the JSF bridge because when you remove that jar and the portlet config from a JSF app, then you can use it directly with no issues. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
