[
https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658206#action_12658206
]
boisvert edited comment on ODE-262 at 12/19/08 2:23 PM:
-------------------------------------------------------------
I am concerned about the name change from CorrelationKeySet to CorrelationKeys
since this class is serializable and is in fact serialized in the
CorrelationNoMatchEvent as well as Selector. The Selector class is actually
serialized as part of the Jacob state which does not use standard Java
serialization (it "compresses" the state and discard some of the serialization
headers)
I think it may be wise to revert the commit and review the code further until
we have fully reviewed and tested to some extent, the backward compatibility
aspects.
was (Author: boisvert):
I am concerned about the name change from CorrelationKeySet to
CorrelationKeys since this class is serializable and is in fact serialized in
the CorrelationNoMatchEvent as well as Selector. The Selector class is
actually serialized as part of the Jacob state which does not use Java
serialization.
I think it may be wise to revert the commit and review the code further until
we have fully reviewed and tested to some extent, the backward compatibility
aspects.
> Duplicated correlation set values is accepted and creates a second instance
> instead of throwing an exception
> ------------------------------------------------------------------------------------------------------------
>
> Key: ODE-262
> URL: https://issues.apache.org/jira/browse/ODE-262
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Affects Versions: 1.1.1
> Environment: Apache ODE 1.1.1 or 1.2
> Tomcat
> The counter example of infoq.
> Reporter: Amin Anjomshoaa
> Assignee: Karthick Sankarachary
> Fix For: 2.0
>
> Attachments: unique-correlation-set-for-branch.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The classical counter example of infoq
> (http://www.infoq.com/articles/paul-brown-ode) can be used. Sending the
> "init" message for the second (third, fourth, ... ) time with the value "foo"
> will create a new instance. I was expecting a CorrelationViolation exception
> when the second init message is arriving.
> All upcoming messages are then correlated with the last instance only.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
