|
Supporting the fileupload for Portlets is also important for me. Could thie patch of Shinsuke SUGAYA be integrated to MyFaces?
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. Is it allowed to have full functionality if both project's classes are available, but limited functionality if they are not? Just an idea..
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. 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. 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 My suggested fix depends on both impl(MyFacesGenericPortlet) and tomahawk(AddResource..). So, if putting it to "share", I encountered the build error.
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 Yes. impl and tomahawk do not depend on my fix(though some classes, such as AddResouce, need to be modified).
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? I take a look as soon as I can. I like it so far!!!
Thanks Shinsuke. 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! 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. 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? Attached files for Jetspeed2.
You also need to add myfaces dependency to components/header-resource/project.xml. 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 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 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. 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 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 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. 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 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/ 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.
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. 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? 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. 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 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 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. Is that any of the files provided above?
regards, Martin 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).
Next week would be perfectly alright.
regards, Martin 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. Attached fix for Tomahawk's trunk.
Hi Shinsuke,
you're creating a new module here - is this reasonable, or should the full thing just be part of tomahawk? regards, Martin Yes. The attachment is just for Tomahawk, not core and others. Actually, I'm using it on Teeda(JSF Implementation) and Tomahawk environment.
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 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. Hi Martin,
Do you have an update for this issue? If you have any problem about my solution, please let me know. 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 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 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 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/ 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 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 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 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. 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 One last tip. For use this, use NonBufferingAddResource.
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 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. 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.
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)? 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)?. 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.
The problem of have e.printStackTrace lines has been solved on revisions 657159
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... 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. 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. At last I have committed fileupload support for portlets. This issue will be finally closed, but first I'll do some reviews before.
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 There is a report on
Solving |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Major
MyFaces's Portlet enhancement
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