You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2017/12/20 08:44:39 UTC

[discuss] moving subclassing/proxying to geronimo-xbean?

Hi guys,

open question: what about trying to move our proxying code to
geronimo-xbean?

it can need some work like defining some common interfaces for providers or
things like that  but  the rational behind it is:

1. remove the asm imports from OWB and therefore allows to upgrade xbean
stack without having to release OWB as something mandatory (or using 2
xbean asm shades)
2. this code has a lot of value for libs so could fit commons-proxy but
xbean is a good candidate since it owns the asm shade which is the critical
dependency

any opinion?

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>

Re: [discuss] moving subclassing/proxying to geronimo-xbean?

Posted by Romain Manni-Bucau <rm...@gmail.com>.
2017-12-20 10:25 GMT+01:00 Mark Struberg <st...@yahoo.de.invalid>:

> -0.7 The whole codebase has quite a few direct depenencies to CDI. E.g. we
> have a Bean cache, check for some very specific CDI use case, etc.
> We also do not update ASM often. And we are much faster in reacting to
> changes when having the code here.
>

This is going to not be true anymore with a new asm each 6 months, was my
main concern, and upgrading the full stack (> OWB) is quite too long today.


>
> I have no problem to extract the CDI-neutral parts to somewhere else. We
> already have done this in DeltaSpike. check the DS-proxy stuff.
> And there is also commons-proxy. Also a good library, but we could not use
> it because we needed more CDI specific stuff.
>

Overall goal is to ensure all the asm related features are in a single lib
and the consumers stay stable with such upgrades, that's why i proposed
xbean.

We can wait a few jre releases to see if it hurst or not but migrations
phases are always a pain :(


>
> LieGrue,
> strub
>
>
> > Am 20.12.2017 um 09:44 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Hi guys,
> >
> > open question: what about trying to move our proxying code to
> > geronimo-xbean?
> >
> > it can need some work like defining some common interfaces for providers
> or
> > things like that  but  the rational behind it is:
> >
> > 1. remove the asm imports from OWB and therefore allows to upgrade xbean
> > stack without having to release OWB as something mandatory (or using 2
> > xbean asm shades)
> > 2. this code has a lot of value for libs so could fit commons-proxy but
> > xbean is a good candidate since it owns the asm shade which is the
> critical
> > dependency
> >
> > any opinion?
> >
> > 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>
>
>

Re: [discuss] moving subclassing/proxying to geronimo-xbean?

Posted by Mark Struberg <st...@yahoo.de.INVALID>.
-0.7 The whole codebase has quite a few direct depenencies to CDI. E.g. we have a Bean cache, check for some very specific CDI use case, etc.
We also do not update ASM often. And we are much faster in reacting to changes when having the code here.

I have no problem to extract the CDI-neutral parts to somewhere else. We already have done this in DeltaSpike. check the DS-proxy stuff.
And there is also commons-proxy. Also a good library, but we could not use it because we needed more CDI specific stuff.

LieGrue,
strub


> Am 20.12.2017 um 09:44 schrieb Romain Manni-Bucau <rm...@gmail.com>:
> 
> Hi guys,
> 
> open question: what about trying to move our proxying code to
> geronimo-xbean?
> 
> it can need some work like defining some common interfaces for providers or
> things like that  but  the rational behind it is:
> 
> 1. remove the asm imports from OWB and therefore allows to upgrade xbean
> stack without having to release OWB as something mandatory (or using 2
> xbean asm shades)
> 2. this code has a lot of value for libs so could fit commons-proxy but
> xbean is a good candidate since it owns the asm shade which is the critical
> dependency
> 
> any opinion?
> 
> 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>