You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2017/09/27 14:53:03 UTC
[xbean] mjars handling
Hi guys,
how do we want to handle multi release jars?
concretely we need to:
1. check it is activated in the manifest.mf
2. if 1 is "true" then check META-INF/versions/<x>/<fqn>.class exists and
read it instead of <fqn>.class
This logic is not hard by itself but has some implication in term of perf
since for *each* class we can end up doing this validation.
Do we want to do it the other way? read it all, put the
META-INF/versions/<current> in another bucket and merge it after. My
assumption is META-INF/versions/* will be way smaller than the opposite so
we would just go through the archive once avoiding all the double checks
and just have an iteration over a small set of classes during the merge
phase at the end.
wdyt?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
Re: [xbean] mjars handling
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi guys,
pushed some work in this area, it is far to be perfect, here are the
small issues (but I think it is already a step forward):
- at the moment we will only handle mjar alternative classes if there
is a main class (without a version), we can need to add support for
"versioned only" classes - don't think it is used yet
- we rely on a classloader by design so it means in the archive we
have to assume the classloader handles mjar release or add a
parameter/flag for that we surely don't want. Since we cant really wap
the loader to make it supporting it since we would split scanning and
runtime (where we never see the classloader) I think it is "ok" even
if not perfect
I just added a test for jarfile and we need to cover way more this
code but wanted to let you know it is started :)
Romain Manni-Bucau
@rmannibucau | Blog | Old Blog | Github | LinkedIn
2017-09-28 9:50 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> was planning to give it a try in ~3 weeks (travelling soon so will not have
> a lot of hack time) and then try to get xbeam-asm-6 out. Issue today is we
> dont support any lib using mjar releases - even on a java 8 VM - including
> log4j since we scan all .class and sometimes it contains java 9 code we cant
> read.
>
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>
> 2017-09-28 9:42 GMT+02:00 Mark Struberg <st...@yahoo.de>:
>>
>> +1 but a bit short on time right now.
>>
>> Might be able to help in a few weeks.
>>
>> LieGrue,
>> strub
>>
>> > Am 27.09.2017 um 16:53 schrieb Romain Manni-Bucau
>> > <rm...@gmail.com>:
>> >
>> > Hi guys,
>> >
>> > how do we want to handle multi release jars?
>> >
>> > concretely we need to:
>> >
>> > 1. check it is activated in the manifest.mf
>> > 2. if 1 is "true" then check META-INF/versions/<x>/<fqn>.class exists
>> > and read it instead of <fqn>.class
>> >
>> > This logic is not hard by itself but has some implication in term of
>> > perf since for *each* class we can end up doing this validation.
>> >
>> > Do we want to do it the other way? read it all, put the
>> > META-INF/versions/<current> in another bucket and merge it after. My
>> > assumption is META-INF/versions/* will be way smaller than the opposite so
>> > we would just go through the archive once avoiding all the double checks and
>> > just have an iteration over a small set of classes during the merge phase at
>> > the end.
>> >
>> > wdyt?
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>>
>
Re: [xbean] mjars handling
Posted by Romain Manni-Bucau <rm...@gmail.com>.
was planning to give it a try in ~3 weeks (travelling soon so will not have
a lot of hack time) and then try to get xbeam-asm-6 out. Issue today is we
dont support any lib using mjar releases - even on a java 8 VM - including
log4j since we scan all .class and sometimes it contains java 9 code we
cant read.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2017-09-28 9:42 GMT+02:00 Mark Struberg <st...@yahoo.de>:
> +1 but a bit short on time right now.
>
> Might be able to help in a few weeks.
>
> LieGrue,
> strub
>
> > Am 27.09.2017 um 16:53 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Hi guys,
> >
> > how do we want to handle multi release jars?
> >
> > concretely we need to:
> >
> > 1. check it is activated in the manifest.mf
> > 2. if 1 is "true" then check META-INF/versions/<x>/<fqn>.class exists
> and read it instead of <fqn>.class
> >
> > This logic is not hard by itself but has some implication in term of
> perf since for *each* class we can end up doing this validation.
> >
> > Do we want to do it the other way? read it all, put the
> META-INF/versions/<current> in another bucket and merge it after. My
> assumption is META-INF/versions/* will be way smaller than the opposite so
> we would just go through the archive once avoiding all the double checks
> and just have an iteration over a small set of classes during the merge
> phase at the end.
> >
> > wdyt?
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>
>
Re: [xbean] mjars handling
Posted by Mark Struberg <st...@yahoo.de>.
+1 but a bit short on time right now.
Might be able to help in a few weeks.
LieGrue,
strub
> Am 27.09.2017 um 16:53 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Hi guys,
>
> how do we want to handle multi release jars?
>
> concretely we need to:
>
> 1. check it is activated in the manifest.mf
> 2. if 1 is "true" then check META-INF/versions/<x>/<fqn>.class exists and read it instead of <fqn>.class
>
> This logic is not hard by itself but has some implication in term of perf since for *each* class we can end up doing this validation.
>
> Do we want to do it the other way? read it all, put the META-INF/versions/<current> in another bucket and merge it after. My assumption is META-INF/versions/* will be way smaller than the opposite so we would just go through the archive once avoiding all the double checks and just have an iteration over a small set of classes during the merge phase at the end.
>
> wdyt?
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory