You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Aaron Evans <aa...@yahoo.ca> on 2005/09/08 15:52:14 UTC

[J2] Issues/Findings with JSF Portlets

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: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org


Re: [J2] Issues/Findings with JSF Portlets

Posted by David Sean Taylor <da...@bluesunrise.com>.
Aaron Evans wrote:
> David Sean Taylor <david <at> bluesunrise.com> writes:
> 
> 
>>Yes, of course I know about those.
>>But now I have forgotten what exactly your problem was.
>>Thought you were having problems with JSF portlets from a 3rd party...
>>
> 
> 
> I think there are basically two problems with JSF apps in the portal:
> 
> 1. This one is limited to the JSF bridge.  Basically, an application which
> uses the JSF bridge cannot be used outside of jetspeed (ie have its URIs
> invoked directly).  You get this error:
> 
> 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)
> 
> 2. The second problem seems to be with JSF apps used in the portal in general.
> At least it manifests itself with both the myfaces portlet implementation and
> the jsf-app that uses the bridge.  Basically, I have a managed bean in the
> request scope and a html form that references it and posts to an action.  I 
> have a navigation rule sending the user back to the html form.  Since I am 
> not using the redirect option in my navigation rule, the form values should
> show up in the html (since a forward was done).  This is not happening, the
> form/bean data is lost.  If I use the app outside of jetspeed, then the data
> is *not* lost.
> 

I haven't been working much with JSF lately
Did you log a JIRA issue ?

One other issue I seem to remember is that you can only have one 
instance of a JSF portlet on a page. If you have 2 instances, their 
managed beans are shared



-- 
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org


Re: [J2] Issues/Findings with JSF Portlets

Posted by Aaron Evans <aa...@yahoo.ca>.
David Sean Taylor <david <at> bluesunrise.com> writes:

> Yes, of course I know about those.
> But now I have forgotten what exactly your problem was.
> Thought you were having problems with JSF portlets from a 3rd party...
> 

I think there are basically two problems with JSF apps in the portal:

1. This one is limited to the JSF bridge.  Basically, an application which
uses the JSF bridge cannot be used outside of jetspeed (ie have its URIs
invoked directly).  You get this error:

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)

2. The second problem seems to be with JSF apps used in the portal in general.
At least it manifests itself with both the myfaces portlet implementation and
the jsf-app that uses the bridge.  Basically, I have a managed bean in the
request scope and a html form that references it and posts to an action.  I 
have a navigation rule sending the user back to the html form.  Since I am 
not using the redirect option in my navigation rule, the form values should
show up in the html (since a forward was done).  This is not happening, the
form/bean data is lost.  If I use the app outside of jetspeed, then the data
is *not* lost.





---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org


Re: [J2] Issues/Findings with JSF Portlets

Posted by David Sean Taylor <da...@bluesunrise.com>.
Aaron Evans wrote:
> David Sean Taylor <david <at> bluesunrise.com> writes:
> 
> 
>>Where can I get this sample JSF portlet app from?
>>Is it available for download
>>
> 
> 
> They come with the jetspeed distribution.  In SVN, the source for them is under
> applications.
> 
Yes, of course I know about those.
But now I have forgotten what exactly your problem was.
Thought you were having problems with JSF portlets from a 3rd party...

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org


Re: [J2] Issues/Findings with JSF Portlets

Posted by Aaron Evans <aa...@yahoo.ca>.
David Sean Taylor <david <at> bluesunrise.com> writes:

> 
> Where can I get this sample JSF portlet app from?
> Is it available for download
> 

They come with the jetspeed distribution.  In SVN, the source for them is under
applications.




---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org


Re: [J2] Issues/Findings with JSF Portlets

Posted by David Sean Taylor <da...@bluesunrise.com>.
Where can I get this sample JSF portlet app from?
Is it available for download

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org


Re: [J2] Issues/Findings with JSF Portlets

Posted by David Le Strat <dl...@yahoo.com>.
Aaron, 

Regarding your questions:

* jsf-demo usse the portals-bridge-jsf as you
mentioned.  It is aimed at demonstrating a bridge
which purpose is to be implementation agnostic (the
Portals bridge project JSF bridge). Sun RI or MyFaces.
 The issue you are running into here is clearly a bug.

* jsf-demo-myfaces is aimed at demonstrating the
myfaces portlet bridge that ships with myfaces.  This
explains the differences between the libraries.  I am
not sure why you would lose request scoped data.  This
may be a bug.  FYI, there has been quite a few fixes
to the myfaces portlet bridge on the myfaces project. 
You may want to check the issue tracking out to see if
this was reported/fixed.

Regards,

David Le Strat.

--- Aaron Evans <aa...@yahoo.ca> wrote:

> 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:
> jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail:
> jetspeed-user-help@portals.apache.org
> 
> 


________________________
David Le Strat
Blogging @ http://dlsthoughts.blogspot.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org