You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Scott O'Bryan <da...@gmail.com> on 2008/10/21 19:27:48 UTC
[VOTE] Release of Portlet Bridge 1.0.0-alpha-3
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>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by michael freedman <mi...@oracle.com>.
Try this. Edit the faces-config.xml file in the
impl\src\main\resources\META-INF directly and add the following lines
after the :
<bridge:excluded-attribute>com.sun.faces.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.application.jsp.JspStateManagerImpl.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.el.unified.resolver.managedbean.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.shared_impl.renderkit.RendererUtils.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.application.DefaultViewHandlerSupport.*</bridge:excluded-attribute>
<bridge:excluded-attribute>jsf_sequence</bridge:excluded-attribute>
Its really only the last one that impacts view restoration but its good
to exlcude the others as well as they don't need to be managed.
Rebuild the bridge/rebuild/rerun the demo. Let me know if this fixes
your problem. If it does I will actually commit this change (I have had
it sitting around for sometime now but didn't want to commit it as part
of the alpha3 work which was already done). I knew that it impacted
refresh in MyFaces but if it fixes you there are other refresh cases
that are easy to hit. Technically its not a bug/something that the
Bridge should worry about -- excluding attributes is something that the
offending system should do (i.e. Myfaces) and or the application -- but
the bridge does have a spirit of excluding for common uses.
-Mike-
Leonardo Uribe wrote:
>
>
> On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
> <michael.freedman@oracle.com <ma...@oracle.com>> 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> 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.
>
>
>
> 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> 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
>> <darkarena@gmail.com <ma...@gmail.com>> 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>
>>
>>
>>
>>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by michael freedman <mi...@oracle.com>.
When you say the state isn't restored when you click a button or link
can you be more specific? there are two views -- the first view asks
you to enter your name. Is the problem on navigating from this page?
I.e. the second view doesn't say "hello <name>". Or is there a problem
when you hit return in the 2nd view to return to the first view? I.e.
the name isn't displayed in the first view ? If the later: note that
this is the correct behavior. When you navigate back to the first view
it should show an empty field. The "exlcude-attribute" problem I
referenced in my other e-mail concerns what happens if you hit refresh
in the 2nd view. Without the excluded-attributes you are returned to
the first view (and the name is preserved) -- with the
exlcuded-attributes the 2nd view is refreshed with the name preserved.
-Mike-
Leonardo Uribe wrote:
>
>
> On Tue, Oct 21, 2008 at 5:18 PM, Leonardo Uribe <lu4242@gmail.com
> <ma...@gmail.com>> wrote:
>
>
>
> On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
> <michael.freedman@oracle.com <ma...@oracle.com>>
> 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> 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> 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
>> <darkarena@gmail.com <ma...@gmail.com>> 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>
>>
>>
>>
>>
>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Scott O'Bryan <da...@gmail.com>.
Wow, it's beginning to sound like a JVM or OS error to meet. None of
the code we have in the bridge SHOULD be OS dependent. Plus, it's
working fine on my machine although, admittedly, I'm running 1.6_10.
I'll try to downgrade to 1.5 and see if I can reproduce the issue.
Scott
Leonardo Uribe wrote:
>
>
> On Tue, Oct 21, 2008 at 7:40 PM, Leonardo Uribe <lu4242@gmail.com
> <ma...@gmail.com>> wrote:
>
>
>
> On Tue, Oct 21, 2008 at 6:52 PM, Scott O'Bryan
> <darkarena@gmail.com <ma...@gmail.com>> 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 <http://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 <http://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 <http://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
> <lu4242@gmail.com <ma...@gmail.com>
> <mailto:lu4242@gmail.com <ma...@gmail.com>>> 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
> (!(JavascriptUtils.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
> <michael.freedman@oracle.com
> <ma...@oracle.com>
> <mailto:michael.freedman@oracle.com
> <ma...@oracle.com>>>
> 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
> <lu4242@gmail.com <ma...@gmail.com>
> <mailto:lu4242@gmail.com <ma...@gmail.com>>
> <mailto:lu4242@gmail.com
> <ma...@gmail.com> <mailto:lu4242@gmail.com
> <ma...@gmail.com>>>>
>
> wrote:
>
>
>
> On Tue, Oct 21, 2008 at 4:50 PM, michael
> freedman
> <michael.freedman@oracle.com
> <ma...@oracle.com>
> <mailto:michael.freedman@oracle.com
> <ma...@oracle.com>>
> <mailto:michael.freedman@oracle.com
> <ma...@oracle.com>
> <mailto:michael.freedman@oracle.com
> <ma...@oracle.com>>>>
> 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> <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>
> <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
> <darkarena@gmail.com
> <ma...@gmail.com>
> <mailto:darkarena@gmail.com
> <ma...@gmail.com>>
> <mailto:darkarena@gmail.com
> <ma...@gmail.com>
>
> <mailto:darkarena@gmail.com
> <ma...@gmail.com>>>> 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>
>
> <http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
>
>
>
>
>
>
>
>
>
>
>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Scott O'Bryan <da...@gmail.com>.
I'll add the patch to alpha-3 and regenerate the artifacts. Thanks
Leonardo.
Scott
Leonardo Uribe wrote:
>
>
> On Wed, Oct 22, 2008 at 12:54 PM, Leonardo Uribe <lu4242@gmail.com
> <ma...@gmail.com>> wrote:
>
>
>
> On Wed, Oct 22, 2008 at 12:13 PM, Michael Freedman
> <michael.freedman@oracle.com <ma...@oracle.com>>
> wrote:
>
> 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-
>
>
> I tried adding the attributes to faces-config.xml of portlet-impl
> and the problem is still present. I'll fill a issue about this
> with all necessary info.
>
>
>
> I rerun all tests to see if I loose some detail (yesterday I worked a
> lot and maybe I was too tired). I made a mistake adding this params to
> faces-config.xml.
>
>
> <bridge:excluded-attribute>org.apache.myfaces.application.jsp.JspStateManagerImpl.*</bridge:excluded-attribute>
>
> <bridge:excluded-attribute>org.apache.myfaces.el.unified.resolver.managedbean.*</bridge:excluded-attribute>
>
> <bridge:excluded-attribute>org.apache.myfaces.shared_impl.renderkit.RendererUtils.*</bridge:excluded-attribute>
>
> <bridge:excluded-attribute>org.apache.myfaces.application.DefaultViewHandlerSupport.*</bridge:excluded-attribute>
>
> <bridge:excluded-attribute>jsf_sequence</bridge:excluded-attribute>
>
> If you add this params to portlet bridge faces-config.xml the problem
> disappear and the application works correctly (I tried several times
> to be sure). So, it could be good to add it for release portlet bridge
> 1.0.0-alpha-3.
>
> I'll create a jira issue for this.
>
> regards
>
> Leonardo Uribe
>
>
>
>
> Leonardo Uribe wrote:
>>
>>
>> On Tue, Oct 21, 2008 at 7:40 PM, Leonardo Uribe
>> <lu4242@gmail.com <ma...@gmail.com>> wrote:
>>
>>
>>
>> On Tue, Oct 21, 2008 at 6:52 PM, Scott O'Bryan
>> <darkarena@gmail.com <ma...@gmail.com>> 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
>> <http://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 <http://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 <http://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
>> <lu4242@gmail.com <ma...@gmail.com>
>> <mailto:lu4242@gmail.com
>> <ma...@gmail.com>>> 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
>> (!(JavascriptUtils.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
>> <michael.freedman@oracle.com
>> <ma...@oracle.com>
>> <mailto:michael.freedman@oracle.com
>> <ma...@oracle.com>>>
>> 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
>> <lu4242@gmail.com
>> <ma...@gmail.com>
>> <mailto:lu4242@gmail.com <ma...@gmail.com>>
>> <mailto:lu4242@gmail.com
>> <ma...@gmail.com>
>> <mailto:lu4242@gmail.com
>> <ma...@gmail.com>>>>
>>
>> wrote:
>>
>>
>>
>> On Tue, Oct 21, 2008 at 4:50
>> PM, michael freedman
>> <michael.freedman@oracle.com
>> <ma...@oracle.com>
>>
>> <mailto:michael.freedman@oracle.com
>> <ma...@oracle.com>>
>>
>> <mailto:michael.freedman@oracle.com
>> <ma...@oracle.com>
>>
>> <mailto:michael.freedman@oracle.com
>> <ma...@oracle.com>>>>
>> 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> <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>
>> <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
>> <darkarena@gmail.com
>> <ma...@gmail.com>
>> <mailto:darkarena@gmail.com
>> <ma...@gmail.com>>
>> <mailto:darkarena@gmail.com
>> <ma...@gmail.com>
>>
>> <mailto:darkarena@gmail.com
>> <ma...@gmail.com>>>> 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>
>>
>>
>> <http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Leonardo Uribe <lu...@gmail.com>.
On Wed, Oct 22, 2008 at 12:54 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>
>
> On Wed, Oct 22, 2008 at 12:13 PM, Michael Freedman <
> michael.freedman@oracle.com> wrote:
>
>> 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-
>>
>
> I tried adding the attributes to faces-config.xml of portlet-impl and the
> problem is still present. I'll fill a issue about this with all necessary
> info.
>
>
I rerun all tests to see if I loose some detail (yesterday I worked a lot
and maybe I was too tired). I made a mistake adding this params to
faces-config.xml.
<bridge:excluded-attribute>org.apache.myfaces.application.jsp.JspStateManagerImpl.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.el.unified.resolver.managedbean.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.shared_impl.renderkit.RendererUtils.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.application.DefaultViewHandlerSupport.*</bridge:excluded-attribute>
<bridge:excluded-attribute>jsf_sequence</bridge:excluded-attribute>
If you add this params to portlet bridge faces-config.xml the problem
disappear and the application works correctly (I tried several times to be
sure). So, it could be good to add it for release portlet bridge
1.0.0-alpha-3.
I'll create a jira issue for this.
regards
Leonardo Uribe
>
>>
>> Leonardo Uribe wrote:
>>
>>
>>
>> On Tue, Oct 21, 2008 at 7:40 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Oct 21, 2008 at 6:52 PM, Scott O'Bryan <da...@gmail.com>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 <lu4242@gmail.com<mailto:
>>>>> lu4242@gmail.com>> 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 (!(JavascriptUtils.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
>>>>> <michael.freedman@oracle.com <ma...@oracle.com>>
>>>>> 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
>>>>> <lu4242@gmail.com <ma...@gmail.com>
>>>>> <mailto:lu4242@gmail.com <ma...@gmail.com>>>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
>>>>> <michael.freedman@oracle.com
>>>>> <ma...@oracle.com>
>>>>> <mailto:michael.freedman@oracle.com
>>>>> <ma...@oracle.com>>>
>>>>> 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
>>>>> <darkarena@gmail.com
>>>>> <ma...@gmail.com>
>>>>> <mailto:darkarena@gmail.com
>>>>> <ma...@gmail.com>>> 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>
>>>>> <
>>>>> http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Leonardo Uribe <lu...@gmail.com>.
On Wed, Oct 22, 2008 at 12:13 PM, Michael Freedman <
michael.freedman@oracle.com> wrote:
> 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-
>
I tried adding the attributes to faces-config.xml of portlet-impl and the
problem is still present. I'll fill a issue about this with all necessary
info.
>
>
> Leonardo Uribe wrote:
>
>
>
> On Tue, Oct 21, 2008 at 7:40 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>
>>
>>
>> On Tue, Oct 21, 2008 at 6:52 PM, Scott O'Bryan <da...@gmail.com>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 <lu4242@gmail.com<mailto:
>>>> lu4242@gmail.com>> 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 (!(JavascriptUtils.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
>>>> <michael.freedman@oracle.com <ma...@oracle.com>>
>>>> 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
>>>> <lu4242@gmail.com <ma...@gmail.com>
>>>> <mailto:lu4242@gmail.com <ma...@gmail.com>>>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
>>>> <michael.freedman@oracle.com
>>>> <ma...@oracle.com>
>>>> <mailto:michael.freedman@oracle.com
>>>> <ma...@oracle.com>>>
>>>> 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
>>>> <darkarena@gmail.com
>>>> <ma...@gmail.com>
>>>> <mailto:darkarena@gmail.com
>>>> <ma...@gmail.com>>> 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>
>>>> <
>>>> http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Leonardo Uribe <lu...@gmail.com>.
On Tue, Oct 21, 2008 at 7:40 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>
>
> On Tue, Oct 21, 2008 at 6:52 PM, Scott O'Bryan <da...@gmail.com>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 <lu4242@gmail.com<mailto:
>>> lu4242@gmail.com>> 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 (!(JavascriptUtils.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
>>> <michael.freedman@oracle.com <ma...@oracle.com>>
>>> 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
>>> <lu4242@gmail.com <ma...@gmail.com>
>>> <mailto:lu4242@gmail.com <ma...@gmail.com>>>
>>> wrote:
>>>
>>>
>>>
>>> On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
>>> <michael.freedman@oracle.com
>>> <ma...@oracle.com>
>>> <mailto:michael.freedman@oracle.com
>>> <ma...@oracle.com>>>
>>> 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
>>> <darkarena@gmail.com
>>> <ma...@gmail.com>
>>> <mailto:darkarena@gmail.com
>>>
>>> <ma...@gmail.com>>> 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>
>>> <
>>> http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Leonardo Uribe <lu...@gmail.com>.
On Tue, Oct 21, 2008 at 6:52 PM, Scott O'Bryan <da...@gmail.com> 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.
>
> Scott
>
> Leonardo Uribe wrote:
>
>>
>>
>> On Tue, Oct 21, 2008 at 6:13 PM, Leonardo Uribe <lu4242@gmail.com<mailto:
>> lu4242@gmail.com>> 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 (!(JavascriptUtils.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
>> <michael.freedman@oracle.com <ma...@oracle.com>>
>> 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
>> <lu4242@gmail.com <ma...@gmail.com>
>> <mailto:lu4242@gmail.com <ma...@gmail.com>>>
>> wrote:
>>
>>
>>
>> On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
>> <michael.freedman@oracle.com
>> <ma...@oracle.com>
>> <mailto:michael.freedman@oracle.com
>> <ma...@oracle.com>>>
>> 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
>> <darkarena@gmail.com
>> <ma...@gmail.com>
>> <mailto:darkarena@gmail.com
>>
>> <ma...@gmail.com>>> 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>
>> <
>> http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Scott O'Bryan <da...@gmail.com>.
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.
Scott
Leonardo Uribe wrote:
>
>
> On Tue, Oct 21, 2008 at 6:13 PM, Leonardo Uribe <lu4242@gmail.com
> <ma...@gmail.com>> 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 (!(JavascriptUtils.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
> <michael.freedman@oracle.com <ma...@oracle.com>>
> 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
> <lu4242@gmail.com <ma...@gmail.com>
> <mailto:lu4242@gmail.com <ma...@gmail.com>>>
> wrote:
>
>
>
> On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
> <michael.freedman@oracle.com
> <ma...@oracle.com>
> <mailto:michael.freedman@oracle.com
> <ma...@oracle.com>>>
> 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
> <darkarena@gmail.com
> <ma...@gmail.com>
> <mailto:darkarena@gmail.com
> <ma...@gmail.com>>> 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>
>
>
>
>
>
>
>
>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Leonardo Uribe <lu...@gmail.com>.
On Tue, Oct 21, 2008 at 6:13 PM, Leonardo Uribe <lu...@gmail.com> 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 (!(JavascriptUtils.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 <
> michael.freedman@oracle.com> 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 <lu4242@gmail.com<mailto:
>>>> lu4242@gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
>>>> <michael.freedman@oracle.com <ma...@oracle.com>>
>>>> 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> 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> 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
>>>>> <darkarena@gmail.com <ma...@gmail.com>> 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>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Leonardo Uribe <lu...@gmail.com>.
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.
On Tue, Oct 21, 2008 at 5:57 PM, michael freedman <
michael.freedman@oracle.com> 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 <lu4242@gmail.com<mailto:
>>> lu4242@gmail.com>> wrote:
>>>
>>>
>>>
>>> On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
>>> <michael.freedman@oracle.com <ma...@oracle.com>>
>>> 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> 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> 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
>>>> <darkarena@gmail.com <ma...@gmail.com>> 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>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by michael freedman <mi...@oracle.com>.
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 <lu4242@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>>
>>
>> On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
>> <michael.freedman@oracle.com <ma...@oracle.com>>
>> 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> 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> 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
>>> <darkarena@gmail.com <ma...@gmail.com>> 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>
>>>
>>>
>>>
>>>
>>
>>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Scott O'Bryan <da...@gmail.com>.
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 <lu4242@gmail.com
> <ma...@gmail.com>> wrote:
>
>
>
> On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
> <michael.freedman@oracle.com <ma...@oracle.com>>
> 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> 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> 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
>> <darkarena@gmail.com <ma...@gmail.com>> 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>
>>
>>
>>
>>
>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Leonardo Uribe <lu...@gmail.com>.
On Tue, Oct 21, 2008 at 5:18 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>
>
> On Tue, Oct 21, 2008 at 4:50 PM, michael freedman <
> michael.freedman@oracle.com> 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 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 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 <da...@gmail.com>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>
>>>>>
>>>>
>>>>
>>>
>>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Leonardo Uribe <lu...@gmail.com>.
On Tue, Oct 21, 2008 at 4:50 PM, michael freedman <
michael.freedman@oracle.com> 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 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.
>
> 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 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 <da...@gmail.com>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>
>>>>
>>>
>>>
>>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by michael freedman <mi...@oracle.com>.
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 and the demo is running fine for me. So please
send me more info on reproducing.
As for running with the RI there are potentially two issues:
first the command is now:
mvn clean -PjettyConfig -Djsf=ri-provided jetty:run
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> 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 <darkarena@gmail.com
> <ma...@gmail.com>> 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>
>
>
>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Leonardo Uribe <lu...@gmail.com>.
I tried to run the demo module and on firefox 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 <da...@gmail.com> 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>
>>>
>>
>>
>
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Posted by Scott O'Bryan <da...@gmail.com>.
+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>
>