You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Detelin Yordanov (JIRA)" <ji...@apache.org> on 2009/07/02 15:41:48 UTC

[jira] Created: (WSCOMMONS-484) Performance enhancement for build from DOM (WSCOMMONS-361) breaks Xerces DOM Node's Java serializability

Performance enhancement for build from DOM (WSCOMMONS-361) breaks Xerces DOM Node's Java serializability
--------------------------------------------------------------------------------------------------------

                 Key: WSCOMMONS-484
                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-484
             Project: WS-Commons
          Issue Type: Bug
          Components: XmlSchema
    Affects Versions: XmlSchema 1.4.3
         Environment: Xerces 2.8.1 DOM Parser
            Reporter: Detelin Yordanov


Patch for "Performance enhancement for build from DOM" (WSCOMMONS-361) makes use of DOM Node's userData field to store NodeNamespaceContext instances when reading an XMLSchema from a DOM tree. When the DOM tree is parsed with Xerces, each DOM Node is also Java serializable (since Xerces Node impelementation implements java.io.Serializable). However, filling the userData field with NodeNamespaceContext instances (which are not serializable) renders the whole tree not-serializable.

I'm not sure whether the problem is in XMLSchema, or in Xerces. The DOM Node interface does not require implementations to be serializable, Xerces just supports this additional feature (see http://xerces.apache.org/xerces2-j/faq-dom.html#faq-4). However, Xerces should not asume the user data to be serializable, since the DOM 3 spec does not require it. Anyway, if I have, I will report this to Xerces project too, but in any case this will have an impact on XMLSchema.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (WSCOMMONS-484) Performance enhancement for build from DOM (WSCOMMONS-361) breaks Xerces DOM Node's Java serializability

Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WSCOMMONS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved WSCOMMONS-484.
-----------------------------------

         Assignee: Daniel Kulp
    Fix Version/s: XmlSchema 1.4.7
       Resolution: Fixed


Changed to not use the user data stuff at all.   When running on DOM level 3 (where the user data methods are), we don't need the NodeNamespaceContext things as we can use the lookupNamespaceURI and lookupPrefix methods on the Element itself.


> Performance enhancement for build from DOM (WSCOMMONS-361) breaks Xerces DOM Node's Java serializability
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WSCOMMONS-484
>                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-484
>             Project: WS-Commons
>          Issue Type: Bug
>          Components: XmlSchema
>    Affects Versions: XmlSchema 1.4.3
>         Environment: Xerces 2.8.1 DOM Parser
>            Reporter: Detelin Yordanov
>            Assignee: Daniel Kulp
>             Fix For: XmlSchema 1.4.7
>
>
> Patch for "Performance enhancement for build from DOM" (WSCOMMONS-361) makes use of DOM Node's userData field to store NodeNamespaceContext instances when reading an XMLSchema from a DOM tree. When the DOM tree is parsed with Xerces, each DOM Node is also Java serializable (since Xerces Node impelementation implements java.io.Serializable). However, filling the userData field with NodeNamespaceContext instances (which are not serializable) renders the whole tree not-serializable.
> I'm not sure whether the problem is in XMLSchema, or in Xerces. The DOM Node interface does not require implementations to be serializable, Xerces just supports this additional feature (see http://xerces.apache.org/xerces2-j/faq-dom.html#faq-4 ). However, Xerces should not asume the user data to be serializable, since the DOM 3 spec does not require it. Anyway, if I have, I will report this to Xerces project too, but in any case this will have an impact on XMLSchema.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (WSCOMMONS-484) Performance enhancement for build from DOM (WSCOMMONS-361) breaks Xerces DOM Node's Java serializability

Posted by "Detelin Yordanov (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WSCOMMONS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Detelin Yordanov updated WSCOMMONS-484:
---------------------------------------

    Description: 
Patch for "Performance enhancement for build from DOM" (WSCOMMONS-361) makes use of DOM Node's userData field to store NodeNamespaceContext instances when reading an XMLSchema from a DOM tree. When the DOM tree is parsed with Xerces, each DOM Node is also Java serializable (since Xerces Node impelementation implements java.io.Serializable). However, filling the userData field with NodeNamespaceContext instances (which are not serializable) renders the whole tree not-serializable.

I'm not sure whether the problem is in XMLSchema, or in Xerces. The DOM Node interface does not require implementations to be serializable, Xerces just supports this additional feature (see http://xerces.apache.org/xerces2-j/faq-dom.html#faq-4 ). However, Xerces should not asume the user data to be serializable, since the DOM 3 spec does not require it. Anyway, if I have, I will report this to Xerces project too, but in any case this will have an impact on XMLSchema.


  was:
Patch for "Performance enhancement for build from DOM" (WSCOMMONS-361) makes use of DOM Node's userData field to store NodeNamespaceContext instances when reading an XMLSchema from a DOM tree. When the DOM tree is parsed with Xerces, each DOM Node is also Java serializable (since Xerces Node impelementation implements java.io.Serializable). However, filling the userData field with NodeNamespaceContext instances (which are not serializable) renders the whole tree not-serializable.

I'm not sure whether the problem is in XMLSchema, or in Xerces. The DOM Node interface does not require implementations to be serializable, Xerces just supports this additional feature (see http://xerces.apache.org/xerces2-j/faq-dom.html#faq-4). However, Xerces should not asume the user data to be serializable, since the DOM 3 spec does not require it. Anyway, if I have, I will report this to Xerces project too, but in any case this will have an impact on XMLSchema.



> Performance enhancement for build from DOM (WSCOMMONS-361) breaks Xerces DOM Node's Java serializability
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WSCOMMONS-484
>                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-484
>             Project: WS-Commons
>          Issue Type: Bug
>          Components: XmlSchema
>    Affects Versions: XmlSchema 1.4.3
>         Environment: Xerces 2.8.1 DOM Parser
>            Reporter: Detelin Yordanov
>
> Patch for "Performance enhancement for build from DOM" (WSCOMMONS-361) makes use of DOM Node's userData field to store NodeNamespaceContext instances when reading an XMLSchema from a DOM tree. When the DOM tree is parsed with Xerces, each DOM Node is also Java serializable (since Xerces Node impelementation implements java.io.Serializable). However, filling the userData field with NodeNamespaceContext instances (which are not serializable) renders the whole tree not-serializable.
> I'm not sure whether the problem is in XMLSchema, or in Xerces. The DOM Node interface does not require implementations to be serializable, Xerces just supports this additional feature (see http://xerces.apache.org/xerces2-j/faq-dom.html#faq-4 ). However, Xerces should not asume the user data to be serializable, since the DOM 3 spec does not require it. Anyway, if I have, I will report this to Xerces project too, but in any case this will have an impact on XMLSchema.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.