[esb-issues] [JBoss JIRA] Updated: (JBESB-3574) EPRHelper modifies EPRs when serialising to XML
[
https://issues.jboss.org/browse/JBESB-3574?page=com.atlassian.jira.plugin...
]
Kevin Conner updated JBESB-3574:
--------------------------------
Attachment: invm_3574.zip
Attached is a quickstart which replicates the concurrent failures but this only works if
the logging is correct.
There is a debug statement in ServiceInvoker which, if enabled, invoked the EPRHelper
method under test. As such it is important that the level for ESB classes should be set
to INFO and not DEBUG.
The test will display messages on STDOUT, similar to the following
2011-03-18 11:56:52,575 INFO [STDOUT] Creating a barrier for 2 parties
2011-03-18 11:57:08,601 INFO [STDOUT] Getting extension iterator
2011-03-18 11:57:08,602 INFO [STDOUT] EPR is InVMEpr [ PortReference < <wsa:Address
invm://494e564d2424242424242424242424245465737433353734/false?false#10000/>,
<wsa:ReferenceProperties jbossesb:passByValue : false/> > ]
2011-03-18 11:57:08,602 INFO [STDOUT] Waiting on the barrier
2011-03-18 11:57:08,610 INFO [STDOUT] Getting extension iterator
2011-03-18 11:57:08,610 INFO [STDOUT] EPR is InVMEpr [ PortReference < <wsa:Address
invm://494e564d2424242424242424242424245465737433353734/false?false#10000/>,
<wsa:ReferenceProperties jbossesb:passByValue : false/> > ]
2011-03-18 11:57:08,610 INFO [STDOUT] Waiting on the barrier
2011-03-18 11:57:08,610 INFO [STDOUT] Waiting for a second time on the barrier
2011-03-18 11:57:08,610 INFO [STDOUT] First at barrier, calling EPRHelper.toXMLString
2011-03-18 11:57:08,610 INFO [STDOUT] Waiting for a second time on the barrier
2011-03-18 11:57:08,610 INFO [STDOUT] Getting first extension from iterator
2011-03-18 11:57:08,610 INFO [STDOUT] FAIL: Triggered ConcurrentModificationException
2011-03-18 11:57:08,611 INFO [STDOUT] Getting first extension from iterator
2011-03-18 11:57:08,611 INFO [STDOUT] FAIL: Triggered ConcurrentModificationException
with each concurrent thread logging a FAIL message if the ConcurrentModificationException
occurs.
Running the test for a second time (without redeployment) will show SUCCESS rather than
FAIL as the EPR has already been modified by the previous execution.
EPRHelper modifies EPRs when serialising to XML
-----------------------------------------------
Key: JBESB-3574
URL: https://issues.jboss.org/browse/JBESB-3574
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.7 CP2
Reporter: Kevin Conner
Assignee: Tom Cunningham
Attachments: diffs.3574, invm_3574.zip
The setSpecificEPR initialises a type extension if one is not already present, but this
cannot be done safely.
Any modifications to an EPR should only be done at the construction point, as it is the
creator who is responsible for doing this.
I'll attach a diff which configures the type on construction, but we should also
consider updating the EPR classes to throw exceptions if modifications are made after the
creator has finished with their construction.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira