You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "Jürgen Schumacher (JIRA)" <ji...@apache.org> on 2009/02/02 09:57:59 UTC
[jira] Created: (ODE-503) Multithreading issue in
...rtrep.v2.EXTENSIONACTIVITY
Multithreading issue in ...rtrep.v2.EXTENSIONACTIVITY
-----------------------------------------------------
Key: ODE-503
URL: https://issues.apache.org/jira/browse/ODE-503
Project: ODE
Issue Type: Bug
Components: BPEL Runtime
Affects Versions: 2.0
Reporter: Jürgen Schumacher
Fix For: 2.0
We have experienced a problem in the execution of extension activities. I suppose it's caused by two process instances of the same BPEL process that invoke a single extension activity at the same time that has not yet been executed since hydration.
The error stacktrace is something like this:
java.lang.IllegalArgumentException: type: -1
at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject(Unknown Source)
at org.apache.xerces.dom.DeferredElementNSImpl.synchronizeData(Unknown Source)
at org.apache.xerces.dom.ElementNSImpl.getNamespaceURI(Unknown Source)
at org.apache.ode.utils.DOMUtils.getElementQName(DOMUtils.java:691)
at org.apache.ode.bpel.rtrep.v2.EXTENSIONACTIVITY.run(EXTENSIONACTIVITY.java:51)
...
(sometimes it's a NullPointerException instead)
This line 51 is
final QName extensionId = DOMUtils.getElementQName(_oext.nestedElement.getElement());
I searched for "java.lang.IllegalArgumentException at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject" and found an older message in the xerces mailing list suggesting that the cause for this could be that the DOM implementation is not thread-safe. So I did a little patch in org.apache.ode.utils.SerializableElement and added a line to readObject(...):
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException {
try {
e = DOMUtils.stringToDOM((String)in.readObject());
DOMUtils.getElementQName(e); // <-- this one is new
...
Now the error doesn't occur anymore (as far as I can tell), because whatever is changed in the DOM object during the first access of the element's QName has already changed during process hydration and the first invocation does only read the DOM object.
This is probably the most simple way to fix the issue, but there may be better possibilities (maybe reading the QName from the nested DOM during instance creation/deserialization of EXTENSIONACTIVITY and storing it for later access in a member variable? that would be also a small performance improvement), but I'll leave this decision to you. I can also provide a proper patch if you tell me which way to go.
Cheers,
Juergen
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-503) Multithreading issue in
...rtrep.v2.EXTENSIONACTIVITY
Posted by "Tammo van Lessen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673355#action_12673355 ]
Tammo van Lessen commented on ODE-503:
--------------------------------------
Hi Jürgen,
agreed :) Pushing people to do the synchronization when necessary seems reasonable. I just committed a change, would be great if you guys could give it a try and let me know how that worked.
Cheers,
Tammo
> Multithreading issue in ...rtrep.v2.EXTENSIONACTIVITY
> -----------------------------------------------------
>
> Key: ODE-503
> URL: https://issues.apache.org/jira/browse/ODE-503
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Affects Versions: 2.0
> Reporter: Jürgen Schumacher
> Assignee: Tammo van Lessen
> Fix For: 2.0
>
> Attachments: ODE-503.patch
>
>
> We have experienced a problem in the execution of extension activities. I suppose it's caused by two process instances of the same BPEL process that invoke a single extension activity at the same time that has not yet been executed since hydration.
> The error stacktrace is something like this:
> java.lang.IllegalArgumentException: type: -1
> at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject(Unknown Source)
> at org.apache.xerces.dom.DeferredElementNSImpl.synchronizeData(Unknown Source)
> at org.apache.xerces.dom.ElementNSImpl.getNamespaceURI(Unknown Source)
> at org.apache.ode.utils.DOMUtils.getElementQName(DOMUtils.java:691)
> at org.apache.ode.bpel.rtrep.v2.EXTENSIONACTIVITY.run(EXTENSIONACTIVITY.java:51)
> ...
> (sometimes it's a NullPointerException instead)
> This line 51 is
> final QName extensionId = DOMUtils.getElementQName(_oext.nestedElement.getElement());
> I searched for "java.lang.IllegalArgumentException at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject" and found an older message in the xerces mailing list suggesting that the cause for this could be that the DOM implementation is not thread-safe. So I did a little patch in org.apache.ode.utils.SerializableElement and added a line to readObject(...):
> private void readObject(java.io.ObjectInputStream in)
> throws IOException, ClassNotFoundException {
> try {
> e = DOMUtils.stringToDOM((String)in.readObject());
> DOMUtils.getElementQName(e); // <-- this one is new
> ...
> Now the error doesn't occur anymore (as far as I can tell), because whatever is changed in the DOM object during the first access of the element's QName has already changed during process hydration and the first invocation does only read the DOM object.
> This is probably the most simple way to fix the issue, but there may be better possibilities (maybe reading the QName from the nested DOM during instance creation/deserialization of EXTENSIONACTIVITY and storing it for later access in a member variable? that would be also a small performance improvement), but I'll leave this decision to you. I can also provide a proper patch if you tell me which way to go.
> Cheers,
> Juergen
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-503) Multithreading issue in
...rtrep.v2.EXTENSIONACTIVITY
Posted by "Jürgen Schumacher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673901#action_12673901 ]
Jürgen Schumacher commented on ODE-503:
---------------------------------------
Hi Tammo,
sorry, it has taken a little while.
It looks like my colleaques can confirm that the new patch resolves the problem.
So I think we can consider this isses fixed (-:
Thanks!
Jürgen.
> Multithreading issue in ...rtrep.v2.EXTENSIONACTIVITY
> -----------------------------------------------------
>
> Key: ODE-503
> URL: https://issues.apache.org/jira/browse/ODE-503
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Affects Versions: 2.0
> Reporter: Jürgen Schumacher
> Assignee: Tammo van Lessen
> Fix For: 2.0
>
> Attachments: ODE-503.patch
>
>
> We have experienced a problem in the execution of extension activities. I suppose it's caused by two process instances of the same BPEL process that invoke a single extension activity at the same time that has not yet been executed since hydration.
> The error stacktrace is something like this:
> java.lang.IllegalArgumentException: type: -1
> at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject(Unknown Source)
> at org.apache.xerces.dom.DeferredElementNSImpl.synchronizeData(Unknown Source)
> at org.apache.xerces.dom.ElementNSImpl.getNamespaceURI(Unknown Source)
> at org.apache.ode.utils.DOMUtils.getElementQName(DOMUtils.java:691)
> at org.apache.ode.bpel.rtrep.v2.EXTENSIONACTIVITY.run(EXTENSIONACTIVITY.java:51)
> ...
> (sometimes it's a NullPointerException instead)
> This line 51 is
> final QName extensionId = DOMUtils.getElementQName(_oext.nestedElement.getElement());
> I searched for "java.lang.IllegalArgumentException at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject" and found an older message in the xerces mailing list suggesting that the cause for this could be that the DOM implementation is not thread-safe. So I did a little patch in org.apache.ode.utils.SerializableElement and added a line to readObject(...):
> private void readObject(java.io.ObjectInputStream in)
> throws IOException, ClassNotFoundException {
> try {
> e = DOMUtils.stringToDOM((String)in.readObject());
> DOMUtils.getElementQName(e); // <-- this one is new
> ...
> Now the error doesn't occur anymore (as far as I can tell), because whatever is changed in the DOM object during the first access of the element's QName has already changed during process hydration and the first invocation does only read the DOM object.
> This is probably the most simple way to fix the issue, but there may be better possibilities (maybe reading the QName from the nested DOM during instance creation/deserialization of EXTENSIONACTIVITY and storing it for later access in a member variable? that would be also a small performance improvement), but I'll leave this decision to you. I can also provide a proper patch if you tell me which way to go.
> Cheers,
> Juergen
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-503) Multithreading issue in
...rtrep.v2.EXTENSIONACTIVITY
Posted by "Jürgen Schumacher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673208#action_12673208 ]
Jürgen Schumacher commented on ODE-503:
---------------------------------------
Hi Tammo,
Finally, I've found two colleaques who can reproduce the issue, and your patch seems to fix it for them (at least for EXTENSIONACTIVITY. We do not use ExtensionAssign operations, sorry, but I suppose that it's basically the same there. However, I would still prefer a more efficient patch (;
> Multithreading issue in ...rtrep.v2.EXTENSIONACTIVITY
> -----------------------------------------------------
>
> Key: ODE-503
> URL: https://issues.apache.org/jira/browse/ODE-503
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Affects Versions: 2.0
> Reporter: Jürgen Schumacher
> Assignee: Tammo van Lessen
> Fix For: 2.0
>
> Attachments: ODE-503.patch
>
>
> We have experienced a problem in the execution of extension activities. I suppose it's caused by two process instances of the same BPEL process that invoke a single extension activity at the same time that has not yet been executed since hydration.
> The error stacktrace is something like this:
> java.lang.IllegalArgumentException: type: -1
> at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject(Unknown Source)
> at org.apache.xerces.dom.DeferredElementNSImpl.synchronizeData(Unknown Source)
> at org.apache.xerces.dom.ElementNSImpl.getNamespaceURI(Unknown Source)
> at org.apache.ode.utils.DOMUtils.getElementQName(DOMUtils.java:691)
> at org.apache.ode.bpel.rtrep.v2.EXTENSIONACTIVITY.run(EXTENSIONACTIVITY.java:51)
> ...
> (sometimes it's a NullPointerException instead)
> This line 51 is
> final QName extensionId = DOMUtils.getElementQName(_oext.nestedElement.getElement());
> I searched for "java.lang.IllegalArgumentException at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject" and found an older message in the xerces mailing list suggesting that the cause for this could be that the DOM implementation is not thread-safe. So I did a little patch in org.apache.ode.utils.SerializableElement and added a line to readObject(...):
> private void readObject(java.io.ObjectInputStream in)
> throws IOException, ClassNotFoundException {
> try {
> e = DOMUtils.stringToDOM((String)in.readObject());
> DOMUtils.getElementQName(e); // <-- this one is new
> ...
> Now the error doesn't occur anymore (as far as I can tell), because whatever is changed in the DOM object during the first access of the element's QName has already changed during process hydration and the first invocation does only read the DOM object.
> This is probably the most simple way to fix the issue, but there may be better possibilities (maybe reading the QName from the nested DOM during instance creation/deserialization of EXTENSIONACTIVITY and storing it for later access in a member variable? that would be also a small performance improvement), but I'll leave this decision to you. I can also provide a proper patch if you tell me which way to go.
> Cheers,
> Juergen
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ODE-503) Multithreading issue in
...rtrep.v2.EXTENSIONACTIVITY
Posted by "Tammo van Lessen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tammo van Lessen reassigned ODE-503:
------------------------------------
Assignee: Tammo van Lessen
> Multithreading issue in ...rtrep.v2.EXTENSIONACTIVITY
> -----------------------------------------------------
>
> Key: ODE-503
> URL: https://issues.apache.org/jira/browse/ODE-503
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Affects Versions: 2.0
> Reporter: Jürgen Schumacher
> Assignee: Tammo van Lessen
> Fix For: 2.0
>
>
> We have experienced a problem in the execution of extension activities. I suppose it's caused by two process instances of the same BPEL process that invoke a single extension activity at the same time that has not yet been executed since hydration.
> The error stacktrace is something like this:
> java.lang.IllegalArgumentException: type: -1
> at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject(Unknown Source)
> at org.apache.xerces.dom.DeferredElementNSImpl.synchronizeData(Unknown Source)
> at org.apache.xerces.dom.ElementNSImpl.getNamespaceURI(Unknown Source)
> at org.apache.ode.utils.DOMUtils.getElementQName(DOMUtils.java:691)
> at org.apache.ode.bpel.rtrep.v2.EXTENSIONACTIVITY.run(EXTENSIONACTIVITY.java:51)
> ...
> (sometimes it's a NullPointerException instead)
> This line 51 is
> final QName extensionId = DOMUtils.getElementQName(_oext.nestedElement.getElement());
> I searched for "java.lang.IllegalArgumentException at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject" and found an older message in the xerces mailing list suggesting that the cause for this could be that the DOM implementation is not thread-safe. So I did a little patch in org.apache.ode.utils.SerializableElement and added a line to readObject(...):
> private void readObject(java.io.ObjectInputStream in)
> throws IOException, ClassNotFoundException {
> try {
> e = DOMUtils.stringToDOM((String)in.readObject());
> DOMUtils.getElementQName(e); // <-- this one is new
> ...
> Now the error doesn't occur anymore (as far as I can tell), because whatever is changed in the DOM object during the first access of the element's QName has already changed during process hydration and the first invocation does only read the DOM object.
> This is probably the most simple way to fix the issue, but there may be better possibilities (maybe reading the QName from the nested DOM during instance creation/deserialization of EXTENSIONACTIVITY and storing it for later access in a member variable? that would be also a small performance improvement), but I'll leave this decision to you. I can also provide a proper patch if you tell me which way to go.
> Cheers,
> Juergen
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-503) Multithreading issue in
...rtrep.v2.EXTENSIONACTIVITY
Posted by "Tammo van Lessen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tammo van Lessen updated ODE-503:
---------------------------------
Attachment: ODE-503.patch
Hi Jürgen, please give the patch a try.
> Multithreading issue in ...rtrep.v2.EXTENSIONACTIVITY
> -----------------------------------------------------
>
> Key: ODE-503
> URL: https://issues.apache.org/jira/browse/ODE-503
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Affects Versions: 2.0
> Reporter: Jürgen Schumacher
> Assignee: Tammo van Lessen
> Fix For: 2.0
>
> Attachments: ODE-503.patch
>
>
> We have experienced a problem in the execution of extension activities. I suppose it's caused by two process instances of the same BPEL process that invoke a single extension activity at the same time that has not yet been executed since hydration.
> The error stacktrace is something like this:
> java.lang.IllegalArgumentException: type: -1
> at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject(Unknown Source)
> at org.apache.xerces.dom.DeferredElementNSImpl.synchronizeData(Unknown Source)
> at org.apache.xerces.dom.ElementNSImpl.getNamespaceURI(Unknown Source)
> at org.apache.ode.utils.DOMUtils.getElementQName(DOMUtils.java:691)
> at org.apache.ode.bpel.rtrep.v2.EXTENSIONACTIVITY.run(EXTENSIONACTIVITY.java:51)
> ...
> (sometimes it's a NullPointerException instead)
> This line 51 is
> final QName extensionId = DOMUtils.getElementQName(_oext.nestedElement.getElement());
> I searched for "java.lang.IllegalArgumentException at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject" and found an older message in the xerces mailing list suggesting that the cause for this could be that the DOM implementation is not thread-safe. So I did a little patch in org.apache.ode.utils.SerializableElement and added a line to readObject(...):
> private void readObject(java.io.ObjectInputStream in)
> throws IOException, ClassNotFoundException {
> try {
> e = DOMUtils.stringToDOM((String)in.readObject());
> DOMUtils.getElementQName(e); // <-- this one is new
> ...
> Now the error doesn't occur anymore (as far as I can tell), because whatever is changed in the DOM object during the first access of the element's QName has already changed during process hydration and the first invocation does only read the DOM object.
> This is probably the most simple way to fix the issue, but there may be better possibilities (maybe reading the QName from the nested DOM during instance creation/deserialization of EXTENSIONACTIVITY and storing it for later access in a member variable? that would be also a small performance improvement), but I'll leave this decision to you. I can also provide a proper patch if you tell me which way to go.
> Cheers,
> Juergen
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-503) Multithreading issue in
...rtrep.v2.EXTENSIONACTIVITY
Posted by "Tammo van Lessen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tammo van Lessen resolved ODE-503.
----------------------------------
Resolution: Fixed
perfect, thanks!
> Multithreading issue in ...rtrep.v2.EXTENSIONACTIVITY
> -----------------------------------------------------
>
> Key: ODE-503
> URL: https://issues.apache.org/jira/browse/ODE-503
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Affects Versions: 2.0
> Reporter: Jürgen Schumacher
> Assignee: Tammo van Lessen
> Fix For: 2.0
>
> Attachments: ODE-503.patch
>
>
> We have experienced a problem in the execution of extension activities. I suppose it's caused by two process instances of the same BPEL process that invoke a single extension activity at the same time that has not yet been executed since hydration.
> The error stacktrace is something like this:
> java.lang.IllegalArgumentException: type: -1
> at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject(Unknown Source)
> at org.apache.xerces.dom.DeferredElementNSImpl.synchronizeData(Unknown Source)
> at org.apache.xerces.dom.ElementNSImpl.getNamespaceURI(Unknown Source)
> at org.apache.ode.utils.DOMUtils.getElementQName(DOMUtils.java:691)
> at org.apache.ode.bpel.rtrep.v2.EXTENSIONACTIVITY.run(EXTENSIONACTIVITY.java:51)
> ...
> (sometimes it's a NullPointerException instead)
> This line 51 is
> final QName extensionId = DOMUtils.getElementQName(_oext.nestedElement.getElement());
> I searched for "java.lang.IllegalArgumentException at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject" and found an older message in the xerces mailing list suggesting that the cause for this could be that the DOM implementation is not thread-safe. So I did a little patch in org.apache.ode.utils.SerializableElement and added a line to readObject(...):
> private void readObject(java.io.ObjectInputStream in)
> throws IOException, ClassNotFoundException {
> try {
> e = DOMUtils.stringToDOM((String)in.readObject());
> DOMUtils.getElementQName(e); // <-- this one is new
> ...
> Now the error doesn't occur anymore (as far as I can tell), because whatever is changed in the DOM object during the first access of the element's QName has already changed during process hydration and the first invocation does only read the DOM object.
> This is probably the most simple way to fix the issue, but there may be better possibilities (maybe reading the QName from the nested DOM during instance creation/deserialization of EXTENSIONACTIVITY and storing it for later access in a member variable? that would be also a small performance improvement), but I'll leave this decision to you. I can also provide a proper patch if you tell me which way to go.
> Cheers,
> Juergen
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-503) Multithreading issue in
...rtrep.v2.EXTENSIONACTIVITY
Posted by "Jürgen Schumacher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673192#action_12673192 ]
Jürgen Schumacher commented on ODE-503:
---------------------------------------
Hi Tammo,
I've not yet been able to reproduce the problem (and therefore could not test your patch), but I'm working on it. Howver, I'm a bit concerned about the performance implications of this patch. We are using extension activities quite heavily and have also some more content inside the extension element (see http://wiki.eclipse.org/SMILA/Documentation/BPEL_Workflow_Processor#Pipelet_invocations for an example) and cloning all this for each invocation in a synchronized block might become a problem, especially as I do not access this element any further in the extension implementation, because I have extracted all necessary information already during deployment using an extension validator (it might be a bit of a misuse, but it works fine ;-). If you really want to be safe, maybe it would be enough to put the final QName extensionId = DOMUtils.getElementQName(_oext.nestedElement.getElement()); inside a synchronized block (or to extract it only once and to store the QName in a member of EXTENSIONACTIVITY/ASSIGN so that we can save the synchronization on further accesses?) and put a hint in the documentation for extension implementors that they should access the passed element only in a synchronized way?
> Multithreading issue in ...rtrep.v2.EXTENSIONACTIVITY
> -----------------------------------------------------
>
> Key: ODE-503
> URL: https://issues.apache.org/jira/browse/ODE-503
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Affects Versions: 2.0
> Reporter: Jürgen Schumacher
> Assignee: Tammo van Lessen
> Fix For: 2.0
>
> Attachments: ODE-503.patch
>
>
> We have experienced a problem in the execution of extension activities. I suppose it's caused by two process instances of the same BPEL process that invoke a single extension activity at the same time that has not yet been executed since hydration.
> The error stacktrace is something like this:
> java.lang.IllegalArgumentException: type: -1
> at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject(Unknown Source)
> at org.apache.xerces.dom.DeferredElementNSImpl.synchronizeData(Unknown Source)
> at org.apache.xerces.dom.ElementNSImpl.getNamespaceURI(Unknown Source)
> at org.apache.ode.utils.DOMUtils.getElementQName(DOMUtils.java:691)
> at org.apache.ode.bpel.rtrep.v2.EXTENSIONACTIVITY.run(EXTENSIONACTIVITY.java:51)
> ...
> (sometimes it's a NullPointerException instead)
> This line 51 is
> final QName extensionId = DOMUtils.getElementQName(_oext.nestedElement.getElement());
> I searched for "java.lang.IllegalArgumentException at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject" and found an older message in the xerces mailing list suggesting that the cause for this could be that the DOM implementation is not thread-safe. So I did a little patch in org.apache.ode.utils.SerializableElement and added a line to readObject(...):
> private void readObject(java.io.ObjectInputStream in)
> throws IOException, ClassNotFoundException {
> try {
> e = DOMUtils.stringToDOM((String)in.readObject());
> DOMUtils.getElementQName(e); // <-- this one is new
> ...
> Now the error doesn't occur anymore (as far as I can tell), because whatever is changed in the DOM object during the first access of the element's QName has already changed during process hydration and the first invocation does only read the DOM object.
> This is probably the most simple way to fix the issue, but there may be better possibilities (maybe reading the QName from the nested DOM during instance creation/deserialization of EXTENSIONACTIVITY and storing it for later access in a member variable? that would be also a small performance improvement), but I'll leave this decision to you. I can also provide a proper patch if you tell me which way to go.
> Cheers,
> Juergen
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.