[
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15030710#comment-15030710
]
Michele Vivoda edited comment on JXPATH-183 at 11/28/15 11:59 PM:
--
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 given a calendar {{cal}} the timezone is {{cal/timeZone}},
looks like that the difference is only in that the properties are not iterable,
for example when using {{cal//*}}
was (Author: vivodamich...@hotmail.com):
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)
