Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
From: Daniel Kulp <dkulp@apache.org>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Subject: Re: [DISCUSS] Trim down karaf distributions for 4.2
Date: Wed, 11 Oct 2017 16:41:11 +0100
References: <CAA66TpoE3t_8WHCvDRkOS=xR8xBdkK+QVFwnvntuC1f6tPLv5w@mail.gmail.com>
 <0AAEE8EE-7F57-4B73-BF8A-EDAD57FEFC64@apache.org>
 <CAA66Tpp-+a0iBOgcoSUy6J1Spd1ViU4Exxq-WQdG4r_zbcqYZw@mail.gmail.com>
To: dev@karaf.apache.org
In-Reply-To: <CAA66Tpp-+a0iBOgcoSUy6J1Spd1ViU4Exxq-WQdG4r_zbcqYZw@mail.gmail.com>
Message-Id: <017E4A1D-EC58-4033-A792-39A402EDE66B@apache.org>
archived-at: Wed, 11 Oct 2017 15:41:44 -0000


> On Oct 11, 2017, at 4:19 PM, Guillaume Nodet <gnodet@apache.org> =
wrote:
>=20
> 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=E2=80=99t remember anymore.  :( It=E2=80=99s 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=E2=80=99t been =
addressed.    I can look more next week when I=E2=80=99m 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=E2=80=99m not TOOO =
concerned about the property call.

2) Create =E2=80=9Cunattached=E2=80=9D elements that are traversed =
later.   Things like the =E2=80=9Cdetail=E2=80=9D elements of faults, =
various header objects (number of these greatly reduced in 3.2) that are =
written out, etc=E2=80=A6

3) SAAJ - per spec, nothing we can really do here.  Luckily we don=E2=80=99=
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.  =20

5) JAXB =E2=80=9Cxsd:any=E2=80=9D 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 =E2=80=9Cempty =
Document" that is just used as a factory for elements.   I=E2=80=99m =
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=E2=80=99t the only thing impacted=E2=80=A6. Anything =
that creates DOM=E2=80=99s would be impacted.   Camel routes with XML, =
XSLT transforms, etc=E2=80=A6.


Dan
=20


>=20
> 2017-10-11 16:06 GMT+02:00 Daniel Kulp <dkulp@apache.org>:
>=20
>>=20
>> The PROBLEM with the in-JDK version of the DOM is that just creating =
a new
>> empty document involved a call to System.getProperty(=E2=80=A6) 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.
>>=20
>>=20
>> Dan
>>=20
>>=20
>>> On Oct 11, 2017, at 2:00 PM, Guillaume Nodet <gnodet@apache.org> =
wrote:
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> In addition, the default distribution still install some "legacy"
>> features
>>> such as aries-blueprint, shell-compat, etc...
>>>=20
>>> 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...
>>>=20
>>> Thoughts ?
>>>=20
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>=20
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>=20
>>=20
>=20
>=20
> --=20
> ------------------------
> Guillaume Nodet

--=20
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com