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