Re: [VOTE] Apache OpenWebBeans 2.0.27

[Reinhard Sandtner]

+1

lg
reini

> Am 02.06.2022 um 20:50 schrieb Mark Struberg :
> 
> +1
> 
> txs and LieGrue,
> strub
> 
> 
>> Am 25.05.2022 um 02:24 schrieb Jean-Louis Monteiro 
>> :
>> 
>> Hi folks,
>> 
>> I'd like to get your help on the Apache OpenWebBeans 2.0.27 release.
>> The changes are fairly small, essentially it fixes the relocation patterns
>> for jakarta compatibility, and it does include a couple of dependency
>> upgrades.
>> 
>> Release notes
>> https://issues.apache.org/jira/projects/OWB/versions/12351322
>> 
>> Git Tag
>> https://github.com/apache/openwebbeans/tree/openwebbeans-2.0.27
>> 
>> Sources
>> https://dist.apache.org/repos/dist/dev/openwebbeans/owb/openwebbeans-2.0.27/
>> 
>> Staging repo
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1081
>> 
>> Please vote to approve this release:
>> [ ] +1 Approve the release
>> [ ]  0 Abstain (please provide specific comments)
>> [ ] -1 Don't approve the release (please provide specific comments)
>> 
>> This vote will be open for at least 72 hours.
>> 
>> Thanks
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
> 

Re: [DISCUSS] CDI-4.0 core

[Mark Struberg]

The point is that most of the new API is really for that Quarkus use case. And 
this can be done in a portable extension as well if one wants. So I see zero 
reason to implement it. And also zero reason to have those api classes in my 
classpath. The rest would be mostly for tomee to be able to go forward.

LieGrue,
strub


> Am 03.06.2022 um 08:31 schrieb Romain Manni-Bucau :
> 
> Le jeu. 2 juin 2022 à 22:44, Mark Struberg  a
> écrit :
> 
>> would imo introduce too many layers which might be hard to maintain in the
>> long run. With the current plugin structure you can already run without
>> even class scanning and dynamic bytecode tinkering if one wants.
>> So don't think it's worth to add another layer of abstraction in the
>> middle.
>> 
> 
> Thing is that currently you dont get most benefit, just tech extension
> points to make the run work:
> 
> - you leverage jakarta/javax and their mess+breaking
> changes+inconsistencies from v4
> - you get more than needed in api
> - you have constraints on beans you dont need
> 
> Your proposal is just the same but half baked since we are compatible or we
> are not, this is why I think we should propose something really stable or
> maybe just stick to impl the spec (modularly or not is a detail but tck
> require both parts of the spec so passing only one is pointless for users
> IMHO).
> 
> 
> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 02.06.2022 um 21:32 schrieb Romain Manni-Bucau >> :
>>> 
>>> Hi,
>>> 
>>> Some times ago I proposed to extract a cdi-like-light owb bundle which
>>> would be a minimal IoC without the cdi 2.0 boilerplate and probably
>> unsafe
>>> free to be "all env friendly". This is very close to owb-se except a few
>>> spi, defaults and jakarta dep.
>>> 
>>> Making it cdi-se/ee as an impl sounds more valuable today for the project
>>> IMHO - because we tend to go lightweight cause of the cloud move and
>>> projects stacking too much are not that adopted - and is still compatible
>>> with your idea so can be worth starting owb 3 from these basis with a
>> light
>>> owb IoC api/spi (TBD if we inherit from jakarta or not) and then back
>>> owb-impl by this "owb-core" and finally impl your idea on this new api?
>>> 
>>> 
>>> 
>>> Le jeu. 2 juin 2022 à 21:04, Mark Struberg > > a
>>> écrit :
>>> 
 hi folks!
 
 I had an idea about how we could implement CDI-4.0 without all the
 overhead it brings.
 The goal is to keep OWB as light as possible but as compatible as
>> possible.
 
 The idea is to use the standard eclipse jcdi package and split it in 2
 parts via maven-shade plugin or simple unzip/zip repackaging.
 This is necessary as JBoss refused to do it properly inside the spec
 itself but forced the full 'light' (which is actually adding 30% more
>> code
 to the CDI api) on all users, regardless whether they need it or not.
 
 Here you can find more information about the background of the split and
 how it's done:
 https://github.com/jakartaee/cdi/pull/582 <
 https://github.com/jakartaee/cdi/pull/582 <
>> https://github.com/jakartaee/cdi/pull/582>>
 
 I'd like to do the same, but for now just implement the clasic Jakarta
>> EE
 part without the 'CDI lite' overhead.
 If we later find some time we can still implement CDI-lite as either an
 OWB plugin or even as a standard portable extension. This can be done
>> here
 or as part of TomEE for example.
 
 I think we might be rather quick to get things going that way.
 
 Wdyt about that idea?
 
 LieGrue,
 strub
>> 
>> 

Re: [DISCUSS] CDI-4.0 core

[Romain Manni-Bucau]

Le ven. 3 juin 2022 à 13:34, Mark Struberg  a
écrit :

> The point is that most of the new API is really for that Quarkus use case.
> And this can be done in a portable extension as well if one wants. So I see
> zero reason to implement it. And also zero reason to have those api classes
> in my classpath. The rest would be mostly for tomee to be able to go
> forward.
>

