Spring Operator

**[Rossen Stoyanchev](https://jira.spring.io/secure/ViewProfile.jspa?name=rstoya05-aop)** commented A JSF ResourceImpl is getting serialized and stored with the custom component and it looks like its custom deserialization method (`readExternal`) relies on FacesContext. However, a FacesContext...

**[Pelz Rutsche](https://jira.spring.io/secure/ViewProfile.jspa?name=pelzrutsche)** commented Thanks a lot for the detailed information. I voted for JAVASERVERFACES-1690 and hopefully the fix will make it into the next release. My current workaround uses a...

**[Rossen Stoyanchev](https://jira.spring.io/secure/ViewProfile.jspa?name=rstoya05-aop)** commented Linking to #185 as it seems much of the discussion around a view-level PersistenceContext ends up bringing up the limitation of not being able to re-use a...

**[Erwin Vervaet](https://jira.spring.io/secure/ViewProfile.jspa?name=klr8)** commented The problem is that the object in the serialized continuation snapshot still refers to the old class, before it was updated. We have seen this issue before...

**[Graeme Rocher](https://jira.spring.io/secure/ViewProfile.jspa?name=graemerocher)** commented As I mentioned in the post, a workaround from my perspective would be to be able to invalidate all serialized flows stored in the repository. This is...

**[Erwin Vervaet](https://jira.spring.io/secure/ViewProfile.jspa?name=klr8)** commented Do you think a 'clear' call via JMX would be sufficient? #122 is asking for something like that.

**[Graeme Rocher](https://jira.spring.io/secure/ViewProfile.jspa?name=graemerocher)** commented So you want users to clear flows via some JMX management console? No I need a programmatic way to do it.

**[Antranig Basman](https://jira.spring.io/secure/ViewProfile.jspa?name=bosmon)** commented The particular root exception class seems "highly recognisable", and it would seem reasonably straightforward to diagnose this situation by walking the "cause" stack and invalidate just the...

**[Rossen Stoyanchev](https://jira.spring.io/secure/ViewProfile.jspa?name=rstoya05-aop)** commented > an external request, by default, causes a new execution key to be created, so only higher-scoped information (e.g. Session) would even be available, correct? The number...

**[Doug Breaux](https://jira.spring.io/secure/ViewProfile.jspa?name=breaux)** commented Thanks, but it seems like even if more executions are allowed, an external/direct link to the flow - even if it explicitly specifies an existing execution key...