On Tue, Oct 21, 2008 at 6:13 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:

> The problem only happens when server state saving is used. On client side
> state saving everything works well.
>
> I'll try add the params to faces-config.xml and see what happens.
>
>
Checking myfaces core 1.2.x code, class JspViewHandlerImpl there is this
code:

    public void writeState(FacesContext facesContext) throws IOException
    {
        StateManager stateManager =
facesContext.getApplication().getStateManager();
        if (stateManager.isSavingStateInClient(facesContext))
        {
        // Only write state marker if javascript view state is disabled
        ExternalContext extContext = facesContext.getExternalContext();
        if (!(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 <
> [EMAIL PROTECTED]> wrote:
>
>> The main thing to note here is that this message is always written to the
>> log when running this Myfaces config (for all your browsers) and hence is
>> non-indicative of the problem.  FYI -- we can't determine that its correct
>> (for all cases) that we didn't find the Token which is why we write a log
>> message.
>>    -Mike-
>>
>>
>> Scott O'Bryan wrote:
>>
>>> Hey Leo, this could be related to the state-saving issue with MyFaces
>>> that I posted to the dev list about a month ago.  I havn't had time to fix
>>> it (or even write a JIRA ticket) but, essentially, there are times that
>>> MyFaces does not generate a state-saving token when maybe it should.  On the
>>> previous attempt for alpha-3, we were generating an exception.  This has
>>> changed into a stern warning which is what you're seeing in the logs.
>>>
>>> Are you seeing a functional issue?  If so, then I suppose I can try and
>>> tackle the MyFaces issue in my copious amounts of free time to see if we can
>>> resolve the issue from the MyFaces side.
>>>
>>> Scott
>>>
>>> Leonardo Uribe wrote:
>>>
>>>>
>>>>
>>>> On Tue, Oct 21, 2008 at 5:18 PM, Leonardo Uribe <[EMAIL PROTECTED]<mailto:
>>>> [EMAIL PROTECTED]>> wrote:
>>>>
>>>>
>>>>
>>>>    On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
>>>>    <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>>>>    wrote:
>>>>
>>>>        What do you mean by the "demo app stops running"?  Does it run
>>>>        at all?  If so how far do you get before you run into the
>>>>        problem?  The error message you are seeing is written into the
>>>>        log, right? If so, all this is telling you is that Myfaces is
>>>>        running in a configuration where it writes the state directly
>>>>        into the rendition versus using the cache/replace model of the
>>>>        SAVESTATE_FIELD_MARKER.   FYI ... I also am using Firefox
>>>>        2.0.0.17 <http://2.0.0.17> 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
>>>>>        <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>>>>>
>>>>>            +1
>>>>>
>>>>>
>>>>>            Scott O'Bryan wrote:
>>>>>
>>>>>                Sorry, I forgot the word [VOTE] in the subject.
>>>>>
>>>>>                Scott O'Bryan wrote:
>>>>>
>>>>>                    Hi,
>>>>>
>>>>>                    I'm trying to release the MyFaces Portlet Bridge
>>>>>                    Master 1.0.0-alpha-3.  This release was created
>>>>>                    in order to support the latest JSR-301 Public
>>>>>                    Review so that it may be tested by developers
>>>>>                    during the review process.  This is still an
>>>>>                    alpha release because there is currently no
>>>>>                    testing of the R.I.
>>>>>
>>>>>                    I was running the needed tasks to get the
>>>>>                    1.0.0-alpha-3 release of the Apache MyFaces
>>>>>                    Portlet Bridge out. The artifacts are deployed to
>>>>>                    my private Apache account ([1]).
>>>>>
>>>>>                    Please take a look at the
>>>>>                    "portlet-bridge-master-pom-1" artifacts and vote
>>>>>
>>>>>                    ------------------------------------------------
>>>>>                    [ ] +1 for community members who have reviewed
>>>>>                    the bits
>>>>>                    [ ] +0
>>>>>                    [ ] -1 for fatal flaws that should cause these
>>>>>                    bits not to be released,
>>>>>                           and why..............
>>>>>                    ------------------------------------------------
>>>>>
>>>>>                    Thanks,
>>>>>                      Scott
>>>>>
>>>>>                    [1]
>>>>>
>>>>> http://people.apache.org/~sobryan/portlet-bridge/1.0.0-alpha-3<http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
>>>>>                    <
>>>>> http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
>>>>>                    <
>>>>> http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>

Reply via email to