Does woodstock ajax require client side state saving?

[Ryan de Laplante]

I'm still having "fun" getting my real application to work like my test
app.   It mostly works, but I find value change events firing multiple
times first showing a null new value (correct) followed by the previous
value being re-set.  I also see the value change events not firing in
the same order as the test app.

I'm thinking this has something to do with view state.  The test app
shows a very long encoded view state in HTML output and AJAX requests,
but the real app shows what appears to be a server side view state token:

<input type="hidden" name="javax.faces.ViewState"
id="javax.faces.ViewState" value="j_id7:j_id8" />

I have added the following to my web.xml, and even restarted the app
server, but it doesn't make a difference.  I can't get it to output an
encoded view state.  Hopefully once I can figure that out, my app will
finally work properly:

<context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value>
</context-param>


Thanks,
Ryan


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ryan de Laplante]

The javax.faces.STATE_SAVING_METHOD context-param in web.xml was a
duplicate.  Visual Web Pack put a ton of settings on one line including
this one, set to server.   Once I removed my dupe context-param and set
the first one to client, the weird unexplainable behaviors went away.  

So I would say yes Woodstock does require client side state saving for
some things to work properly.


Ryan


Ryan de Laplante wrote:

> I'm still having "fun" getting my real application to work like my
> test app.   It mostly works, but I find value change events firing
> multiple times first showing a null new value (correct) followed by
> the previous value being re-set.  I also see the value change events
> not firing in the same order as the test app.
>
> I'm thinking this has something to do with view state.  The test app
> shows a very long encoded view state in HTML output and AJAX requests,
> but the real app shows what appears to be a server side view state token:
>
> <input type="hidden" name="javax.faces.ViewState"
> id="javax.faces.ViewState" value="j_id7:j_id8" />
>
> I have added the following to my web.xml, and even restarted the app
> server, but it doesn't make a difference.  I can't get it to output an
> encoded view state.  Hopefully once I can figure that out, my app will
> finally work properly:
>
> <context-param>
>    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
>    <param-value>client</param-value>
> </context-param>
>
>
> Thanks,
> Ryan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ryan Lubke]

Ryan de Laplante wrote:
> The javax.faces.STATE_SAVING_METHOD context-param in web.xml was a
> duplicate.  Visual Web Pack put a ton of settings on one line
> including this one, set to server.   Once I removed my dupe
> context-param and set the first one to client, the weird unexplainable
> behaviors went away.
> So I would say yes Woodstock does require client side state saving for
> some things to work properly.
>
> Ryan
Something to consider: in Mojarra 1.2_05 and above there is an option to
serialize the view state to the session when using
server-side state saving.  See the 1.2_05 change log [1] for details on
the option.  

If you try it, I'd be interested knowing if it resolved your issue.  It
may be preferable to use over client state saving due to
the larger bandwidth usage associated with client state saving.

[1] https://javaserverfaces.dev.java.net/rlnotes/1.2_05/changelog.html

-rl

>
>
> Ryan de Laplante wrote:
>> I'm still having "fun" getting my real application to work like my
>> test app.   It mostly works, but I find value change events firing
>> multiple times first showing a null new value (correct) followed by
>> the previous value being re-set.  I also see the value change events
>> not firing in the same order as the test app.
>>
>> I'm thinking this has something to do with view state.  The test app
>> shows a very long encoded view state in HTML output and AJAX
>> requests, but the real app shows what appears to be a server side
>> view state token:
>>
>> <input type="hidden" name="javax.faces.ViewState"
>> id="javax.faces.ViewState" value="j_id7:j_id8" />
>>
>> I have added the following to my web.xml, and even restarted the app
>> server, but it doesn't make a difference.  I can't get it to output
>> an encoded view state.  Hopefully once I can figure that out, my app
>> will finally work properly:
>>
>> <context-param>
>>    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
>>    <param-value>client</param-value>
>> </context-param>
>>
>>
>> Thanks,
>> Ryan
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ryan de Laplante]

