Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.0
    • Fix Version/s: None
    • Component/s: Portlet_Support
    • Labels:
      None
    • Environment:
      LInux, J2SE 1.4.2

      Description

      MyFacesGenericPortlet does not fully support the feature of tomahawk component, such as inputHtml and fileUpload. So, I request the following feature to run it on portlet:

      • support tags in <head> (ex. inputHtml component)
      • support upload (fileUpload component)
      1. PortletEnableTomahawk.patch
        85 kB
        Martin Marinschek
      2. Tomahawk_FileUpload_IBMPortal.zip
        4 kB
        Ryan Wynn
      3. tomahawk-patch-portlet.zip
        16 kB
        Leonardo Uribe

        Issue Links

          Activity

          Hide
          Shinsuke Sugaya added a comment -

          Attached patch(newfile_for_portlet.tar.gz and patch_for_portlet.patch).
          But this patch is not a final fix. Because added MyFacesExtendedPortlet
          depends on MyFacesGenericPortlet and classes in tomahawk should not
          depend on impl. So, this dependency issue needs to be fixed.

          impl:

          • MyFacesGenericPortlet
            o move setContentType to do* method
          • DefaultViewSelector
            o add setPortletConfig method to get parameters from portlet.xml

          tomahawk:

          • AddResource
            o add some method for PortletRequest
          • MultipartRequest
            o interface for MultipartRequestWrapper

          I would like to add the following to somewhere..
          (At the moment, I added it to tomahawk in order to build and
          do testing. But tomahawk should not depend on impl. Therefore,
          it needs to be fixed.)

          • MyFacesExtendedPortlet (extends MyFaceGenericPortlet)
            o support tags in <head>
            o support upload
            o support portlet mode change
          Show
          Shinsuke Sugaya added a comment - Attached patch(newfile_for_portlet.tar.gz and patch_for_portlet.patch). But this patch is not a final fix. Because added MyFacesExtendedPortlet depends on MyFacesGenericPortlet and classes in tomahawk should not depend on impl. So, this dependency issue needs to be fixed. impl: MyFacesGenericPortlet o move setContentType to do* method DefaultViewSelector o add setPortletConfig method to get parameters from portlet.xml tomahawk: AddResource o add some method for PortletRequest MultipartRequest o interface for MultipartRequestWrapper I would like to add the following to somewhere.. (At the moment, I added it to tomahawk in order to build and do testing. But tomahawk should not depend on impl. Therefore, it needs to be fixed.) MyFacesExtendedPortlet (extends MyFaceGenericPortlet) o support tags in <head> o support upload o support portlet mode change
          Hide
          Stephan Strittmatter added a comment -

          Supporting the fileupload for Portlets is also important for me. Could thie patch of Shinsuke SUGAYA be integrated to MyFaces?

          Show
          Stephan Strittmatter added a comment - Supporting the fileupload for Portlets is also important for me. Could thie patch of Shinsuke SUGAYA be integrated to MyFaces?
          Hide
          Stan Silvert added a comment -

          Shinsuke's patch can not be integrated as-is because of dependecies it creates between impl and tomahawk. Shinsuke and I are trying to work out a solution that will keep each project independent.

          The requirement is that tomahawk classes can not have any dependencies on impl classes. Impl classes can not have dependencies on tomahawk classes.

          So, this is a fairly challenging problem because these things naturally depend on each other.

          Show
          Stan Silvert added a comment - Shinsuke's patch can not be integrated as-is because of dependecies it creates between impl and tomahawk. Shinsuke and I are trying to work out a solution that will keep each project independent. The requirement is that tomahawk classes can not have any dependencies on impl classes. Impl classes can not have dependencies on tomahawk classes. So, this is a fairly challenging problem because these things naturally depend on each other.
          Hide
          Dave Brondsema added a comment -

          Is it allowed to have full functionality if both project's classes are available, but limited functionality if they are not? Just an idea..

          Show
          Dave Brondsema added a comment - Is it allowed to have full functionality if both project's classes are available, but limited functionality if they are not? Just an idea..
          Hide
          Stan Silvert added a comment -

          Currently, no. But, we may have to relax the rules just a bit.

          I'm thinking that we might package "crossover" classes into a different jar. All crossover classes would live in the Tomahawk project but you would only use the extra jar if you want to use Tomahawk with MyFaces portlets. We might also make another jar for using Tomahawk with RI portlets.

          Show
          Stan Silvert added a comment - Currently, no. But, we may have to relax the rules just a bit. I'm thinking that we might package "crossover" classes into a different jar. All crossover classes would live in the Tomahawk project but you would only use the extra jar if you want to use Tomahawk with MyFaces portlets. We might also make another jar for using Tomahawk with RI portlets.
          Hide
          Shinsuke Sugaya added a comment -

          I agree with Stan.
          With the reflection API, I think we might be able to implement it. But MyFacesGenericPortlet will be complex..
          I prefer a simple way. So, to make another jar is +1.

          Show
          Shinsuke Sugaya added a comment - I agree with Stan. With the reflection API, I think we might be able to implement it. But MyFacesGenericPortlet will be complex.. I prefer a simple way. So, to make another jar is +1.
          Hide
          Martin Marinschek added a comment -

          Maybe I don't understand completely what the problem is here - but wouldn't be the "share" part of the sourcebase exactly the right location for such shared code?

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Maybe I don't understand completely what the problem is here - but wouldn't be the "share" part of the sourcebase exactly the right location for such shared code? regards, Martin
          Hide
          Shinsuke Sugaya added a comment -

          My suggested fix depends on both impl(MyFacesGenericPortlet) and tomahawk(AddResource..). So, if putting it to "share", I encountered the build error.

          Show
          Shinsuke Sugaya added a comment - My suggested fix depends on both impl(MyFacesGenericPortlet) and tomahawk(AddResource..). So, if putting it to "share", I encountered the build error.
          Hide
          Martin Marinschek added a comment -

          Ah, so your's is the other way round - your code depends on impl and tomahawk.... and not impl and tomahawk depend on your classes, right?

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Ah, so your's is the other way round - your code depends on impl and tomahawk.... and not impl and tomahawk depend on your classes, right? regards, Martin
          Hide
          Shinsuke Sugaya added a comment -

          Yes. impl and tomahawk do not depend on my fix(though some classes, such as AddResouce, need to be modified).

          Show
          Shinsuke Sugaya added a comment - Yes. impl and tomahawk do not depend on my fix(though some classes, such as AddResouce, need to be modified).
          Hide
          Shinsuke Sugaya added a comment -

          Attached filterportlet.patch and filterportlet.tar.gz(added files).
          In order to fix the dependency issue and deal with future problems(when adding new components), I developed MyFacesFilterPortlet(it's very flexible!). The MyFacesFilterPortlet is like Servlet Filter. So, you can add needed processes before and after accessing MyFacesGenericPortlet.

          For example, if you want to use Tomahawk components on a portlet, create the following portlet.xml:

          <portlet-app id="example-portlets" version="1.0">
          <portlet id="ExampleNavigator">
          <init-param>
          <name>default-view</name>
          <value>/jsp/index.jsp</value>
          </init-param>
          <init-param>
          <name>default-view-selector</name>
          <value>jp.sf.jetplume.portlets.PortletViewSelector</value>
          </init-param>
          <init-param>
          <name>portlet-class</name>
          <value>org.apache.myfaces.portlet.MyFacesGenericPortlet</value>
          </init-param>
          <init-param>
          <name>portlet-filters</name>
          <value>org.apache.myfaces.portlet.TomahawkPortletFilter</value>
          </init-param>
          <init-param>
          <name>org.apache.myfaces.portlet.TomahawkPortletFilter:upload-threshold-size</name>
          <value>1m</value>
          </init-param>
          <description>Example Navigator</description>
          <portlet-name>ExampleNavigator</portlet-name>
          <display-name>Example Navigator</display-name>
          <portlet-class>org.apache.myfaces.portlet.MyFacesFilterPortlet</portlet-class>
          <supports>
          <mime-type>text/html</mime-type>
          <portlet-mode>VIEW</portlet-mode>
          <portlet-mode>EDIT</portlet-mode>
          <portlet-mode>HELP</portlet-mode>
          </supports>
          <portlet-info>
          <title>Example Navigator</title>
          <short-title>Example</short-title>
          </portlet-info>
          </portlet>
          </portlet-app>

          TomahawkPortletFilter provides features to support tags in <head> and fileupload for Tomahawk component.

          Stan, could you review this filter portlet?

          Show
          Shinsuke Sugaya added a comment - Attached filterportlet.patch and filterportlet.tar.gz(added files). In order to fix the dependency issue and deal with future problems(when adding new components), I developed MyFacesFilterPortlet(it's very flexible!). The MyFacesFilterPortlet is like Servlet Filter. So, you can add needed processes before and after accessing MyFacesGenericPortlet. For example, if you want to use Tomahawk components on a portlet, create the following portlet.xml: <portlet-app id="example-portlets" version="1.0"> <portlet id="ExampleNavigator"> <init-param> <name>default-view</name> <value>/jsp/index.jsp</value> </init-param> <init-param> <name>default-view-selector</name> <value>jp.sf.jetplume.portlets.PortletViewSelector</value> </init-param> <init-param> <name>portlet-class</name> <value>org.apache.myfaces.portlet.MyFacesGenericPortlet</value> </init-param> <init-param> <name>portlet-filters</name> <value>org.apache.myfaces.portlet.TomahawkPortletFilter</value> </init-param> <init-param> <name>org.apache.myfaces.portlet.TomahawkPortletFilter:upload-threshold-size</name> <value>1m</value> </init-param> <description>Example Navigator</description> <portlet-name>ExampleNavigator</portlet-name> <display-name>Example Navigator</display-name> <portlet-class>org.apache.myfaces.portlet.MyFacesFilterPortlet</portlet-class> <supports> <mime-type>text/html</mime-type> <portlet-mode>VIEW</portlet-mode> <portlet-mode>EDIT</portlet-mode> <portlet-mode>HELP</portlet-mode> </supports> <portlet-info> <title>Example Navigator</title> <short-title>Example</short-title> </portlet-info> </portlet> </portlet-app> TomahawkPortletFilter provides features to support tags in <head> and fileupload for Tomahawk component. Stan, could you review this filter portlet?
          Hide
          Stan Silvert added a comment -

          I take a look as soon as I can. I like it so far!!!

          Thanks Shinsuke.

          Show
          Stan Silvert added a comment - I take a look as soon as I can. I like it so far!!! Thanks Shinsuke.
          Hide
          Werner Gresshoff added a comment -

          Hi,

          I tried that with Liferay and got the following error:
          05:52:19,859 ERROR [MyFacesGenericPortlet] headerResource is null. This portlet cannot probably put some tags into <head> element.

          Otherwise the Portlet filter seems to work fine. Great! I missed that!

          Show
          Werner Gresshoff added a comment - Hi, I tried that with Liferay and got the following error: 05:52:19,859 ERROR [MyFacesGenericPortlet] headerResource is null. This portlet cannot probably put some tags into <head> element. Otherwise the Portlet filter seems to work fine. Great! I missed that!
          Hide
          Shinsuke Sugaya added a comment -

          Hi Werner,

          If you want to use it on Liferay, you have to implement HeaderResource for Liferay to support tags in <head>. Please see filterportlet/tomahawk/src/java/org/apache/myfaces/portlet/headerresource/ in filterportlet.tar.gz.

          I have only Jetspeed2's HeaderResource implementation right now. I do not think they should be included in MyFaces svn. Because it depends on Portal. So, I did not include it in the patch. For Jetspeed2, I'll integrate it to J2 svn after this bug is fixed.

          Show
          Shinsuke Sugaya added a comment - Hi Werner, If you want to use it on Liferay, you have to implement HeaderResource for Liferay to support tags in <head>. Please see filterportlet/tomahawk/src/java/org/apache/myfaces/portlet/headerresource/ in filterportlet.tar.gz. I have only Jetspeed2's HeaderResource implementation right now. I do not think they should be included in MyFaces svn. Because it depends on Portal. So, I did not include it in the patch. For Jetspeed2, I'll integrate it to J2 svn after this bug is fixed.
          Hide
          Stephan Strittmatter added a comment -

          Werner, has you already written HeaderResource for Liferay? Probably you could share it here?
          Shinsuke, probably you could also add a reference to the Jetspeet2 Implementation here?

          Show
          Stephan Strittmatter added a comment - Werner, has you already written HeaderResource for Liferay? Probably you could share it here? Shinsuke, probably you could also add a reference to the Jetspeet2 Implementation here?
          Hide
          Shinsuke Sugaya added a comment -

          Attached files for Jetspeed2.
          You also need to add myfaces dependency to components/header-resource/project.xml.

          Show
          Shinsuke Sugaya added a comment - Attached files for Jetspeed2. You also need to add myfaces dependency to components/header-resource/project.xml.
          Hide
          Shankar Dj added a comment -

          Hi,

          I am facing the same problem with Weblogic. I am wondering if this patch is applicable to myfaces 1.1.1 nightly build ? Also if there is timeline for this enhancement to be available in the production release.

          Thanks, DJ

          Show
          Shankar Dj added a comment - Hi, I am facing the same problem with Weblogic. I am wondering if this patch is applicable to myfaces 1.1.1 nightly build ? Also if there is timeline for this enhancement to be available in the production release. Thanks, DJ
          Hide
          Henrik Bentel added a comment -

          Hi

          Will the filterportlet.patch be applied for the next release? Or at least partially?
          It contains several fixes which removes dependencies on HttpServletRequest which is great for JSF Portlets.

          Don't know if the reflection based solution introduces a lot of overhead, but I'd rather have JSF portlets work at all.

          thanks,
          Henrik

          Show
          Henrik Bentel added a comment - Hi Will the filterportlet.patch be applied for the next release? Or at least partially? It contains several fixes which removes dependencies on HttpServletRequest which is great for JSF Portlets. Don't know if the reflection based solution introduces a lot of overhead, but I'd rather have JSF portlets work at all. thanks, Henrik
          Hide
          Shinsuke Sugaya added a comment -

          We waited the final release for Apache Portals Bridges' Polrtlet FIlter and Jakarta Commons FileUpload.
          They have been released now. So, I'll start to work on this issue again.

          Show
          Shinsuke Sugaya added a comment - We waited the final release for Apache Portals Bridges' Polrtlet FIlter and Jakarta Commons FileUpload. They have been released now. So, I'll start to work on this issue again.
          Hide
          Shinsuke Sugaya added a comment -

          Stan,

          Attached the updated fix(filter051230.*). Could you review it?
          (added/updated commons-fileupload 1.1, commons-io 1.1, portals-bridges-portletfilter-1.0.jar)

          I put all source code to:

          MyFaces source code(including the fix):
          http://people.apache.org/~shinsuke/patch/myfaces/myfaces051230.tar.gz

          Jetspeed2 HeaderResource file:
          http://people.apache.org/~shinsuke/patch/myfaces/j2.tar.gz

          Portlets I used for test:
          http://people.apache.org/~shinsuke/patch/myfaces/cms-portlets.war
          http://people.apache.org/~shinsuke/patch/myfaces/vfs-portlets.war

          For the portlet filter, please see:
          http://portals.apache.org/bridges/multiproject/portals-bridges-portletfilter/index.html

          Show
          Shinsuke Sugaya added a comment - Stan, Attached the updated fix(filter051230.*). Could you review it? (added/updated commons-fileupload 1.1, commons-io 1.1, portals-bridges-portletfilter-1.0.jar) I put all source code to: MyFaces source code(including the fix): http://people.apache.org/~shinsuke/patch/myfaces/myfaces051230.tar.gz Jetspeed2 HeaderResource file: http://people.apache.org/~shinsuke/patch/myfaces/j2.tar.gz Portlets I used for test: http://people.apache.org/~shinsuke/patch/myfaces/cms-portlets.war http://people.apache.org/~shinsuke/patch/myfaces/vfs-portlets.war For the portlet filter, please see: http://portals.apache.org/bridges/multiproject/portals-bridges-portletfilter/index.html
          Hide
          Henrik Bentel added a comment -

          Has anyone created a HeaderResource file for Liferay 3.6.x?

          I've been looking at creating an implementation but I having problems finding a way to do it in Liferay.
          They depend largly on statically included JSP files ( their *-ext.jsp paradigm) for any cusomization of css or javascript includes.

          -Henrik

          Show
          Henrik Bentel added a comment - Has anyone created a HeaderResource file for Liferay 3.6.x? I've been looking at creating an implementation but I having problems finding a way to do it in Liferay. They depend largly on statically included JSP files ( their *-ext.jsp paradigm) for any cusomization of css or javascript includes. -Henrik
          Hide
          Shinsuke Sugaya added a comment -

          For HeaderResource mechanism, please see HeaderResource interface(it's simple). init() is to initialize the instance, and addHeaderResources() is that portal server puts JavaScript and StyleSheet tags into <head>. To put tags into <head> is not defined in JSR 168. So, some portal servers might not have the mechanism to put tags to <head>. If so, you need to use
          Extensions Filter or the like.

          Basically this solution does not depend on Jetspeed. Since Jetspeed just have components in PortletContext, I added getter/setter method for PortletContext. If you need other parameters to implement it, please let me know. I'll add it to HeaderResource interface.

          Show
          Shinsuke Sugaya added a comment - For HeaderResource mechanism, please see HeaderResource interface(it's simple). init() is to initialize the instance, and addHeaderResources() is that portal server puts JavaScript and StyleSheet tags into <head>. To put tags into <head> is not defined in JSR 168. So, some portal servers might not have the mechanism to put tags to <head>. If so, you need to use Extensions Filter or the like. Basically this solution does not depend on Jetspeed. Since Jetspeed just have components in PortletContext, I added getter/setter method for PortletContext. If you need other parameters to implement it, please let me know. I'll add it to HeaderResource interface.
          Hide
          Andreas Wiesauer added a comment -

          Hello Shinsuke,

          I need FileUpload for my MyFaces Portlet Application on Jetspeed 2.0 FINAL and I tried your enhancement. It works wonderful, the only problem is that Tomcat says "cannot create headerresourcefactory for jetspeed". I added the <js:service name='HeaderResource'/> to jetspeed-portlet.xml, but it seems that the factory is not in portlet context.

          Maybe this happens because I bound the org/apache/jetspeed/headerresource/myfaces/HeaderResourceImpl.java directly to my WebApp (because we can't change the jetspeed 2.0 build at the moment).

          So, do you have any idea how to solve the problem?

          best regards,
          Andy

          Show
          Andreas Wiesauer added a comment - Hello Shinsuke, I need FileUpload for my MyFaces Portlet Application on Jetspeed 2.0 FINAL and I tried your enhancement. It works wonderful, the only problem is that Tomcat says "cannot create headerresourcefactory for jetspeed". I added the <js:service name='HeaderResource'/> to jetspeed-portlet.xml, but it seems that the factory is not in portlet context. Maybe this happens because I bound the org/apache/jetspeed/headerresource/myfaces/HeaderResourceImpl.java directly to my WebApp (because we can't change the jetspeed 2.0 build at the moment). So, do you have any idea how to solve the problem? best regards, Andy
          Hide
          Shinsuke Sugaya added a comment -

          Yes. If you want to use it on J2, headerresource_for_j2.tar.gz is needed.

          I'm providing myfaces-bridges as an other solution from SourceForge.jp, and also you can check the implementaion on some portlets, such as blog, notepad..

          https://sourceforge.jp/projects/pal/

          Show
          Shinsuke Sugaya added a comment - Yes. If you want to use it on J2, headerresource_for_j2.tar.gz is needed. I'm providing myfaces-bridges as an other solution from SourceForge.jp, and also you can check the implementaion on some portlets, such as blog, notepad.. https://sourceforge.jp/projects/pal/
          Hide
          Dave Brondsema added a comment -

          The MyFaces SVN codebase has made several changes since the latest patches (very big changes so that they cannot be applied). Here are my patches after manually applying the changes. It includes the files that are new. I've also added a few warnings and modified MultipartPortletRequestWrapper#getAttribute so that it behaves like MultipartRequestWrapper#getAttribute. The patches do not include support for AddResource (only filters and fileupload) since the AddResource class has had its own changes and I wasn't sure how to modify the patch correspondingly.

          Show
          Dave Brondsema added a comment - The MyFaces SVN codebase has made several changes since the latest patches (very big changes so that they cannot be applied). Here are my patches after manually applying the changes. It includes the files that are new. I've also added a few warnings and modified MultipartPortletRequestWrapper#getAttribute so that it behaves like MultipartRequestWrapper#getAttribute. The patches do not include support for AddResource (only filters and fileupload) since the AddResource class has had its own changes and I wasn't sure how to modify the patch correspondingly.
          Hide
          Dave Brondsema added a comment -

          As far as an evaluation of the code, I think it's fairly good. Unfortunately even though the tomahawk filter does not have a true dependency on myfaces-impl, in all practicality it does. impl's PortletFilterWrapper expects TomahawkPortletFilter to have specific methods. And TomahawkPortletFilter is only going to be able to work if you have MyFacesFilterPortlet from myfaces-impl. But I think that unfortunately is an unavoidable design issue because the portlet spec doesn't define filters, so we have to implement them. There's probably no way we could write a tomahawk file upload component (for portlets) that works in all JSF implementations because we need a portlet filter and there's no standard way to do that.

          Perhaps we could move the MyFacesFilterPortlet into tomahawk for the purposes of the tomahawk file upload component. But it really needs to be in the implementation if it is to be able to work with the AddResource class.

          Show
          Dave Brondsema added a comment - As far as an evaluation of the code, I think it's fairly good. Unfortunately even though the tomahawk filter does not have a true dependency on myfaces-impl, in all practicality it does. impl's PortletFilterWrapper expects TomahawkPortletFilter to have specific methods. And TomahawkPortletFilter is only going to be able to work if you have MyFacesFilterPortlet from myfaces-impl. But I think that unfortunately is an unavoidable design issue because the portlet spec doesn't define filters, so we have to implement them. There's probably no way we could write a tomahawk file upload component (for portlets) that works in all JSF implementations because we need a portlet filter and there's no standard way to do that. Perhaps we could move the MyFacesFilterPortlet into tomahawk for the purposes of the tomahawk file upload component. But it really needs to be in the implementation if it is to be able to work with the AddResource class.
          Hide
          Slava Khimenko added a comment -

          Hi!
          I want to use myFaces in portlets with Pluto 1.0.1 portal, but some of them does not work (inputCalendar and etc.).
          Has anyone created a HeaderResource file for Pluto 1.0.1?

          Show
          Slava Khimenko added a comment - Hi! I want to use myFaces in portlets with Pluto 1.0.1 portal, but some of them does not work (inputCalendar and etc.). Has anyone created a HeaderResource file for Pluto 1.0.1?
          Hide
          Michael Binette added a comment -

          Is their a timeframe of when these patches will make it into the nightly build or any release? It doesn't look like the easiest thing to apply these patches, especially since MyFaces and Tomahawk keep changing and the patches seem to keep changing with it.

          Or, can someone who understands this thread put a step by step process of how to get this to work using all of the most recent releases, MyFaces 1.1.3, Tomahawk 1.1.3 and Portals Bridges 1.0. I would really like to implement this without having to modify Jetspeed 2. Maybe a separate jar with these changes can be put in the WEB-INF/lib?

          I'm not really interested in File Upload but in some of the Tomahawk components like the calendar which depend on the ExtensionsFilter.

          Show
          Michael Binette added a comment - Is their a timeframe of when these patches will make it into the nightly build or any release? It doesn't look like the easiest thing to apply these patches, especially since MyFaces and Tomahawk keep changing and the patches seem to keep changing with it. Or, can someone who understands this thread put a step by step process of how to get this to work using all of the most recent releases, MyFaces 1.1.3, Tomahawk 1.1.3 and Portals Bridges 1.0. I would really like to implement this without having to modify Jetspeed 2. Maybe a separate jar with these changes can be put in the WEB-INF/lib? I'm not really interested in File Upload but in some of the Tomahawk components like the calendar which depend on the ExtensionsFilter.
          Hide
          Ryan Wynn added a comment -

          workaround to use tomahawk file upload in WebSphere Portal

          Show
          Ryan Wynn added a comment - workaround to use tomahawk file upload in WebSphere Portal
          Hide
          Shinsuke Sugaya added a comment -

          I created MyFaces Bridge 0.8 in http://sourceforge.jp/projects/pal/ . In this release, dependencies to a special feature for Portal were removed. I checked it on Jetspeed2, Liferay and JBoss Portal, and it works If you are interested in it, please try it. For more information, please see:
          http://palab.blogspot.com/2006/09/myfaces-bridge-08-released.html

          Show
          Shinsuke Sugaya added a comment - I created MyFaces Bridge 0.8 in http://sourceforge.jp/projects/pal/ . In this release, dependencies to a special feature for Portal were removed. I checked it on Jetspeed2, Liferay and JBoss Portal, and it works If you are interested in it, please try it. For more information, please see: http://palab.blogspot.com/2006/09/myfaces-bridge-08-released.html
          Hide
          Martin Marinschek added a comment -

          Hi Shinsuke,

          I'd really love to finally take the portlet issues on - are you still interested in getting this into MyFaces? Which of the attached issues are for the current state?

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Hi Shinsuke, I'd really love to finally take the portlet issues on - are you still interested in getting this into MyFaces? Which of the attached issues are for the current state? regards, Martin
          Hide
          Shinsuke Sugaya added a comment -

          Hi Martin,

          To fix this issue, my recommendation is to add MyFaces Bridge 0.8 as Tomahawk's component. If you have any questions, please let me know.

          Show
          Shinsuke Sugaya added a comment - Hi Martin, To fix this issue, my recommendation is to add MyFaces Bridge 0.8 as Tomahawk's component. If you have any questions, please let me know.
          Hide
          Martin Marinschek added a comment -

          Is that any of the files provided above?

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Is that any of the files provided above? regards, Martin
          Hide
          Shinsuke Sugaya added a comment -

          No. Attached patches I provided are old and they does not work on some portals. If you integrate MyFaces Bridge 0.8 into tomahawk, I'll create a patch(I'm busy this week.. so, I think I'll work next week).

          Show
          Shinsuke Sugaya added a comment - No. Attached patches I provided are old and they does not work on some portals. If you integrate MyFaces Bridge 0.8 into tomahawk, I'll create a patch(I'm busy this week.. so, I think I'll work next week).
          Hide
          Martin Marinschek added a comment -

          Next week would be perfectly alright.

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Next week would be perfectly alright. regards, Martin
          Hide
          Stephan Strittmatter added a comment -

          Having this integration for Tomahawk 1.1.4 would be very helpful for us! I will already say thank you for your work on this issue!
          Probably I can suport you on testing on Liferay portlets having fileupload features.

          Show
          Stephan Strittmatter added a comment - Having this integration for Tomahawk 1.1.4 would be very helpful for us! I will already say thank you for your work on this issue! Probably I can suport you on testing on Liferay portlets having fileupload features.
          Hide
          Shinsuke Sugaya added a comment -

          Attached fix for Tomahawk's trunk.

          Show
          Shinsuke Sugaya added a comment - Attached fix for Tomahawk's trunk.
          Hide
          Martin Marinschek added a comment -

          Hi Shinsuke,

          you're creating a new module here - is this reasonable, or should the full thing just be part of tomahawk?

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Hi Shinsuke, you're creating a new module here - is this reasonable, or should the full thing just be part of tomahawk? regards, Martin
          Hide
          Shinsuke Sugaya added a comment -

          Yes. The attachment is just for Tomahawk, not core and others. Actually, I'm using it on Teeda(JSF Implementation) and Tomahawk environment.

          Show
          Shinsuke Sugaya added a comment - Yes. The attachment is just for Tomahawk, not core and others. Actually, I'm using it on Teeda(JSF Implementation) and Tomahawk environment.
          Hide
          Martin Marinschek added a comment -

          Don't get your answer - you mean it should be integrated, or be a separate module?

          I see that in your patch, you're currently creating a new module - new jar-file. What's the reason for this?

          Interesting to hear about Teeda - never heard about this JSF implementation before. Good to know, I'll need to update my Presentations

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Don't get your answer - you mean it should be integrated, or be a separate module? I see that in your patch, you're currently creating a new module - new jar-file. What's the reason for this? Interesting to hear about Teeda - never heard about this JSF implementation before. Good to know, I'll need to update my Presentations regards, Martin
          Hide
          Shinsuke Sugaya added a comment -

          I'm thinking that it's better to integrate it as a new module(a separate jar file). Because this module replaces with RenderKitFactory to replace with ResponseWriter. So, I think that user which want to create a Web application cannot use it.
          If you need more info or the above is not an answer you want , please let me know.

          Show
          Shinsuke Sugaya added a comment - I'm thinking that it's better to integrate it as a new module(a separate jar file). Because this module replaces with RenderKitFactory to replace with ResponseWriter. So, I think that user which want to create a Web application cannot use it. If you need more info or the above is not an answer you want , please let me know.
          Hide
          Shinsuke Sugaya added a comment -

          Hi Martin,

          Do you have an update for this issue? If you have any problem about my solution, please let me know.

          Show
          Shinsuke Sugaya added a comment - Hi Martin, Do you have an update for this issue? If you have any problem about my solution, please let me know.
          Hide
          Jorge Rodríguez Pedrianes added a comment -

          Hi shinshuke

          I try to use your solution and i see a problem:

          When I use <t:inputCalendar .../> and I javascript popup, this fail, because when firefox try execute assosiated javascript don't found a required class:
          ....
          myInputCalendarVar=new org_apache_myfaces_PopupCalendar()
          ....

          The problem is that you add javascript at end, and to avoid this options in inputCalendar you must add javascript at begin of portlet.

          Thanks

          Show
          Jorge Rodríguez Pedrianes added a comment - Hi shinshuke I try to use your solution and i see a problem: When I use <t:inputCalendar .../> and I javascript popup, this fail, because when firefox try execute assosiated javascript don't found a required class: .... myInputCalendarVar=new org_apache_myfaces_PopupCalendar() .... The problem is that you add javascript at end, and to avoid this options in inputCalendar you must add javascript at begin of portlet. Thanks
          Hide
          Martin Marinschek added a comment -

          Hi Shinsuke,

          after rethinking the options, I think it's ok to create a new module. I need to review the rest of the patch though - haven't had any time to do this so far. Stay tuned, it won't take too long anymore.

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Hi Shinsuke, after rethinking the options, I think it's ok to create a new module. I need to review the rest of the patch though - haven't had any time to do this so far. Stay tuned, it won't take too long anymore. regards, Martin
          Hide
          Andreas Wiesauer added a comment -

          Hello Shinsuke,

          I tried your myfaces-bridge 0.8, but I have trouble with some components, for example inputCaledar. If it is rendered normally, it works, but if I switch to rendering as popup (JavaScript), I get an Exception and the message, that myfaces extension filters are not configured properly.

          Could you have any hints how portlet.xml and especially web.xml has to be configured so that this will work?

          Thanks for your help!

          Best regards,
          Andy

          Show
          Andreas Wiesauer added a comment - Hello Shinsuke, I tried your myfaces-bridge 0.8, but I have trouble with some components, for example inputCaledar. If it is rendered normally, it works, but if I switch to rendering as popup (JavaScript), I get an Exception and the message, that myfaces extension filters are not configured properly. Could you have any hints how portlet.xml and especially web.xml has to be configured so that this will work? Thanks for your help! Best regards, Andy
          Hide
          Shinsuke Sugaya added a comment -

          In the following project, I provide portlets which use myfaces-bridge 0.8. Please refer them.
          http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/pal/

          Show
          Shinsuke Sugaya added a comment - In the following project, I provide portlets which use myfaces-bridge 0.8. Please refer them. http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/pal/
          Hide
          Andreas Wiesauer added a comment -

          Thank you, Shinsuke. The error has gone now. But now I have the same problem as Jorge above, the popup is not rendered because javascript is added at the end of the portlet. Maybe you could fix this?

          Best regards,
          Andy

          Show
          Andreas Wiesauer added a comment - Thank you, Shinsuke. The error has gone now. But now I have the same problem as Jorge above, the popup is not rendered because javascript is added at the end of the portlet. Maybe you could fix this? Best regards, Andy
          Hide
          Shinsuke Sugaya added a comment -

          Tomahawk Bridge 0.9 is available. myfaces-bridge 0.8 was replaced with it.
          http://palab.blogspot.com/2006/12/tomahawk-bridge-09-released.html

          Show
          Shinsuke Sugaya added a comment - Tomahawk Bridge 0.9 is available. myfaces-bridge 0.8 was replaced with it. http://palab.blogspot.com/2006/12/tomahawk-bridge-09-released.html
          Hide
          Martin Marinschek added a comment -

          Hi Shinsuke, others,

          excuse my long silence - it was mostly due to the fact that I found it hard to fully understand what happened in your bridge, Shinsuke - the code is not very easy comprehensible, especially the javascript-rendering-part. I should have discussed more with you guys, but here I am with a different solution which replaces the DefaultAddResource-implementation of MyFaces with one that does not do buffering.

          Additionally, the extensions-filter is not necessary anymore in a servlet-world - instead, a FacesContextFactory-wrapper and a phase-listener take over. In the portlet-world, the extensions-filter should still be configured in the main web.xml of the portal, it will then serve out resources (use the filter-mapping from before).

          With this, a few things won't work in the portlet world, but most things will do.

          However, there is still two issues with my proposed solution:

          • I can only get it to work with JSF 1.1 or JSF 1.2, but not in both. This is as I need to wrap the FacesContext, and I cannot use the interface of the JSF 1.2 FacesContext in the Tomahawk-1.1 version. However, in a 1.2 environment, the method getELContext() will be called on the FacesContext; and this method is only available in the 1.2 interface. This really means there should have been a FacesContextWrapper fro the beginning in the javax.api.*-classes, then this wouldn't be a problem at all. Does anyone have a suggestion?
          • I haven't so far taken care of file-upload - should be easy, however. The question is where the init-parameters should come frome now that the filter can safely be removed. Should we maybe read the init-parameters from the filter still, so that the users can keep their configuration?

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Hi Shinsuke, others, excuse my long silence - it was mostly due to the fact that I found it hard to fully understand what happened in your bridge, Shinsuke - the code is not very easy comprehensible, especially the javascript-rendering-part. I should have discussed more with you guys, but here I am with a different solution which replaces the DefaultAddResource-implementation of MyFaces with one that does not do buffering. Additionally, the extensions-filter is not necessary anymore in a servlet-world - instead, a FacesContextFactory-wrapper and a phase-listener take over. In the portlet-world, the extensions-filter should still be configured in the main web.xml of the portal, it will then serve out resources (use the filter-mapping from before). With this, a few things won't work in the portlet world, but most things will do. However, there is still two issues with my proposed solution: I can only get it to work with JSF 1.1 or JSF 1.2, but not in both. This is as I need to wrap the FacesContext, and I cannot use the interface of the JSF 1.2 FacesContext in the Tomahawk-1.1 version. However, in a 1.2 environment, the method getELContext() will be called on the FacesContext; and this method is only available in the 1.2 interface. This really means there should have been a FacesContextWrapper fro the beginning in the javax.api.*-classes, then this wouldn't be a problem at all. Does anyone have a suggestion? I haven't so far taken care of file-upload - should be easy, however. The question is where the init-parameters should come frome now that the filter can safely be removed. Should we maybe read the init-parameters from the filter still, so that the users can keep their configuration? regards, Martin
          Hide
          Leonardo Uribe added a comment -

          This file solves problems like compatibility with portlet-bridge and others

          Now, the app runs well in and outside the portlet container

          Also include a patch for myfaces 1.1 for make MyfacesGenericPortlet compatible with this.

          Show
          Leonardo Uribe added a comment - This file solves problems like compatibility with portlet-bridge and others Now, the app runs well in and outside the portlet container Also include a patch for myfaces 1.1 for make MyfacesGenericPortlet compatible with this.
          Hide
          Leonardo Uribe added a comment -

          I have applied the patch plus some enhacements like avoid hard dependencies with javax.portlet api.

          Changes on myfaces-impl and on tomahawk.

          fixed at revision 656086

          Show
          Leonardo Uribe added a comment - I have applied the patch plus some enhacements like avoid hard dependencies with javax.portlet api. Changes on myfaces-impl and on tomahawk. fixed at revision 656086
          Hide
          Leonardo Uribe added a comment -

          One last tip. For use this, use NonBufferingAddResource.

          Show
          Leonardo Uribe added a comment - One last tip. For use this, use NonBufferingAddResource.
          Hide
          Simon Kitching added a comment -

          This patch doesn't work with Orchestra 1.1 release.

          The problem is that this introduces a custom TomahawkFacesContextFactory that is always installed automatically when tomahawk is in the classpath. And Orchestra does the same. But the orchestra FacesContextWrapper instances that the factory creates are package-scoped, so reflection calls by the new tomahawk wrapper fail.

          I'll change orchestra to make its FacesContextWrapper class public. But it does show the danger of custom FacesContextFactory classes.

          There are also a number of nasty issues related to wrapping of FacesContextFactory. See:
          MYFACES-1820

          Show
          Simon Kitching added a comment - This patch doesn't work with Orchestra 1.1 release. The problem is that this introduces a custom TomahawkFacesContextFactory that is always installed automatically when tomahawk is in the classpath. And Orchestra does the same. But the orchestra FacesContextWrapper instances that the factory creates are package-scoped, so reflection calls by the new tomahawk wrapper fail. I'll change orchestra to make its FacesContextWrapper class public. But it does show the danger of custom FacesContextFactory classes. There are also a number of nasty issues related to wrapping of FacesContextFactory. See: MYFACES-1820
          Hide
          Simon Kitching added a comment -

          The exception logging on this class is all wrong. Output goes straight to STDERR. It should use a logging method.

          And should it be swallowing these exceptions? Normally, if something fails here, then returning null will just cause a different error later, in the EL expression parser. I cannot see anything in the spec that says that this method is permitted to return null.

          Show
          Simon Kitching added a comment - The exception logging on this class is all wrong. Output goes straight to STDERR. It should use a logging method. And should it be swallowing these exceptions? Normally, if something fails here, then returning null will just cause a different error later, in the EL expression parser. I cannot see anything in the spec that says that this method is permitted to return null.
          Hide
          Scott O'Bryan added a comment -

          Simon, I disagree with your comments here. Orchestra CANNOT work off reflection on the FacesContext for non-standard API's. Trinidad also does the same thing. You really need to find another way to expose the functionality you need. That said, I had to do something similar in configurators, and I did this by adding wrappers to the getInitParameter. In any case, you NEED to find another way to expose this.

          Show
          Scott O'Bryan added a comment - Simon, I disagree with your comments here. Orchestra CANNOT work off reflection on the FacesContext for non-standard API's. Trinidad also does the same thing. You really need to find another way to expose the functionality you need. That said, I had to do something similar in configurators, and I did this by adding wrappers to the getInitParameter. In any case, you NEED to find another way to expose this.
          Hide
          Simon Kitching added a comment -

          Sorry, Scott, I don't understand your comment.

          Orchestra provides a FacesContextFactory that returns an anonymous class that subclasses a base class FacesContextWrapper. This is all standard decorator behaviour.

          But the orchestra FacesContextWrapper was declared package-scoped, as it isn't a class that we want other people using; it's just a base for the FacesContext instance that we return. Orchestra doesn't add any new methods to the FacesContext class.

          It is the new tomahawk code that is using reflection to try to handle methods added by JSF1.2 while still building with JSF1.1. This is necessary due to a major design flaw in JSF, where adding methods in new spec releases breaks old code. When running in a JSF1.2 environment, Tomahawk's code checks whether the JSF1.2 method getELContext is present on the FacesContext instance (which was the Orchestra one). It was found (a Method object was located), so Tomahawk invoked it. But that Method was attached to a package-scoped class and therefore not invokable.

          As far as I can see, Tomahawk's approach is ok (although it does scare me that tomahawk is wrapping each FacesContext instance, just by being in the classpath). I hadn't considered things wrapping orchestra's FacesContextWrapper and then using reflection to invoke standard api methods on it.

          Note that Tomahawk does not have separate JSF1.1 and JSF1.2 flavours; it implements just JSF1.1 except for the odd workaround in situations like this where the JSF spec is not backwards-compatible.

          Do you think there is something wrong with either Tomahawk or Orchestra here (except the logging issue I noted, and possible delegation problems as described in MYFACES-1820)?

          Show
          Simon Kitching added a comment - Sorry, Scott, I don't understand your comment. Orchestra provides a FacesContextFactory that returns an anonymous class that subclasses a base class FacesContextWrapper. This is all standard decorator behaviour. But the orchestra FacesContextWrapper was declared package-scoped, as it isn't a class that we want other people using; it's just a base for the FacesContext instance that we return. Orchestra doesn't add any new methods to the FacesContext class. It is the new tomahawk code that is using reflection to try to handle methods added by JSF1.2 while still building with JSF1.1. This is necessary due to a major design flaw in JSF, where adding methods in new spec releases breaks old code. When running in a JSF1.2 environment, Tomahawk's code checks whether the JSF1.2 method getELContext is present on the FacesContext instance (which was the Orchestra one). It was found (a Method object was located), so Tomahawk invoked it. But that Method was attached to a package-scoped class and therefore not invokable. As far as I can see, Tomahawk's approach is ok (although it does scare me that tomahawk is wrapping each FacesContext instance, just by being in the classpath). I hadn't considered things wrapping orchestra's FacesContextWrapper and then using reflection to invoke standard api methods on it. Note that Tomahawk does not have separate JSF1.1 and JSF1.2 flavours; it implements just JSF1.1 except for the odd workaround in situations like this where the JSF spec is not backwards-compatible. Do you think there is something wrong with either Tomahawk or Orchestra here (except the logging issue I noted, and possible delegation problems as described in MYFACES-1820 )?
          Hide
          Leonardo Uribe added a comment -

          So the scenario when this issue cause problems is tomahawk 1.1 + orchestra + myfaces 1.2.x, because tomahawk calls EL methods on its delegate wrapper by reflection. If this is the problem, one solution is have a core12 project and a specific wrapper without reflection, but right now I'm doing component generation with sandbox, so this solution could take some time.

          The logging issue should be easy to solve. Could you (Simon) commit a solution, if you have the time to do this? (if not I can do it but I'm not sure what this should looks like and where to do the changes)?.

          Show
          Leonardo Uribe added a comment - So the scenario when this issue cause problems is tomahawk 1.1 + orchestra + myfaces 1.2.x, because tomahawk calls EL methods on its delegate wrapper by reflection. If this is the problem, one solution is have a core12 project and a specific wrapper without reflection, but right now I'm doing component generation with sandbox, so this solution could take some time. The logging issue should be easy to solve. Could you (Simon) commit a solution, if you have the time to do this? (if not I can do it but I'm not sure what this should looks like and where to do the changes)?.
          Hide
          Scott O'Bryan added a comment -

          Ohhhhh.. Sorry Simon, I misunderstood. You're right. Whoever is relying on a specific implementation needs to stop it. Sorry, I just sort of glanced the emails and this caught my eye.

          Show
          Scott O'Bryan added a comment - Ohhhhh.. Sorry Simon, I misunderstood. You're right. Whoever is relying on a specific implementation needs to stop it. Sorry, I just sort of glanced the emails and this caught my eye.
          Hide
          Leonardo Uribe added a comment -

          The problem of have e.printStackTrace lines has been solved on revisions 657159

          Show
          Leonardo Uribe added a comment - The problem of have e.printStackTrace lines has been solved on revisions 657159
          Hide
          Simon Kitching added a comment -

          As noted in this thread, there are some significant other issues with this patch.
          http://markmail.org/message/bknubhi7xixi2ra6

          Most significantly, there are some "todo" comments in this code that appear very important, ie the new code appears to currently not support functionality that the old code had

          In addition.

          • documentation is badly lacking.
          • the code is fairly ugly; some refactoring would be good.

          This patch has a major impact upon a large number of tomahawk components. And because it automatically installs a wrapper around every FacesContext and ExternalContext object it can (and did) screw up application behaviour totally unrelated to Tomahawk. Patches like this need very careful review before committing - and preferably lots of logging so that when something goes wrong it is obvious.

          I will try to find time to review this code myself (including finding a better fix than the patch recently committed to solve the delegate.release bug. But it would be nice for such intrusive patches to get more review before being committed...

          Show
          Simon Kitching added a comment - As noted in this thread, there are some significant other issues with this patch. http://markmail.org/message/bknubhi7xixi2ra6 Most significantly, there are some "todo" comments in this code that appear very important, ie the new code appears to currently not support functionality that the old code had In addition. documentation is badly lacking. the code is fairly ugly; some refactoring would be good. This patch has a major impact upon a large number of tomahawk components. And because it automatically installs a wrapper around every FacesContext and ExternalContext object it can (and did) screw up application behaviour totally unrelated to Tomahawk. Patches like this need very careful review before committing - and preferably lots of logging so that when something goes wrong it is obvious. I will try to find time to review this code myself (including finding a better fix than the patch recently committed to solve the delegate.release bug. But it would be nice for such intrusive patches to get more review before being committed...
          Hide
          Leonardo Uribe added a comment -

          It's difficult to review all possible situations. But anyway, we need a solution.

          I have committed on revision 657458 and others the most simple solution to avoid the problems raised: disable it. Later, we can fix the problems and that's all.

          Show
          Leonardo Uribe added a comment - It's difficult to review all possible situations. But anyway, we need a solution. I have committed on revision 657458 and others the most simple solution to avoid the problems raised: disable it. Later, we can fix the problems and that's all.
          Hide
          Leonardo Uribe added a comment -

          I have added multipart content support and enabled again (also corrected some stuff in ExtensionsFilter)

          Now the last thing to do with this issue is add fileupload portlet support.

          Show
          Leonardo Uribe added a comment - I have added multipart content support and enabled again (also corrected some stuff in ExtensionsFilter) Now the last thing to do with this issue is add fileupload portlet support.
          Hide
          Leonardo Uribe added a comment -

          At last I have committed fileupload support for portlets. This issue will be finally closed, but first I'll do some reviews before.

          Show
          Leonardo Uribe added a comment - At last I have committed fileupload support for portlets. This issue will be finally closed, but first I'll do some reviews before.
          Hide
          Andreas Niemeyer added a comment -

          Hi,

          Is that issue solved and reviewed enough two month later?

          We are trying to use this component with facelets 1.1.14, myfaces 1.1.6, portlet-bridge 1.0.0-alpha-2 and tomahawk-1.1.7. without success.

          If we try with myfaces 1.1.6 there is a " java.lang.IllegalStateException: BufferedResponseStream is null" caught, with 1.1.4 an java.lang.NullPointerException arised.

          Maybe it works with some versions but nice to know what versions to be used.

          Thank you for all the good stuff and investigations, hopefully it is working in some way!

          Kind regards,
          Andreas

          Show
          Andreas Niemeyer added a comment - Hi, Is that issue solved and reviewed enough two month later? We are trying to use this component with facelets 1.1.14, myfaces 1.1.6, portlet-bridge 1.0.0-alpha-2 and tomahawk-1.1.7. without success. If we try with myfaces 1.1.6 there is a " java.lang.IllegalStateException: BufferedResponseStream is null" caught, with 1.1.4 an java.lang.NullPointerException arised. Maybe it works with some versions but nice to know what versions to be used. Thank you for all the good stuff and investigations, hopefully it is working in some way! Kind regards, Andreas
          Hide
          Leonardo Uribe added a comment -

          There is a report on TOMAHAWK-1331 about a problem with portlet support. That one was fixed, so v 1.1.8 works with it.

          Solving TOMAHAWK-1381, there is a working example of this feature (tomahawk configured with TomahawkFacesContextWrapper), so it could help as reference. I'll close this one again, since there is no problem at this point.

          Show
          Leonardo Uribe added a comment - There is a report on TOMAHAWK-1331 about a problem with portlet support. That one was fixed, so v 1.1.8 works with it. Solving TOMAHAWK-1381 , there is a working example of this feature (tomahawk configured with TomahawkFacesContextWrapper), so it could help as reference. I'll close this one again, since there is no problem at this point.

            People

            • Assignee:
              Martin Marinschek
              Reporter:
              Shinsuke Sugaya
            • Votes:
              19 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development