I double/triple checked that everything is cleared twice. Still the same 
problem...

I found out though that when dialog is launched via commandLink then when 
returning to returnListener method the pageFlowScope is clean. But when it is 
launched without commandLink and when coming back to returnListener theres 
stuff in pageFlowScope. Then when I call pageFlowScope.clear() theres still 
some children left... (Meaning theres something in the TokenCache) This might 
be the reason.

But how to get rid of the children?

S

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias 
Wessendorf
Sent: 30. syyskuuta 2008 11:49
To: MyFaces Discussion
Subject: Re: [Trinidad] Strange behaviour of the pageFlowScope

Hi,

>
> java.lang.IllegalArgumentException: Cannot convert com.xxx.ui.policy.
>
> [EMAIL PROTECTED] of type class com.xxx.ui.policy.mode
>
> l.UiModelA to class com.xxx.ui.policy.model.UiModelB
>
>         at com.sun.el.lang.ELSupport.coerceToType(ELSupport.java:381)
>
>         at com.sun.el.parser.AstValue.setValue(AstValue.java:164)
>
>         at
> com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:269)
>
>
>
>         at
> com.sun.facelets.el.TagValueExpression.setValue(TagValueExpression.ja
>
> va:93)
>
>         at
> com.sun.facelets.el.LegacyValueBinding.setValue(LegacyValueBinding.ja
>
> va:68)
>
>         at
> org.apache.myfaces.trinidad.event.SetActionListener.processAction(Set
>
> ActionListener.java:59)


here, in line 59, is where the "class cast exception" happens.
It tries to update an EL value (setValue()).

It would be worth to start a debugger to see
a) the EL string (#{bean.blah}
b) double check if something wasn't cleaned up

-Matthias

