[
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030710#comment-15030710
]
Michele Vivoda commented on JXPATH-183:
---------------------------------------
Registering the class as atomic value should be the solution of this issue, the
trick is that one must not register the abstract super class but the
implementation class:
{noformat}
try {
JXPathIntrospector.registerAtomicClass(
DatatypeFactory.newInstance().newXMLGregorianCalendar("2010-02-02").getClass());
} catch (DatatypeConfigurationException e) {
e.printStackTrace();
// ignore, no datatype lib
}
{noformat}
Maybe this should be done in the constructor of {{JXPathIntrospector}} and
probably also for {{GregorianCalendar}}. I noticed also that, after registering
a class as atomic is still possible to access the properties using a "direct"
xpath, for example calendar timezone {{cal/timeZone}}, looks like that the
difference is only in that the properties are not iterable, for example when
using {{cal//*}}
> XMLGregorianCalendar existence adding a lot of performance penalty
> ------------------------------------------------------------------
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
> Issue Type: Improvement
> Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
> Reporter: Ganna Shmatova
> Labels: performance
> Attachments: JXPath183Test.java
>
>
> We're using JXPath to parse some input from a client. When they give us a
> valid date it gets transformed from a SOAP message into Java objects. When
> this happens JXPath queries suddenly take 1-8 seconds more (depending on
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java
> for now)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
