Re: [DISCUSS] CDI-4.0 core

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 13 oct. 2022 à 23:46, David Blevins  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.  
>
>
> -David
>
>
> > On Oct 13, 2022, at 8:14 AM, Mark Struberg 
> 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 <
> rmannibu...@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  |  Blog
> >>  | Old Blog
> >>  | Github <
> https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >>
> >>
> >> Le jeu. 13 oct. 2022 à 02:47, David Blevins  a
> >> écrit :
> >>
>  On Jun 2, 2022, at 12:03 PM, Mark Struberg  >
>

Re: [DISCUSS] CDI-4.0 core

[David Blevins]

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.  


-David


> On Oct 13, 2022, at 8:14 AM, Mark Struberg  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 
> 
> 
> 
> 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 :
>> 
>> 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  |  Blog
>>  | Old Blog
>>  | Github  
>> |
>> LinkedIn  | Book
>> 
>> 
>> 
>> Le jeu. 13 oct. 2022 à 02:47, David Blevins  a
>> écrit :
>> 
 On Jun 2, 2022, at 12:03 PM, Mark Struberg 
>>> 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
>>> 
>>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

[GitHub] [openwebbeans-meecrowave] rmannibucau commented on pull request #17: fix: MEECROWAVE-323 - incorrect filename

[GitBox]

rmannibucau commented on PR #17:
URL: 
https://github.com/apache/openwebbeans-meecrowave/pull/17#issuecomment-1278101388

   Thanks a lot!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@openwebbeans.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [openwebbeans-meecrowave] rmannibucau merged pull request #17: fix: MEECROWAVE-323 - incorrect filename

[GitBox]

rmannibucau merged PR #17:
URL: https://github.com/apache/openwebbeans-meecrowave/pull/17


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@openwebbeans.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [openwebbeans-meecrowave] bvfalcon opened a new pull request, #17: fix: MEECROWAVE-323 - incorrect filename

[GitBox]

bvfalcon opened a new pull request, #17:
URL: https://github.com/apache/openwebbeans-meecrowave/pull/17

   Bug with erroneous automatic renaming file solved - 
[MEECROWAVE-323](https://issues.apache.org/jira/browse/MEECROWAVE-323).
   
   I have used the solution [from 
johnzon](https://github.com/apache/johnzon/blob/master/pom.xml#L131) :)
   
   Signed-off-by: Vladimir V. Bychkov 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@openwebbeans.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MEECROWAVE-323) Incorrect filename for annotation processor

[Romain Manni-Bucau (Jira)]

[ 
https://issues.apache.org/jira/browse/MEECROWAVE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17617183#comment-17617183
 ] 

Romain Manni-Bucau commented on MEECROWAVE-323:
---

Hi [~vbychkov] , do you want to submit a PR on github 
(@apache/openwebbeans-meecrowave project) - guess we can exclude the file since 
it is log4j related and we don't intend to enable to build custom log4j plugins 
with this fatjar?

Side note: for people blocked, maven-compiler supports to configure the 
annotation processors explicitly which enables to bypass this error.

> Incorrect filename for annotation processor
> ---
>
> Key: MEECROWAVE-323
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-323
> Project: Meecrowave
>  Issue Type: Bug
>Affects Versions: 1.2.14
> Environment: Java 17
>Reporter: Vladimir V. Bychkov
>Priority: Blocker
>
> Dependency artifact 
> [meecrowave-core:1.2.14:jakarta|https://repo1.maven.org/maven2/org/apache/meecrowave/meecrowave-core/1.2.14/meecrowave-core-1.2.14-jakarta.jar]
>  contains file /META-INF/services/*jakarta*.annotation.processing.Processor. 
> The name of file si incorrect: this file is not a part of Jakarta EE, but 
> part of Java EE. His name since JDK 6 was und stays 
> *javax*.annotation.processing.Processor.
> This error is name is a blocker: when build with maven-compiler it produces 
> error
> {code}
> Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: 
> Compilation failure error: Bad service configuration file, or exception 
> thrown while constructing Processor object: 
> jakarta/annotation/processing/AbstractProcessor
> at 
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1310)
> at 
> org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:183)
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:370)
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [DISCUSS] CDI-4.0 core

[Mark Struberg]

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 :
> 
> 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.limb...@openknowledge.de 
>  >
> www.openknowledge.de 
>   
> >
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
> 
> Treffen Sie uns auf kommenden Konferenzen und Workshops:
> Zu unseren 
> Events  
> >
> 
> Von: Romain Manni-Bucau mailto:rmannibu...@gmail.com>>
> Datum: Mittwoch, 12. Oktober 2022 um 18:11
> An: dev@openwebbeans.apache.org  
> mailto:dev@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 
> 

[jira] [Created] (MEECROWAVE-323) Incorrect filename for annotation processor

[Vladimir V. Bychkov (Jira)]

Vladimir V. Bychkov created MEECROWAVE-323:
--

 Summary: Incorrect filename for annotation processor
 Key: MEECROWAVE-323
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-323
 Project: Meecrowave
  Issue Type: Bug
Affects Versions: 1.2.14
 Environment: Java 17
Reporter: Vladimir V. Bychkov


Dependency artifact 
[meecrowave-core:1.2.14:jakarta|https://repo1.maven.org/maven2/org/apache/meecrowave/meecrowave-core/1.2.14/meecrowave-core-1.2.14-jakarta.jar]
 contains file /META-INF/services/*jakarta*.annotation.processing.Processor. 
The name of file si incorrect: this file is not a part of Jakarta EE, but part 
of Java EE. His name since JDK 6 was und stays 
*javax*.annotation.processing.Processor.

This error is name is a blocker: when build with maven-compiler it produces 
error

{code}
Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: 
Compilation failure error: Bad service configuration file, or exception thrown 
while constructing Processor object: 
jakarta/annotation/processing/AbstractProcessor

at 
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1310)
at 
org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:183)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:370)
{code}




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [DISCUSS] CDI-4.0 core

[Mark Struberg]

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 



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 :
> 
> 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  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le jeu. 13 oct. 2022 à 02:47, David Blevins  a
> écrit :
> 
>>> On Jun 2, 2022, at 12:03 PM, Mark Struberg 
>> 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
>> 
>>