Ryan Lubke wrote:

> Ryan de Laplante wrote:
>> The javax.faces.STATE_SAVING_METHOD context-param in web.xml was a
>> duplicate.  Visual Web Pack put a ton of settings on one line
>> including this one, set to server.   Once I removed my dupe
>> context-param and set the first one to client, the weird
>> unexplainable behaviors went away. So I would say yes Woodstock does
>> require client side state saving for some things to work properly.
>>
>> Ryan
> Something to consider: in Mojarra 1.2_05 and above there is an option
> to serialize the view state to the session when using
> server-side state saving.  See the 1.2_05 change log [1] for details
> on the option.
> If you try it, I'd be interested knowing if it resolved your issue.  
> It may be preferable to use over client state saving due to
> the larger bandwidth usage associated with client state saving.
>
> [1] https://javaserverfaces.dev.java.net/rlnotes/1.2_05/changelog.html
>
> -rl

So set javax.faces.STATE_SAVING_METHOD to server again, and add a new
context-parm called com.sun.faces.serializeServerState set to true?

I  see that  SJSAS 9.1 UR2 uses JSF 1.2_04.   The update center doesn't
show an update for JSF 1.2_05.  Actually, the UC seems quite out of
date.  A lot of things in there are from almost a year ago such as
OpenESB  V2 Preview 3.    Any suggestions on how to install the latest
JSF?  Oh.. I just found a page suggesting I don't use the GlassFish
Update Center for the upgrade anyway, and to do a manual install.  I'll
try that out tomorrow:

https://javaserverfaces.dev.java.net/rlnotes/1.2_05/issues.html

Apparently I'll need to upgrade JAXP as well?


Thanks,
Ryan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ryan Lubke]

Ryan de Laplante wrote:

> Ryan Lubke wrote:
>> Ryan de Laplante wrote:
>>> The javax.faces.STATE_SAVING_METHOD context-param in web.xml was a
>>> duplicate.  Visual Web Pack put a ton of settings on one line
>>> including this one, set to server.   Once I removed my dupe
>>> context-param and set the first one to client, the weird
>>> unexplainable behaviors went away. So I would say yes Woodstock does
>>> require client side state saving for some things to work properly.
>>>
>>> Ryan
>> Something to consider: in Mojarra 1.2_05 and above there is an option
>> to serialize the view state to the session when using
>> server-side state saving.  See the 1.2_05 change log [1] for details
>> on the option. If you try it, I'd be interested knowing if it
>> resolved your issue.  It may be preferable to use over client state
>> saving due to
>> the larger bandwidth usage associated with client state saving.
>>
>> [1] https://javaserverfaces.dev.java.net/rlnotes/1.2_05/changelog.html
>>
>> -rl
> So set javax.faces.STATE_SAVING_METHOD to server again, and add a new
> context-parm called com.sun.faces.serializeServerState set to true?

Yep.
> I  see that  SJSAS 9.1 UR2 uses JSF 1.2_04.   The update center
> doesn't show an update for JSF 1.2_05.  Actually, the UC seems quite
> out of date.  A lot of things in there are from almost a year ago such
> as OpenESB  V2 Preview 3.    Any suggestions on how to install the
> latest JSF?  Oh.. I just found a page suggesting I don't use the
> GlassFish Update Center for the upgrade anyway, and to do a manual
> install.  I'll try that out tomorrow:
>
> https://javaserverfaces.dev.java.net/rlnotes/1.2_05/issues.html
The downloads section on the Mojarra
(https://javaserverfaces.dev.java.net) site has an updater for GlassFish.
Just run the updater and it will take care of the rest.
>
> Apparently I'll need to upgrade JAXP as well?
You shouldn't have to.  1.2_05's parsing leverages JAXP 1.3 which is
included in JDK 1.5.

>
>
> Thanks,
> Ryan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...