You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Fabian Lange <fa...@codecentric.de> on 2016/07/14 21:11:14 UTC
Removal of JaxBUtil ?
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
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
Re: Removal of JaxBUtil ?
Posted by Benson Margulies <be...@basistech.com>.
It's not a terribly complex data model, doing it with StAx by hand
wouldn't look so bad.
On Thu, Jul 14, 2016 at 5:11 PM, Fabian Lange
<fa...@codecentric.de> wrote:
> 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
>
> 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
Re: Removal of JaxBUtil ?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Fabian,
clearly, we adopted JAXB because we directly created the annotated POJO
and the marshalling/unmarshalling (as the feature parsing is also used
in the maven plugin MOJO) and it was easier than "manual" parsing.
Maintenance is also easier as just updated the POJOs work.
What would you propose as JAXB alternative ?
Regards
JB
On 07/14/2016 11:11 PM, Fabian Lange wrote:
> 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
>
> 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
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Removal of JaxBUtil ?
Posted by Daniel Kulp <dk...@apache.org>.
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é <jb...@nanthrax.net> 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é <jb...@nanthrax.net>
>> 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 <
>>>> fabian.lange@codecentric.de <ma...@codecentric.de>> 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 <gnodet@apache.org
>>>> <ma...@apache.org>> 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 <
>>>> fabian.lange@codecentric.de
>>>> <ma...@codecentric.de>>:
>>>>
>>>> > 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: gnodet@redhat.com <ma...@redhat.com>
>>>> Web: http://fusesource.com
>>>> Blog: http://gnodet.blogspot.com/
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Removal of JaxBUtil ?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@nanthrax.net>
> 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 <
>>> fabian.lange@codecentric.de <ma...@codecentric.de>> 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 <gnodet@apache.org
>>> <ma...@apache.org>> 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 <
>>> fabian.lange@codecentric.de
>>> <ma...@codecentric.de>>:
>>>
>>> > 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: gnodet@redhat.com <ma...@redhat.com>
>>> Web: http://fusesource.com
>>> Blog: http://gnodet.blogspot.com/
>>>
>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Removal of JaxBUtil ?
Posted by Fabian Lange <fa...@codecentric.de>.
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é <jb...@nanthrax.net>
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 <
>> fabian.lange@codecentric.de <ma...@codecentric.de>> 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 <gnodet@apache.org
>> <ma...@apache.org>> 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 <
>> fabian.lange@codecentric.de
>> <ma...@codecentric.de>>:
>>
>> > 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: gnodet@redhat.com <ma...@redhat.com>
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Removal of JaxBUtil ?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <fabian.lange@codecentric.de
> <ma...@codecentric.de>> 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 <gnodet@apache.org
> <ma...@apache.org>> 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/core/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 <fabian.lange@codecentric.de
> <ma...@codecentric.de>>:
>
> > 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: gnodet@redhat.com <ma...@redhat.com>
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Removal of JaxBUtil ?
Posted by Fabian Lange <fa...@codecentric.de>.
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 <fa...@codecentric.de>
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 <gn...@apache.org>
> 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
>>
>> The xml is now also written, that may be the reason why we switched.
>>
>> 2016-07-14 23:11 GMT+02:00 Fabian Lange <fa...@codecentric.de>:
>>
>> > 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
>> >
>> > 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: gnodet@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>
>
>
Re: Removal of JaxBUtil ?
Posted by Fabian Lange <fa...@codecentric.de>.
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 <gn...@apache.org> 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
>
> The xml is now also written, that may be the reason why we switched.
>
> 2016-07-14 23:11 GMT+02:00 Fabian Lange <fa...@codecentric.de>:
>
> > 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
> >
> > 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: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
Re: Removal of JaxBUtil ?
Posted by Guillaume Nodet <gn...@apache.org>.
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
The xml is now also written, that may be the reason why we switched.
2016-07-14 23:11 GMT+02:00 Fabian Lange <fa...@codecentric.de>:
> 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
>
> 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: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/