> On Oct 11, 2017, at 4:19 PM, Guillaume Nodet <[email protected]> wrote: > > I agree, but this needs to be addressed in a Java 9 way, and that's not > through endorsed libraries which are not supported anymore. We'll need a > jigsaw module for xerces. > Btw, is there an issue raised on OpenJDK ? They could maybe cache the value > in a static variable ?
Honestly, I don’t remember anymore. :( It’s been several years since I looked into this. I did just check and the System property call is still in the CoreDocumentImpl constructor in the latest 1.8 JDK so if it has been logged, it hasn’t been addressed. I can look more next week when I’m back from Portugal. That said, I did a quick look through CXF and I think I can reduce the issues a bit there. Most of the created documents fall into a few use cases: 1) WSDL/Schema parsing - this is startup so I’m not TOOO concerned about the property call. 2) Create “unattached” elements that are traversed later. Things like the “detail” elements of faults, various header objects (number of these greatly reduced in 3.2) that are written out, etc… 3) SAAJ - per spec, nothing we can really do here. Luckily we don’t need to do this for default use cases, but anyone doing SAAJ things are impacted 4) SOAP headers on incoming messages - we store various things on the DOM for handling later. 5) JAXB “xsd:any” and text/xml attachments - both create Documents to store it. Nothing we can do here. I believe I can handle the #2 cases with a static “empty Document" that is just used as a factory for elements. I’m going to experiment a bit more with this next week. Alessio did a bit of work a while ago to reduce the impact of #4 by only doing that if really needed, but there are some popular use cases (WS-Addressing, WS-Security) that would hit this anyway. Obviously CXF isn’t the only thing impacted…. Anything that creates DOM’s would be impacted. Camel routes with XML, XSLT transforms, etc…. Dan > > 2017-10-11 16:06 GMT+02:00 Daniel Kulp <[email protected]>: > >> >> The PROBLEM with the in-JDK version of the DOM is that just creating a new >> empty document involved a call to System.getProperty(…) which is a >> synchronized call. The Apache xerces version does not have that problem. >> Thus, by removing the xerces jar, performance of certain uses cases will >> drop with high concurrency. Unfortunately, CXF is one of those use cases. >> >> >> Dan >> >> >>> On Oct 11, 2017, at 2:00 PM, Guillaume Nodet <[email protected]> wrote: >>> >>> The point that makes me raise this problem is that the karaf default >>> distribution uses the Apache versions of xerces and xalan. Fwiw, the >>> latest xerces release is from 2011 and the latest xalan from 2014, so >>> they're not the most active. In particular, xalan latest release does >> not >>> implement jaxp 1.4. >>> >>> One additional point is that those libraries stuff is broken on Java 9, >> so >>> one option would be to remove it alltogether which bring us much closer >> to >>> Java 9 support ;-) Seriously, I'm not sure I want to spend too much time >>> allowing pluggability for specs/implementations while the only real >>> implementation provider is the JDK itself. That's really a lot of work >> for >>> no real benefit. >>> >>> In addition, the default distribution still install some "legacy" >> features >>> such as aries-blueprint, shell-compat, etc... >>> >>> So here's a list of propositions for 4.2: >>> * remove all libraries for specs / impls from apache-karaf distro >>> * remove support for endorsed / ext libraries in the <library> element >>> and wherever used >>> * remove aries-blueprint and shell-compat from default distro >>> * remove a few features from the karaf-minimal distro. I'm not sure >> which >>> one exactly, but I think we should get the zip under 10 Mb. Maybe only >>> keeping jaas, shell, feature, ssh, bundle, config, deployer and log, also >>> removing equinox / logback bundles... >>> >>> Thoughts ? >>> >>> -- >>> ------------------------ >>> Guillaume Nodet >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> > > > -- > ------------------------ > Guillaume Nodet -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
