Return-Path: Delivered-To: apmail-myfaces-users-archive@www.apache.org Received: (qmail 7728 invoked from network); 30 Sep 2008 14:27:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Sep 2008 14:27:33 -0000 Received: (qmail 53751 invoked by uid 500); 30 Sep 2008 14:27:27 -0000 Delivered-To: apmail-myfaces-users-archive@myfaces.apache.org Received: (qmail 53719 invoked by uid 500); 30 Sep 2008 14:27:27 -0000 Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Discussion" Delivered-To: mailing list users@myfaces.apache.org Received: (qmail 53708 invoked by uid 99); 30 Sep 2008 14:27:27 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Sep 2008 07:27:27 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mwessendorf@gmail.com designates 74.125.78.147 as permitted sender) Received: from [74.125.78.147] (HELO ey-out-1920.google.com) (74.125.78.147) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Sep 2008 14:26:24 +0000 Received: by ey-out-1920.google.com with SMTP id 4so15891eyg.24 for ; Tue, 30 Sep 2008 07:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=64SFozc93U3IKa6pMvEiKZSGNSSer7ZPttH7G/Kzfhs=; b=h/nbCGta9EkJ29IVgXB6drM4uopkgWUBNa3sGs50adtSgHLEPHihHGFr7z6csIBLdb R0vLkWY9pBbhtKUDLCPtsYwvAHd30wNXsrlnYie+957GIHiQM24RoXm8lhlO1gwfdITT 8lP7Poqp5EbKwdG+u2OMX9MZ1c0s/MgQDgm/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=aqzuccQgC7MNwI/kOOPucB61abK2qHMWGCU7Eg9XiM4g8a1Ncn9Tg7W08SDXz/u4HU kwSzPvBh+FV57AzhEKtb9+q7Y2QS8HPOw88w9dnxY/syLDQETAFfrJejNpR5CSJf+dxU 4zxlmVj9sdXzr0WDXtUiLczUwwQzbGwoAyRj0= Received: by 10.210.122.5 with SMTP id u5mr3283948ebc.90.1222784799986; Tue, 30 Sep 2008 07:26:39 -0700 (PDT) Received: by 10.210.112.3 with HTTP; Tue, 30 Sep 2008 07:26:39 -0700 (PDT) Message-ID: <71235db40809300726l503655cfhafac1c44b6c947b3@mail.gmail.com> Date: Tue, 30 Sep 2008 16:26:39 +0200 From: "Matthias Wessendorf" Sender: mwessendorf@gmail.com To: "MyFaces Discussion" Subject: Re: [Trinidad] Strange behaviour of the pageFlowScope In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <71235db40809290928q1d4f3903v8b641e22a5b4401@mail.gmail.com> <71235db40809300148g2d09cf08y95aa81dd7d4584c7@mail.gmail.com> X-Google-Sender-Auth: 0637c70507d03c2e X-Virus-Checked: Checked by ClamAV on apache.org 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 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: mwessendorf@gmail.com [mailto:mwessendorf@gmail.com] 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. >> >> model.UiModelA@15660c3 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: mwessendorf@gmail.com [mailto:mwessendorf@gmail.com] 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 >> >> 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. >> >>> >> >>> model.UiModelA@e73995 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