commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michele Vivoda (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
Date Sat, 28 Nov 2015 23:57:11 GMT

    [ 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)

Mime
View raw message