Hmm, I don't see it this way:

1. This is not limited to quarkus case even if it got copied form there and
if I fully agree the spec was wrongly done at technical level (not a single
valid reason to do it this way but several to NOT do it)
2. We have a very valid reason to implement it: we are a CDI impl, if we
start to not be spec compliant we don't have any value until we have our
own API as explained (this is the main exit point for us to not respect the
full spec IMHO)
3. About the classpath: agree, there is also a bug in last cdi release for
jakarta 10 where it brings transitively build classes (no comment)

This is why I think the topic is OWB API vs 100% spec one more than CDI vs
CDI.custom which would be more misleading for most consumers IMHO.


>
> LieGrue,
> strub
>
>
> > Am 03.06.2022 um 08:31 schrieb Romain Manni-Bucau  >:
> >
> > Le jeu. 2 juin 2022 à 22:44, Mark Struberg  a
> > écrit :
> >
> >> would imo introduce too many layers which might be hard to maintain in
> the
> >> long run. With the current plugin structure you can already run without
> >> even class scanning and dynamic bytecode tinkering if one wants.
> >> So don't think it's worth to add another layer of abstraction in the
> >> middle.
> >>
> >
> > Thing is that currently you dont get most benefit, just tech extension
> > points to make the run work:
> >
> > - you leverage jakarta/javax and their mess+breaking
> > changes+inconsistencies from v4
> > - you get more than needed in api
> > - you have constraints on beans you dont need
> >
> > Your proposal is just the same but half baked since we are compatible or
> we
> > are not, this is why I think we should propose something really stable or
> > maybe just stick to impl the spec (modularly or not is a detail but tck
> > require both parts of the spec so passing only one is pointless for users
> > IMHO).
> >
> >
> >
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 02.06.2022 um 21:32 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> Hi,
> >>>
> >>> Some times ago I proposed to extract a cdi-like-light owb bundle which
> >>> would be a minimal IoC without the cdi 2.0 boilerplate and probably
> >> unsafe
> >>> free to be "all env friendly". This is very close to owb-se except a
> few
> >>> spi, defaults and jakarta dep.
> >>>
> >>> Making it cdi-se/ee as an impl sounds more valuable today for the
> project
> >>> IMHO - because we tend to go lightweight cause of the cloud move and
> >>> projects stacking too much are not that adopted - and is still
> compatible
> >>> with your idea so can be worth starting owb 3 from these basis with a
> >> light
> >>> owb IoC api/spi (TBD if we inherit from jakarta or not) and then back
> >>> owb-impl by this "owb-core" and finally impl your idea on this new api?
> >>>
> >>>
> >>>
> >>> Le jeu. 2 juin 2022 à 21:04, Mark Struberg  >> > a
> >>> écrit :
> >>>
>  hi folks!
> 
>  I had an idea about how we could implement CDI-4.0 without all the
>  overhead it brings.
>  The goal is to keep OWB as light as possible but as compatible as
> >> possible.
> 
>  The idea is to use the standard eclipse jcdi package and split it in 2
>  parts via maven-shade plugin or simple unzip/zip repackaging.
>  This is necessary as JBoss refused to do it properly inside the spec
>  itself but forced the full 'light' (which is actually adding 30% more
> >> code
>  to the CDI api) on all users, regardless whether they need it or not.
> 
>  Here you can find more information about the background of the split
> and
>  how it's done:
>  https://github.com/jakartaee/cdi/pull/582 <
>  https://github.com/jakartaee/cdi/pull/582 <
> >> https://github.com/jakartaee/cdi/pull/582>>
> 
>  I'd like to do the same, but for now just implement the clasic Jakarta
> >> EE
>  part without the 'CDI lite' overhead.
>  If we later find some time we can still implement CDI-lite as either
> an
>  OWB plugin or even as a standard portable extension. This can be done
> >> here
>  or as part of TomEE for example.
> 
>  I think we might be rather quick to get things going that way.
> 
>  Wdyt about that idea?
> 
>  LieGrue,
>  strub
> >>
> >>
>
>

Re: Tomcat 7.x EOL

[Rémy Maucherat]

On Tue, May 24, 2022 at 2:10 PM Romain Manni-Bucau
 wrote:
>
> Hi,
>
> Since Tomcat enhanced InstanceManager I guess we can upgrade and decrease a
> lot the hacks/reflection we used by the past.
> Only open point on my side is: is it worth having a tomcat integration? I
> know very few users of that but generally speaking the web integration is
> really sufficient so do we want to keep it or let tomcat handle it -
> https://github.com/apache/tomcat/tree/main/modules/owb?

No problem, I'll keep on doing it (just in case someone comes along
wanting something that depends on cdi). For sure you should
immediately remove any code that depends on or supports Tomcat 7.

Rémy

> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le mar. 24 mai 2022 à 13:09, Jean-Louis Monteiro 
> a écrit :
>
> > Hi,
> >
> > I was doing some dependency updates on OpenWebBeans and wanted to do a
> > release and I noticed we still have Tomcat 7.x in OWB.
> >
> > Shouldn't we try to move to the latest javax compatible version (aka 9.x)?
> > Tomcat 7.x is EOL and has many CVEs.
> >
> > What do you think?
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >