Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?

2014-02-21 Thread user 01
Sorry to bug you all again.. I am still seeking a clarification on above
 points.. if anyone can please enlighten me.

Thanks.


On Sat, Feb 15, 2014 at 1:29 AM, user 01 user...@gmail.com wrote:

 Can some one please clarify What is this attributes map otherwise really
 meant for? Is it to maintain JSF internal viewstate ?


 On Fri, Feb 14, 2014 at 1:31 AM, user 01 user...@gmail.com wrote:

 Thanks a lot Leonardo for the solution. Played somewhat with it, looks
 like it'll works for me. The data survives session destroys.

 What is this attributes map otherwise really meant for, to maintain JSF
 internal viewstate ? Is it safe for me to use it like that ? Looks like a
 hack infact:)

 I could use the attributes map to store values/ objects, can't I just use
 this map to store the viewscoped beans simply?


 On Thu, Feb 13, 2014 at 11:05 AM, Leonardo Uribe lu4...@gmail.comwrote:

 Hi

 In JSF 2.2 it was decided to store view scope beans always in session
 (take a look at the description of @ViewScoped annotation in the
 javadoc). But you can just call facesContext.getViewRoot() and use the
 attribute map. Just remember the values there must be Serializable or
 implement StateHolder.

 In my understanding, this was done in this way to support @PreDestroy
 annotation when the session is expired.

 regards,

 Leonardo Uribe



 2014-02-12 23:28 GMT-05:00 user 01 user...@gmail.com:
  I'm using Myfaces 2.2 with Client-side state saving. I see that the
  ViewScoped beans  data stored in viewmap is lost after the user
 session is
  destroyed.
  I came to know, not sure if it is correct, that this is the expected
  behavior but then what's the way to avoid view expired exceptions after
  session destroy?
 
  My problem is that I destroy the user session pretty quickly after some
  inactivity period(like after 20 minutes) but I want the viewscope data
 to
  survive even after that(when using client saving) so that when the user
  comes back after session destroy, he doesn't need to do a page
 refresh. I
  dont know why  how this is so implemented but It is very normal that
 the
  user may be busy reading some section of website or be away for 20
 minutes,
   as he comes back  interacts with opened pages, how would I make that
  work without the state ?
  I think this is a common requirement for any public websites.
 
  I think the internally used jsf viewstate is not lost, if I use client
 side
  state saving(as my pages still work), but then why are those viewscoped
  beans scoped that were also serialized to page along with the
 viewstate.
 
  If this the designed behavior, Is there any way I could make the view
  scoped data survive session expiration ?






Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?

2014-02-21 Thread Thomas Andraschko
It's just a map to add data - like ViewState.
In JSF 2.0 and JSF 2.1, it was used to directly store the ViewScoped beans.

Don't know about more internals.


2014-02-21 21:42 GMT+01:00 user 01 user...@gmail.com:

 Sorry to bug you all again.. I am still seeking a clarification on above
  points.. if anyone can please enlighten me.

 Thanks.


 On Sat, Feb 15, 2014 at 1:29 AM, user 01 user...@gmail.com wrote:

  Can some one please clarify What is this attributes map otherwise really
  meant for? Is it to maintain JSF internal viewstate ?
 
 
  On Fri, Feb 14, 2014 at 1:31 AM, user 01 user...@gmail.com wrote:
 
  Thanks a lot Leonardo for the solution. Played somewhat with it, looks
  like it'll works for me. The data survives session destroys.
 
  What is this attributes map otherwise really meant for, to maintain JSF
  internal viewstate ? Is it safe for me to use it like that ? Looks like
 a
  hack infact:)
 
  I could use the attributes map to store values/ objects, can't I just
 use
  this map to store the viewscoped beans simply?
 
 
  On Thu, Feb 13, 2014 at 11:05 AM, Leonardo Uribe lu4...@gmail.com
 wrote:
 
  Hi
 
  In JSF 2.2 it was decided to store view scope beans always in session
  (take a look at the description of @ViewScoped annotation in the
  javadoc). But you can just call facesContext.getViewRoot() and use the
  attribute map. Just remember the values there must be Serializable or
  implement StateHolder.
 
  In my understanding, this was done in this way to support @PreDestroy
  annotation when the session is expired.
 
  regards,
 
  Leonardo Uribe
 
 
 
  2014-02-12 23:28 GMT-05:00 user 01 user...@gmail.com:
   I'm using Myfaces 2.2 with Client-side state saving. I see that the
   ViewScoped beans  data stored in viewmap is lost after the user
  session is
   destroyed.
   I came to know, not sure if it is correct, that this is the expected
   behavior but then what's the way to avoid view expired exceptions
 after
   session destroy?
  
   My problem is that I destroy the user session pretty quickly after
 some
   inactivity period(like after 20 minutes) but I want the viewscope
 data
  to
   survive even after that(when using client saving) so that when the
 user
   comes back after session destroy, he doesn't need to do a page
  refresh. I
   dont know why  how this is so implemented but It is very normal that
  the
   user may be busy reading some section of website or be away for 20
  minutes,
as he comes back  interacts with opened pages, how would I make
 that
   work without the state ?
   I think this is a common requirement for any public websites.
  
   I think the internally used jsf viewstate is not lost, if I use
 client
  side
   state saving(as my pages still work), but then why are those
 viewscoped
   beans scoped that were also serialized to page along with the
  viewstate.
  
   If this the designed behavior, Is there any way I could make the view
   scoped data survive session expiration ?
 
 
 
 



2.2.0 and multipart

2014-02-21 Thread Leonardo K. Shikida
Hi

Just noticed this thread about tomee, myfacs 2.2.0 and multipart request

stackoverflow.com/questions/21948228/how-to-get-jsf-file-upload-to-work-on-tomee-1-6

does anyone know if between 2.1.13 and 2.2.0, multipart request has got any
new bug? could not find anything in JIRA

the guy who posted the stackoverflow question tested with

h:commandButton while I've reproduced the problem just switching
myfaces jars from vanilla tomee 1.6.0 from 2.1.13 to 2.2.0 and using
p:fileUpload

[]

Leo