>
>         at
> javax.faces.event.ActionEvent.processListener(ActionEvent.java:51)
>
>         at
> org.apache.myfaces.trinidad.component.UIXComponentBase.broadcast(UIXC
>
> omponentBase.java:628)
>
>         at
> org.apache.myfaces.trinidad.component.UIXCommand.broadcast(UIXCommand
>
> .java:143)
>
>         at javax.faces.component.UIData.broadcast(UIData.java:517)
>
>         at javax.faces.component.UIData.broadcast(UIData.java:517)
>
>         at
> javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:9
>
> 7)
>
>         at
> javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1
>
> 71)
>
>         at
> org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(Invoke
>
> ApplicationExecutor.java:32)
>
>         at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl
>
> .java:95)
>
>         at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java
>
> :70)
>
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:139)
>
>         at
> com.profitsoftware.ui.CustomFacesServlet.service(CustomFacesServlet.j
>
> ava:44)
>
>         at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487
>
> )
>
>         at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
>
> Handler.java:1093)
>
>         at
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invoke
>
> DoFilter(TrinidadFilterImpl.java:250)
>
>         at
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilt
>
> erImpl(TrinidadFilterImpl.java:207)
>
>         at
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilte
>
> r(TrinidadFilterImpl.java:161)
>
>         at
> org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFi
>
> lter.java:92)
>
>         at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
>
> Handler.java:1084)
>
>         at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(Extensions
>
> Filter.java:301)
>
>         at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
>
> Handler.java:1084)
>
>         at
> com.profitsoftware.jaasutils.jetty.WLFilter$SecuredRequest.run(WLFilt
>
> er.java:72)
>
>         at java.security.AccessController.doPrivileged(Native Method)
>
>         at javax.security.auth.Subject.doAs(Subject.java:337)
>
>         at
> com.ibm.websphere.security.auth.WSSubject.doAs(WSSubject.java:118)
>
>         at
> com.profitsoftware.jaasutils.jetty.WLFilter$WASSecuredRequest.run(WLF
>
> ilter.java:49)
>
>         at weblogic.security.subject.SubjectProxy.doAs(SubjectProxy.java:64)
>
>         at
> weblogic.security.subject.SubjectManager.runAs(SubjectManager.java:26
>
> 2)
>
>         at weblogic.security.Security.runAs(Security.java:48)
>
>         at
> com.profitsoftware.jaasutils.jetty.WLFilter.doFilter(WLFilter.java:14
>
> 0)
>
>         at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
>
> Handler.java:1084)
>
>         at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
>
> 60)
>
>         at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.jav
>
> a:216)
>
>         at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:1
>
> 81)
>
>         at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:7
>
> 26)
>
>         at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
>
>
>
>         at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
>
> lerCollection.java:206)
>
>         at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
>
> java:114)
>
>         at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
>
> 52)
>
>         at org.mortbay.jetty.Server.handle(Server.java:324)
>
>         at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:50
>
> 5)
>
>         at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnectio
>
> n.java:842)
>
>         at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
>
>         at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>
>         at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
>
>         at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.ja
>
> va:395)
>
>         at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
>
> .java:450)
>
> ]
>
> ...
>
>
>
> Hope this helps.
>
>
>
> Santeri
>
>
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Matthias Wessendorf
> Sent: 29. syyskuuta 2008 19:28
> To: MyFaces Discussion
> Subject: Re: [Trinidad] Strange behaviour of the pageFlowScope
>
>
>
> On Mon, Sep 29, 2008 at 9:42 AM, Luhtala Santeri
>
> <[EMAIL PROTECTED]> wrote:
>
>> Hmm. Nobody seems to know or want share his/her knowledge about
>
>> pageFlowScope...
>
> :-) Not everybody is reading mails over the weekend ;-)
>
>>
>
>>
>
>>
>
>> Is there any decent documentation about this? I know the the docs in
>> Myfaces
>
>> site but they don't quite explain how and what happens with pageFlowScope
>
>> when navigating back and forth and if the dialog is not launched with some
>
>> action...
>
>
>
> the execption is caused by EL engine, when trying to use update
>
> incompatible values.
>
>
>
> Can you
>
> a) provide a more detailed stack trace
>
> b) some code examples that work and that don't work
>
>
>
> clear is just a java.util.Map.clear() delegation. So code would be good,
>
> to understand the problem better
>
>>
>
>>
>
>>
>
>> S
>
>>
>
>>
>
>>
>
>> ________________________________
>
>>
>
>> From: Luhtala Santeri
>
>> Sent: 26. syyskuuta 2008 9:21
>
>> To: MyFaces Discussion
>
>> Subject: [Trinidad] Strange behaviour of the pageFlowScope
>
>>
>
>>
>
>>
>
>> We have couple of pretty similar dialogs in our app. Stuff is passed to
>
>> dialog via pageFlowScope. In some situations the objects are passed using
>
>> tr:setActionListener-tag with commandLink and then the actual launching is
>
>> done in Java and in some cases the dialog is launched from Java-code and
>> the
>
>> values are set to pageFlowScope also there(So no commandLinks).
>
>>
>
>>
>
>>
>
>> I have a strange exception. If I have launched the dialog from Java-code
>> and
>
>> have set the values to pageFlowScope also there, then when I have done the
>
>> stuff in dialog and exit the dialog's scope and clear the pageFlowScope it
>
>> seems to clear it ok. But, when I open the other similar kind of
>> dialog(from
>
>> commandLink) then we crash with this:
>
>>
>
>> ....
>
>>
>
>> java.lang.IllegalArgumentException: Cannot convert com.xxx.ui.policy.
>
>>
>
>> [EMAIL PROTECTED] of type class com.xxx.ui.policy.model
>
>>
>
>> . UiModelA to class com.xxx.ui.policy.model.UiModelB
>
>>
>
>>         at com.sun.el.lang.ELSupport.coerceToType(ELSupport.java:381)
>
>>
>
>>         at com.sun.el.parser.AstValue.setValue(AstValue.java:164)
>
>>
>
>>         at
>
>> com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:269)
>
>>
>
>> ....
>
>>
>
>> When the dialog is launched via commandLink and values are set to
>
>> pageFlowScope with tr:setActionListener then theres no problem....!!!??? So
>
>> what does this tr:setActionListener do actually??
>
>>
>
>>
>
>>
>
>> We use the same 'key' (like "selected") when setting values to
>> pageFlowScope
>
>> with both dialogs. But this shouldn't matter? Right? And after all the
>
>> pageFlowScope is just some sort of Map. What does this
>> pageFlowScope.clear()
>
>> actually do? And how can this be dependent of the type? I don't get this...
>
>>
>
>>
>
>>
>
>> Santeri
>
>
>
>
>
>
>
> --
>
> Matthias Wessendorf
>
>
>
> blog: http://matthiaswessendorf.wordpress.com/
>
> sessions: http://www.slideshare.net/mwessendorf
>
> twitter: http://twitter.com/mwessendorf



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Reply via email to