[
https://issues.apache.org/jira/browse/MUSE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Twiner resolved MUSE-298.
-------------------------------
Resolution: Fixed
fix in head. Check for the wrapping element being the
WefConstants.COMP_ADDRESS_QNAME, if it is then unpack the first child (the
EPR). Also disable the whole this(null) constructor thing.
> SimpleComponentAddress - doesn't extract the component address from the
> contents when using the "parsing" constructor
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: MUSE-298
> URL: https://issues.apache.org/jira/browse/MUSE-298
> Project: Muse
> Issue Type: Bug
> Components: WSDM Event Format (WEF)
> Affects Versions: 2.2.0
> Reporter: Chris Twiner
> Assignee: Chris Twiner
> Priority: Blocker
> Fix For: 2.2.1
>
>
> When serializing to string (for example sending to a consumer) the serialize
> works as expected. However the parse on the consumer (or indeed via another
> producer component) keeps the ComponentAddress as the top element, not the
> EPR. Any following serializations therefore include multiple
> ComponentAddresses:
> http://www.nabble.com/Problem-Generating-Management-Events-from-DOM-Elements.-td15139782.html
> <muws1:SourceComponent>
> <muws1:ComponentAddress>
> <muws1:ComponentAddress>
> <wsa:EndpointReference
> xmlns:wsa="http://www.w3.org/2005/08/addressing"
> xmlns:wsa="http://www.w3.org/2005/08/addressing">
>
> <wsa:Address>http://localhost/my-resources/services/event-publisher</wsa:Address>
> </wsa:EndpointReference>
> </muws1:ComponentAddress>
> </muws1:ComponentAddress>
> </muws1:SourceComponent>
> I have verififed that the other WEF components don't seem to suffer from this
> issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]