Initial tests of the sample jsps in my environment were a little bumpy...
(probably something due to the RAD / IBM'ized version of JSF i'm using i'm
guessing
(Sun RI 1.1_02 with jsf-ibm.jar) tomahawk 1.1.5 and sandbox 1.1.5
Appears as if there is some contention with the viewhandlers..... when the
conversation trys to initiate something has already commited some response
somewhere..
I'm sure it's just my environment but I don't have that much time to debug
now. :(
Oh well maybe i'll get to it later.
Thank you again!
[Servlet.LOG]: /test/conversation/pageConversation.jsp: init
[10/16/06 10:43:41:255 CDT] 39111561 SystemOut O 10:43:41
[ApplicationImpl.setViewHandler() Line:129] ERROR: - Response for this
request has been rendered already
[10/16/06 10:43:42:607 CDT] 39111561 WebGroup E SRVE0026E: [Servlet
Error]-[Illegal attempt to set ViewHandler after a response has been
generated.]: java.lang.IllegalStateException: Illegal attempt to set
ViewHandler after a response has been generated.
at
com.sun.faces.application.ApplicationImpl.setViewHandler(ApplicationImpl.java:132)
at
org.apache.myfaces.custom.conversation.UIStartConversation.setupConversationSystem(UIStartConversation.java:102)
at
org.apache.myfaces.custom.conversation.UIStartConversation.encodeBegin(UIStartConversation.java:64)
Martin Marinschek wrote:
>
> And indeed, its just great.
>
> What's missing, is a short section on the Wiki describing how to use
> ORM-functionality (like Hibernate) with the conversation. Mario, do
> you have any time adding this?
>
> regards,
>
> Martin
>
> On 10/16/06, Nenz <[EMAIL PROTECTED]> wrote:
>>
>> Ahh okay.. thanks for the details!
>>
>> Sounds like something, albeit more advanced, then what I was trying to do
>> with a Phase listener approach maintaining session objects via viewIds
>> and
>> "rules" and destroying as necessary according to these parameters as well
>> as
>> using servlet filters for the rest of the cleanup I needed.
>>
>> Worked very well for current view (ie.. page reloads) and simple 2 pages
>> list / detail relationships... but for a true "process scope", I quickly
>> realized this I may have bit off more then I could chew!! :)
>>
>> I'm going to give the samples a shot now and if they work well implement
>> them on a more extreme level!
>>
>> Thank you very much!
>>
>>
>>
>>
>>
>>
>>
>> Werner Punz wrote:
>> >
>> > Nenz schrieb:
>> >> Looks great! Just what I need.
>> >>
>> >> Finally something to help us abstract the joys of "process scope" in a
>> >> web
>> >> app. I truely believe we have taken the (stateless) protocol itself
>> well
>> >> beyond what it was originally intended to do, thus all the hacks we
>> are
>> >> having to do to get around a fundamental "flaw" as opposed to perhaps
>> >> developing a new protocol itself (I know that's a much bigger
>> >> conversation)
>> >>
>> >> Not knowing the inner workings of this other then it uses a filter,
>> are
>> >> there any differences between using server state saving / client state
>> >> saving... the Sun RI vs MyFaces Impl?
>> >>
>> >> I guess the true question is ... on a high level.. how is this
>> >> maintaining
>> >> state... I'm assuming it's either swapping session or serializing
>> objects
>> >> in
>> >> hidden form fields and using url parms to further maintain this info?
>> >>
>> >> Thanks!
>> >>
>> >>
>> > Mario may correct me if I am wrong since I know the mechanisms only
>> from
>> > long Discussions I had with him, he basically was starting the thing
>> > when I gave him the idea on a tag I once did which was a savestate
>> > replacment which used the session directly instead of going the
>> > savestate route.
>> > And what he did was some genious kind of work indeed.
>> >
>> > What it does as I assume is saving the affected objects into the
>> session
>> > and using a servlet filter for the garbage collecting the objects.
>> >
>> > Hence pure client side savestating still will push those objects into
>> > the session, as I assume, the rest of the functionality is built around
>> > this idea.
>> >
>> > I dont know how far mario has driven the idea, from an earlier
>> > discussion we had on this one, it was clear some generic orm sesssion
>> > handler interface for orm mappers also must be integrated to ease the
>> > burdens on the orm using people. I am not sure how far mario has driven
>> > this by now.
>> >
>> > The whole thing was thought originally to replace the basic scope
>> > mechanisms of seam which are excellent ideawise, but too strongly bound
>> > to ejb3, with a tag based approach, which we both liked from savestate,
>> > so that you neither have to deal with EJB3 on a server level nor with
>> > xml configuration graves like other scope approaches follow.
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Save---restore-state-of-entire-view--tf2443158.html#a6835446
>> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>>
>>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
--
View this message in context:
http://www.nabble.com/Save---restore-state-of-entire-view--tf2443158.html#a6837465
Sent from the MyFaces - Users mailing list archive at Nabble.com.
