You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Mark Struberg <st...@yahoo.de> on 2018/10/01 10:38:50 UTC
Re: asm7 preparation
We should analyse if ASM7 is a drop-in replacement and can be used in a backward compatible way.
If so, then we could keep the shaded o.a.g.asm6 package and just document it.
If ASM7 removed some old methods, then we really should also shade to a private asm7 package.
LieGrue,
strub
> Am 30.09.2018 um 19:44 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Hi guys,
>
> Asm 7 beta was released yesterday, I'd like to try to release it ASAP.
> I see 1 main point to discuss before releasing: do we keep the version in the package and module name? For now it is required cause we cant guarantee anything about asm compatibility.
>
> Options I see are:
> 1. drop asm and use bcel (which is asf)
> 2. drop asm and reimplement bytecode parsing for our need (but will create issue in most of our stack for proxy creation IMHO)
> 3. keep it like that
> 4. use an "asm.*" package crossing fingers
>
> I'd love 4 but I fear it can create issue quickly when I see what java is becoming so, personally, i think 3 is safe but since we are at "that" moment I'd like to get your feedback.
>
> Side note: if I get no other vote than 3 before tuesday, i'll try to launch the release on tuesday with asm7 module and package to let us get it out.
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
Re: asm7 preparation
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Trying to go back to action: any objection to release master as it (ie with
asm7 module and a dropped asm6 module)? Sounds like the best compromise we
can get - and the same as commons.
Side note: if we need we can create a maintenance branch for asm6 but from
experience we always moved forward - cause java support way ;) - and never
needed to go back so sounds good enough to move forward to keep trunk as it.
If no objection I will try to launch it hopefully tomorrow or later this
week.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 2 oct. 2018 à 09:21, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
>
>
>
>
> Le mar. 2 oct. 2018 à 00:34, David Blevins <da...@gmail.com> a
> écrit :
>
>> > On Oct 1, 2018, at 7:12 AM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>> >
>> > :) as usual with asm, looks ok but breaks several apps ;). But main
>> point is: do we want to export as asm6 the real asm7 and fake the runtime
>> it will work? If we want a smooth upgrade we can update asm6 module to have
>> some of changes but keep asm7 module to ensure we cover it IMHO.
>>
>> We should definitely not introduce ASM 7 code into our asm6 module.
>>
>> Another topic is we've been on ASM 6 for 2 years. Should we change the
>> XBean major version to 5 when we switch to ASM 7?
>>
>
> Since some years I really think we should explode xbean to be able to have
> this real versioning otherwise we are always between "this part needs a new
> major but not this one for consistency".
>
>
>>
>> That would give us the option to keep pushing out XBean 4.x releases with
>> further ASM 6 updates for those who can't/won't upgrade yet or also have
>> stable branches to maintain.
>>
>
> Strictly speaking we can have asm[3-7] in the same source tree so not sure
> it helps to move in one direction or the other.
>
>
>>
>> If if we don't change the major version and any critical bugs or security
>> vulnerabilities hit XBean 4.10, we'd have to do a 4.10.1. If that happened
>> a few times we'd find ourselves with 4.10.2, 4.10.3 and effectively
>> maintaining a de facto branch, just after the fact and in a very awkward
>> way.
>>
>
> I actually like that for multiple reasons:
>
> 1. upgrading is a very doable work for all projects which would require
> such an upgrade so not a blocker
> 2. we can always lazily create a maintenance branch from a tag (vs eagerly
> which is generally useless) and when done it does not get more love than
> the CVE fix if it exists
>
> At the end it is the less costly solution IMHO.
>
>
>>
>>
>> -David
>>
>>
Re: asm7 preparation
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mar. 2 oct. 2018 à 00:34, David Blevins <da...@gmail.com> a
écrit :
> > On Oct 1, 2018, at 7:12 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > :) as usual with asm, looks ok but breaks several apps ;). But main
> point is: do we want to export as asm6 the real asm7 and fake the runtime
> it will work? If we want a smooth upgrade we can update asm6 module to have
> some of changes but keep asm7 module to ensure we cover it IMHO.
>
> We should definitely not introduce ASM 7 code into our asm6 module.
>
> Another topic is we've been on ASM 6 for 2 years. Should we change the
> XBean major version to 5 when we switch to ASM 7?
>
Since some years I really think we should explode xbean to be able to have
this real versioning otherwise we are always between "this part needs a new
major but not this one for consistency".
>
> That would give us the option to keep pushing out XBean 4.x releases with
> further ASM 6 updates for those who can't/won't upgrade yet or also have
> stable branches to maintain.
>
Strictly speaking we can have asm[3-7] in the same source tree so not sure
it helps to move in one direction or the other.
>
> If if we don't change the major version and any critical bugs or security
> vulnerabilities hit XBean 4.10, we'd have to do a 4.10.1. If that happened
> a few times we'd find ourselves with 4.10.2, 4.10.3 and effectively
> maintaining a de facto branch, just after the fact and in a very awkward
> way.
>
I actually like that for multiple reasons:
1. upgrading is a very doable work for all projects which would require
such an upgrade so not a blocker
2. we can always lazily create a maintenance branch from a tag (vs eagerly
which is generally useless) and when done it does not get more love than
the CVE fix if it exists
At the end it is the less costly solution IMHO.
>
>
> -David
>
>
Re: asm7 preparation
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ok, then i'll try to launch 4.11 today, thanks guys and noted that we must
discuss xbean future soon - we can plan it for next year maybe?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 2 oct. 2018 à 23:11, David Blevins <da...@gmail.com> a
écrit :
> > On Oct 2, 2018, at 8:48 AM, Mark Struberg <st...@yahoo.de> wrote:
> >
> > Otoh I'm totally fine either ways.
>
> For clarity, though I made the suggestion, I'm fine either way as well.
>
> There might be a few 4.10.x in our future, but it wouldn't be terrible.
>
> I definitely see how a 5x change has the opportunity to make everyone
> suddenly ambitious which usually pushes things out.
>
> I'm good with whatever.
>
>
> -David
>
>
Re: asm7 preparation
Posted by David Blevins <da...@gmail.com>.
> On Oct 2, 2018, at 8:48 AM, Mark Struberg <st...@yahoo.de> wrote:
>
> Otoh I'm totally fine either ways.
For clarity, though I made the suggestion, I'm fine either way as well.
There might be a few 4.10.x in our future, but it wouldn't be terrible.
I definitely see how a 5x change has the opportunity to make everyone suddenly ambitious which usually pushes things out.
I'm good with whatever.
-David
Re: asm7 preparation
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Think we are all about xbean 4 ;).
Agree it shouldn't be an issue and more than a snapshot state to have 2 asm
versions in tomee now.
Side note: my personal feeling is that we'll explode xbean and never do a
5.x to have an asm (asm shade + util + proxy base tool?) subproject and
telnet, blueprint etc subprojects. Would simplify the maintenance and
lifecycle...but this is another thread of discussion for later ;).
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 2 oct. 2018 à 17:48, Mark Struberg <st...@yahoo.de> a écrit :
> Not 100% sure we should go xbean-5.x. Otoh I'm totally fine either ways.
> We might end up pushing the major version every half a year with the new
> Java cadence :(
>
> Another thought:
> It might happen that we have both shaded asm6 and 7 for a short period in
> time in TomEE.
> But as soon as xbean-asm7 is done I'll run OpenJPA and OpenWebBeans
> releases with the new xbean-asm7.
> So this period should really only be very short. And possibly we even
> manage to get it down to nada.
>
> LieGrue,
> strub
>
> > Am 02.10.2018 um 00:34 schrieb David Blevins <da...@gmail.com>:
> >
> >> On Oct 1, 2018, at 7:12 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >>
> >> :) as usual with asm, looks ok but breaks several apps ;). But main
> point is: do we want to export as asm6 the real asm7 and fake the runtime
> it will work? If we want a smooth upgrade we can update asm6 module to have
> some of changes but keep asm7 module to ensure we cover it IMHO.
> >
> > We should definitely not introduce ASM 7 code into our asm6 module.
> >
> > Another topic is we've been on ASM 6 for 2 years. Should we change the
> XBean major version to 5 when we switch to ASM 7?
> >
> > That would give us the option to keep pushing out XBean 4.x releases
> with further ASM 6 updates for those who can't/won't upgrade yet or also
> have stable branches to maintain.
> >
> > If if we don't change the major version and any critical bugs or
> security vulnerabilities hit XBean 4.10, we'd have to do a 4.10.1. If that
> happened a few times we'd find ourselves with 4.10.2, 4.10.3 and
> effectively maintaining a de facto branch, just after the fact and in a
> very awkward way.
> >
> >
> > -David
> >
>
>
Re: asm7 preparation
Posted by Mark Struberg <st...@yahoo.de>.
Not 100% sure we should go xbean-5.x. Otoh I'm totally fine either ways.
We might end up pushing the major version every half a year with the new Java cadence :(
Another thought:
It might happen that we have both shaded asm6 and 7 for a short period in time in TomEE.
But as soon as xbean-asm7 is done I'll run OpenJPA and OpenWebBeans releases with the new xbean-asm7.
So this period should really only be very short. And possibly we even manage to get it down to nada.
LieGrue,
strub
> Am 02.10.2018 um 00:34 schrieb David Blevins <da...@gmail.com>:
>
>> On Oct 1, 2018, at 7:12 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>>
>> :) as usual with asm, looks ok but breaks several apps ;). But main point is: do we want to export as asm6 the real asm7 and fake the runtime it will work? If we want a smooth upgrade we can update asm6 module to have some of changes but keep asm7 module to ensure we cover it IMHO.
>
> We should definitely not introduce ASM 7 code into our asm6 module.
>
> Another topic is we've been on ASM 6 for 2 years. Should we change the XBean major version to 5 when we switch to ASM 7?
>
> That would give us the option to keep pushing out XBean 4.x releases with further ASM 6 updates for those who can't/won't upgrade yet or also have stable branches to maintain.
>
> If if we don't change the major version and any critical bugs or security vulnerabilities hit XBean 4.10, we'd have to do a 4.10.1. If that happened a few times we'd find ourselves with 4.10.2, 4.10.3 and effectively maintaining a de facto branch, just after the fact and in a very awkward way.
>
>
> -David
>
Re: asm7 preparation
Posted by David Blevins <da...@gmail.com>.
> On Oct 1, 2018, at 7:12 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> :) as usual with asm, looks ok but breaks several apps ;). But main point is: do we want to export as asm6 the real asm7 and fake the runtime it will work? If we want a smooth upgrade we can update asm6 module to have some of changes but keep asm7 module to ensure we cover it IMHO.
We should definitely not introduce ASM 7 code into our asm6 module.
Another topic is we've been on ASM 6 for 2 years. Should we change the XBean major version to 5 when we switch to ASM 7?
That would give us the option to keep pushing out XBean 4.x releases with further ASM 6 updates for those who can't/won't upgrade yet or also have stable branches to maintain.
If if we don't change the major version and any critical bugs or security vulnerabilities hit XBean 4.10, we'd have to do a 4.10.1. If that happened a few times we'd find ourselves with 4.10.2, 4.10.3 and effectively maintaining a de facto branch, just after the fact and in a very awkward way.
-David
Re: asm7 preparation
Posted by Romain Manni-Bucau <rm...@gmail.com>.
:) as usual with asm, looks ok but breaks several apps ;). But main point
is: do we want to export as asm6 the real asm7 and fake the runtime it will
work? If we want a smooth upgrade we can update asm6 module to have some of
changes but keep asm7 module to ensure we cover it IMHO.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 1 oct. 2018 à 16:03, Raymond Auge <ra...@liferay.com> a
écrit :
> FYI, here's a diff of the API
>
> https://gist.github.com/rotty3000/a68c8ea494f4c1b2e304822dc8a72a66
>
> It doesn't look that scary tbh. Only couple methods changed which were
> already marked experimental and just normalized into the regular API, same
> for a couple of constants, and one other method removed and exploded into 3.
>
> Hope this helps,
> - Ray
>
> On Mon, Oct 1, 2018 at 9:39 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>>
>> @Raymond: no worries ->
>> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-asm7-shaded/
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le lun. 1 oct. 2018 à 15:37, Raymond Auge <ra...@liferay.com> a
>> écrit :
>>
>>> Sorry for the newbie interruption. But can someone point me to the
>>> relevant code/project/module in Geronimo that has this asm integration?
>>>
>>> Thanks,
>>> - Ray
>>>
>>> On Mon, Oct 1, 2018 at 8:30 AM Romain Manni-Bucau <rm...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>>
>>>> Le lun. 1 oct. 2018 à 14:26, Mark Struberg <st...@yahoo.de> a
>>>> écrit :
>>>>
>>>>> Introducing our own API doesn't make much sense to me.
>>>>>
>>>>
>>>> Agree cause it is not just an xbean internal
>>>>
>>>>
>>>>> The challenges (support for new unknown Java versions) would be
>>>>> exactly the same as ASM has.
>>>>>
>>>>
>>>> It wouldn't if we would be in asm scope cause we would use a very
>>>> limited set of asm features. We are kind in a situation where we use 10% of
>>>> the features and expose 100% by construction :(.
>>>>
>>>>
>>>>> So we would in the end also be forced to break the API :(
>>>>> Remember that the main reason we created the whole shading for is to
>>>>> allow to upgrade parts of the stack without interfering with a.) some
>>>>> custom apps and b.) each other.
>>>>>
>>>>
>>>> Agree.
>>>>
>>>>
>>>>>
>>>>> Right now you can just swap out openjpa in TomEE for example. All you
>>>>> need to do is to _potentially_ also add another xbean-asm version.
>>>>> And that is good that way imo.
>>>>>
>>>>
>>>> Ok so you confirm keeping the pattern we use (ie going with asm7) is ok
>>>> for you?
>>>>
>>>> FYI the diff:
>>>> https://gitlab.ow2.org/asm/asm/compare/ASM_6_2_1...ASM_7_0_BETA
>>>> But some impl changes are not just fixes and even if signatures don't
>>>> always change I think it is sane to not put a v7 in an asm6 package/module
>>>> - same as for java 8 upgrade where the verifier was stricter.
>>>>
>>>>
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>> > Am 01.10.2018 um 14:12 schrieb Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com>:
>>>>> >
>>>>> >
>>>>> >
>>>>> > Le lun. 1 oct. 2018 à 12:39, Mark Struberg <st...@yahoo.de> a
>>>>> écrit :
>>>>> > We should analyse if ASM7 is a drop-in replacement and can be used
>>>>> in a backward compatible way.
>>>>> >
>>>>> > Didn't review everything but there are some changes in the impl
>>>>> which are not compatible and why we must upgrade even if asm 6.2.1 had some
>>>>> good java 11 support.
>>>>> >
>>>>> > If so, then we could keep the shaded o.a.g.asm6 package and just
>>>>> document it.
>>>>> >
>>>>> > I thought about it but it sounds so dangerous and hard to control on
>>>>> the long run than upgrading all our stack sounds worth it for me.
>>>>> >
>>>>> > If ASM7 removed some old methods, then we really should also shade
>>>>> to a private asm7 package.
>>>>> >
>>>>> > This lead to the option to not expose ASM at all and create our own
>>>>> API but it breaks the reason why all our stack uses this shade: have a
>>>>> fully featured ASM usable by proxying impl of the full stack
>>>>> > and share it with the scanner. This is why I thought we can't really
>>>>> fake the package without serious risk, we expose a too big coverage now
>>>>> (cxf, openjpa, xbean, big data engines, user apps, ...).
>>>>> >
>>>>> >
>>>>> > LieGrue,
>>>>> > strub
>>>>> >
>>>>> >
>>>>> > > Am 30.09.2018 um 19:44 schrieb Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com>:
>>>>> > >
>>>>> > > Hi guys,
>>>>> > >
>>>>> > > Asm 7 beta was released yesterday, I'd like to try to release it
>>>>> ASAP.
>>>>> > > I see 1 main point to discuss before releasing: do we keep the
>>>>> version in the package and module name? For now it is required cause we
>>>>> cant guarantee anything about asm compatibility.
>>>>> > >
>>>>> > > Options I see are:
>>>>> > > 1. drop asm and use bcel (which is asf)
>>>>> > > 2. drop asm and reimplement bytecode parsing for our need (but
>>>>> will create issue in most of our stack for proxy creation IMHO)
>>>>> > > 3. keep it like that
>>>>> > > 4. use an "asm.*" package crossing fingers
>>>>> > >
>>>>> > > I'd love 4 but I fear it can create issue quickly when I see what
>>>>> java is becoming so, personally, i think 3 is safe but since we are at
>>>>> "that" moment I'd like to get your feedback.
>>>>> > >
>>>>> > > Side note: if I get no other vote than 3 before tuesday, i'll try
>>>>> to launch the release on tuesday with asm7 module and package to let us get
>>>>> it out.
>>>>> > >
>>>>> > > Romain Manni-Bucau
>>>>> > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>>>>> >
>>>>>
>>>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>> (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>>> (@OSGiAlliance)
>>>
>>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
Re: asm7 preparation
Posted by Raymond Auge <ra...@liferay.com>.
FYI, here's a diff of the API
https://gist.github.com/rotty3000/a68c8ea494f4c1b2e304822dc8a72a66
It doesn't look that scary tbh. Only couple methods changed which were
already marked experimental and just normalized into the regular API, same
for a couple of constants, and one other method removed and exploded into 3.
Hope this helps,
- Ray
On Mon, Oct 1, 2018 at 9:39 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
> @Raymond: no worries ->
> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-asm7-shaded/
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le lun. 1 oct. 2018 à 15:37, Raymond Auge <ra...@liferay.com> a
> écrit :
>
>> Sorry for the newbie interruption. But can someone point me to the
>> relevant code/project/module in Geronimo that has this asm integration?
>>
>> Thanks,
>> - Ray
>>
>> On Mon, Oct 1, 2018 at 8:30 AM Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>
>>>
>>>
>>>
>>> Le lun. 1 oct. 2018 à 14:26, Mark Struberg <st...@yahoo.de> a écrit :
>>>
>>>> Introducing our own API doesn't make much sense to me.
>>>>
>>>
>>> Agree cause it is not just an xbean internal
>>>
>>>
>>>> The challenges (support for new unknown Java versions) would be exactly
>>>> the same as ASM has.
>>>>
>>>
>>> It wouldn't if we would be in asm scope cause we would use a very
>>> limited set of asm features. We are kind in a situation where we use 10% of
>>> the features and expose 100% by construction :(.
>>>
>>>
>>>> So we would in the end also be forced to break the API :(
>>>> Remember that the main reason we created the whole shading for is to
>>>> allow to upgrade parts of the stack without interfering with a.) some
>>>> custom apps and b.) each other.
>>>>
>>>
>>> Agree.
>>>
>>>
>>>>
>>>> Right now you can just swap out openjpa in TomEE for example. All you
>>>> need to do is to _potentially_ also add another xbean-asm version.
>>>> And that is good that way imo.
>>>>
>>>
>>> Ok so you confirm keeping the pattern we use (ie going with asm7) is ok
>>> for you?
>>>
>>> FYI the diff:
>>> https://gitlab.ow2.org/asm/asm/compare/ASM_6_2_1...ASM_7_0_BETA
>>> But some impl changes are not just fixes and even if signatures don't
>>> always change I think it is sane to not put a v7 in an asm6 package/module
>>> - same as for java 8 upgrade where the verifier was stricter.
>>>
>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>> > Am 01.10.2018 um 14:12 schrieb Romain Manni-Bucau <
>>>> rmannibucau@gmail.com>:
>>>> >
>>>> >
>>>> >
>>>> > Le lun. 1 oct. 2018 à 12:39, Mark Struberg <st...@yahoo.de> a
>>>> écrit :
>>>> > We should analyse if ASM7 is a drop-in replacement and can be used in
>>>> a backward compatible way.
>>>> >
>>>> > Didn't review everything but there are some changes in the impl which
>>>> are not compatible and why we must upgrade even if asm 6.2.1 had some good
>>>> java 11 support.
>>>> >
>>>> > If so, then we could keep the shaded o.a.g.asm6 package and just
>>>> document it.
>>>> >
>>>> > I thought about it but it sounds so dangerous and hard to control on
>>>> the long run than upgrading all our stack sounds worth it for me.
>>>> >
>>>> > If ASM7 removed some old methods, then we really should also shade to
>>>> a private asm7 package.
>>>> >
>>>> > This lead to the option to not expose ASM at all and create our own
>>>> API but it breaks the reason why all our stack uses this shade: have a
>>>> fully featured ASM usable by proxying impl of the full stack
>>>> > and share it with the scanner. This is why I thought we can't really
>>>> fake the package without serious risk, we expose a too big coverage now
>>>> (cxf, openjpa, xbean, big data engines, user apps, ...).
>>>> >
>>>> >
>>>> > LieGrue,
>>>> > strub
>>>> >
>>>> >
>>>> > > Am 30.09.2018 um 19:44 schrieb Romain Manni-Bucau <
>>>> rmannibucau@gmail.com>:
>>>> > >
>>>> > > Hi guys,
>>>> > >
>>>> > > Asm 7 beta was released yesterday, I'd like to try to release it
>>>> ASAP.
>>>> > > I see 1 main point to discuss before releasing: do we keep the
>>>> version in the package and module name? For now it is required cause we
>>>> cant guarantee anything about asm compatibility.
>>>> > >
>>>> > > Options I see are:
>>>> > > 1. drop asm and use bcel (which is asf)
>>>> > > 2. drop asm and reimplement bytecode parsing for our need (but will
>>>> create issue in most of our stack for proxy creation IMHO)
>>>> > > 3. keep it like that
>>>> > > 4. use an "asm.*" package crossing fingers
>>>> > >
>>>> > > I'd love 4 but I fear it can create issue quickly when I see what
>>>> java is becoming so, personally, i think 3 is safe but since we are at
>>>> "that" moment I'd like to get your feedback.
>>>> > >
>>>> > > Side note: if I get no other vote than 3 before tuesday, i'll try
>>>> to launch the release on tuesday with asm7 module and package to let us get
>>>> it out.
>>>> > >
>>>> > > Romain Manni-Bucau
>>>> > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>>>> >
>>>>
>>>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>> (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>> (@OSGiAlliance)
>>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: asm7 preparation
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Raymond: no worries ->
http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-asm7-shaded/
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 1 oct. 2018 à 15:37, Raymond Auge <ra...@liferay.com> a
écrit :
> Sorry for the newbie interruption. But can someone point me to the
> relevant code/project/module in Geronimo that has this asm integration?
>
> Thanks,
> - Ray
>
> On Mon, Oct 1, 2018 at 8:30 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>>
>>
>>
>> Le lun. 1 oct. 2018 à 14:26, Mark Struberg <st...@yahoo.de> a écrit :
>>
>>> Introducing our own API doesn't make much sense to me.
>>>
>>
>> Agree cause it is not just an xbean internal
>>
>>
>>> The challenges (support for new unknown Java versions) would be exactly
>>> the same as ASM has.
>>>
>>
>> It wouldn't if we would be in asm scope cause we would use a very limited
>> set of asm features. We are kind in a situation where we use 10% of the
>> features and expose 100% by construction :(.
>>
>>
>>> So we would in the end also be forced to break the API :(
>>> Remember that the main reason we created the whole shading for is to
>>> allow to upgrade parts of the stack without interfering with a.) some
>>> custom apps and b.) each other.
>>>
>>
>> Agree.
>>
>>
>>>
>>> Right now you can just swap out openjpa in TomEE for example. All you
>>> need to do is to _potentially_ also add another xbean-asm version.
>>> And that is good that way imo.
>>>
>>
>> Ok so you confirm keeping the pattern we use (ie going with asm7) is ok
>> for you?
>>
>> FYI the diff:
>> https://gitlab.ow2.org/asm/asm/compare/ASM_6_2_1...ASM_7_0_BETA
>> But some impl changes are not just fixes and even if signatures don't
>> always change I think it is sane to not put a v7 in an asm6 package/module
>> - same as for java 8 upgrade where the verifier was stricter.
>>
>>
>>>
>>> LieGrue,
>>> strub
>>>
>>> > Am 01.10.2018 um 14:12 schrieb Romain Manni-Bucau <
>>> rmannibucau@gmail.com>:
>>> >
>>> >
>>> >
>>> > Le lun. 1 oct. 2018 à 12:39, Mark Struberg <st...@yahoo.de> a
>>> écrit :
>>> > We should analyse if ASM7 is a drop-in replacement and can be used in
>>> a backward compatible way.
>>> >
>>> > Didn't review everything but there are some changes in the impl which
>>> are not compatible and why we must upgrade even if asm 6.2.1 had some good
>>> java 11 support.
>>> >
>>> > If so, then we could keep the shaded o.a.g.asm6 package and just
>>> document it.
>>> >
>>> > I thought about it but it sounds so dangerous and hard to control on
>>> the long run than upgrading all our stack sounds worth it for me.
>>> >
>>> > If ASM7 removed some old methods, then we really should also shade to
>>> a private asm7 package.
>>> >
>>> > This lead to the option to not expose ASM at all and create our own
>>> API but it breaks the reason why all our stack uses this shade: have a
>>> fully featured ASM usable by proxying impl of the full stack
>>> > and share it with the scanner. This is why I thought we can't really
>>> fake the package without serious risk, we expose a too big coverage now
>>> (cxf, openjpa, xbean, big data engines, user apps, ...).
>>> >
>>> >
>>> > LieGrue,
>>> > strub
>>> >
>>> >
>>> > > Am 30.09.2018 um 19:44 schrieb Romain Manni-Bucau <
>>> rmannibucau@gmail.com>:
>>> > >
>>> > > Hi guys,
>>> > >
>>> > > Asm 7 beta was released yesterday, I'd like to try to release it
>>> ASAP.
>>> > > I see 1 main point to discuss before releasing: do we keep the
>>> version in the package and module name? For now it is required cause we
>>> cant guarantee anything about asm compatibility.
>>> > >
>>> > > Options I see are:
>>> > > 1. drop asm and use bcel (which is asf)
>>> > > 2. drop asm and reimplement bytecode parsing for our need (but will
>>> create issue in most of our stack for proxy creation IMHO)
>>> > > 3. keep it like that
>>> > > 4. use an "asm.*" package crossing fingers
>>> > >
>>> > > I'd love 4 but I fear it can create issue quickly when I see what
>>> java is becoming so, personally, i think 3 is safe but since we are at
>>> "that" moment I'd like to get your feedback.
>>> > >
>>> > > Side note: if I get no other vote than 3 before tuesday, i'll try to
>>> launch the release on tuesday with asm7 module and package to let us get it
>>> out.
>>> > >
>>> > > Romain Manni-Bucau
>>> > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>>> >
>>>
>>>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
Re: asm7 preparation
Posted by Raymond Auge <ra...@liferay.com>.
Sorry for the newbie interruption. But can someone point me to the relevant
code/project/module in Geronimo that has this asm integration?
Thanks,
- Ray
On Mon, Oct 1, 2018 at 8:30 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
>
>
> Le lun. 1 oct. 2018 à 14:26, Mark Struberg <st...@yahoo.de> a écrit :
>
>> Introducing our own API doesn't make much sense to me.
>>
>
> Agree cause it is not just an xbean internal
>
>
>> The challenges (support for new unknown Java versions) would be exactly
>> the same as ASM has.
>>
>
> It wouldn't if we would be in asm scope cause we would use a very limited
> set of asm features. We are kind in a situation where we use 10% of the
> features and expose 100% by construction :(.
>
>
>> So we would in the end also be forced to break the API :(
>> Remember that the main reason we created the whole shading for is to
>> allow to upgrade parts of the stack without interfering with a.) some
>> custom apps and b.) each other.
>>
>
> Agree.
>
>
>>
>> Right now you can just swap out openjpa in TomEE for example. All you
>> need to do is to _potentially_ also add another xbean-asm version.
>> And that is good that way imo.
>>
>
> Ok so you confirm keeping the pattern we use (ie going with asm7) is ok
> for you?
>
> FYI the diff:
> https://gitlab.ow2.org/asm/asm/compare/ASM_6_2_1...ASM_7_0_BETA
> But some impl changes are not just fixes and even if signatures don't
> always change I think it is sane to not put a v7 in an asm6 package/module
> - same as for java 8 upgrade where the verifier was stricter.
>
>
>>
>> LieGrue,
>> strub
>>
>> > Am 01.10.2018 um 14:12 schrieb Romain Manni-Bucau <
>> rmannibucau@gmail.com>:
>> >
>> >
>> >
>> > Le lun. 1 oct. 2018 à 12:39, Mark Struberg <st...@yahoo.de> a écrit
>> :
>> > We should analyse if ASM7 is a drop-in replacement and can be used in a
>> backward compatible way.
>> >
>> > Didn't review everything but there are some changes in the impl which
>> are not compatible and why we must upgrade even if asm 6.2.1 had some good
>> java 11 support.
>> >
>> > If so, then we could keep the shaded o.a.g.asm6 package and just
>> document it.
>> >
>> > I thought about it but it sounds so dangerous and hard to control on
>> the long run than upgrading all our stack sounds worth it for me.
>> >
>> > If ASM7 removed some old methods, then we really should also shade to a
>> private asm7 package.
>> >
>> > This lead to the option to not expose ASM at all and create our own API
>> but it breaks the reason why all our stack uses this shade: have a fully
>> featured ASM usable by proxying impl of the full stack
>> > and share it with the scanner. This is why I thought we can't really
>> fake the package without serious risk, we expose a too big coverage now
>> (cxf, openjpa, xbean, big data engines, user apps, ...).
>> >
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> > > Am 30.09.2018 um 19:44 schrieb Romain Manni-Bucau <
>> rmannibucau@gmail.com>:
>> > >
>> > > Hi guys,
>> > >
>> > > Asm 7 beta was released yesterday, I'd like to try to release it ASAP.
>> > > I see 1 main point to discuss before releasing: do we keep the
>> version in the package and module name? For now it is required cause we
>> cant guarantee anything about asm compatibility.
>> > >
>> > > Options I see are:
>> > > 1. drop asm and use bcel (which is asf)
>> > > 2. drop asm and reimplement bytecode parsing for our need (but will
>> create issue in most of our stack for proxy creation IMHO)
>> > > 3. keep it like that
>> > > 4. use an "asm.*" package crossing fingers
>> > >
>> > > I'd love 4 but I fear it can create issue quickly when I see what
>> java is becoming so, personally, i think 3 is safe but since we are at
>> "that" moment I'd like to get your feedback.
>> > >
>> > > Side note: if I get no other vote than 3 before tuesday, i'll try to
>> launch the release on tuesday with asm7 module and package to let us get it
>> out.
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>> >
>>
>>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: asm7 preparation
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le lun. 1 oct. 2018 à 14:26, Mark Struberg <st...@yahoo.de> a écrit :
> Introducing our own API doesn't make much sense to me.
>
Agree cause it is not just an xbean internal
> The challenges (support for new unknown Java versions) would be exactly
> the same as ASM has.
>
It wouldn't if we would be in asm scope cause we would use a very limited
set of asm features. We are kind in a situation where we use 10% of the
features and expose 100% by construction :(.
> So we would in the end also be forced to break the API :(
> Remember that the main reason we created the whole shading for is to allow
> to upgrade parts of the stack without interfering with a.) some custom apps
> and b.) each other.
>
Agree.
>
> Right now you can just swap out openjpa in TomEE for example. All you need
> to do is to _potentially_ also add another xbean-asm version.
> And that is good that way imo.
>
Ok so you confirm keeping the pattern we use (ie going with asm7) is ok for
you?
FYI the diff:
https://gitlab.ow2.org/asm/asm/compare/ASM_6_2_1...ASM_7_0_BETA
But some impl changes are not just fixes and even if signatures don't
always change I think it is sane to not put a v7 in an asm6 package/module
- same as for java 8 upgrade where the verifier was stricter.
>
> LieGrue,
> strub
>
> > Am 01.10.2018 um 14:12 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> >
> >
> > Le lun. 1 oct. 2018 à 12:39, Mark Struberg <st...@yahoo.de> a écrit :
> > We should analyse if ASM7 is a drop-in replacement and can be used in a
> backward compatible way.
> >
> > Didn't review everything but there are some changes in the impl which
> are not compatible and why we must upgrade even if asm 6.2.1 had some good
> java 11 support.
> >
> > If so, then we could keep the shaded o.a.g.asm6 package and just
> document it.
> >
> > I thought about it but it sounds so dangerous and hard to control on the
> long run than upgrading all our stack sounds worth it for me.
> >
> > If ASM7 removed some old methods, then we really should also shade to a
> private asm7 package.
> >
> > This lead to the option to not expose ASM at all and create our own API
> but it breaks the reason why all our stack uses this shade: have a fully
> featured ASM usable by proxying impl of the full stack
> > and share it with the scanner. This is why I thought we can't really
> fake the package without serious risk, we expose a too big coverage now
> (cxf, openjpa, xbean, big data engines, user apps, ...).
> >
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 30.09.2018 um 19:44 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com>:
> > >
> > > Hi guys,
> > >
> > > Asm 7 beta was released yesterday, I'd like to try to release it ASAP.
> > > I see 1 main point to discuss before releasing: do we keep the version
> in the package and module name? For now it is required cause we cant
> guarantee anything about asm compatibility.
> > >
> > > Options I see are:
> > > 1. drop asm and use bcel (which is asf)
> > > 2. drop asm and reimplement bytecode parsing for our need (but will
> create issue in most of our stack for proxy creation IMHO)
> > > 3. keep it like that
> > > 4. use an "asm.*" package crossing fingers
> > >
> > > I'd love 4 but I fear it can create issue quickly when I see what java
> is becoming so, personally, i think 3 is safe but since we are at "that"
> moment I'd like to get your feedback.
> > >
> > > Side note: if I get no other vote than 3 before tuesday, i'll try to
> launch the release on tuesday with asm7 module and package to let us get it
> out.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
> >
>
>
Re: asm7 preparation
Posted by Mark Struberg <st...@yahoo.de>.
Introducing our own API doesn't make much sense to me.
The challenges (support for new unknown Java versions) would be exactly the same as ASM has.
So we would in the end also be forced to break the API :(
Remember that the main reason we created the whole shading for is to allow to upgrade parts of the stack without interfering with a.) some custom apps and b.) each other.
Right now you can just swap out openjpa in TomEE for example. All you need to do is to _potentially_ also add another xbean-asm version.
And that is good that way imo.
LieGrue,
strub
> Am 01.10.2018 um 14:12 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
>
>
> Le lun. 1 oct. 2018 à 12:39, Mark Struberg <st...@yahoo.de> a écrit :
> We should analyse if ASM7 is a drop-in replacement and can be used in a backward compatible way.
>
> Didn't review everything but there are some changes in the impl which are not compatible and why we must upgrade even if asm 6.2.1 had some good java 11 support.
>
> If so, then we could keep the shaded o.a.g.asm6 package and just document it.
>
> I thought about it but it sounds so dangerous and hard to control on the long run than upgrading all our stack sounds worth it for me.
>
> If ASM7 removed some old methods, then we really should also shade to a private asm7 package.
>
> This lead to the option to not expose ASM at all and create our own API but it breaks the reason why all our stack uses this shade: have a fully featured ASM usable by proxying impl of the full stack
> and share it with the scanner. This is why I thought we can't really fake the package without serious risk, we expose a too big coverage now (cxf, openjpa, xbean, big data engines, user apps, ...).
>
>
> LieGrue,
> strub
>
>
> > Am 30.09.2018 um 19:44 schrieb Romain Manni-Bucau <rm...@gmail.com>:
> >
> > Hi guys,
> >
> > Asm 7 beta was released yesterday, I'd like to try to release it ASAP.
> > I see 1 main point to discuss before releasing: do we keep the version in the package and module name? For now it is required cause we cant guarantee anything about asm compatibility.
> >
> > Options I see are:
> > 1. drop asm and use bcel (which is asf)
> > 2. drop asm and reimplement bytecode parsing for our need (but will create issue in most of our stack for proxy creation IMHO)
> > 3. keep it like that
> > 4. use an "asm.*" package crossing fingers
> >
> > I'd love 4 but I fear it can create issue quickly when I see what java is becoming so, personally, i think 3 is safe but since we are at "that" moment I'd like to get your feedback.
> >
> > Side note: if I get no other vote than 3 before tuesday, i'll try to launch the release on tuesday with asm7 module and package to let us get it out.
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>
Re: asm7 preparation
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le lun. 1 oct. 2018 à 12:39, Mark Struberg <st...@yahoo.de> a écrit :
> We should analyse if ASM7 is a drop-in replacement and can be used in a
> backward compatible way.
>
Didn't review everything but there are some changes in the impl which are
not compatible and why we must upgrade even if asm 6.2.1 had some good java
11 support.
> If so, then we could keep the shaded o.a.g.asm6 package and just document
> it.
>
I thought about it but it sounds so dangerous and hard to control on the
long run than upgrading all our stack sounds worth it for me.
> If ASM7 removed some old methods, then we really should also shade to a
> private asm7 package.
>
This lead to the option to not expose ASM at all and create our own API but
it breaks the reason why all our stack uses this shade: have a fully
featured ASM usable by proxying impl of the full stack
and share it with the scanner. This is why I thought we can't really fake
the package without serious risk, we expose a too big coverage now (cxf,
openjpa, xbean, big data engines, user apps, ...).
>
> LieGrue,
> strub
>
>
> > Am 30.09.2018 um 19:44 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Hi guys,
> >
> > Asm 7 beta was released yesterday, I'd like to try to release it ASAP.
> > I see 1 main point to discuss before releasing: do we keep the version
> in the package and module name? For now it is required cause we cant
> guarantee anything about asm compatibility.
> >
> > Options I see are:
> > 1. drop asm and use bcel (which is asf)
> > 2. drop asm and reimplement bytecode parsing for our need (but will
> create issue in most of our stack for proxy creation IMHO)
> > 3. keep it like that
> > 4. use an "asm.*" package crossing fingers
> >
> > I'd love 4 but I fear it can create issue quickly when I see what java
> is becoming so, personally, i think 3 is safe but since we are at "that"
> moment I'd like to get your feedback.
> >
> > Side note: if I get no other vote than 3 before tuesday, i'll try to
> launch the release on tuesday with asm7 module and package to let us get it
> out.
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>
>