If you can post a patch against the ui example in CVS head to demonstrate this
I will take a look and see if we can do something to help in Seam.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4076244#4076244
Reply to the post :
http://www.jboss.com/index.htm
This is causing us troubles too. I can see that the JSF spec allows it, but
it's one of those things where the integration between JSF and Hibernate is not
SEAMless at all... it should just work, and it just doesn't, so it pollutes
our application with code to deal with maintaining the lists.
I'm not sure why it replaces it, but thats not really the point - the point is
that the JSF spec allows it to do this (it doesn't say - if there is an already
existing List, then remove all its elements and add new ones). This may be a
flaw in the spec (I'm not sure it is) but we can't address
>This is well within the contract for JSF - It simply says that the value
>attribute of the UISelectMany should be an array or List - it doesn't say that
>it is a PersistentBag.
PersistentBag is an implementation of java.util.List and i don't see any need
in a replacement of an existing and no
Seems related to this:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=49
HTH.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059610#4059610
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059610
_
This is well within the contract for JSF - It simply says that the value
attribute of the UISelectMany should be an array or List - it doesn't say that
it is a PersistentBag.
So, yes, the UISelectMany did replace the collection, as it is allowed to do.
The only work around I can see is to deal
