It would be worth to start a debugger to see
a) what the EL string is like (e.g. #{bean.blah})On Tue, Sep 30, 2008 at 3:43 PM, Luhtala Santeri <[EMAIL PROTECTED]> wrote: > 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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
