Why not just use the StAX API’s built into the JDK to avoid another dependency? That said, it’s likely using StAX might/should bring in woodstox.
Dan > On Aug 9, 2017, at 5:11 AM, Jean-Baptiste Onofré <[email protected]> wrote: > > Fair enough. Agree, worth to evaluate xmlpullparser. > > Regards > JB > > On 08/09/2017 11:04 AM, Fabian Lange wrote: >> I cannot really tell. >> Whatever XML stream or Document parser we would use, it also would load new >> classes and require some time to initialize. >> JAXB is however known to be the most inefficient in that regard. On the >> other hand it offers the most convenience because you get these nice mapped >> POJOs. >> Felix SCR does it manually as far as I can see: >> https://github.com/apache/felix/blob/trunk/osgi-r7/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java >> Felix IPojo uses sax: >> https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/ipojo/manipulator/manipulator/src/main/java/org/apache/felix/ipojo/xml/parser/XMLMetadataParser.java >> Felix metatype uses xmlpullparser: >> https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/metatype/src/main/java/org/apache/felix/metatype/MetaDataReader.java >> None of Felix uses jaxb. >> Maybe its worth giving xmlpullparser a shot. The code of metatype looks >> straigtforward, and the embedded classes are minimal. >> Fabian >> On Wed, Aug 9, 2017 at 10:53 AM, Jean-Baptiste Onofré <[email protected]> >> wrote: >>> Hi Fabian, >>> >>> interesting fact indeed. What alternate do you propose ? >>> >>> Regards >>> JB >>> >>> On 08/09/2017 10:46 AM, Fabian Lange wrote: >>> >>>> Hey, >>>> I have new intel on this. A colleague generated a flame graph. >>>> I cannot share the raw svg unfortunately, but I cropped the Feature JAXB >>>> parsing. >>>> >>>> It is about 25% of the overall startup time just to boot up the jaxb >>>> infrastructure. >>>> >>>> Fabian >>>> >>>> >>>> On Fri, Jul 22, 2016 at 10:06 AM, Fabian Lange < >>>> [email protected] <mailto:[email protected]>> wrote: >>>> >>>> Thanks, good hint. >>>> For those inclined to understand my request, attached is the output of >>>> -XX:+TraceClassLoading >>>> >>>> Using the xml binding feature approximately loads 800 classes (which >>>> represent about 5MB memory) >>>> >>>> I haven't checked alternatives to the jaxb. And I am aware that this >>>> is a >>>> more esoteric requirement to reduce footprint. >>>> >>>> However, I am sure if this would not be from the JDK, nobody would >>>> pull in a >>>> 5MB dependency to parse a single xml file. >>>> >>>> Fabian >>>> >>>> >>>> On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Note that on older branches, the feature repositories are still >>>> parsed >>>> using DOM >>>> https://github.com/apache/karaf/blob/karaf-2.x/features/core >>>> /src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java >>>> <https://github.com/apache/karaf/blob/karaf-2.x/features/cor >>>> e/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java> >>>> >>>> The xml is now also written, that may be the reason why we >>>> switched. >>>> >>>> 2016-07-14 23:11 GMT+02:00 Fabian Lange < >>>> [email protected] >>>> <mailto:[email protected]>>: >>>> >>>> > Hi, >>>> > >>>> > i am looking into ways to trim down Karaf. I notices that >>>> Karaf uses JaxB >>>> > to parse features.xml - However this is the only application >>>> of JaxB. >>>> > >>>> > Could somebody more involved help me to figure out if it is >>>> worth to >>>> > replace it with manual marshalling? I assume other xmls are >>>> parsed >>>> > differently? >>>> > Advantage would be that the whole jaxb infrastructure could be >>>> avoided, >>>> > including the contexts. >>>> > >>>> > I know manual parsing is a pain, but anyway, just wanted to >>>> throw >>>> this out, >>>> > maybe somebody has a good suggestion. >>>> > >>>> > Fabian >>>> > -- >>>> > Fabian Lange | Performance Expert >>>> > mobil: +49 (0) 160.3673393 <tel:%2B49%20%280%29%20160.3673393> >>>> > >>>> > codecentric AG | Merscheider Straße 1 | 42699 Solingen | >>>> Deutschland >>>> > >>>> > Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht >>>> Wuppertal >>>> > Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns >>>> > Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . >>>> Jürgen >>>> Schütz >>>> > >>>> >>>> >>>> >>>> -- >>>> ------------------------ >>>> Guillaume Nodet >>>> ------------------------ >>>> Red Hat, Open Source Integration >>>> >>>> Email: [email protected] <mailto:[email protected]> >>>> Web: http://fusesource.com >>>> Blog: http://gnodet.blogspot.com/ >>>> >>>> >>>> >>>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
