You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Luhtala Santeri <Sa...@profitsoftware.com> on 2008/09/26 08:20:47 UTC
[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
RE: [Trinidad] Strange behaviour of the pageFlowScope
Posted by Luhtala Santeri <Sa...@profitsoftware.com>.
Ahh. A little correction to my previous mail.
To be more precise, we have two kinds of dialogs. The ones that are launched from links that are inside tables and the ones that are not in tables.
The ones that are not launched from a link in a table seem to work what comes to returnListener even when launched purely from Java without actionEvent. But these dialogs are also the ones that 'cause'
the IllegalArgumentException.
So after making the previously mentioned redirect to ext system from this kind of dialog and then after coming back trying to launch any other dialog from commandLink causes the exception.
S
________________________________
From: Luhtala Santeri
Sent: 30. syyskuuta 2008 10:25
To: MyFaces Discussion
Subject: RE: [Trinidad] Strange behaviour of the pageFlowScope
Hi
What a relief that somebody tries to help :-)
This is a complex thingy but I try to keep this short.
First of all. This works. Return listeners, pageFlowscope, everything is fine.
This is the jspx code:
(This is inside h:dataTable which is inside another h:dataTable)
...
<tr:commandLink
id="Link"
action="#{DialogBean.showDetails}"
useWindow="true"
partialSubmit="true"
binding="#{Bean.DialogLauncher}"
returnListener="#{Bean.handleReturnFromDialog}"
>
<tr:setActionListener from="#{value}" to="#{pageFlowScope.original}" />
<tr:setActionListener from="#{parent.values}" to="#{pageFlowScope.allValues}" />
<tr:setActionListener from="#{parent}" to="#{pageFlowScope.parentOriginal}" />
<tr:setActionListener from="#{Bean.parents}" to="#{pageFlowScope.parentAllValues}" />
<tr:setActionListener from="#{'edit'}" to="#{pageFlowScope.mode}"/>
<h:outputText value="#{value.LinkText}" styleClass="data_text data_underline"/>
</tr:commandLink>
...
This is the actual launching code:
(This is just basic stuff. The launcherCommand is the binded UIXCommand -> see binding attribute above...)
...
requestContext.launchDialog(dialog,
dialogParams,
launherCommand,
true, // show it in a window
windowProperties);
...
So to put it short. When everything is done via tr:commandLink and using tr:setActionListener it works.
But we have a situation if the user clicks a link in that dialog then we close the dialog and redirect to a another system(non-JSF external system) and when we come back from there we want to go to the same situation where we were before the redirect.
So in this situation we first navigate to the 'main' page in question and then from Java code launch the dialog. Then theres no actionEvent or source or tr:setActionListener. That is where the problems start to pile up. Can't get returnListener to work, don't know how to make those valueBindings work like when they are done with tr:setActionListener, pageFlowScope acts strange.
Heres the 'set-up' code before the launching of dialog. The actual launching code is the same.
(just setting the needed stuff in pageFlowScope 'by hand')
...
requestContext.getPageFlowScope().put("parentAllValues", getParents());
requestContext.getPageFlowScope().put("parentOriginal", getParents().get(originalParentIndex));
requestContext.getPageFlowScope().put("mode", "edit");
requestContext.getPageFlowScope().put("allValues", getParents().get(originalParentIndex).getValues());
requestContext.getPageFlowScope().put("original", getParents().get(originalParentIndex).getValues().get(originalIndex));
//This is new stuff from ext system
requestContext.getPageFlowScope().put("copy", newBenUiModel);
//Launch the Dialog
((DialogBean)FacesContextUtils.getWebApplicationContext(FacesContext.getCurrentInstance())
.getBean("DialogBean")).showDetails();
...
And after this kind of dialog launch if I try to open any other dialog I end up with this:
...
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)
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
<Sa...@profitsoftware.com> 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
RE: [Trinidad] Strange behaviour of the pageFlowScope
Posted by Luhtala Santeri <Sa...@profitsoftware.com>.
Ok. Ill try to file an issue. And provide some understandable description/test case.
S
-----Original Message-----
From: mwessendorf@gmail.com [mailto:mwessendorf@gmail.com] On Behalf Of Matthias Wessendorf
Sent: 1. lokakuuta 2008 14:11
To: MyFaces Discussion
Subject: Re: [Trinidad] Strange behaviour of the pageFlowScope
On Wed, Oct 1, 2008 at 8:02 AM, Luhtala Santeri
<Sa...@profitsoftware.com> wrote:
> Ok. Sorry. I checked that also and it seems ok.
> The 'to' EL string is "#{pageFlowScope.original}".
I wonder why it still checks the base type and therefore throws the exception.
Is it possible to a) file a jira issue and b) create a *simple*
re-produceable test-case?
That makes it easier to debug the issue.
That said I am not really free (in meaning of time) to jump in right now
-M
>
> S
>
> -----Original Message-----
> From: mwessendorf@gmail.com [mailto:mwessendorf@gmail.com] On Behalf Of Matthias Wessendorf
> Sent: 30. syyskuuta 2008 17:27
> To: MyFaces Discussion
> Subject: Re: [Trinidad] Strange behaviour of the pageFlowScope
>
> 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
> <Sa...@profitsoftware.com> 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
>>>
>>> <Sa...@profitsoftware.com> 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
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [Trinidad] Strange behaviour of the pageFlowScope
Posted by Matthias Wessendorf <ma...@apache.org>.
On Wed, Oct 1, 2008 at 8:02 AM, Luhtala Santeri
<Sa...@profitsoftware.com> wrote:
> Ok. Sorry. I checked that also and it seems ok.
> The 'to' EL string is "#{pageFlowScope.original}".
I wonder why it still checks the base type and therefore throws the exception.
Is it possible to a) file a jira issue and b) create a *simple*
re-produceable test-case?
That makes it easier to debug the issue.
That said I am not really free (in meaning of time) to jump in right now
-M
>
> S
>
> -----Original Message-----
> From: mwessendorf@gmail.com [mailto:mwessendorf@gmail.com] On Behalf Of Matthias Wessendorf
> Sent: 30. syyskuuta 2008 17:27
> To: MyFaces Discussion
> Subject: Re: [Trinidad] Strange behaviour of the pageFlowScope
>
> 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
> <Sa...@profitsoftware.com> 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
>>>
>>> <Sa...@profitsoftware.com> 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
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
RE: [Trinidad] Strange behaviour of the pageFlowScope
Posted by Luhtala Santeri <Sa...@profitsoftware.com>.
Ok. Sorry. I checked that also and it seems ok.
The 'to' EL string is "#{pageFlowScope.original}".
S
-----Original Message-----
From: mwessendorf@gmail.com [mailto:mwessendorf@gmail.com] On Behalf Of Matthias Wessendorf
Sent: 30. syyskuuta 2008 17:27
To: MyFaces Discussion
Subject: Re: [Trinidad] Strange behaviour of the pageFlowScope
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
<Sa...@profitsoftware.com> 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
>>
>> <Sa...@profitsoftware.com> 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
Re: [Trinidad] Strange behaviour of the pageFlowScope
Posted by Matthias Wessendorf <ma...@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
<Sa...@profitsoftware.com> 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
>>
>> <Sa...@profitsoftware.com> 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
RE: [Trinidad] Strange behaviour of the pageFlowScope
Posted by Luhtala Santeri <Sa...@profitsoftware.com>.
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
>
> <Sa...@profitsoftware.com> 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
Re: [Trinidad] Strange behaviour of the pageFlowScope
Posted by Matthias Wessendorf <ma...@apache.org>.
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
>
> <Sa...@profitsoftware.com> 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
RE: [Trinidad] Strange behaviour of the pageFlowScope
Posted by Luhtala Santeri <Sa...@profitsoftware.com>.
Hi
What a relief that somebody tries to help :-)
This is a complex thingy but I try to keep this short.
First of all. This works. Return listeners, pageFlowscope, everything is fine.
This is the jspx code:
(This is inside h:dataTable which is inside another h:dataTable)
...
<tr:commandLink
id="Link"
action="#{DialogBean.showDetails}"
useWindow="true"
partialSubmit="true"
binding="#{Bean.DialogLauncher}"
returnListener="#{Bean.handleReturnFromDialog}"
>
<tr:setActionListener from="#{value}" to="#{pageFlowScope.original}" />
<tr:setActionListener from="#{parent.values}" to="#{pageFlowScope.allValues}" />
<tr:setActionListener from="#{parent}" to="#{pageFlowScope.parentOriginal}" />
<tr:setActionListener from="#{Bean.parents}" to="#{pageFlowScope.parentAllValues}" />
<tr:setActionListener from="#{'edit'}" to="#{pageFlowScope.mode}"/>
<h:outputText value="#{value.LinkText}" styleClass="data_text data_underline"/>
</tr:commandLink>
...
This is the actual launching code:
(This is just basic stuff. The launcherCommand is the binded UIXCommand -> see binding attribute above...)
...
requestContext.launchDialog(dialog,
dialogParams,
launherCommand,
true, // show it in a window
windowProperties);
...
So to put it short. When everything is done via tr:commandLink and using tr:setActionListener it works.
But we have a situation if the user clicks a link in that dialog then we close the dialog and redirect to a another system(non-JSF external system) and when we come back from there we want to go to the same situation where we were before the redirect.
So in this situation we first navigate to the 'main' page in question and then from Java code launch the dialog. Then theres no actionEvent or source or tr:setActionListener. That is where the problems start to pile up. Can't get returnListener to work, don't know how to make those valueBindings work like when they are done with tr:setActionListener, pageFlowScope acts strange.
Heres the 'set-up' code before the launching of dialog. The actual launching code is the same.
(just setting the needed stuff in pageFlowScope 'by hand')
...
requestContext.getPageFlowScope().put("parentAllValues", getParents());
requestContext.getPageFlowScope().put("parentOriginal", getParents().get(originalParentIndex));
requestContext.getPageFlowScope().put("mode", "edit");
requestContext.getPageFlowScope().put("allValues", getParents().get(originalParentIndex).getValues());
requestContext.getPageFlowScope().put("original", getParents().get(originalParentIndex).getValues().get(originalIndex));
//This is new stuff from ext system
requestContext.getPageFlowScope().put("copy", newBenUiModel);
//Launch the Dialog
((DialogBean)FacesContextUtils.getWebApplicationContext(FacesContext.getCurrentInstance())
.getBean("DialogBean")).showDetails();
...
And after this kind of dialog launch if I try to open any other dialog I end up with this:
...
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)
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
<Sa...@profitsoftware.com> 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
Re: [Trinidad] Strange behaviour of the pageFlowScope
Posted by Matthias Wessendorf <ma...@apache.org>.
On Mon, Sep 29, 2008 at 9:42 AM, Luhtala Santeri
<Sa...@profitsoftware.com> 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
RE: [Trinidad] Strange behaviour of the pageFlowScope
Posted by Luhtala Santeri <Sa...@profitsoftware.com>.
Hmm. Nobody seems to know or want share his/her knowledge about pageFlowScope...
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...
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