You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Mark Struberg <st...@yahoo.de.INVALID> on 2022/06/02 19:03:28 UTC
[DISCUSS] CDI-4.0 core
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>
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
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
> Unrelated side note that annoys the heck out of me: the Spec Committee literally had a vote that no specs could have optional parts (I voted -1 on that) and then now I'm looking at an "Optional Components" section in the new Core Profile spec. <face-palm-emoji/>
Wow, this would be a complete overturn about how JavaEE specs have always worked so far.
There are literally a bunch of specs coming to my mind which always had optional parts init.
Starting with CDI (EE parts were only required if those EE features were available already back in CDI-1.0). Then JPA and even JDBC XA support which is fully optional. etc.
Is this just managers voting or really people who are also involved in writing the containers as well?
LieGrue,
strub
> Am 13.10.2022 um 23:45 schrieb David Blevins <da...@gmail.com>:
>
> Thanks Romain and Mark for the insights. Note, if something like this happens again, let me know. When wearing the day-job hat we do get a vote on if specs should go final.
>
> In terms of Jakarta EE 10, it strangely looks like the Jakarta EE 10 Platform spec is still using CDI 3.0 while the Jakarta EE 10 Core Profile uses CDI 4.0. Not sure how we'll work that out on the TomEE side.
>
> The Core Profile spec says CDI lite is required:
>
> "Jakarta Contexts and Dependency Injection (CDI) 4.0 (CDI Lite section)"
>
> https://jakarta.ee/specifications/coreprofile/10/jakarta-coreprofile-spec-10.0.html#required_components
>
> Whereas the optional section says there are some classes that are not required:
>
> "The Java SE section of the CDI 4.0 specification is not required for Core Profile
> implementations. Only Full CDI implementations are required to support the (CDI)
> Java SE API classes."
>
> https://jakarta.ee/specifications/coreprofile/10/jakarta-coreprofile-spec-10.0.html#optional-components
>
> Do you have any insight as to what "Java SE" classes are excluded and if that eliminates the need to implement the APIs we don't like?
>
> Unrelated side note that annoys the heck out of me: the Spec Committee literally had a vote that no specs could have optional parts (I voted -1 on that) and then now I'm looking at an "Optional Components" section in the new Core Profile spec. <face-palm-emoji/>
>
>
> -David
>
>
>> On Oct 13, 2022, at 8:14 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>>
>> To be very clear: imo the CDI-4.0 spec should never have been released that way. Sorry for the hard words.
>>
>> The whole part of the 'cdi-lite' is actually not a subpart of CDI but extends CDI with a (partly vendor specific) build time api. Which is also not really technically necessary imo. So far Helidon, Meecrowave, micronaut, etc managed to run on Graalvm quite fine without this api.
>>
>> Here is my PR which got rejected. It proves that there is no technical requirement to have all this crap in the same spec api jar!
>> https://github.com/jakartaee/cdi/pull/582 <https://github.com/jakartaee/cdi/pull/582>
>>
>>
>> My personal approach would be the following:
>> 1.) Enhance our geronimo-jcdi spec api to include the few new changes they made to BeanManager etc.
>>
>> 2.) Take the official cdi api (with the lite parts) and 'extract' those lite parts into an own jcdi-lite-api.jar
>>
>> 3.) provide a maven plugin and standard CDI Extension to handle the lite parts. This is perfectly doable!
>>
>> 4.) It is even possible to support the whole non-reflection features by using a dedicated ScannerService etc.
>>
>> That way almost no code change to OWB would be needed. Almost all of the changes could be done via an Extension. That way OWB would still remain quite small and not get as bloated as other implementations.
>>
>>
>> It's actually a shame that those changes got pushed so hard despite a lot of EG members heavily objecting with good arguments!
>>
>> LieGrue,
>> strub
>>
>>
>>
>>> Am 13.10.2022 um 08:25 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>>>
>>> Hi David,
>>>
>>> It is not about perf but about the cdi "lite" part (build time spec).
>>> We explained why it was unecessary technically on cdi bugtracker and
>>> requested that at least it was excluded from cdi spec jar and considered
>>> another subspec since it is fully unrelated to CDI but it got rejected by a
>>> few pushing their vendor API to the spec.
>>>
>>> The idea is to not expose an API we'll not support I guess and bundle
>>> properly the API.
>>>
>>> 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 jeu. 13 oct. 2022 à 02:47, David Blevins <da...@gmail.com> a
>>> écrit :
>>>
>>>>> On Jun 2, 2022, at 12:03 PM, Mark Struberg <st...@yahoo.de.INVALID>
>>>> wrote:
>>>>>
>>>>> I had an idea about how we could implement CDI-4.0 without all the
>>>> overhead it brings.
>>>>
>>>> Can you elaborate on the overhead you're concerned about? (not a challenge
>>>> -- I'm not very familiar with the details yet)
>>>>
>>>>
>>>> -David
>>>>
>>>>
>>
>
Re: [DISCUSS] CDI-4.0 core
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi David,
I guess SE section == SeContainer and not build time (= not runtime server
job by design ;)) so I assume the point is "an EE container does not need
SE bootstrap classes".
There is the same thing in JAXRS AFAIK.
That said the build time API has a challenge: it is not portable between
build and run phase so it can NOT be implemented by any container - without
repeating it is not needed at all technically, oops I did ;).
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 jeu. 13 oct. 2022 à 23:46, David Blevins <da...@gmail.com> a
écrit :
> Thanks Romain and Mark for the insights. Note, if something like this
> happens again, let me know. When wearing the day-job hat we do get a vote
> on if specs should go final.
>
> In terms of Jakarta EE 10, it strangely looks like the Jakarta EE 10
> Platform spec is still using CDI 3.0 while the Jakarta EE 10 Core Profile
> uses CDI 4.0. Not sure how we'll work that out on the TomEE side.
>
> The Core Profile spec says CDI lite is required:
>
> "Jakarta Contexts and Dependency Injection (CDI) 4.0 (CDI Lite
> section)"
>
>
> https://jakarta.ee/specifications/coreprofile/10/jakarta-coreprofile-spec-10.0.html#required_components
>
> Whereas the optional section says there are some classes that are not
> required:
>
> "The Java SE section of the CDI 4.0 specification is not required for
> Core Profile
> implementations. Only Full CDI implementations are required to support
> the (CDI)
> Java SE API classes."
>
>
> https://jakarta.ee/specifications/coreprofile/10/jakarta-coreprofile-spec-10.0.html#optional-components
>
> Do you have any insight as to what "Java SE" classes are excluded and if
> that eliminates the need to implement the APIs we don't like?
>
> Unrelated side note that annoys the heck out of me: the Spec Committee
> literally had a vote that no specs could have optional parts (I voted -1 on
> that) and then now I'm looking at an "Optional Components" section in the
> new Core Profile spec. <face-palm-emoji/>
>
>
> -David
>
>
> > On Oct 13, 2022, at 8:14 AM, Mark Struberg <st...@yahoo.de.INVALID>
> wrote:
> >
> > To be very clear: imo the CDI-4.0 spec should never have been released
> that way. Sorry for the hard words.
> >
> > The whole part of the 'cdi-lite' is actually not a subpart of CDI but
> extends CDI with a (partly vendor specific) build time api. Which is also
> not really technically necessary imo. So far Helidon, Meecrowave,
> micronaut, etc managed to run on Graalvm quite fine without this api.
> >
> > Here is my PR which got rejected. It proves that there is no technical
> requirement to have all this crap in the same spec api jar!
> > https://github.com/jakartaee/cdi/pull/582 <
> https://github.com/jakartaee/cdi/pull/582>
> >
> >
> > My personal approach would be the following:
> > 1.) Enhance our geronimo-jcdi spec api to include the few new changes
> they made to BeanManager etc.
> >
> > 2.) Take the official cdi api (with the lite parts) and 'extract' those
> lite parts into an own jcdi-lite-api.jar
> >
> > 3.) provide a maven plugin and standard CDI Extension to handle the lite
> parts. This is perfectly doable!
> >
> > 4.) It is even possible to support the whole non-reflection features by
> using a dedicated ScannerService etc.
> >
> > That way almost no code change to OWB would be needed. Almost all of the
> changes could be done via an Extension. That way OWB would still remain
> quite small and not get as bloated as other implementations.
> >
> >
> > It's actually a shame that those changes got pushed so hard despite a
> lot of EG members heavily objecting with good arguments!
> >
> > LieGrue,
> > strub
> >
> >
> >
> >> Am 13.10.2022 um 08:25 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com>:
> >>
> >> Hi David,
> >>
> >> It is not about perf but about the cdi "lite" part (build time spec).
> >> We explained why it was unecessary technically on cdi bugtracker and
> >> requested that at least it was excluded from cdi spec jar and considered
> >> another subspec since it is fully unrelated to CDI but it got rejected
> by a
> >> few pushing their vendor API to the spec.
> >>
> >> The idea is to not expose an API we'll not support I guess and bundle
> >> properly the API.
> >>
> >> 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 jeu. 13 oct. 2022 à 02:47, David Blevins <da...@gmail.com> a
> >> écrit :
> >>
> >>>> On Jun 2, 2022, at 12:03 PM, Mark Struberg <struberg@yahoo.de.INVALID
> >
> >>> wrote:
> >>>>
> >>>> I had an idea about how we could implement CDI-4.0 without all the
> >>> overhead it brings.
> >>>
> >>> Can you elaborate on the overhead you're concerned about? (not a
> challenge
> >>> -- I'm not very familiar with the details yet)
> >>>
> >>>
> >>> -David
> >>>
> >>>
> >
>
>
Re: [DISCUSS] CDI-4.0 core
Posted by David Blevins <da...@gmail.com>.
Thanks Romain and Mark for the insights. Note, if something like this happens again, let me know. When wearing the day-job hat we do get a vote on if specs should go final.
In terms of Jakarta EE 10, it strangely looks like the Jakarta EE 10 Platform spec is still using CDI 3.0 while the Jakarta EE 10 Core Profile uses CDI 4.0. Not sure how we'll work that out on the TomEE side.
The Core Profile spec says CDI lite is required:
"Jakarta Contexts and Dependency Injection (CDI) 4.0 (CDI Lite section)"
https://jakarta.ee/specifications/coreprofile/10/jakarta-coreprofile-spec-10.0.html#required_components
Whereas the optional section says there are some classes that are not required:
"The Java SE section of the CDI 4.0 specification is not required for Core Profile
implementations. Only Full CDI implementations are required to support the (CDI)
Java SE API classes."
https://jakarta.ee/specifications/coreprofile/10/jakarta-coreprofile-spec-10.0.html#optional-components
Do you have any insight as to what "Java SE" classes are excluded and if that eliminates the need to implement the APIs we don't like?
Unrelated side note that annoys the heck out of me: the Spec Committee literally had a vote that no specs could have optional parts (I voted -1 on that) and then now I'm looking at an "Optional Components" section in the new Core Profile spec. <face-palm-emoji/>
-David
> On Oct 13, 2022, at 8:14 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>
> To be very clear: imo the CDI-4.0 spec should never have been released that way. Sorry for the hard words.
>
> The whole part of the 'cdi-lite' is actually not a subpart of CDI but extends CDI with a (partly vendor specific) build time api. Which is also not really technically necessary imo. So far Helidon, Meecrowave, micronaut, etc managed to run on Graalvm quite fine without this api.
>
> Here is my PR which got rejected. It proves that there is no technical requirement to have all this crap in the same spec api jar!
> https://github.com/jakartaee/cdi/pull/582 <https://github.com/jakartaee/cdi/pull/582>
>
>
> My personal approach would be the following:
> 1.) Enhance our geronimo-jcdi spec api to include the few new changes they made to BeanManager etc.
>
> 2.) Take the official cdi api (with the lite parts) and 'extract' those lite parts into an own jcdi-lite-api.jar
>
> 3.) provide a maven plugin and standard CDI Extension to handle the lite parts. This is perfectly doable!
>
> 4.) It is even possible to support the whole non-reflection features by using a dedicated ScannerService etc.
>
> That way almost no code change to OWB would be needed. Almost all of the changes could be done via an Extension. That way OWB would still remain quite small and not get as bloated as other implementations.
>
>
> It's actually a shame that those changes got pushed so hard despite a lot of EG members heavily objecting with good arguments!
>
> LieGrue,
> strub
>
>
>
>> Am 13.10.2022 um 08:25 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>>
>> Hi David,
>>
>> It is not about perf but about the cdi "lite" part (build time spec).
>> We explained why it was unecessary technically on cdi bugtracker and
>> requested that at least it was excluded from cdi spec jar and considered
>> another subspec since it is fully unrelated to CDI but it got rejected by a
>> few pushing their vendor API to the spec.
>>
>> The idea is to not expose an API we'll not support I guess and bundle
>> properly the API.
>>
>> 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 jeu. 13 oct. 2022 à 02:47, David Blevins <da...@gmail.com> a
>> écrit :
>>
>>>> On Jun 2, 2022, at 12:03 PM, Mark Struberg <st...@yahoo.de.INVALID>
>>> wrote:
>>>>
>>>> I had an idea about how we could implement CDI-4.0 without all the
>>> overhead it brings.
>>>
>>> Can you elaborate on the overhead you're concerned about? (not a challenge
>>> -- I'm not very familiar with the details yet)
>>>
>>>
>>> -David
>>>
>>>
>
Re: [DISCUSS] CDI-4.0 core
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
To be very clear: imo the CDI-4.0 spec should never have been released that way. Sorry for the hard words.
The whole part of the 'cdi-lite' is actually not a subpart of CDI but extends CDI with a (partly vendor specific) build time api. Which is also not really technically necessary imo. So far Helidon, Meecrowave, micronaut, etc managed to run on Graalvm quite fine without this api.
Here is my PR which got rejected. It proves that there is no technical requirement to have all this crap in the same spec api jar!
https://github.com/jakartaee/cdi/pull/582 <https://github.com/jakartaee/cdi/pull/582>
My personal approach would be the following:
1.) Enhance our geronimo-jcdi spec api to include the few new changes they made to BeanManager etc.
2.) Take the official cdi api (with the lite parts) and 'extract' those lite parts into an own jcdi-lite-api.jar
3.) provide a maven plugin and standard CDI Extension to handle the lite parts. This is perfectly doable!
4.) It is even possible to support the whole non-reflection features by using a dedicated ScannerService etc.
That way almost no code change to OWB would be needed. Almost all of the changes could be done via an Extension. That way OWB would still remain quite small and not get as bloated as other implementations.
It's actually a shame that those changes got pushed so hard despite a lot of EG members heavily objecting with good arguments!
LieGrue,
strub
> Am 13.10.2022 um 08:25 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Hi David,
>
> It is not about perf but about the cdi "lite" part (build time spec).
> We explained why it was unecessary technically on cdi bugtracker and
> requested that at least it was excluded from cdi spec jar and considered
> another subspec since it is fully unrelated to CDI but it got rejected by a
> few pushing their vendor API to the spec.
>
> The idea is to not expose an API we'll not support I guess and bundle
> properly the API.
>
> 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 jeu. 13 oct. 2022 à 02:47, David Blevins <da...@gmail.com> a
> écrit :
>
>>> On Jun 2, 2022, at 12:03 PM, Mark Struberg <st...@yahoo.de.INVALID>
>> wrote:
>>>
>>> I had an idea about how we could implement CDI-4.0 without all the
>> overhead it brings.
>>
>> Can you elaborate on the overhead you're concerned about? (not a challenge
>> -- I'm not very familiar with the details yet)
>>
>>
>> -David
>>
>>
Re: [DISCUSS] CDI-4.0 core
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi David,
It is not about perf but about the cdi "lite" part (build time spec).
We explained why it was unecessary technically on cdi bugtracker and
requested that at least it was excluded from cdi spec jar and considered
another subspec since it is fully unrelated to CDI but it got rejected by a
few pushing their vendor API to the spec.
The idea is to not expose an API we'll not support I guess and bundle
properly the API.
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 jeu. 13 oct. 2022 à 02:47, David Blevins <da...@gmail.com> a
écrit :
> > On Jun 2, 2022, at 12:03 PM, Mark Struberg <st...@yahoo.de.INVALID>
> wrote:
> >
> > I had an idea about how we could implement CDI-4.0 without all the
> overhead it brings.
>
> Can you elaborate on the overhead you're concerned about? (not a challenge
> -- I'm not very familiar with the details yet)
>
>
> -David
>
>
Re: [DISCUSS] CDI-4.0 core
Posted by David Blevins <da...@gmail.com>.
> On Jun 2, 2022, at 12:03 PM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>
> I had an idea about how we could implement CDI-4.0 without all the overhead it brings.
Can you elaborate on the overhead you're concerned about? (not a challenge -- I'm not very familiar with the details yet)
-David
Re: [DISCUSS] CDI-4.0 core
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Sounds more or less like making AnnotatedElementFactory pluggable? Right now this class is final, but we could even extract our an interface maybe. ScannerService is already fully pluggalbe, thus should not be that much of a problem.
Anything else to make pluggable?
LieGrue,
strub
> Am 12.10.2022 um 21:01 schrieb Arne Limburg <ar...@openknowledge.de>:
>
> Hi Romain,
>
> I would love to elaborate that further. I would remove the scanning part in example (or make it pluggable). Then we could easily implement compile-time scanning or something like that.
> Maybe the core should start with a set of Beans and only do the runtime stuff.
> Setup could be done in different modules (cdi-1, cdi-2, cdi-lite, …)
>
> I like the overall idea also I hate that we would have to wrap Bean interface and friends in the CDI module. Maybe we find a better way to do that (i.e. extracting a cdi-minmal-api or so, but we still would have to decide between javax or jakarta namespace).
>
> Cheers,
> Arne
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limburg@openknowledge.de <ma...@openknowledge.de><mailto:arne.limburg@openknowledge.de <ma...@openknowledge.de>>
> www.openknowledge.de <http://www.openknowledge.de/><https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F&data=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9vRVYZVZ%2Feqk%2BvFxU5COofNvgs8U0AxtxRqwVEwqXHA%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F&data=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9vRVYZVZ%2Feqk%2BvFxU5COofNvgs8U0AxtxRqwVEwqXHA%3D&reserved=0>>
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
>
> Treffen Sie uns auf kommenden Konferenzen und Workshops:
> Zu unseren Events<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fevent%2F&data=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8tjmukdm1NxhXQMkn4VnESiBI216kXvh%2Fjb7%2FFYI0kE%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fevent%2F&data=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8tjmukdm1NxhXQMkn4VnESiBI216kXvh%2Fjb7%2FFYI0kE%3D&reserved=0>>
>
> Von: Romain Manni-Bucau <rmannibucau@gmail.com <ma...@gmail.com>>
> Datum: Mittwoch, 12. Oktober 2022 um 18:11
> An: dev@openwebbeans.apache.org <ma...@openwebbeans.apache.org> <dev@openwebbeans.apache.org <ma...@openwebbeans.apache.org>>
> Betreff: Re: [DISCUSS] CDI-4.0 core
> Hi Arne,
>
> What I'm looking for is basically be able to use most of CDI programming
> model (contexts, SE scanning, interceptors, ...) maybe not decorators - no
> strong opinion on them.
> The impl would use a default defining service which would be the
> classloader implementation to be any java version friendly without hacks
> and the preloaded flavor impl should be usable (optim or graal native-image
> case - SM case is no more relevant I guess since it will be dropped).
> We could also probably force to have a META-INF/beans.xml (or
> META-INF/owb.xml if we prefer) for the scanning to not get this broken
> implicit annotated mode CDI 2 introduced.
> In terms of extension I guess we can keep it - adding/mutating
> types/interceptors/... at runtime is key, but it would also be fine to go
> back on CDI 1.0 layer since new API are mainly duplicates or synthaxic
> sugar.
> Since it would be an impl I'm not sure we need the interface/impl split so
> we can save some class by just using a direct class (public class
> ProcessAnnotatedType for ex) if it makes sense.
>
> In terms of supported API set (jakarta.inject.Inject vs
> org.apache.openwebbeans.api.Inject for ex) I guess we would add a service
> in WBC to enable to read the set we want.
> Default would be o.a.owb one, cdi impl module would switch to
> o.a.owb+jakarta/javax ones - a bit like our resource service but more
> generic.
>
> In terms of impl, cdi module would mainly wrap the core objects and extend
> it in some locations, a bit like tomee does for OWB@EE.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Frmannibucau&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PQbRCzdzdQ8v2AqUz%2F9SZg0gFwy5c8CR3CzgIPf6vEs%3D&reserved=0 <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Frmannibucau&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PQbRCzdzdQ8v2AqUz%2F9SZg0gFwy5c8CR3CzgIPf6vEs%3D&reserved=0>> | Blog
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Frmannibucau.metawerx.net%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zNquMZrZ%2FsP%2BYJuw9Xvd1oF62979ugTAi5ZO9ngSbuo%3D&reserved=0 <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Frmannibucau.metawerx.net%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zNquMZrZ%2FsP%2BYJuw9Xvd1oF62979ugTAi5ZO9ngSbuo%3D&reserved=0>> | Old Blog
> <https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Frmannibucau.wordpress.com%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=trl%2FrClQhqO7i2h8h5sfgt7l9l%2BZeBzmpocbyD%2B09Y8%3D&reserved=0 <https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Frmannibucau.wordpress.com%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=trl%2FrClQhqO7i2h8h5sfgt7l9l%2BZeBzmpocbyD%2B09Y8%3D&reserved=0>> | Github <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frmannibucau&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=S9SW788%2FdxunSNyfKz3yh5vyupuFoz0vske%2FIM5v%2FTc%3D&reserved=0 <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frmannibucau&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=S9SW788%2FdxunSNyfKz3yh5vyupuFoz0vske%2FIM5v%2FTc%3D&reserved=0>> |
> LinkedIn <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Frmannibucau&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Chd5RGJ6hOkrK8nAwQJwZ58o5Nomg8tJ3%2FTI8BJP7FA%3D&reserved=0 <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Frmannibucau&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Chd5RGJ6hOkrK8nAwQJwZ58o5Nomg8tJ3%2FTI8BJP7FA%3D&reserved=0>> | Book
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.packtpub.com%2Fapplication-development%2Fjava-ee-8-high-performance&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FS%2F%2F76e3K11L6i5o%2FKe0w1y4lDXzmStTql6kv1hOb4A%3D&reserved=0 <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.packtpub.com%2Fapplication-development%2Fjava-ee-8-high-performance&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FS%2F%2F76e3K11L6i5o%2FKe0w1y4lDXzmStTql6kv1hOb4A%3D&reserved=0>>
>
>
> Le mer. 12 oct. 2022 à 17:48, Arne Limburg <arne.limburg@openknowledge.de <ma...@openknowledge.de>>
> a écrit :
>
>> Hi,
>>
>> I know, I am late to the party.
>> I actually like the idea of an own API and maybe adding CDI-(and/or
>> CDI-lite) support on top of it.
>> Romain, could you elaborate further, how this API should look like and
>> what part of our current impl could be moved into it (and which parts
>> should be moved somewhere else)?
>>
>> Cheers,
>> Arne
>>
>> OPEN KNOWLEDGE GmbH
>> Poststraße 1, 26122 Oldenburg
>> Mobil: +49 151 - 108 22 942
>> Tel: +49 441 - 4082-154
>> Fax: +49 441 - 4082-111
>> arne.limburg@openknowledge.de <ma...@openknowledge.de><mailto:arne.limburg@openknowledge.de <ma...@openknowledge.de>>
>> https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openknowledge.de%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6MSnRSFohYLdkn8mLT7v9C%2B0uEk62YK0L7uvWmjAHZs%3D&reserved=0<<https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openknowledge.de%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6MSnRSFohYLdkn8mLT7v9C%2B0uEk62YK0L7uvWmjAHZs%3D&reserved=0%3c> <https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openknowledge.de%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6MSnRSFohYLdkn8mLT7v9C%2B0uEk62YK0L7uvWmjAHZs%3D&reserved=0%3C%3Chttps://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openknowledge.de%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6MSnRSFohYLdkn8mLT7v9C%2B0uEk62YK0L7uvWmjAHZs%3D&reserved=0%3c%3E>
>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y7QuEZpzyr9lvmxko%2Fx4V6hZeDGpaa8Bx%2Bzgd3pgIcE%3D&reserved=0 <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y7QuEZpzyr9lvmxko%2Fx4V6hZeDGpaa8Bx%2Bzgd3pgIcE%3D&reserved=0>
>>>
>> Registergericht: Amtsgericht Oldenburg, HRB 4670
>> Geschäftsführer: Lars Röwekamp, Jens Schumann
>>
>> Treffen Sie uns auf kommenden Konferenzen und Workshops:
>> Zu unseren Events<
>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fevent%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3GUY2OqKe9DsuAtEhfHx5J8ztt%2BaHze2GWT%2Fqkkftvw%3D&reserved=0 <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fevent%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3GUY2OqKe9DsuAtEhfHx5J8ztt%2BaHze2GWT%2Fqkkftvw%3D&reserved=0>
>>>
>>
>> Von: Romain Manni-Bucau <rmannibucau@gmail.com <ma...@gmail.com>>
>> Datum: Freitag, 3. Juni 2022 um 13:47
>> An: openwebbeans-dev <dev@openwebbeans.apache.org <ma...@openwebbeans.apache.org>>
>> Betreff: Re: [DISCUSS] CDI-4.0 core
>> Le ven. 3 juin 2022 à 13:34, Mark Struberg <struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>> 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 <
>> rmannibucau@gmail.com <ma...@gmail.com>
>>>> :
>>>>
>>>> Le jeu. 2 juin 2022 à 22:44, Mark Struberg <struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>>
>> 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 <
>>> rmannibucau@gmail.com <ma...@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 <struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>
>>>>> <mailto:struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>>> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0 <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0>
>> <
>>>>>>>
>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0 <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0>
>> <
>>>>>
>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0 <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0>
>>>> <
>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0 <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0>
>>>
>>>>>>>
>>>>>>> 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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Well, about the scanning we already handle build time scanning thanks se
api (disableDiscovery + extension for explicit registration /
prescannedmetada service, this is what we use to be graal friendly).
About javax/jakarta: the whole point is to decoralate from the spec which
went in a bad escape lane and only expose supported api and not a set of
api we'll not impl + not fake implementing an api (@inject debate) if we
change the default behavior.
We can still fake the code at build time by monkey matching the spec type
to impl it semi-automatically thanks a build plugin if you find it more
relevant but think if we end up using jakarta spec this idea kind of end in
the status quo since end users will still consume the spec and rely on its
instability and verbosity.
Hope it makes sense.
Le mer. 12 oct. 2022 à 21:02, Arne Limburg <ar...@openknowledge.de>
a écrit :
> Hi Romain,
>
> I would love to elaborate that further. I would remove the scanning part
> in example (or make it pluggable). Then we could easily implement
> compile-time scanning or something like that.
> Maybe the core should start with a set of Beans and only do the runtime
> stuff.
> Setup could be done in different modules (cdi-1, cdi-2, cdi-lite, …)
>
> I like the overall idea also I hate that we would have to wrap Bean
> interface and friends in the CDI module. Maybe we find a better way to do
> that (i.e. extracting a cdi-minmal-api or so, but we still would have to
> decide between javax or jakarta namespace).
>
> Cheers,
> Arne
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limburg@openknowledge.de<ma...@openknowledge.de>
> www.openknowledge.de<
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F&data=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9vRVYZVZ%2Feqk%2BvFxU5COofNvgs8U0AxtxRqwVEwqXHA%3D&reserved=0
> >
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
>
> Treffen Sie uns auf kommenden Konferenzen und Workshops:
> Zu unseren Events<
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fevent%2F&data=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8tjmukdm1NxhXQMkn4VnESiBI216kXvh%2Fjb7%2FFYI0kE%3D&reserved=0
> >
>
> Von: Romain Manni-Bucau <rm...@gmail.com>
> Datum: Mittwoch, 12. Oktober 2022 um 18:11
> An: dev@openwebbeans.apache.org <de...@openwebbeans.apache.org>
> Betreff: Re: [DISCUSS] CDI-4.0 core
> Hi Arne,
>
> What I'm looking for is basically be able to use most of CDI programming
> model (contexts, SE scanning, interceptors, ...) maybe not decorators - no
> strong opinion on them.
> The impl would use a default defining service which would be the
> classloader implementation to be any java version friendly without hacks
> and the preloaded flavor impl should be usable (optim or graal native-image
> case - SM case is no more relevant I guess since it will be dropped).
> We could also probably force to have a META-INF/beans.xml (or
> META-INF/owb.xml if we prefer) for the scanning to not get this broken
> implicit annotated mode CDI 2 introduced.
> In terms of extension I guess we can keep it - adding/mutating
> types/interceptors/... at runtime is key, but it would also be fine to go
> back on CDI 1.0 layer since new API are mainly duplicates or synthaxic
> sugar.
> Since it would be an impl I'm not sure we need the interface/impl split so
> we can save some class by just using a direct class (public class
> ProcessAnnotatedType for ex) if it makes sense.
>
> In terms of supported API set (jakarta.inject.Inject vs
> org.apache.openwebbeans.api.Inject for ex) I guess we would add a service
> in WBC to enable to read the set we want.
> Default would be o.a.owb one, cdi impl module would switch to
> o.a.owb+jakarta/javax ones - a bit like our resource service but more
> generic.
>
> In terms of impl, cdi module would mainly wrap the core objects and extend
> it in some locations, a bit like tomee does for OWB@EE.
>
>
> Romain Manni-Bucau
> @rmannibucau <
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Frmannibucau&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PQbRCzdzdQ8v2AqUz%2F9SZg0gFwy5c8CR3CzgIPf6vEs%3D&reserved=0>
> | Blog
> <
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Frmannibucau.metawerx.net%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zNquMZrZ%2FsP%2BYJuw9Xvd1oF62979ugTAi5ZO9ngSbuo%3D&reserved=0>
> | Old Blog
> <
> https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Frmannibucau.wordpress.com%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=trl%2FrClQhqO7i2h8h5sfgt7l9l%2BZeBzmpocbyD%2B09Y8%3D&reserved=0>
> | Github <
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frmannibucau&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=S9SW788%2FdxunSNyfKz3yh5vyupuFoz0vske%2FIM5v%2FTc%3D&reserved=0>
> |
> LinkedIn <
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Frmannibucau&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Chd5RGJ6hOkrK8nAwQJwZ58o5Nomg8tJ3%2FTI8BJP7FA%3D&reserved=0>
> | Book
> <
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.packtpub.com%2Fapplication-development%2Fjava-ee-8-high-performance&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FS%2F%2F76e3K11L6i5o%2FKe0w1y4lDXzmStTql6kv1hOb4A%3D&reserved=0
> >
>
>
> Le mer. 12 oct. 2022 à 17:48, Arne Limburg <ar...@openknowledge.de>
> a écrit :
>
> > Hi,
> >
> > I know, I am late to the party.
> > I actually like the idea of an own API and maybe adding CDI-(and/or
> > CDI-lite) support on top of it.
> > Romain, could you elaborate further, how this API should look like and
> > what part of our current impl could be moved into it (and which parts
> > should be moved somewhere else)?
> >
> > Cheers,
> > Arne
> >
> > OPEN KNOWLEDGE GmbH
> > Poststraße 1, 26122 Oldenburg
> > Mobil: +49 151 - 108 22 942
> > Tel: +49 441 - 4082-154
> > Fax: +49 441 - 4082-111
> > arne.limburg@openknowledge.de<ma...@openknowledge.de>
> >
> https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openknowledge.de%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6MSnRSFohYLdkn8mLT7v9C%2B0uEk62YK0L7uvWmjAHZs%3D&reserved=0
> <<
> https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openknowledge.de%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6MSnRSFohYLdkn8mLT7v9C%2B0uEk62YK0L7uvWmjAHZs%3D&reserved=0%3c
> >
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y7QuEZpzyr9lvmxko%2Fx4V6hZeDGpaa8Bx%2Bzgd3pgIcE%3D&reserved=0
> > >
> > Registergericht: Amtsgericht Oldenburg, HRB 4670
> > Geschäftsführer: Lars Röwekamp, Jens Schumann
> >
> > Treffen Sie uns auf kommenden Konferenzen und Workshops:
> > Zu unseren Events<
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fevent%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3GUY2OqKe9DsuAtEhfHx5J8ztt%2BaHze2GWT%2Fqkkftvw%3D&reserved=0
> > >
> >
> > Von: Romain Manni-Bucau <rm...@gmail.com>
> > Datum: Freitag, 3. Juni 2022 um 13:47
> > An: openwebbeans-dev <de...@openwebbeans.apache.org>
> > Betreff: Re: [DISCUSS] CDI-4.0 core
> > Le ven. 3 juin 2022 à 13:34, Mark Struberg <st...@yahoo.de.invalid> 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 <
> > rmannibucau@gmail.com
> > > >:
> > > >
> > > > Le jeu. 2 juin 2022 à 22:44, Mark Struberg <struberg@yahoo.de.invalid
> >
> > 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 <
> > > rmannibucau@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
> <struberg@yahoo.de.invalid
> > > >> <ma...@yahoo.de.invalid>> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0
> > <
> > > >>>>
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0
> > <
> > > >>
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0
> > >><
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0
> > >
> > > >>>>
> > > >>>> 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
> > > >>
> > > >>
> > >
> > >
> >
>
AW: [DISCUSS] CDI-4.0 core
Posted by Arne Limburg <ar...@openknowledge.de>.
Hi Romain,
I would love to elaborate that further. I would remove the scanning part in example (or make it pluggable). Then we could easily implement compile-time scanning or something like that.
Maybe the core should start with a set of Beans and only do the runtime stuff.
Setup could be done in different modules (cdi-1, cdi-2, cdi-lite, …)
I like the overall idea also I hate that we would have to wrap Bean interface and friends in the CDI module. Maybe we find a better way to do that (i.e. extracting a cdi-minmal-api or so, but we still would have to decide between javax or jakarta namespace).
Cheers,
Arne
OPEN KNOWLEDGE GmbH
Poststraße 1, 26122 Oldenburg
Mobil: +49 151 - 108 22 942
Tel: +49 441 - 4082-154
Fax: +49 441 - 4082-111
arne.limburg@openknowledge.de<ma...@openknowledge.de>
www.openknowledge.de<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F&data=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9vRVYZVZ%2Feqk%2BvFxU5COofNvgs8U0AxtxRqwVEwqXHA%3D&reserved=0>
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
Treffen Sie uns auf kommenden Konferenzen und Workshops:
Zu unseren Events<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fevent%2F&data=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8tjmukdm1NxhXQMkn4VnESiBI216kXvh%2Fjb7%2FFYI0kE%3D&reserved=0>
Von: Romain Manni-Bucau <rm...@gmail.com>
Datum: Mittwoch, 12. Oktober 2022 um 18:11
An: dev@openwebbeans.apache.org <de...@openwebbeans.apache.org>
Betreff: Re: [DISCUSS] CDI-4.0 core
Hi Arne,
What I'm looking for is basically be able to use most of CDI programming
model (contexts, SE scanning, interceptors, ...) maybe not decorators - no
strong opinion on them.
The impl would use a default defining service which would be the
classloader implementation to be any java version friendly without hacks
and the preloaded flavor impl should be usable (optim or graal native-image
case - SM case is no more relevant I guess since it will be dropped).
We could also probably force to have a META-INF/beans.xml (or
META-INF/owb.xml if we prefer) for the scanning to not get this broken
implicit annotated mode CDI 2 introduced.
In terms of extension I guess we can keep it - adding/mutating
types/interceptors/... at runtime is key, but it would also be fine to go
back on CDI 1.0 layer since new API are mainly duplicates or synthaxic
sugar.
Since it would be an impl I'm not sure we need the interface/impl split so
we can save some class by just using a direct class (public class
ProcessAnnotatedType for ex) if it makes sense.
In terms of supported API set (jakarta.inject.Inject vs
org.apache.openwebbeans.api.Inject for ex) I guess we would add a service
in WBC to enable to read the set we want.
Default would be o.a.owb one, cdi impl module would switch to
o.a.owb+jakarta/javax ones - a bit like our resource service but more
generic.
In terms of impl, cdi module would mainly wrap the core objects and extend
it in some locations, a bit like tomee does for OWB@EE.
Romain Manni-Bucau
@rmannibucau <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Frmannibucau&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PQbRCzdzdQ8v2AqUz%2F9SZg0gFwy5c8CR3CzgIPf6vEs%3D&reserved=0> | Blog
<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Frmannibucau.metawerx.net%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zNquMZrZ%2FsP%2BYJuw9Xvd1oF62979ugTAi5ZO9ngSbuo%3D&reserved=0> | Old Blog
<https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Frmannibucau.wordpress.com%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=trl%2FrClQhqO7i2h8h5sfgt7l9l%2BZeBzmpocbyD%2B09Y8%3D&reserved=0> | Github <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frmannibucau&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=S9SW788%2FdxunSNyfKz3yh5vyupuFoz0vske%2FIM5v%2FTc%3D&reserved=0> |
LinkedIn <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Frmannibucau&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Chd5RGJ6hOkrK8nAwQJwZ58o5Nomg8tJ3%2FTI8BJP7FA%3D&reserved=0> | Book
<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.packtpub.com%2Fapplication-development%2Fjava-ee-8-high-performance&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FS%2F%2F76e3K11L6i5o%2FKe0w1y4lDXzmStTql6kv1hOb4A%3D&reserved=0>
Le mer. 12 oct. 2022 à 17:48, Arne Limburg <ar...@openknowledge.de>
a écrit :
> Hi,
>
> I know, I am late to the party.
> I actually like the idea of an own API and maybe adding CDI-(and/or
> CDI-lite) support on top of it.
> Romain, could you elaborate further, how this API should look like and
> what part of our current impl could be moved into it (and which parts
> should be moved somewhere else)?
>
> Cheers,
> Arne
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limburg@openknowledge.de<ma...@openknowledge.de>
> https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openknowledge.de%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6MSnRSFohYLdkn8mLT7v9C%2B0uEk62YK0L7uvWmjAHZs%3D&reserved=0<<https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openknowledge.de%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6MSnRSFohYLdkn8mLT7v9C%2B0uEk62YK0L7uvWmjAHZs%3D&reserved=0%3c>
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y7QuEZpzyr9lvmxko%2Fx4V6hZeDGpaa8Bx%2Bzgd3pgIcE%3D&reserved=0
> >
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
>
> Treffen Sie uns auf kommenden Konferenzen und Workshops:
> Zu unseren Events<
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fevent%2F&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3GUY2OqKe9DsuAtEhfHx5J8ztt%2BaHze2GWT%2Fqkkftvw%3D&reserved=0
> >
>
> Von: Romain Manni-Bucau <rm...@gmail.com>
> Datum: Freitag, 3. Juni 2022 um 13:47
> An: openwebbeans-dev <de...@openwebbeans.apache.org>
> Betreff: Re: [DISCUSS] CDI-4.0 core
> Le ven. 3 juin 2022 à 13:34, Mark Struberg <st...@yahoo.de.invalid> 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 <
> rmannibucau@gmail.com
> > >:
> > >
> > > Le jeu. 2 juin 2022 à 22:44, Mark Struberg <st...@yahoo.de.invalid>
> 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 <
> > rmannibucau@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 <struberg@yahoo.de.invalid
> > >> <ma...@yahoo.de.invalid>> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0
> <
> > >>>>
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0
> <
> > >>
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0
> >><
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yW8SX%2FjZhiMZg%2B6ikg7n5RhOzBmLMe2Ds7CBqF5oPS0%3D&reserved=0
> >
> > >>>>
> > >>>> 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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Arne,
What I'm looking for is basically be able to use most of CDI programming
model (contexts, SE scanning, interceptors, ...) maybe not decorators - no
strong opinion on them.
The impl would use a default defining service which would be the
classloader implementation to be any java version friendly without hacks
and the preloaded flavor impl should be usable (optim or graal native-image
case - SM case is no more relevant I guess since it will be dropped).
We could also probably force to have a META-INF/beans.xml (or
META-INF/owb.xml if we prefer) for the scanning to not get this broken
implicit annotated mode CDI 2 introduced.
In terms of extension I guess we can keep it - adding/mutating
types/interceptors/... at runtime is key, but it would also be fine to go
back on CDI 1.0 layer since new API are mainly duplicates or synthaxic
sugar.
Since it would be an impl I'm not sure we need the interface/impl split so
we can save some class by just using a direct class (public class
ProcessAnnotatedType for ex) if it makes sense.
In terms of supported API set (jakarta.inject.Inject vs
org.apache.openwebbeans.api.Inject for ex) I guess we would add a service
in WBC to enable to read the set we want.
Default would be o.a.owb one, cdi impl module would switch to
o.a.owb+jakarta/javax ones - a bit like our resource service but more
generic.
In terms of impl, cdi module would mainly wrap the core objects and extend
it in some locations, a bit like tomee does for OWB@EE.
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 mer. 12 oct. 2022 à 17:48, Arne Limburg <ar...@openknowledge.de>
a écrit :
> Hi,
>
> I know, I am late to the party.
> I actually like the idea of an own API and maybe adding CDI-(and/or
> CDI-lite) support on top of it.
> Romain, could you elaborate further, how this API should look like and
> what part of our current impl could be moved into it (and which parts
> should be moved somewhere else)?
>
> Cheers,
> Arne
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limburg@openknowledge.de<ma...@openknowledge.de>
> www.openknowledge.de<
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F&data=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9vRVYZVZ%2Feqk%2BvFxU5COofNvgs8U0AxtxRqwVEwqXHA%3D&reserved=0
> >
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
>
> Treffen Sie uns auf kommenden Konferenzen und Workshops:
> Zu unseren Events<
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fevent%2F&data=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8tjmukdm1NxhXQMkn4VnESiBI216kXvh%2Fjb7%2FFYI0kE%3D&reserved=0
> >
>
> Von: Romain Manni-Bucau <rm...@gmail.com>
> Datum: Freitag, 3. Juni 2022 um 13:47
> An: openwebbeans-dev <de...@openwebbeans.apache.org>
> Betreff: Re: [DISCUSS] CDI-4.0 core
> Le ven. 3 juin 2022 à 13:34, Mark Struberg <st...@yahoo.de.invalid> 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 <
> rmannibucau@gmail.com
> > >:
> > >
> > > Le jeu. 2 juin 2022 à 22:44, Mark Struberg <st...@yahoo.de.invalid>
> 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 <
> > rmannibucau@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 <struberg@yahoo.de.invalid
> > >> <ma...@yahoo.de.invalid>> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C2da58e208a2a4913c8d708da4556e190%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C637898536701353621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ayK%2FosvbL0osh5S3VXY88wdcbsxQwYAScI%2Bn7AHnfTI%3D&reserved=0
> <
> > >>>>
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C2da58e208a2a4913c8d708da4556e190%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C637898536701353621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ayK%2FosvbL0osh5S3VXY88wdcbsxQwYAScI%2Bn7AHnfTI%3D&reserved=0
> <
> > >>
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C2da58e208a2a4913c8d708da4556e190%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C637898536701353621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ayK%2FosvbL0osh5S3VXY88wdcbsxQwYAScI%2Bn7AHnfTI%3D&reserved=0
> >><
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C2da58e208a2a4913c8d708da4556e190%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C637898536701353621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ayK%2FosvbL0osh5S3VXY88wdcbsxQwYAScI%2Bn7AHnfTI%3D&reserved=0%3e%3e
> >
> > >>>>
> > >>>> 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
> > >>
> > >>
> >
> >
>
AW: [DISCUSS] CDI-4.0 core
Posted by Arne Limburg <ar...@openknowledge.de>.
Hi,
I know, I am late to the party.
I actually like the idea of an own API and maybe adding CDI-(and/or CDI-lite) support on top of it.
Romain, could you elaborate further, how this API should look like and what part of our current impl could be moved into it (and which parts should be moved somewhere else)?
Cheers,
Arne
OPEN KNOWLEDGE GmbH
Poststraße 1, 26122 Oldenburg
Mobil: +49 151 - 108 22 942
Tel: +49 441 - 4082-154
Fax: +49 441 - 4082-111
arne.limburg@openknowledge.de<ma...@openknowledge.de>
www.openknowledge.de<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F&data=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9vRVYZVZ%2Feqk%2BvFxU5COofNvgs8U0AxtxRqwVEwqXHA%3D&reserved=0>
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
Treffen Sie uns auf kommenden Konferenzen und Workshops:
Zu unseren Events<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fevent%2F&data=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8tjmukdm1NxhXQMkn4VnESiBI216kXvh%2Fjb7%2FFYI0kE%3D&reserved=0>
Von: Romain Manni-Bucau <rm...@gmail.com>
Datum: Freitag, 3. Juni 2022 um 13:47
An: openwebbeans-dev <de...@openwebbeans.apache.org>
Betreff: Re: [DISCUSS] CDI-4.0 core
Le ven. 3 juin 2022 à 13:34, Mark Struberg <st...@yahoo.de.invalid> 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 <rmannibucau@gmail.com
> >:
> >
> > Le jeu. 2 juin 2022 à 22:44, Mark Struberg <st...@yahoo.de.invalid> 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 <
> rmannibucau@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 <struberg@yahoo.de.invalid
> >> <ma...@yahoo.de.invalid>> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C2da58e208a2a4913c8d708da4556e190%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C637898536701353621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ayK%2FosvbL0osh5S3VXY88wdcbsxQwYAScI%2Bn7AHnfTI%3D&reserved=0 <
> >>>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C2da58e208a2a4913c8d708da4556e190%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C637898536701353621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ayK%2FosvbL0osh5S3VXY88wdcbsxQwYAScI%2Bn7AHnfTI%3D&reserved=0 <
> >> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C2da58e208a2a4913c8d708da4556e190%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C637898536701353621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ayK%2FosvbL0osh5S3VXY88wdcbsxQwYAScI%2Bn7AHnfTI%3D&reserved=0>><https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjakartaee%2Fcdi%2Fpull%2F582&data=05%7C01%7Carne.limburg%40openknowledge.de%7C2da58e208a2a4913c8d708da4556e190%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C637898536701353621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ayK%2FosvbL0osh5S3VXY88wdcbsxQwYAScI%2Bn7AHnfTI%3D&reserved=0%3e%3e>
> >>>>
> >>>> 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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 3 juin 2022 à 13:34, Mark Struberg <st...@yahoo.de.invalid> 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 <rmannibucau@gmail.com
> >:
> >
> > Le jeu. 2 juin 2022 à 22:44, Mark Struberg <st...@yahoo.de.invalid> 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 <
> rmannibucau@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 <struberg@yahoo.de.invalid
> >> <ma...@yahoo.de.invalid>> 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
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <rm...@gmail.com>:
>
> Le jeu. 2 juin 2022 à 22:44, Mark Struberg <st...@yahoo.de.invalid> 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 <rmannibucau@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 <struberg@yahoo.de.invalid
>> <ma...@yahoo.de.invalid>> 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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 2 juin 2022 à 22:44, Mark Struberg <st...@yahoo.de.invalid> 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 <rmannibucau@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 <struberg@yahoo.de.invalid
> <ma...@yahoo.de.invalid>> 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
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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.
LieGrue,
strub
> Am 02.06.2022 um 21:32 schrieb Romain Manni-Bucau <rm...@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 <struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>> 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
Posted by Romain Manni-Bucau <rm...@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 <st...@yahoo.de.invalid> 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>
>
> 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