Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3

[Michael Freedman]

Can you send a description of the exact steps to reproduce the problem.  I.e. Run app, fill in X, Click Y .... then you will notice Z? Also can you send a more thorough description of the problem you are seeing.  I.e On all other platforms the app behaves like X when you do Y but in this platform/browser the app behaves like Z when you do Y? Did you run with the excluded attributes I suggested?  Not excluding jsf_sequence will cause incorrect view state/view restoration in certain circumstances.  However, as Scott says, the bridge injects no markup into the response hence running in a different browser/platform should be unrelated to the Bridge.     -Mike- Leonardo Uribe wrote: On Tue, Oct 21, 2008 at 7:40 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote: On Tue, Oct 21, 2008 at 6:52 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: Leonardo, Right.  This was the problem discovered last release.  The behavior your seeing is actually expected (it was CHANGED to do what it does because it USED to throw an exception).  What Mike discovered was that, although there is really no need to tokenize server-side and JS state saving, we were not actually gaining anything by NOT tokenizing it (there are no performance increases because of the current code path).  And in order for the bridge to automatically determine the token being used, it needs to be present. The way I see it, we have two choices.  We can try to work off of the implementation name of the distribution on MyFaces (which would make the implementation name part of the contract) OR we can modify MyFaces to always write the token.  Alternatively, I believe if you set the token in the init parameters of the portlet (as specified in JSR-301) then that will also get rid of the log entry.  We were trying to let the R.I. autodetect between the R.I. and MyFaces. As for the excludes, if that works then we should probably commit these changes to the alpha-3 branch and I can regenrate. I have made more tests about this problem. It seems the problem is not related to write the state marker or not. The actual code if the marker is not found it just write it directly the response. I have one machine with firefox 3.0.3, and the problem is not present. The machine with firefox 2.0.0.17 has the problem. A correct request (firefox 3.0.3, opera 9 or IE 7) output on the log (stdout) something like this: 2008-10-21 19:25:47.666:/portlet-bridge-demo:INFO:  PortletExternalContextImpl.g etViewId: found jsf target viewId = view:/helloworld/index.jsp 2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:  dumpScopeId: ACTION_PHASE 2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:  Elements in scope: portlet-b ridge-demo:19hv18thfnrd9:view:-25ecdd41:11d21e77bb0:-7fdb 2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:       org.apache.myfaces.port let.faces.includeInScope.requestParameters 2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:       org.apache.myfaces.port let.faces.includeInScope.facesViewRoot 2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:       org.apache.myfaces.el.u nified.resolver.managedbean.beansUnderConstruction 2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:       org.apache.myfaces.appl ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW 2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:       org.apache.myfaces.appl ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING 2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:       jsf_sequence 2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:       namebean 2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:       org.apache.myfaces.shar ed_impl.renderkit.RendererUtils.RenderKitImpl 2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:  end dumpScopeId Oct 21, 2008 7:25:47 PM org.apache.pluto.driver.PortalDriverFilter doFilter INFO: Forwarding to realPath: /pluto/index.jsp 2008-10-21 19:25:47.744:/portlet-bridge-demo:INFO:  Unable to locate a SAVESTATE _FIELD_MARKER in response.  This could be because your Faces environment doesn't  write such a marker or because the bridge doesn't know the marker in use.  If t he later, configure the appropriate application init parameter javax.portlet.fac es.SAVESTATE_FIELD_MARKER. 2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:  dumpScopeId: RENDER_PHASE 2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:  Elements in scope: portlet-b ridge-demo:19hv18thfnrd9:view:-25ecdd41:11d21e77bb0:-7fdb 2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:       org.apache.myfaces.port let.faces.includeInScope.requestParameters 2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:       org.apache.myfaces.el.u nified.resolver.managedbean.beansUnderConstruction 2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:       org.apache.myfaces.appl ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW 2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:       org.apache.myfaces.appl ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING 2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:       jsf_sequence 2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:       namebean 2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:       org.apache.myfaces.shar ed_impl.renderkit.RendererUtils.RenderKitImpl 2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:  end dumpScopeId A request using firefox 2.0.0.17 looks like this: 2008-10-21 19:26:46.822:/portlet-bridge-demo:INFO:  PortletExternalContextImpl.g etViewId: found jsf target viewId = view:/helloworld/index.jsp 2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:  dumpScopeId: ACTION_PHASE 2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:  Elements in scope: portlet-b ridge-demo:yh4tse3ctjqw:view:-25ecdd41:11d21e77bb0:-7fda 2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:       org.apache.myfaces.port let.faces.includeInScope.requestParameters 2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:       org.apache.myfaces.port let.faces.includeInScope.facesViewRoot 2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:       org.apache.myfaces.el.u nified.resolver.managedbean.beansUnderConstruction 2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:       org.apache.myfaces.appl ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW 2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:       org.apache.myfaces.appl ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING 2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:       jsf_sequence 2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:       namebean 2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:       org.apache.myfaces.shar ed_impl.renderkit.RendererUtils.RenderKitImpl 2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:  end dumpScopeId Oct 21, 2008 7:26:46 PM org.apache.pluto.driver.PortalDriverFilter doFilter INFO: Forwarding to realPath: /pluto/index.jsp 2008-10-21 19:26:46.869:/portlet-bridge-demo:INFO:  Unable to locate a SAVESTATE _FIELD_MARKER in response.  This could be because your Faces environment doesn't  write such a marker or because the bridge doesn't know the marker in use.  If t he later, configure the appropriate application init parameter javax.portlet.fac es.SAVESTATE_FIELD_MARKER. 2008-10-21 19:26:46.869:/portlet-bridge-demo:INFO:  dumpScopeId: RENDER_PHASE 2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:  Elements in scope: portlet-b ridge-demo:yh4tse3ctjqw:view:-25ecdd41:11d21e77bb0:-7fda 2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:       org.apache.myfaces.port let.faces.includeInScope.requestParameters 2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:       org.apache.myfaces.el.u nified.resolver.managedbean.beansUnderConstruction 2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:       org.apache.myfaces.appl ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW 2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:       org.apache.myfaces.appl ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING 2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:       jsf_sequence 2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:       namebean 2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:       org.apache.myfaces.shar ed_impl.renderkit.RendererUtils.RenderKitImpl 2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:  end dumpScopeId Oct 21, 2008 7:26:48 PM org.apache.pluto.driver.PortalDriverFilter doFilter INFO: Forwarding to realPath: /pluto/index.jsp 2008-10-21 19:26:48.163:/portlet-bridge-demo:INFO:  PortletExternalContextImpl.g etViewId: found jsf target viewId = view:/helloworld/hello.jsp 2008-10-21 19:26:48.163:/portlet-bridge-demo:INFO:  History for mode: view : /he lloworld/hello.jsp?javax.portlet.faces.PortletMode=view&__jpfbReqScopeId=portlet -bridge-demo%3Ayh4tse3ctjqw%3Aview%3A-25ecdd41%3A11d21e77bb0%3A-7fda&javax.faces .ViewState=CX8k%2BpTXi4XRIwnlHJaWVyc31c23xqtKQKd4yZOqnb9H8Xs6FKjAxuC58ztDpvj1O2O 1%2B8C%2F2gMMzdqOlEnLOB4LrckaiKM%2Bu3h3WzFSRkY%3D 2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:  Unable to locate a SAVESTATE _FIELD_MARKER in response.  This could be because your Faces environment doesn't  write such a marker or because the bridge doesn't know the marker in use.  If t he later, configure the appropriate application init parameter javax.portlet.fac es.SAVESTATE_FIELD_MARKER. 2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:  dumpScopeId: RENDER_PHASE 2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:  Elements in scope: portlet-b ridge-demo:yh4tse3ctjqw:view:-25ecdd41:11d21e77bb0:-7fda 2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:       org.apache.myfaces.port let.faces.includeInScope.requestParameters 2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:       org.apache.myfaces.el.u nified.resolver.managedbean.beansUnderConstruction 2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:       org.apache.myfaces.appl ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW 2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:       org.apache.myfaces.appl ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING 2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:       jsf_sequence 2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:       namebean 2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:       org.apache.myfaces.shar ed_impl.renderkit.RendererUtils.RenderKitImpl 2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:  end dumpScopeId The interesting thing about this is that the  RENDER_PHASE is executed twice (there are not two different request, just one). I'll try modify myfaces core 1.2.x, so it writes the marker on server state saving (yes, there are no performance increase, but I'll take a look at it), and see what happens. It seems to be a non blocking issue for release if we modify myfaces core.   I apply the modification on JspViewHandlerImpl, so the marker is always written. The result is the same, but the warning disappear. I tried to test firefox 2.0.0.17 (windows vista) from another computer and works normal, so it seem to be a problem on my other machine (windows xp). I tried install firefox 3.0.3 and the problem is present too. The strange part of all this stuff is that jsf ri does not have the problem (and using myfaces core with client side state saving too). The configuration that fails specifically is windows xp, firefox, myfaces core 1.2.x and server state saving.   Scott Leonardo Uribe wrote: On Tue, Oct 21, 2008 at 6:13 PM, Leonardo Uribe <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:    The problem only happens when server state saving is used. On    client side state saving everything works well.    I'll try add the params to faces-config.xml and see what happens. Checking myfaces core 1.2.x code, class JspViewHandlerImpl there is this code:    public void writeState(FacesContext facesContext) throws IOException    {        StateManager stateManager = facesContext.getApplication().getStateManager();        if (stateManager.isSavingStateInClient(facesContext))        {        // Only write state marker if _javascript_ view state is disabled        ExternalContext extContext = facesContext.getExternalContext();        if (!(_javascript_Utils.isJavascriptAllowed(extContext) && MyfacesConfig.getCurrentInstance(extContext).isViewStateJavascript())) {            facesContext.getResponseWriter().write(FORM_STATE_MARKER);        }        }        else        {            stateManager.writeState(facesContext, new Object[2]);        }    } Myfaces core 1.2.x does not write any marker on server side state saving (I suppose jsf ri does) and the inner class JspViewHandlerImpl.StateMarkerAwareWriter (this class is responsible to change the marker) is only used on client side state saving, but portlet bridge always assume that some marker is written.      On Tue, Oct 21, 2008 at 5:57 PM, michael freedman    <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>    wrote:        The main thing to note here is that this message is always        written to the log when running this Myfaces config (for all        your browsers) and hence is non-indicative of the problem.         FYI -- we can't determine that its correct (for all cases)        that we didn't find the Token which is why we write a log message.           -Mike-        Scott O'Bryan wrote:            Hey Leo, this could be related to the state-saving issue            with MyFaces that I posted to the dev list about a month            ago.  I havn't had time to fix it (or even write a JIRA            ticket) but, essentially, there are times that MyFaces            does not generate a state-saving token when maybe it            should.  On the previous attempt for alpha-3, we were            generating an exception.  This has changed into a stern            warning which is what you're seeing in the logs.            Are you seeing a functional issue?  If so, then I suppose            I can try and tackle the MyFaces issue in my copious            amounts of free time to see if we can resolve the issue            from the MyFaces side.            Scott            Leonardo Uribe wrote:                On Tue, Oct 21, 2008 at 5:18 PM, Leonardo Uribe                <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>                <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>                wrote:                   On Tue, Oct 21, 2008 at 4:50 PM, michael freedman                   <[EMAIL PROTECTED]                <mailto:[EMAIL PROTECTED]>                <mailto:[EMAIL PROTECTED]                <mailto:[EMAIL PROTECTED]>>>                   wrote:                       What do you mean by the "demo app stops                running"?  Does it run                       at all?  If so how far do you get before you                run into the                       problem?  The error message you are seeing is                written into the                       log, right? If so, all this is telling you is                that Myfaces is                       running in a configuration where it writes the                state directly                       into the rendition versus using the                cache/replace model of the                       SAVESTATE_FIELD_MARKER.   FYI ... I also am                using Firefox                       2.0.0.17 <http://2.0.0.17> <http://2.0.0.17>                and the demo is running fine for                       me.  So please send me more info on reproducing.                   I just run the demo like this:                   mvn clean -PjettyConfig jetty:run (according to the                pom myfaces                   core 1.2.2 is used)                   and then try the demo several times. Sometimes                works but others do                   not and the message is on the log. I'm just run the                demo as is,                   without any modification. I don't know if there is                some special                   configuration to make it work correctly with                myfaces core. If this                   is true, it could be good to use profiles to define                several                   web.xml files for configure and test it.                                  One last note: stops running means when you click a                button or link the state is not restored and the                request is readed as it was new.                                       As for running with the RI there are                potentially two issues:                       first the command is now:                       mvn clean -PjettyConfig -Djsf=ri-provided jetty:run                   Ok, thanks, it works and does not have the problem                with firefox.                                         The other problem is you need to make sure its                not trying to                       run with the prior MyFaces TLD -- generally the                clean should                       do this, though.                           -Mike-                       Leonardo Uribe wrote:                           I tried to run the demo module and on                    firefox 2.0.0.17 <http://2.0.0.17>                           <http://2.0.0.17> sometimes I have this                    (the demo app stops                           running):                           2008-10-21                    15:51:40.318:/portlet-bridge-demo:INFO:  History                           for mode: view : /he                                             lloworld/index.jsp?javax.portlet.faces.PortletMode=view&__jpfbReqScopeId=portlet                                             -bridge-demo%3Ayd3exguy3te2%3Aview%3A24d73b2a%3A11d21270f21%3A-7fd3&javax.faces.                                             ViewState=qpZU311sohuneMJrlpRjNB4K2cfv0ubhRgzMYD5Kf4V1pkzHlFXyeKdNfb5408dPXMeN1u                           tp3qg5cWArexFYziMyJAzgTwOQ8GFyqxDCz8Y%3D                           2008-10-21                    15:51:40.318:/portlet-bridge-demo:INFO:  Unable to                           locate a SAVESTATE                           _FIELD_MARKER in response.  This could be                    because your Faces                           environment doesn't                            write such a marker or because the bridge                    doesn't know the                           marker in use.  If t                           he later, configure the appropriate                    application init                           parameter javax.portlet.fac                           es.SAVESTATE_FIELD_MARKER.                           In opera 9 and IE 7 everything works fine.                           Also when I tried to run                           mvn clean -PjettyConfig -Djsf=ri jetty:run                           throws this error:                           2008-10-21 15:52:51.809::WARN:  failed                    portlet-bridge-demo                           java.lang.NoClassDefFoundError:                    javax/faces/FacesException                                   at                    java.lang.ClassLoader.defineClass1(Native Method)                                   at                                             java.lang.ClassLoader.defineClass(ClassLoader.java:620)                                   at                                             java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12                           4)                                   at                                             java.net.URLClassLoader.defineClass(URLClassLoader.java:260)                                   at                                             java.net.URLClassLoader.access$000(URLClassLoader.java:56)                                   at                    java.net.URLClassLoader$1.run(URLClassLoader.java:195)                                   at                    java.security.AccessController.doPrivileged(Native                           Method)                                   at                                             java.net.URLClassLoader.findClass(URLClassLoader.java:188)                                   at                                             org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoade                           r.java:366)                                   at                                             org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoade                           r.java:337)                           maybe this is not blocking but it could be                    good to have a                           fast way to test it.                           On Tue, Oct 21, 2008 at 12:28 PM, Scott O'Bryan                           <[EMAIL PROTECTED]                    <mailto:[EMAIL PROTECTED]>                    <mailto:[EMAIL PROTECTED]                    <mailto:[EMAIL PROTECTED]>>> wrote:                               +1                               Scott O'Bryan wrote:                                   Sorry, I forgot the word [VOTE] in                    the subject.                                   Scott O'Bryan wrote:                                       Hi,                                       I'm trying to release the                    MyFaces Portlet Bridge                                       Master 1.0.0-alpha-3.  This                    release was created                                       in order to support the latest                    JSR-301 Public                                       Review so that it may be tested                    by developers                                       during the review process.                     This is still an                                       alpha release because there is                    currently no                                       testing of the R.I.                                       I was running the needed tasks                    to get the                                       1.0.0-alpha-3 release of the                    Apache MyFaces                                       Portlet Bridge out. The                    artifacts are deployed to                                       my private Apache account ([1]).                                       Please take a look at the                                       "portlet-bridge-master-pom-1"                    artifacts and vote                                                         ------------------------------------------------                                       [ ] +1 for community members                    who have reviewed                                       the bits                                       [ ] +0                                       [ ] -1 for fatal flaws that                    should cause these                                       bits not to be released,                                              and why..............                                                         ------------------------------------------------                                       Thanks,                                         Scott                                       [1]                                                         http://people.apache.org/~sobryan/portlet-bridge/1.0.0-alpha-3                    <http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>                                                         <http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>                                                         <http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>