[jira] [Commented] (MEECROWAVE-337) Migrate javax to jakarta

[Mark Struberg (Jira)]

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

Mark Struberg commented on MEECROWAVE-337:
--

I agree that we should move Meecrowave to native jakartaEE finally and ship a 
release in the near future.

> Migrate javax to jakarta
> 
>
> Key: MEECROWAVE-337
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-337
> Project: Meecrowave
>  Issue Type: Wish
>Reporter: Shai Zambrovski
>Priority: Major
>
> Hi
> 1st of all, I just want to say thanks for this great framework.
> There is a plan to:
> 1. Continue release newer versions? The last in maven repo was released on 
> Jan 23
> 2. Any plan to migrate javax to jakarta namespace? It does doing some 
> headache in our products.
> 3. Fix CVEs in the latest versions
> Thanks,
> Shai



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

[jira] [Created] (OWB-1438) Synthetic InjectionPoint for CDI.current() and similar usages

[Mark Struberg (Jira)]

Mark Struberg created OWB-1438:
--

 Summary: Synthetic InjectionPoint for CDI.current() and similar 
usages
 Key: OWB-1438
 URL: https://issues.apache.org/jira/browse/OWB-1438
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 4.0.2
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 4.0.3


Right now using CDI.current().select(...).get() does not create an 
InjectionPoint. Thus it's not possible to use a Dependent Scoped producer. We 
could create a synthetic InjectionPoint with the qualifiers and type which got 
selected.



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

Re: [VOTE] Release Apache OpenWebBeans-4.0.2

[Mark Struberg]

Time to tally the VOTE.

And sorry for taking so long!

Here is also my own +1.


The VOTE did therefore pass with the following
+1: Thomas, Gerhard, Daniel, Reinhard, Mark

No -1 nor 0

Will proceed with the release tasks.

txs and LieGrue,
strub



> Am 29.01.2024 um 10:36 schrieb Mark Struberg :
> 
> Hi lords and ladies!
> 
> I'd like to call a VOTE on releasing Apache OpenWebBeans-4.0.2
> 
> We fixed the following tickets
> 
> Bug
>[OWB-1436] - org.apache.webbeans.el22.WrappedValueExpressionNode'does not 
> have the property 'xxx'
>[OWB-1437] - InstanceImpl#destroy might lead to a NPE
> 
> Improvement
>[OWB-1434] - upgrade various dependencies to more recent versions
> 
> 
> The stating repo is here
> 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1085/
> 
> 
> The source jar is available at
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1085/org/apache/openwebbeans/openwebbeans/4.0.2/
> 
> sha512 is 
> 28199a1eaff15f3c5b9a6d11467eb595a3c9e78bfde5e9e624ed9e4031d48cb86546c88836f92ac0040f30261a3081a7fa543959ef1489061de31ef5f27fcc5f
> 
> Please VOTE
> 
> [+1] let's ship it!
> [+0] meh, don't care or not perfect
> [-1] abort, there is a ${showstopper}
> 
> The VOTE is open for 72h
> 
> txs and LieGrue,
> strub
> 

[VOTE] Release Apache OpenWebBeans-4.0.2

[Mark Struberg]

Hi lords and ladies!

I'd like to call a VOTE on releasing Apache OpenWebBeans-4.0.2

We fixed the following tickets

Bug
[OWB-1436] - org.apache.webbeans.el22.WrappedValueExpressionNode'does not 
have the property 'xxx'
[OWB-1437] - InstanceImpl#destroy might lead to a NPE

Improvement
[OWB-1434] - upgrade various dependencies to more recent versions


The stating repo is here

https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1085/


The source jar is available at
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1085/org/apache/openwebbeans/openwebbeans/4.0.2/

sha512 is 
28199a1eaff15f3c5b9a6d11467eb595a3c9e78bfde5e9e624ed9e4031d48cb86546c88836f92ac0040f30261a3081a7fa543959ef1489061de31ef5f27fcc5f

Please VOTE

[+1] let's ship it!
[+0] meh, don't care or not perfect
[-1] abort, there is a ${showstopper}

The VOTE is open for 72h

txs and LieGrue,
strub

[jira] [Resolved] (OWB-1434) upgrade various dependencies to more recent versions

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1434.

Resolution: Fixed

> upgrade various dependencies to more recent versions
> 
>
> Key: OWB-1434
> URL: https://issues.apache.org/jira/browse/OWB-1434
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 4.0.0
>    Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 4.0.2
>
>
> While preparing a 4.0.1 release we should also go through various 
> dependencies and upgrade to more recent versions. E.g. fixed jakarta spec api 
> jars.



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

rolling a release

[Mark Struberg]

hi folks!

FYI, I gonna trigger a release now.

LieGrue,
strub

Re: [VOTE] [RESULT] Release Apache OpenWebBeans-4.0.1

[Mark Struberg]

and my own +1

Which makes it
+1: Thomas, Daniel, Romain, Mark

No -1 nor 0

txs for reviewing and voting!

Will continue with the release steps.

LieGrue,
strub




> Am 13.11.2023 um 07:28 schrieb Romain Manni-Bucau :
> 
> +1
> 
> Le lun. 13 nov. 2023 à 07:16, Daniel Dias Dos Santos <
> daniel.dias.analist...@gmail.com> a écrit :
> 
>> Hi,
>> 
>> +1
>> 
>> On Sun, Nov 12, 2023, 06:57 Thomas Andraschko >> 
>> wrote:
>> 
>>> +1
>>> 
>>> Mark Struberg  schrieb am Sa., 11. Nov. 2023,
>>> 20:09:
>>> 
>>>> Good afternoon!
>>>> 
>>>> I'd like to call a VOTE on releasing Apache OpenWebBeans 4.0.1
>>>> 
>>>> The following tickets got resolved:
>>>> Improvement
>>>> 
>>>> [OWB-1430 <https://issues.apache.org/jira/browse/OWB-1430>] -
>>>> BeanManagerBean should implement BeanContainer
>>>> [OWB-1431 <https://issues.apache.org/jira/browse/OWB-1431>] - upgrade
>>>> xbean to 4.24
>>>> [OWB-1432 <https://issues.apache.org/jira/browse/OWB-1432>] -
>>>> ClassCastException in ValidatingInjectionTargetFactory
>>>> [OWB-1433 <https://issues.apache.org/jira/browse/OWB-1433>] - upgrade
>>>> maven plugins and set Java version to 11
>>>> [OWB-1434 <https://issues.apache.org/jira/browse/OWB-1434>] - upgrade
>>>> various dependencies to more recent versions
>>>> [OWB-1435 <https://issues.apache.org/jira/browse/OWB-1435>] - upgrade
>> to
>>>> apache parent 30
>>>> 
>>>> 
>>>> The staging repo is
>>>> 
>>>> 
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1084/
>>>> 
>>>> The source release can be found here:
>>>> 
>>>> 
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1084/org/apache/openwebbeans/openwebbeans/4.0.1/
>>>> 
>>>> sha512 is
>>>> 
>>>> 
>>> 
>> 85cfd180ae29273ce6a96d9c5114de6b76a57a0066fb5f4a2daa9412754bde6ee2d2382a8bb986eeb86c3dee43f9b7f2b8b9dd1be61559031d6efcc8dfd18497
>>>> 
>>>> Please VOTE:
>>>> 
>>>> [+1] yup, ship it!
>>>> [+0] meh, don't care
>>>> [-1] nah, there is a ${showstopper}
>>>> 
>>>> The VOTE is open for 72h
>>>> 
>>>> txs and LieGrue,
>>>> strub
>>>> 
>>>> 
>>> 
>> 

[VOTE] Release Apache OpenWebBeans-4.0.1

[Mark Struberg]

Good afternoon!

I'd like to call a VOTE on releasing Apache OpenWebBeans 4.0.1

The following tickets got resolved:
Improvement

[OWB-1430 ] - BeanManagerBean 
should implement BeanContainer
[OWB-1431 ] - upgrade xbean to 
4.24
[OWB-1432 ] - 
ClassCastException in ValidatingInjectionTargetFactory
[OWB-1433 ] - upgrade maven 
plugins and set Java version to 11
[OWB-1434 ] - upgrade various 
dependencies to more recent versions
[OWB-1435 ] - upgrade to apache 
parent 30


The staging repo is
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1084/

The source release can be found here:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1084/org/apache/openwebbeans/openwebbeans/4.0.1/

sha512 is
85cfd180ae29273ce6a96d9c5114de6b76a57a0066fb5f4a2daa9412754bde6ee2d2382a8bb986eeb86c3dee43f9b7f2b8b9dd1be61559031d6efcc8dfd18497

Please VOTE:

[+1] yup, ship it!
[+0] meh, don't care
[-1] nah, there is a ${showstopper}

The VOTE is open for 72h

txs and LieGrue,
strub

[jira] [Resolved] (OWB-1435) upgrade to apache parent 30

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1435.

Resolution: Fixed

> upgrade to apache parent 30
> ---
>
> Key: OWB-1435
> URL: https://issues.apache.org/jira/browse/OWB-1435
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 4.0.0
>    Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 4.0.1
>
>
> upgrade to apache parent 30



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

[jira] [Created] (OWB-1435) upgrade to apache parent 30

[Mark Struberg (Jira)]

Mark Struberg created OWB-1435:
--

 Summary: upgrade to apache parent 30
 Key: OWB-1435
 URL: https://issues.apache.org/jira/browse/OWB-1435
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 4.0.0
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 4.0.1


upgrade to apache parent 30



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

[jira] [Created] (OWB-1434) upgrade various dependencies to more recent versions

[Mark Struberg (Jira)]

Mark Struberg created OWB-1434:
--

 Summary: upgrade various dependencies to more recent versions
 Key: OWB-1434
 URL: https://issues.apache.org/jira/browse/OWB-1434
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 4.0.0
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 4.0.1


While preparing a 4.0.1 release we should also go through various dependencies 
and upgrade to more recent versions. E.g. fixed jakarta spec api jars.



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

[jira] [Resolved] (OWB-1433) upgrade maven plugins and set Java version to 11

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1433.

Resolution: Fixed

> upgrade maven plugins and set Java version to 11
> 
>
> Key: OWB-1433
> URL: https://issues.apache.org/jira/browse/OWB-1433
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 4.0.0
>    Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 4.0.1
>
>
> upgrade some maven plugins
> * maven-jar-plugin 2.6 -> 3.2.0
> * maven-compiler-plugin 3.5.1 -> 3.8.1
> also set the default Java version for source and target to Java11



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

[jira] [Created] (OWB-1433) upgrade maven plugins and set Java version to 11

[Mark Struberg (Jira)]

Mark Struberg created OWB-1433:
--

 Summary: upgrade maven plugins and set Java version to 11
 Key: OWB-1433
 URL: https://issues.apache.org/jira/browse/OWB-1433
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 4.0.0
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 4.0.1


upgrade some maven plugins

* maven-jar-plugin 2.6 -> 3.2.0
* maven-compiler-plugin 3.5.1 -> 3.8.1


also set the default Java version for source and target to Java11



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

[jira] [Commented] (OWB-1429) Java 21 not supported?

[Mark Struberg (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784119#comment-17784119
 ] 

Mark Struberg commented on OWB-1429:


Cool, thanks for clarifying!
Will try to work towards a 2.0.28 version as well.

> Java 21 not supported?
> --
>
> Key: OWB-1429
> URL: https://issues.apache.org/jira/browse/OWB-1429
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.27
>Reporter: Torsten Stolpmann
>Priority: Major
>
> I am porting our application from Java 11 to Java 21.
> During initialization, I get the following exception from OpenWebBeans 2.0.27:
> Caused by: java.lang.RuntimeException: Unable to read class definition for 
> com.sun.faces.context.FacesFileNotFoundException
>     at 
> org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1180)
>     at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:153)
>     at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:166)
>     at 
> org.apache.webbeans.corespi.scanner.xbean.OwbAnnotationFinder.(OwbAnnotationFinder.java:41)
>     at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.initFinder(AbstractMetaDataDiscovery.java:138)
>     at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:177)
>     ... 33 more
> Caused by: java.lang.IllegalArgumentException: Unsupported class file major 
> version 65
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:199)
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:180)
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:166)
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:287)
>     at 
> org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1176)
> I already updated the org.apache.xbean:xbean-asm9-shaded dependency to the 
> latest version 4.24.
> Is OpenWebBeans 2.0.27 not supposed to work with Java 21?
> What else can I try?



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

[jira] [Comment Edited] (OWB-1429) Java 21 not supported?

[Mark Struberg (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784052#comment-17784052
 ] 

Mark Struberg edited comment on OWB-1429 at 11/8/23 3:04 PM:
-

Java 21 also requires the new TCK - where they introduced new bugs/non spec 
compliant behaviour :( I've now challenged a few more tests to make it pass.

*edit* just figured that this is about OWB-2.x. I'll dig and see what I can do 
to make it work. xbean-asm-4.24 uses ASM-9.6 which even supports Java22 
already. So it should work. Can you probably provide a sample project to 
showcase the problem would be very helpful - txs!



was (Author: struberg):
Java 21 also requires the new TCK - where they introduced new bugs/non spec 
compliant behaviour :( I've now challenged a few more tests to make it pass.

*edit* just figured that this is about OWB-2.x. I'll dig and see what I can do 
to make it work.

> Java 21 not supported?
> --
>
> Key: OWB-1429
> URL: https://issues.apache.org/jira/browse/OWB-1429
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.27
>Reporter: Torsten Stolpmann
>Priority: Major
>
> I am porting our application from Java 11 to Java 21.
> During initialization, I get the following exception from OpenWebBeans 2.0.27:
> Caused by: java.lang.RuntimeException: Unable to read class definition for 
> com.sun.faces.context.FacesFileNotFoundException
>     at 
> org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1180)
>     at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:153)
>     at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:166)
>     at 
> org.apache.webbeans.corespi.scanner.xbean.OwbAnnotationFinder.(OwbAnnotationFinder.java:41)
>     at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.initFinder(AbstractMetaDataDiscovery.java:138)
>     at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:177)
>     ... 33 more
> Caused by: java.lang.IllegalArgumentException: Unsupported class file major 
> version 65
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:199)
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:180)
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:166)
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:287)
>     at 
> org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1176)
> I already updated the org.apache.xbean:xbean-asm9-shaded dependency to the 
> latest version 4.24.
> Is OpenWebBeans 2.0.27 not supposed to work with Java 21?
> What else can I try?



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

[jira] [Comment Edited] (OWB-1429) Java 21 not supported?

[Mark Struberg (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784052#comment-17784052
 ] 

Mark Struberg edited comment on OWB-1429 at 11/8/23 2:58 PM:
-

Java 21 also requires the new TCK - where they introduced new bugs/non spec 
compliant behaviour :( I've now challenged a few more tests to make it pass.

*edit* just figured that this is about OWB-2.x. I'll dig and see what I can do 
to make it work.


was (Author: struberg):
Java 21 also requires the new TCK - where they introduced new bugs/non spec 
compliant behaviour :( I've now challenged a few more tests to make it pass.

> Java 21 not supported?
> --
>
> Key: OWB-1429
> URL: https://issues.apache.org/jira/browse/OWB-1429
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.27
>Reporter: Torsten Stolpmann
>Priority: Major
>
> I am porting our application from Java 11 to Java 21.
> During initialization, I get the following exception from OpenWebBeans 2.0.27:
> Caused by: java.lang.RuntimeException: Unable to read class definition for 
> com.sun.faces.context.FacesFileNotFoundException
>     at 
> org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1180)
>     at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:153)
>     at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:166)
>     at 
> org.apache.webbeans.corespi.scanner.xbean.OwbAnnotationFinder.(OwbAnnotationFinder.java:41)
>     at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.initFinder(AbstractMetaDataDiscovery.java:138)
>     at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:177)
>     ... 33 more
> Caused by: java.lang.IllegalArgumentException: Unsupported class file major 
> version 65
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:199)
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:180)
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:166)
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:287)
>     at 
> org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1176)
> I already updated the org.apache.xbean:xbean-asm9-shaded dependency to the 
> latest version 4.24.
> Is OpenWebBeans 2.0.27 not supposed to work with Java 21?
> What else can I try?



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

[jira] [Commented] (OWB-1429) Java 21 not supported?

[Mark Struberg (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784052#comment-17784052
 ] 

Mark Struberg commented on OWB-1429:


Java 21 also requires the new TCK - where they introduced new bugs/non spec 
compliant behaviour :( I've now challenged a few more tests to make it pass.

> Java 21 not supported?
> --
>
> Key: OWB-1429
> URL: https://issues.apache.org/jira/browse/OWB-1429
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.27
>Reporter: Torsten Stolpmann
>Priority: Major
>
> I am porting our application from Java 11 to Java 21.
> During initialization, I get the following exception from OpenWebBeans 2.0.27:
> Caused by: java.lang.RuntimeException: Unable to read class definition for 
> com.sun.faces.context.FacesFileNotFoundException
>     at 
> org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1180)
>     at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:153)
>     at 
> org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:166)
>     at 
> org.apache.webbeans.corespi.scanner.xbean.OwbAnnotationFinder.(OwbAnnotationFinder.java:41)
>     at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.initFinder(AbstractMetaDataDiscovery.java:138)
>     at 
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:177)
>     ... 33 more
> Caused by: java.lang.IllegalArgumentException: Unsupported class file major 
> version 65
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:199)
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:180)
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:166)
>     at org.apache.xbean.asm9.ClassReader.(ClassReader.java:287)
>     at 
> org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1176)
> I already updated the org.apache.xbean:xbean-asm9-shaded dependency to the 
> latest version 4.24.
> Is OpenWebBeans 2.0.27 not supposed to work with Java 21?
> What else can I try?



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

[jira] [Resolved] (OWB-1432) ClassCastException in ValidatingInjectionTargetFactory

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1432.

Resolution: Fixed

> ClassCastException in ValidatingInjectionTargetFactory
> --
>
> Key: OWB-1432
> URL: https://issues.apache.org/jira/browse/OWB-1432
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 4.0.0
>    Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 4.0.1
>
>
> In ValidatingInjectionTargetFactory we upcast to a InjectionTargetImpl 
> without any check.



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

[jira] [Resolved] (OWB-1430) BeanManagerBean should implement BeanContainer

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1430.

Resolution: Fixed

> BeanManagerBean should implement BeanContainer
> --
>
> Key: OWB-1430
> URL: https://issues.apache.org/jira/browse/OWB-1430
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 4.0.0
>    Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 4.0.1
>
>
> BeanManagerBean should also sattisfy the BeanContainer type.



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

[jira] [Created] (OWB-1432) ClassCastException in ValidatingInjectionTargetFactory

[Mark Struberg (Jira)]

Mark Struberg created OWB-1432:
--

 Summary: ClassCastException in ValidatingInjectionTargetFactory
 Key: OWB-1432
 URL: https://issues.apache.org/jira/browse/OWB-1432
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 4.0.0
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 4.0.1


In ValidatingInjectionTargetFactory we upcast to a InjectionTargetImpl without 
any check.



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

[jira] [Resolved] (OWB-1431) upgrade xbean to 4.24

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1431.

Resolution: Fixed

> upgrade xbean to 4.24
> -
>
> Key: OWB-1431
> URL: https://issues.apache.org/jira/browse/OWB-1431
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 4.0.0
>    Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 4.0.1
>
>
> upgrade xbean to 4.24



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

[jira] [Created] (OWB-1431) upgrade xbean to 4.24

[Mark Struberg (Jira)]

Mark Struberg created OWB-1431:
--

 Summary: upgrade xbean to 4.24
 Key: OWB-1431
 URL: https://issues.apache.org/jira/browse/OWB-1431
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 4.0.0
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 4.0.1


upgrade xbean to 4.24



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

[jira] [Created] (OWB-1430) BeanManagerBean should implement BeanContainer

[Mark Struberg (Jira)]

Mark Struberg created OWB-1430:
--

 Summary: BeanManagerBean should implement BeanContainer
 Key: OWB-1430
 URL: https://issues.apache.org/jira/browse/OWB-1430
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 4.0.0
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 4.0.1


BeanManagerBean should also sattisfy the BeanContainer type.



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

Re: [VOTE] Release Apache OpenWebBeans-4.0.0

[Mark Struberg]

Sure, good idea. Let's do that!
Happy if you could grab mw and do the update if you like.

LieGrue,
strub

> Am 14.09.2023 um 14:29 schrieb Arne Limburg :
> 
> Hi all,
> 
> congratulations for the release. Are there any plans to release meecrowave 
> with the new namespace anytime soon?
> Anything where I can help?
> 
> 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 
> <mailto:arne.limb...@openknowledge.de><mailto:arne.limb...@openknowledge.de>
> http://www.openknowledge.de/<https://www.openknowledge.de/> 
> <http://www.openknowledge.de/%3Chttps://www.openknowledge.de/%3E>
> 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://www.openknowledge.de/event/>
> 
> Von: Mark Struberg  <mailto:strub...@yahoo.de.INVALID>>
> Datum: Donnerstag, 7. September 2023 um 19:32
> An: openwebbeans-dev  <mailto:dev@openwebbeans.apache.org>>
> Betreff: Re: [VOTE] Release Apache OpenWebBeans-4.0.0
> Good afternoon!
> 
> 72h is over, time to tally the VOTE!
> 
> The following votes got casted:
> 
> +1: Thomas, Daniel, Romain, Richard, Mark
> No -1 nor 0
> 
> I'll continue with the release.
> Thanks to all who reviewed and voted!
> 
> txs and LieGrue,
> strub
> 
> 
> 
>> Am 04.09.2023 um 14:13 schrieb Mark Struberg :
>> 
>> Hi folks!
>> 
>> I'd like to call a VOTE on releasing Apache OpenWebBeans-4.0.0
>> This is the first release with the jakarta namespace.
>> We passed most of the CDI-4.0 TCK (all the standalone parts), the full EE 
>> TCK will be passed as part of the Apache TomEE project.
>> 
>> The following tickets got resolved:
>> 
>> Bug
>>   [OWB-1368] - Maven artifacts with Jakarta classifier requires the 
>> artifacts without classifier
>>   [OWB-1418] - @Priority on @Alternative @Stereotype enables the bean
>>   [OWB-1423] - openwebbeans-impl-jakarta is using old javax namespace
>>   [OWB-1425] - Interceptors not being called on UnmanagedInstance
>>   [OWB-1426] - Missing bean types for indirectly implemented interfaces
>> 
>> Epic
>>   [OWB-1417] - Implement CDI-4.0 spec
>> 
>> New Feature
>>   [OWB-1427] - Support for dotted bean names with EL
>> 
>> Improvement
>>   [OWB-1428] - make default bean-discovery-mode configurable
>> 
>> Task
>>   [OWB-1088] - fix samples with java 8 and update to tomcat7/8
>> 
>> TCK Challenge
>>   [OWB-1419] - 
>> org.jboss.cdi.tck.interceptors.tests.bindings.aroundConstruct.ConstructorInterceptionTest
>>   [OWB-1420] - 
>> org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.bindings.LifecycleInterceptorDefinitionTest
>>   [OWB-1421] - 
>> org.jboss.cdi.tck.interceptors.tests.bindings.overriding.InterceptorBindingOverridingTest
>>   [OWB-1422] - 
>> org.jboss.cdi.tck.tests.interceptors.definition.InterceptorDefinitionTest
>>   [OWB-1424] - 
>> org.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTestorg.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTest
>> 
>> 
>> The staging repo is available at 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/<https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/>
>>  
>> <https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/%3Chttps://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/%3E>
>> 
>> The source zip can be found here: 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/org/apache/openwebbeans/openwebbeans/4.0.0/<https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/org/apache/openwebbeans/openwebbeans/4.0.0/>
>>  
>> <https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/org/apache/openwebbeans/openwebbeans/4.0.0/%3Chttps://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/org/apache/openwebbeans/openwebbeans/4.0.0/%3E>
>> 
>> sha512 is 
>> 99f470a2a64e98e292bc6e604377ed7c2f3c9b5593d40dfe079d6b16bf23df5ff17054f76ef0b3ee138d17dc611abdd89285496936f3674f1928c2c2c0faf963
>> 
>> 
>> 
>> Please VOTE
>> [+1] yep, ship it!
>> [+0] meh, don't care
>> [-1] nah, there is a ${showstopper}
>> 
>> The VOTE is open for 72h
>> 
>> 
>> txs and LieGrue,
>> strub

Re: [VOTE] Release Apache OpenWebBeans-4.0.0

[Mark Struberg]

Good afternoon!

72h is over, time to tally the VOTE!

The following votes got casted:

+1: Thomas, Daniel, Romain, Richard, Mark
No -1 nor 0

I'll continue with the release.
Thanks to all who reviewed and voted!

txs and LieGrue,
strub



> Am 04.09.2023 um 14:13 schrieb Mark Struberg :
> 
> Hi folks!
> 
> I'd like to call a VOTE on releasing Apache OpenWebBeans-4.0.0
> This is the first release with the jakarta namespace.
> We passed most of the CDI-4.0 TCK (all the standalone parts), the full EE TCK 
> will be passed as part of the Apache TomEE project.
> 
> The following tickets got resolved:
> 
> Bug
>[OWB-1368] - Maven artifacts with Jakarta classifier requires the 
> artifacts without classifier
>[OWB-1418] - @Priority on @Alternative @Stereotype enables the bean
>[OWB-1423] - openwebbeans-impl-jakarta is using old javax namespace
>[OWB-1425] - Interceptors not being called on UnmanagedInstance
>[OWB-1426] - Missing bean types for indirectly implemented interfaces
> 
> Epic
>[OWB-1417] - Implement CDI-4.0 spec
> 
> New Feature
>[OWB-1427] - Support for dotted bean names with EL
> 
> Improvement
>[OWB-1428] - make default bean-discovery-mode configurable
> 
> Task
>[OWB-1088] - fix samples with java 8 and update to tomcat7/8
> 
> TCK Challenge
>[OWB-1419] - 
> org.jboss.cdi.tck.interceptors.tests.bindings.aroundConstruct.ConstructorInterceptionTest
>[OWB-1420] - 
> org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.bindings.LifecycleInterceptorDefinitionTest
>[OWB-1421] - 
> org.jboss.cdi.tck.interceptors.tests.bindings.overriding.InterceptorBindingOverridingTest
>[OWB-1422] - 
> org.jboss.cdi.tck.tests.interceptors.definition.InterceptorDefinitionTest
>[OWB-1424] - 
> org.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTestorg.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTest
> 
> 
> The staging repo is available at 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/
> 
> The source zip can be found here: 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/org/apache/openwebbeans/openwebbeans/4.0.0/
> 
> sha512 is 
> 99f470a2a64e98e292bc6e604377ed7c2f3c9b5593d40dfe079d6b16bf23df5ff17054f76ef0b3ee138d17dc611abdd89285496936f3674f1928c2c2c0faf963
> 
> 
> 
> Please VOTE
> [+1] yep, ship it!
> [+0] meh, don't care
> [-1] nah, there is a ${showstopper}
> 
> The VOTE is open for 72h
> 
> 
> txs and LieGrue,
> strub
> 

Re: [VOTE] Release Apache OpenWebBeans-4.0.0

[Mark Struberg]

+1


LieGrue,
strub


> Am 04.09.2023 um 14:13 schrieb Mark Struberg :
> 
> Hi folks!
> 
> I'd like to call a VOTE on releasing Apache OpenWebBeans-4.0.0
> This is the first release with the jakarta namespace.
> We passed most of the CDI-4.0 TCK (all the standalone parts), the full EE TCK 
> will be passed as part of the Apache TomEE project.
> 
> The following tickets got resolved:
> 
> Bug
>[OWB-1368] - Maven artifacts with Jakarta classifier requires the 
> artifacts without classifier
>[OWB-1418] - @Priority on @Alternative @Stereotype enables the bean
>[OWB-1423] - openwebbeans-impl-jakarta is using old javax namespace
>[OWB-1425] - Interceptors not being called on UnmanagedInstance
>[OWB-1426] - Missing bean types for indirectly implemented interfaces
> 
> Epic
>[OWB-1417] - Implement CDI-4.0 spec
> 
> New Feature
>[OWB-1427] - Support for dotted bean names with EL
> 
> Improvement
>[OWB-1428] - make default bean-discovery-mode configurable
> 
> Task
>[OWB-1088] - fix samples with java 8 and update to tomcat7/8
> 
> TCK Challenge
>[OWB-1419] - 
> org.jboss.cdi.tck.interceptors.tests.bindings.aroundConstruct.ConstructorInterceptionTest
>[OWB-1420] - 
> org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.bindings.LifecycleInterceptorDefinitionTest
>[OWB-1421] - 
> org.jboss.cdi.tck.interceptors.tests.bindings.overriding.InterceptorBindingOverridingTest
>[OWB-1422] - 
> org.jboss.cdi.tck.tests.interceptors.definition.InterceptorDefinitionTest
>[OWB-1424] - 
> org.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTestorg.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTest
> 
> 
> The staging repo is available at 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/
> 
> The source zip can be found here: 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/org/apache/openwebbeans/openwebbeans/4.0.0/
> 
> sha512 is 
> 99f470a2a64e98e292bc6e604377ed7c2f3c9b5593d40dfe079d6b16bf23df5ff17054f76ef0b3ee138d17dc611abdd89285496936f3674f1928c2c2c0faf963
> 
> 
> 
> Please VOTE
> [+1] yep, ship it!
> [+0] meh, don't care
> [-1] nah, there is a ${showstopper}
> 
> The VOTE is open for 72h
> 
> 
> txs and LieGrue,
> strub
> 

[VOTE] Release Apache OpenWebBeans-4.0.0

[Mark Struberg]

Hi folks!

I'd like to call a VOTE on releasing Apache OpenWebBeans-4.0.0
This is the first release with the jakarta namespace.
We passed most of the CDI-4.0 TCK (all the standalone parts), the full EE TCK 
will be passed as part of the Apache TomEE project.

The following tickets got resolved:

Bug
[OWB-1368] - Maven artifacts with Jakarta classifier requires the artifacts 
without classifier
[OWB-1418] - @Priority on @Alternative @Stereotype enables the bean
[OWB-1423] - openwebbeans-impl-jakarta is using old javax namespace
[OWB-1425] - Interceptors not being called on UnmanagedInstance
[OWB-1426] - Missing bean types for indirectly implemented interfaces

Epic
[OWB-1417] - Implement CDI-4.0 spec

New Feature
[OWB-1427] - Support for dotted bean names with EL

Improvement
[OWB-1428] - make default bean-discovery-mode configurable

Task
[OWB-1088] - fix samples with java 8 and update to tomcat7/8

TCK Challenge
[OWB-1419] - 
org.jboss.cdi.tck.interceptors.tests.bindings.aroundConstruct.ConstructorInterceptionTest
[OWB-1420] - 
org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.bindings.LifecycleInterceptorDefinitionTest
[OWB-1421] - 
org.jboss.cdi.tck.interceptors.tests.bindings.overriding.InterceptorBindingOverridingTest
[OWB-1422] - 
org.jboss.cdi.tck.tests.interceptors.definition.InterceptorDefinitionTest
[OWB-1424] - 
org.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTestorg.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTest


The staging repo is available at 
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/

The source zip can be found here: 
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1083/org/apache/openwebbeans/openwebbeans/4.0.0/

sha512 is 
99f470a2a64e98e292bc6e604377ed7c2f3c9b5593d40dfe079d6b16bf23df5ff17054f76ef0b3ee138d17dc611abdd89285496936f3674f1928c2c2c0faf963



Please VOTE
[+1] yep, ship it!
[+0] meh, don't care
[-1] nah, there is a ${showstopper}

The VOTE is open for 72h


txs and LieGrue,
strub

[jira] [Resolved] (OWB-1088) fix samples with java 8 and update to tomcat7/8

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1088.

Fix Version/s: 4.0.0
   (was: 2.0.27)
   Resolution: Fixed

> fix samples with java 8 and update to tomcat7/8
> ---
>
> Key: OWB-1088
> URL: https://issues.apache.org/jira/browse/OWB-1088
> Project: OpenWebBeans
>  Issue Type: Task
>  Components: Samples  Documentation
>Affects Versions: 2.0.0
>Reporter: Reinhard Sandtner
>Assignee: Reinhard Sandtner
>Priority: Major
> Fix For: 4.0.0
>
>
> some of our samples are currently broken under java 8



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

[jira] [Resolved] (OWB-1416) Possible misintepretation of spec regarding Unproxyable bean types

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1416.

  Assignee: Mark Struberg
Resolution: Won't Fix

I've looked at it again. Note the exact wording "A bean type must be proxyable 
if an injection point resolves to a bean" plus the definition of bean type:

See the paragraph "Bean types of a managed bean.
The unrestricted set of bean types for a managed bean contains the bean class, 
every superclass and all interfaces it implements directly or indirectly."

This is different from the types of the injection point. See the paragraph 
"Legal injection point types". That means that the full impl has to be 
proxyable, not just the type of the injection point.

> Possible misintepretation of spec regarding Unproxyable bean types
> --
>
> Key: OWB-1416
> URL: https://issues.apache.org/jira/browse/OWB-1416
> Project: OpenWebBeans
>  Issue Type: Bug
>Reporter: Alexander Larsen
>Assignee: Mark Struberg
>Priority: Major
>
> OWB seems to throw an exception for all unproxyable normal scoped beans. I 
> think that this might be incorrect.
> The 
> [specification|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#unproxyable] 
> says the "A bean type must be proxyable if an injection point resolves to a 
> bean", not that all the types of the bean must be proxyable. In other words, 
> as long as the bean is a legal bean, and all injection point resolving to 
> this bean is a proxyable type - no exception should be thrown.
> In the part about [contextual 
> references|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#contextual_reference],
>  there is further indications that unproxyable types should be allowed in the 
> set of types for the bean. It's only when you try to get a reference(injected 
> or by bean manager) to an unproxyable type, and the bean must be proxied 
> (normal scoped, intercepted or decorated) an exception should thrown.
> Also, the [Weld user guide suggests introducing an interface as a solution to 
> having an unproxyable 
> bean|https://docs.jboss.org/weld/reference/latest/en-US/html_single/#_client_proxies].
> The current OWB implementation makes a pattern of having an interface and 
> (one or more) implementation class with final fields/methods somewhat 
> difficult :)



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

[jira] [Resolved] (OWB-1423) openwebbeans-impl-jakarta is using old javax namespace

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1423.

Fix Version/s: 4.0.0
   Resolution: Fixed

> openwebbeans-impl-jakarta is using old javax namespace
> --
>
> Key: OWB-1423
> URL: https://issues.apache.org/jira/browse/OWB-1423
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 2.0.26, 2.0.27
>Reporter: Georg Tsakumagos
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 4.0.0
>
>
> h3. Description
> Openwebbeans with jakarta qualifier should use the jakarta namespace. I try 
> to use openejb 9.0.0 for testing but run into a no NoSuchMethodError.
> The class 
> *_org.apache.webbeans.portable.events.discovery.BeforeBeanDiscoveryImpl_* is 
> using the old namespace.
> h3. Stacktrace
> {code:java}
> Caused by: org.apache.webbeans.exception.WebBeansException: 
> java.lang.NoSuchMethodError: 'void 
> jakarta.enterprise.inject.spi.BeforeBeanDiscovery.addAnnotatedType(jakarta.enterprise.inject.spi.AnnotatedType)'
>   at 
> org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:377)
>   at 
> org.apache.webbeans.event.NotificationManager.invokeObserverMethod(NotificationManager.java:1146)
>   at 
> org.apache.webbeans.event.NotificationManager.doFireSync(NotificationManager.java:1009)
>   ... 61 more
> Caused by: java.lang.NoSuchMethodError: 'void 
> jakarta.enterprise.inject.spi.BeforeBeanDiscovery.addAnnotatedType(jakarta.enterprise.inject.spi.AnnotatedType)'
>   at 
> org.apache.bval.cdi.BValExtension.addBvalBinding(BValExtension.java:112)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> {code}
> h3. GAV Coordinates
> {code:xml}
> 
>   org.apache.openwebbeans
>   openwebbeans-impl
>   jakarta
>   2.0.27
>  {code}



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

[jira] [Resolved] (OWB-1368) Maven artifacts with Jakarta classifier requires the artifacts without classifier

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1368.

Fix Version/s: 4.0.0
   Resolution: Fixed

> Maven artifacts with Jakarta classifier requires the artifacts without 
> classifier
> -
>
> Key: OWB-1368
> URL: https://issues.apache.org/jira/browse/OWB-1368
> Project: OpenWebBeans
>  Issue Type: Bug
>Reporter: Thiago Henrique Hupner
>    Assignee: Mark Struberg
>Priority: Critical
> Fix For: 4.0.0
>
>
> We're trying to use the Jakartized version of OpenWebBeans. However, I 
> noticed that the artifacts with Jakarta classifier requires the dependencies 
> without a classifier.
> While we can fix it on our side by excluding all the dependencies and 
> reincluding all of them with the Jakarta classifier, it is very inconvenient.
> Is there a way to fix it on the OpenWebBeans side? So we can just include, 
> for instance, openwebbeans-web instead of requiring all of the components 
> with the Jakarta classifier.
>  



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

[jira] [Assigned] (OWB-1423) openwebbeans-impl-jakarta is using old javax namespace

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg reassigned OWB-1423:
--

Assignee: Mark Struberg

> openwebbeans-impl-jakarta is using old javax namespace
> --
>
> Key: OWB-1423
> URL: https://issues.apache.org/jira/browse/OWB-1423
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 2.0.26, 2.0.27
>Reporter: Georg Tsakumagos
>    Assignee: Mark Struberg
>Priority: Major
>
> h3. Description
> Openwebbeans with jakarta qualifier should use the jakarta namespace. I try 
> to use openejb 9.0.0 for testing but run into a no NoSuchMethodError.
> The class 
> *_org.apache.webbeans.portable.events.discovery.BeforeBeanDiscoveryImpl_* is 
> using the old namespace.
> h3. Stacktrace
> {code:java}
> Caused by: org.apache.webbeans.exception.WebBeansException: 
> java.lang.NoSuchMethodError: 'void 
> jakarta.enterprise.inject.spi.BeforeBeanDiscovery.addAnnotatedType(jakarta.enterprise.inject.spi.AnnotatedType)'
>   at 
> org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:377)
>   at 
> org.apache.webbeans.event.NotificationManager.invokeObserverMethod(NotificationManager.java:1146)
>   at 
> org.apache.webbeans.event.NotificationManager.doFireSync(NotificationManager.java:1009)
>   ... 61 more
> Caused by: java.lang.NoSuchMethodError: 'void 
> jakarta.enterprise.inject.spi.BeforeBeanDiscovery.addAnnotatedType(jakarta.enterprise.inject.spi.AnnotatedType)'
>   at 
> org.apache.bval.cdi.BValExtension.addBvalBinding(BValExtension.java:112)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> {code}
> h3. GAV Coordinates
> {code:xml}
> 
>   org.apache.openwebbeans
>   openwebbeans-impl
>   jakarta
>   2.0.27
>  {code}



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

Gonna release the OWB master

[Mark Struberg]

hi folks!

I'll start an OWB release soon.
We finished our work for the OWB core container over 2 months ago and it is 
used in TomEE since then. DeltaSpike is also using it since then and needs an 
OWB release to be able to release DeltaSpike. So far no error or show stopper 
got reported, so I think we can safely assume that the core at least works fine.
Note that OWB itself never passed the full CDI TCK in this project but only as 
part of TomEE. So there is no problem to progress with the release.

LieGrue,
strub

[jira] [Commented] (OWB-1426) Missing bean types for indirectly implemented interfaces

[Mark Struberg (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693474#comment-17693474
 ] 

Mark Struberg commented on OWB-1426:


Turns out that the CDITCK challenge got accepted
https://github.com/jakartaee/cdi-tck/issues/429.

Closing this ticket

> Missing bean types for indirectly implemented interfaces
> 
>
> Key: OWB-1426
> URL: https://issues.apache.org/jira/browse/OWB-1426
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core, TCK
>Reporter: Jean-Louis Monteiro
>Priority: Major
> Fix For: 4.0.0
>
>
> The following TCK test is failing in OWB and I think it's a good one from the 
> spec point of view.
>  
> {color:#067d17}org.jboss.cdi.tck.tests.definition.bean.BeanDefinitionTest{color}
>  
> The spec says 
> [https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#managed_bean_types]
>  
> {quote}The unrestricted set of bean types for a managed bean contains the 
> bean class, every superclass and all interfaces it implements directly or 
> indirectly.
> The resulting set of bean types for a managed bean consists only of [legal 
> bean 
> types|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#legal_bean_types],
>  all other types are removed from the set of bean types.
> Note the additional restrictions upon bean types of beans with normal scopes 
> defined in [Unproxyable bean 
> types|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#unproxyable].
> {quote}



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

[jira] [Closed] (OWB-1426) Missing bean types for indirectly implemented interfaces

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg closed OWB-1426.
--
  Assignee: Mark Struberg
Resolution: Fixed

> Missing bean types for indirectly implemented interfaces
> 
>
> Key: OWB-1426
> URL: https://issues.apache.org/jira/browse/OWB-1426
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core, TCK
>Reporter: Jean-Louis Monteiro
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 4.0.0
>
>
> The following TCK test is failing in OWB and I think it's a good one from the 
> spec point of view.
>  
> {color:#067d17}org.jboss.cdi.tck.tests.definition.bean.BeanDefinitionTest{color}
>  
> The spec says 
> [https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#managed_bean_types]
>  
> {quote}The unrestricted set of bean types for a managed bean contains the 
> bean class, every superclass and all interfaces it implements directly or 
> indirectly.
> The resulting set of bean types for a managed bean consists only of [legal 
> bean 
> types|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#legal_bean_types],
>  all other types are removed from the set of bean types.
> Note the additional restrictions upon bean types of beans with normal scopes 
> defined in [Unproxyable bean 
> types|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#unproxyable].
> {quote}



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

[jira] [Commented] (OWB-1426) Missing bean types for indirectly implemented interfaces

[Mark Struberg (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693471#comment-17693471
 ] 

Mark Struberg commented on OWB-1426:


No, this test in the TCK is imo clearly wrong.
{source}
class MyBean implements MyInterface
interface MyInterface extends MySuperInterface
{source}

The TCK test assumes {{MySuperInterface.class}} but we correctly do have the 
parameterized type {{MySuperInterface}}, which is correct according to 
the Java Lang Spec as not erasure kicks in.

Note that we correctly DO erase types for example  in MyBean which ends up 
as MyBean.class in the type list. For for {{MySuperInterface}} there is 
just no erasure!.

> Missing bean types for indirectly implemented interfaces
> 
>
> Key: OWB-1426
> URL: https://issues.apache.org/jira/browse/OWB-1426
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core, TCK
>Reporter: Jean-Louis Monteiro
>Priority: Major
> Fix For: 4.0.0
>
>
> The following TCK test is failing in OWB and I think it's a good one from the 
> spec point of view.
>  
> {color:#067d17}org.jboss.cdi.tck.tests.definition.bean.BeanDefinitionTest{color}
>  
> The spec says 
> [https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#managed_bean_types]
>  
> {quote}The unrestricted set of bean types for a managed bean contains the 
> bean class, every superclass and all interfaces it implements directly or 
> indirectly.
> The resulting set of bean types for a managed bean consists only of [legal 
> bean 
> types|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#legal_bean_types],
>  all other types are removed from the set of bean types.
> Note the additional restrictions upon bean types of beans with normal scopes 
> defined in [Unproxyable bean 
> types|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#unproxyable].
> {quote}



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

[jira] [Resolved] (OWB-1425) Interceptors not being called on UnmanagedInstance

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1425.

Resolution: Resolved

> Interceptors not being called on UnmanagedInstance
> --
>
> Key: OWB-1425
> URL: https://issues.apache.org/jira/browse/OWB-1425
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core, TCK
>Reporter: Jean-Louis Monteiro
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 4.0.0
>
>
> OWB does not interceptors on UnmanagedInstance even though the specification 
> is quite clear in that area.
>  
> https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#biz_method_full
> {quote}When the application invokes:
>  * a method of a bean via a contextual reference to the bean, as defined in 
> [Contextual reference for a 
> bean|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#contextual_reference],
>  * a method of a bean via a non-contextual reference to the bean, if the 
> instance was created by the container (e.g. using 
> {{InjectionTarget.produce()}} or {{{}*UnmanagedInstance.produce()*{}}}, or
>  * a method of a bean via a non-contextual reference to the bean, if the 
> instance was enhanced with the {{InterceptionFactory}} interface as defined 
> in [The {{InterceptionFactory}} 
> interface|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#interception_factory],
> the invocation is treated as a {_}business method invocation{_}.
> {quote}
> The spec also says
> {quote}A method invocation passes through method interceptors and decorators 
> if, and only if, it is a business method invocation.
> Otherwise, the invocation is treated as a normal Java method call and is not 
> intercepted by the container.
> {quote}
>  
> We can't pass the following TCK test 
> org.jboss.cdi.tck.tests.full.extensions.beanManager.unmanaged.UnmanagedInstanceTest
>  



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

[jira] [Assigned] (OWB-1425) Interceptors not being called on UnmanagedInstance

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg reassigned OWB-1425:
--

Assignee: Mark Struberg

> Interceptors not being called on UnmanagedInstance
> --
>
> Key: OWB-1425
> URL: https://issues.apache.org/jira/browse/OWB-1425
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core, TCK
>Reporter: Jean-Louis Monteiro
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 4.0.0
>
>
> OWB does not interceptors on UnmanagedInstance even though the specification 
> is quite clear in that area.
>  
> https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#biz_method_full
> {quote}When the application invokes:
>  * a method of a bean via a contextual reference to the bean, as defined in 
> [Contextual reference for a 
> bean|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#contextual_reference],
>  * a method of a bean via a non-contextual reference to the bean, if the 
> instance was created by the container (e.g. using 
> {{InjectionTarget.produce()}} or {{{}*UnmanagedInstance.produce()*{}}}, or
>  * a method of a bean via a non-contextual reference to the bean, if the 
> instance was enhanced with the {{InterceptionFactory}} interface as defined 
> in [The {{InterceptionFactory}} 
> interface|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#interception_factory],
> the invocation is treated as a {_}business method invocation{_}.
> {quote}
> The spec also says
> {quote}A method invocation passes through method interceptors and decorators 
> if, and only if, it is a business method invocation.
> Otherwise, the invocation is treated as a normal Java method call and is not 
> intercepted by the container.
> {quote}
>  
> We can't pass the following TCK test 
> org.jboss.cdi.tck.tests.full.extensions.beanManager.unmanaged.UnmanagedInstanceTest
>  



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

[jira] [Resolved] (OWB-1428) make default bean-discovery-mode configurable

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1428.

Resolution: Fixed

> make default bean-discovery-mode configurable
> -
>
> Key: OWB-1428
> URL: https://issues.apache.org/jira/browse/OWB-1428
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 4.0.0
>    Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 4.0.0
>
>
> make default bean-discovery-mode configurable
> There was a really wicked change in the CDI-4.0 specification which will 
> break many applications. They switched the bean-discovery-mode of an empty 
> beans.xml file (or a beans.xml without any version) from ALL to ANNOTATED 
> (Despite warnings that his is totally backward incompatible and could easily 
> have been avoided).
> The default in OWB is still ALL, but it can be configured to any other 
> bean-discovery-mode with this config switch to pass this very TCK test.



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

[jira] [Created] (OWB-1428) make default bean-discovery-mode configurable

[Mark Struberg (Jira)]

Mark Struberg created OWB-1428:
--

 Summary: make default bean-discovery-mode configurable
 Key: OWB-1428
 URL: https://issues.apache.org/jira/browse/OWB-1428
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 4.0.0
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 4.0.0


make default bean-discovery-mode configurable

There was a really wicked change in the CDI-4.0 specification which will break 
many applications. They switched the bean-discovery-mode of an empty beans.xml 
file (or a beans.xml without any version) from ALL to ANNOTATED (Despite 
warnings that his is totally backward incompatible and could easily have been 
avoided).

The default in OWB is still ALL, but it can be configured to any other 
bean-discovery-mode with this config switch to pass this very TCK test.




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

Re: [DISCUSS] Release OWB-4.0.0?

[Mark Struberg]

I've created a few tickets but not all yet. Just wanted to get the most 
obviously broken tests out of the way.

LieGrue,
strub

> Am 09.02.2023 um 02:17 schrieb David Blevins :
> 
> 
> 
>> On Jan 30, 2023, at 5:40 AM, Mark Struberg  wrote:
>> * Some challenged tests, some unspecified behaviour in some tests. E.g. they 
>> assume a specified order class annotations before method annotations for 
>> Interceptors. But the spec *explicitly* says that for Interceptors with the 
>> same @Priority the order is unspecified.
> 
> Do you have links to the challenges you filed and does it look like they’ll 
> be accepted?
> 
> 
> -David
> 

Re: [DISCUSS] Release OWB-4.0.0?

[Mark Struberg]

I'm fine with 11 as well, all runs really well and we don't use any feature 
from Java17. I did it mainly to push the boundaries a bit. Maybe I pushed too 
far ;)

LieGrue,
strub


> Am 09.02.2023 um 02:15 schrieb David Blevins :
> 
> Looks like we’ve set the Java version to 17.  I can confirm it does build 
> fine with 11.
> 
> Are we open to using 11 for 4.0.0 and waiting till the next release to go to 
> 17?
> 
> 
> -David
> 
> 
>> On Jan 30, 2023, at 5:40 AM, Mark Struberg  wrote:
>> 
>> hi folks!
>> 
>> We are up and running with passing most CDI-4.0 TCK tests.
>> There are a few areas where we have excluded some tests:
>> 
>> * CDI-lite. I'll not gonna implement this in OWB as it is purely for Quarkus 
>> and I don't care. It should be straight forward to implement the 
>> functionality as  OWB plugin if someone really needs it though.
>> * Some challenged tests, some unspecified behaviour in some tests. E.g. they 
>> assume a specified order class annotations before method annotations for 
>> Interceptors. But the spec *explicitly* says that for Interceptors with the 
>> same @Priority the order is unspecified.
>> * backward incompatible reversing the default bean-discovery-mode for empty 
>> beans.xmls. I'll not gonna implement this as it also did break the JakartaEE 
>> rules alltogether.
>> 
>> 
>> Things I want to change yet before the release:
>> 
>> * Decide about the jetty9 plugin. Tbh I'd keep it excluded until someone 
>> wants to contribute fixes to it.
>> * provide a shaded version of the CDI api jar without all the CDI-lite parts.
>> 
>> 
>> Wdyt?
>> 
>> LieGrue,
>> strub
>> 
>> 
> 

Re: [DISCUSS] Release OWB-4.0.0?

[Mark Struberg]

Already in the past we did not implement all features of the CDI spec in OWB. 
We left certain EE features defined in the CDI spec up to OpenEJB for 
example.What we did is to provide internal SPI to make this possible. As we do 
now. Imo all the necessary SPI should be in place. If something is missing I 
gonna add it. But I personally will not invest time in CDI-light. If you or 
anyone else wants to do it you are perfectly welcome. But I personally will not 
like to see us blocked for years to come by a trojan horse feature of imo not 
much use.

LieGrue,
strub


> Am 30.01.2023 um 23:23 schrieb Romain Manni-Bucau :
> 
> Le lun. 30 janv. 2023 à 21:27, Mark Struberg  a
> écrit :
> 
>> It's not the full story.
>> We for example did never really implement the inconsistent BDA
>> specification, global alternatives etc.
>> Same here.
>> 
> 
> But we implemented all api, here it is way more obvious it is wrong since
> it is having CDI core dead api, nothing ambiguous as the bda so not the
> same story at all IMHO.
> 
> 
>> The CDI-4.0 situation is an inconsistent mess. Even Weld does not
>> implement it fully it seems.
>> I really don't want to be blocked by a mess in the spec.
>> 
> 
> Strictly speaking it was a stupid spec decision but it is not a mess.
> Make it optional, yes, but not missing in a final release targetting this
> spec version. Literally means project goal we write on each report would
> either be totally wrong or we freeze the project to jakartaee 9.
> 
> Both are wrong IMHO on the community+project sides.
> 
> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>>> Am 30.01.2023 um 19:02 schrieb Romain Manni-Bucau >> :
>>> 
>>> Le lun. 30 janv. 2023 à 17:10, Mark Struberg > <mailto:strub...@yahoo.de.invalid>> a
>>> écrit :
>>> 
>>>> I don't see any reason for any -alpha or whatever release. We did never
>>>> claim to be a certified implementation in the past, nor likely will we
>> in
>>>> the future. We try to pass as much from the TCK as makes sense and
>>>> report/challenge TCK tests which disrespect/contradict the spec wording
>>>> and/or JavaDoc of the API. Most of those challenge tickets have been
>>>> bulk-closed and never really addressed for the past CDI versions. So my
>>>> will to go hunt for the carrot in front of my nose is not infinite
>>>> ("endenwollend" as we say here in Vienna).
>>>> 
>>> 
>>> We always went the spec side even if we add toggles to disable/enable
>>> things, but ultimately we cover the full API.
>>> Not providing any way to get it means we don't implement CDI anymore,
>>> nothing else. Can be fine but should be promoted and we should also see
>>> with TomEE what it means for them.
>>> Holding a release is not a goal but doing a final which looks like it
>>> covers the spec whereas it does not cover a third of it would be way more
>>> negative for the project IMHO so let's not be the bad guys and just
>> expose
>>> explicitly our state with a pre-final whatever name fits for you.
>>> 
>>> 
>>>> 
>>>> If someone wants to address/implement the CDI-lite functionality (s)he
>> is
>>>> perfectly welcome to do so. I doubt I will find the time to do it.
>>>> 
>>> 
>>> Once again, no issue to not do it now, should just be a goal of 4.0.0.
>>> 
>>> 
>>>> 
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>>> Am 30.01.2023 um 14:48 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com
>>>>> :
>>>>> 
>>>>> * +1 to drop jetty plugin for now
>>>>> * +-0 to shade cdi-api (nobody will consume it anyway)
>>>>> * -1 to release to not milestone without being spec compliant -
>> including
>>>>> cdi-lite which is part of cdi-core (even if we all disagree), minimum
>> for
>>>>> me is to provide an openwebbeans-lite module implementing the cdi
>>>> extension
>>>>> making it supported, +1 to get a 4.0.0-alpha1 if it helps
>>>>> 
>>>>> 
>>>>> 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/rmannibuc

Re: [DISCUSS] Release OWB-4.0.0?

[Mark Struberg]

It's not the full story. 
We for example did never really implement the inconsistent BDA specification, 
global alternatives etc. 
Same here.

The CDI-4.0 situation is an inconsistent mess. Even Weld does not implement it 
fully it seems.
I really don't want to be blocked by a mess in the spec.

LieGrue,
strub



> Am 30.01.2023 um 19:02 schrieb Romain Manni-Bucau :
> 
> Le lun. 30 janv. 2023 à 17:10, Mark Struberg  <mailto:strub...@yahoo.de.invalid>> a
> écrit :
> 
>> I don't see any reason for any -alpha or whatever release. We did never
>> claim to be a certified implementation in the past, nor likely will we in
>> the future. We try to pass as much from the TCK as makes sense and
>> report/challenge TCK tests which disrespect/contradict the spec wording
>> and/or JavaDoc of the API. Most of those challenge tickets have been
>> bulk-closed and never really addressed for the past CDI versions. So my
>> will to go hunt for the carrot in front of my nose is not infinite
>> ("endenwollend" as we say here in Vienna).
>> 
> 
> We always went the spec side even if we add toggles to disable/enable
> things, but ultimately we cover the full API.
> Not providing any way to get it means we don't implement CDI anymore,
> nothing else. Can be fine but should be promoted and we should also see
> with TomEE what it means for them.
> Holding a release is not a goal but doing a final which looks like it
> covers the spec whereas it does not cover a third of it would be way more
> negative for the project IMHO so let's not be the bad guys and just expose
> explicitly our state with a pre-final whatever name fits for you.
> 
> 
>> 
>> If someone wants to address/implement the CDI-lite functionality (s)he is
>> perfectly welcome to do so. I doubt I will find the time to do it.
>> 
> 
> Once again, no issue to not do it now, should just be a goal of 4.0.0.
> 
> 
>> 
>> 
>> LieGrue,
>> strub
>> 
>>> Am 30.01.2023 um 14:48 schrieb Romain Manni-Bucau >> :
>>> 
>>> * +1 to drop jetty plugin for now
>>> * +-0 to shade cdi-api (nobody will consume it anyway)
>>> * -1 to release to not milestone without being spec compliant - including
>>> cdi-lite which is part of cdi-core (even if we all disagree), minimum for
>>> me is to provide an openwebbeans-lite module implementing the cdi
>> extension
>>> making it supported, +1 to get a 4.0.0-alpha1 if it helps
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>>> 
>>> 
>>> Le lun. 30 janv. 2023 à 14:43, Thomas Andraschko <
>>> andraschko.tho...@gmail.com> a écrit :
>>> 
>>>> all sounds good to me
>>>> 
>>>> Am Mo., 30. Jan. 2023 um 14:41 Uhr schrieb Mark Struberg
>>>> :
>>>> 
>>>>> hi folks!
>>>>> 
>>>>> We are up and running with passing most CDI-4.0 TCK tests.
>>>>> There are a few areas where we have excluded some tests:
>>>>> 
>>>>> * CDI-lite. I'll not gonna implement this in OWB as it is purely for
>>>>> Quarkus and I don't care. It should be straight forward to implement
>> the
>>>>> functionality as  OWB plugin if someone really needs it though.
>>>>> * Some challenged tests, some unspecified behaviour in some tests. E.g.
>>>>> they assume a specified order class annotations before method
>> annotations
>>>>> for Interceptors. But the spec *explicitly* says that for Interceptors
>>>> with
>>>>> the same @Priority the order is unspecified.
>>>>> * backward incompatible reversing the default bean-discovery-mode for
>>>>> empty beans.xmls. I'll not gonna implement this as it also did break
>> the
>>>>> JakartaEE rules alltogether.
>>>>> 
>>>>> 
>>>>> Things I want to change yet before the release:
>>>>> 
>>>>> * Decide about the jetty9 plugin. Tbh I'd keep it excluded until
>> someone
>>>>> wants to contribute fixes to it.
>>>>> * provide a shaded version of the CDI api jar without all the CDI-lite
>>>>> parts.
>>>>> 
>>>>> 
>>>>> Wdyt?
>>>>> 
>>>>> LieGrue,
>>>>> strub

[jira] [Resolved] (OWB-1417) Implement CDI-4.0 spec

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1417.

  Assignee: Mark Struberg
Resolution: Fixed

CDI-4.0 core is now fully working.

There are a few tests in the TCK which are challenged (see tck module) and we 
did not switch the default behaviour of empty beans.xml files as this change is 
actually forbidden by the overall JakartaEE rules.

> Implement CDI-4.0 spec
> --
>
> Key: OWB-1417
> URL: https://issues.apache.org/jira/browse/OWB-1417
> Project: OpenWebBeans
>  Issue Type: Epic
>Affects Versions: 4.0.0
>Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 4.0.0
>
>
> All tickets to implement CDI-4.0
>  
> We likely will just implement the core parts in the first go. The rest 
> (especially 'cdi-light') might be implemented in a portable way.



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

Re: [DISCUSS] Release OWB-4.0.0?

[Mark Struberg]

I don't see any reason for any -alpha or whatever release. We did never claim 
to be a certified implementation in the past, nor likely will we in the future. 
We try to pass as much from the TCK as makes sense and report/challenge TCK 
tests which disrespect/contradict the spec wording and/or JavaDoc of the API. 
Most of those challenge tickets have been bulk-closed and never really 
addressed for the past CDI versions. So my will to go hunt for the carrot in 
front of my nose is not infinite ("endenwollend" as we say here in Vienna).

If someone wants to address/implement the CDI-lite functionality (s)he is 
perfectly welcome to do so. I doubt I will find the time to do it.


LieGrue,
strub

> Am 30.01.2023 um 14:48 schrieb Romain Manni-Bucau :
> 
> * +1 to drop jetty plugin for now
> * +-0 to shade cdi-api (nobody will consume it anyway)
> * -1 to release to not milestone without being spec compliant - including
> cdi-lite which is part of cdi-core (even if we all disagree), minimum for
> me is to provide an openwebbeans-lite module implementing the cdi extension
> making it supported, +1 to get a 4.0.0-alpha1 if it helps
> 
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le lun. 30 janv. 2023 à 14:43, Thomas Andraschko <
> andraschko.tho...@gmail.com> a écrit :
> 
>> all sounds good to me
>> 
>> Am Mo., 30. Jan. 2023 um 14:41 Uhr schrieb Mark Struberg
>> :
>> 
>>> hi folks!
>>> 
>>> We are up and running with passing most CDI-4.0 TCK tests.
>>> There are a few areas where we have excluded some tests:
>>> 
>>> * CDI-lite. I'll not gonna implement this in OWB as it is purely for
>>> Quarkus and I don't care. It should be straight forward to implement the
>>> functionality as  OWB plugin if someone really needs it though.
>>> * Some challenged tests, some unspecified behaviour in some tests. E.g.
>>> they assume a specified order class annotations before method annotations
>>> for Interceptors. But the spec *explicitly* says that for Interceptors
>> with
>>> the same @Priority the order is unspecified.
>>> * backward incompatible reversing the default bean-discovery-mode for
>>> empty beans.xmls. I'll not gonna implement this as it also did break the
>>> JakartaEE rules alltogether.
>>> 
>>> 
>>> Things I want to change yet before the release:
>>> 
>>> * Decide about the jetty9 plugin. Tbh I'd keep it excluded until someone
>>> wants to contribute fixes to it.
>>> * provide a shaded version of the CDI api jar without all the CDI-lite
>>> parts.
>>> 
>>> 
>>> Wdyt?
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>> 

[DISCUSS] Release OWB-4.0.0?

[Mark Struberg]

hi folks!

We are up and running with passing most CDI-4.0 TCK tests.
There are a few areas where we have excluded some tests:

* CDI-lite. I'll not gonna implement this in OWB as it is purely for Quarkus 
and I don't care. It should be straight forward to implement the functionality 
as  OWB plugin if someone really needs it though.
* Some challenged tests, some unspecified behaviour in some tests. E.g. they 
assume a specified order class annotations before method annotations for 
Interceptors. But the spec *explicitly* says that for Interceptors with the 
same @Priority the order is unspecified.
* backward incompatible reversing the default bean-discovery-mode for empty 
beans.xmls. I'll not gonna implement this as it also did break the JakartaEE 
rules alltogether.


Things I want to change yet before the release:

* Decide about the jetty9 plugin. Tbh I'd keep it excluded until someone wants 
to contribute fixes to it.
* provide a shaded version of the CDI api jar without all the CDI-lite parts.


Wdyt?

LieGrue,
strub

OWB-4.0.0 status

[Mark Struberg]

Hi!

We now pass all TCK tests apart from 'cdi-lite' ones (actually build-time 
extension) and a few imo broken ones.

I've documented why I think those tests are invalid in te testng xml

https://github.com/apache/openwebbeans/blob/main/webbeans-tck/standalone-suite.xml#L63

Happy to get feedback and corrections when I was wrong.

txs and LieGrue,
strub

[jira] [Resolved] (OWB-1418) @Priority on @Alternative @Stereotype enables the bean

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1418.

Resolution: Fixed

> @Priority on @Alternative @Stereotype enables the bean
> --
>
> Key: OWB-1418
> URL: https://issues.apache.org/jira/browse/OWB-1418
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 4.0.0
>    Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 4.0.0
>
>
> An Alternative is enabled if @Alternative @Stereotype has a @Priority 
> annotation. This is defined in 
> [https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#priority_stereotype]
> {quote}
> Declaring stereotype with @Priority
> A stereotype may declare a @Priority annotation which functions as a means of 
> enabling and ordering affected beans.
> {quote}



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

[jira] [Created] (OWB-1418) @Priority on @Alternative @Stereotype enables the bean

[Mark Struberg (Jira)]

Mark Struberg created OWB-1418:
--

 Summary: @Priority on @Alternative @Stereotype enables the bean
 Key: OWB-1418
 URL: https://issues.apache.org/jira/browse/OWB-1418
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Core
Affects Versions: 4.0.0
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 4.0.0


An Alternative is enabled if @Alternative @Stereotype has a @Priority 
annotation. This is defined in 
[https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#priority_stereotype]

{quote}
Declaring stereotype with @Priority

A stereotype may declare a @Priority annotation which functions as a means of 
enabling and ordering affected beans.
{quote}



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

Re: some CDI-4.0 work

[Mark Struberg]

I've for now inlined the checkstyle config as there are problems with git svn 
clone the old build-tools repo.
Will look into this a bit later, but you should be good to go for now.

LieGrue,
strub

> Am 24.01.2023 um 15:24 schrieb Mark Struberg :
> 
> nope, on my todo list. give me a few minutes ;)
> 
> Btw, do we still want to keep webbeans-resources? This is support for 
> @Ressource, but I doubt that anyone is using this still?
> 
> LieGrue,
> strub
> 
> 
>> Am 24.01.2023 um 12:31 schrieb Jonathan Gallimore 
>> mailto:jonathan.gallim...@gmail.com>>:
>> 
>> Hi Mark
>> 
>> Did you push any build-tools changes anywhere? My current OWB build fails 
>> looking for 
>> org.apache.openwebbeans.build-tools:checkstyle-rules:4.0-SNAPSHOT. Just 
>> curious if I could check it out somewhere and build it to get further.
>> 
>> Thanks
>> 
>> Jon
>> 
>> On Sun, Jan 22, 2023 at 10:23 PM Mark Struberg  
>> wrote:
>>> Hi!
>>> 
>>> I've started with some work on implementing CDI-4.0.
>>> 
>>> Not sure how we do with out build-tools, so did not yet commit anything to 
>>> our repo.
>>> But a preview work can be seen here
>>> 
>>> struberg/openwebbeans at fb_jakarta
>>> github.com
>>> <https://github.com/struberg/openwebbeans/tree/fb_jakarta>struberg/openwebbeans
>>>  at fb_jakarta <https://github.com/struberg/openwebbeans/tree/fb_jakarta>
>>> github.com <http://github.com/> 
>>> <https://github.com/struberg/openwebbeans/tree/fb_jakarta>
>>> Trying to improve things in the next few days and then push it to our repo.
>>> 
>>> Question is also whether we use this moment and move from master to trunk 
>>> or main? What do you folks prefer?
>>> 
>>> LieGrue,
>>> strub

Re: some CDI-4.0 work

[Mark Struberg]

nope, on my todo list. give me a few minutes ;)

Btw, do we still want to keep webbeans-resources? This is support for 
@Ressource, but I doubt that anyone is using this still?

LieGrue,
strub


> Am 24.01.2023 um 12:31 schrieb Jonathan Gallimore 
> :
> 
> Hi Mark
> 
> Did you push any build-tools changes anywhere? My current OWB build fails 
> looking for 
> org.apache.openwebbeans.build-tools:checkstyle-rules:4.0-SNAPSHOT. Just 
> curious if I could check it out somewhere and build it to get further.
> 
> Thanks
> 
> Jon
> 
> On Sun, Jan 22, 2023 at 10:23 PM Mark Struberg  
> wrote:
>> Hi!
>> 
>> I've started with some work on implementing CDI-4.0.
>> 
>> Not sure how we do with out build-tools, so did not yet commit anything to 
>> our repo.
>> But a preview work can be seen here
>> 
>> struberg/openwebbeans at fb_jakarta
>> github.com
>>  
>> <https://github.com/struberg/openwebbeans/tree/fb_jakarta>struberg/openwebbeans
>>  at fb_jakarta <https://github.com/struberg/openwebbeans/tree/fb_jakarta>
>> github.com <https://github.com/struberg/openwebbeans/tree/fb_jakarta>
>> Trying to improve things in the next few days and then push it to our repo.
>> 
>> Question is also whether we use this moment and move from master to trunk or 
>> main? What do you folks prefer?
>> 
>> LieGrue,
>> strub

[DISCUSS] rename master branch to owb_2.0.x?

[Mark Struberg]

Hi!

I've created a new 'main' branch to contain our work on OWB-4.0.
Should we make this branch the new default branch in gitbox/gibhub and move the 
current master to be owb_2.0.x to indicate the maintenance status?

LieGrue,
strub

Re: some CDI-4.0 work

[Mark Struberg]

Things start to look really good!

I've created a new 'main' branch on our gitbox repo and pushed my changes to it.

We can later rename the master branch to owb_2.0.x. So we have a smooth change 
to main as upstream development branch also.

LieGrue,
strub



> Am 23.01.2023 um 10:50 schrieb Romain Manni-Bucau :
> 
> s/trunk/master/ ;)
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>> | 
> Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le lun. 23 janv. 2023 à 10:43, Mark Struberg  <mailto:strub...@yahoo.de.invalid>> a
> écrit :
> 
>> There is no trunk branch in owb anymore afaict. This one got renamed to
>> master in 2019 after migrating to git.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 23.01.2023 um 08:59 schrieb Romain Manni-Bucau >> :
>>> 
>>> Hi,
>>> 
>>> We released everything so maybe move to our trunk branch to not redo
>> tooling setup.
>>> Then we need to drop @New support and impl a runtime extension for light
>> support and release a 4.0.0?
>>> 
>>> Le dim. 22 janv. 2023 à 23:23, Mark Struberg 
>> a écrit :
>>>> Hi!
>>>> 
>>>> I've started with some work on implementing CDI-4.0.
>>>> 
>>>> Not sure how we do with out build-tools, so did not yet commit anything
>> to our repo.
>>>> But a preview work can be seen here
>>>> 
>>>> struberg/openwebbeans at fb_jakarta
>>>> github.com
>>>> <https://github.com/struberg/openwebbeans/tree/fb_jakarta>struberg/openwebbeans
>> at fb_jakarta <https://github.com/struberg/openwebbeans/tree/fb_jakarta>
>>>> github.com <http://github.com/> 
>>>> <https://github.com/struberg/openwebbeans/tree/fb_jakarta>
>>>> Trying to improve things in the next few days and then push it to our
>> repo.
>>>> 
>>>> Question is also whether we use this moment and move from master to
>> trunk or main? What do you folks prefer?
>>>> 
>>>> LieGrue,
>>>> strub

Re: some CDI-4.0 work

[Mark Struberg]

There is no trunk branch in owb anymore afaict. This one got renamed to master 
in 2019 after migrating to git.

LieGrue,
strub


> Am 23.01.2023 um 08:59 schrieb Romain Manni-Bucau :
> 
> Hi,
> 
> We released everything so maybe move to our trunk branch to not redo tooling 
> setup.
> Then we need to drop @New support and impl a runtime extension for light 
> support and release a 4.0.0?
> 
> Le dim. 22 janv. 2023 à 23:23, Mark Struberg  a 
> écrit :
>> Hi!
>> 
>> I've started with some work on implementing CDI-4.0.
>> 
>> Not sure how we do with out build-tools, so did not yet commit anything to 
>> our repo.
>> But a preview work can be seen here
>> 
>> struberg/openwebbeans at fb_jakarta
>> github.com
>>  
>> <https://github.com/struberg/openwebbeans/tree/fb_jakarta>struberg/openwebbeans
>>  at fb_jakarta <https://github.com/struberg/openwebbeans/tree/fb_jakarta>
>> github.com <https://github.com/struberg/openwebbeans/tree/fb_jakarta>
>> Trying to improve things in the next few days and then push it to our repo.
>> 
>> Question is also whether we use this moment and move from master to trunk or 
>> main? What do you folks prefer?
>> 
>> LieGrue,
>> strub

some CDI-4.0 work

[Mark Struberg]

Hi!

I've started with some work on implementing CDI-4.0.

Not sure how we do with out build-tools, so did not yet commit anything to our 
repo.
But a preview work can be seen here
https://github.com/struberg/openwebbeans/tree/fb_jakarta
struberg/openwebbeans at fb_jakarta
github.com

Trying to improve things in the next few days and then push it to our repo.

Question is also whether we use this moment and move from master to trunk or 
main? What do you folks prefer?

LieGrue,
strub

[jira] [Created] (OWB-1417) Implement CDI-4.0 spec

[Mark Struberg (Jira)]

Mark Struberg created OWB-1417:
--

 Summary: Implement CDI-4.0 spec
 Key: OWB-1417
 URL: https://issues.apache.org/jira/browse/OWB-1417
 Project: OpenWebBeans
  Issue Type: Epic
Affects Versions: 4.0.0
Reporter: Mark Struberg
 Fix For: 4.0.0


All tickets to implement CDI-4.0

 

We likely will just implement the core parts in the first go. The rest 
(especially 'cdi-light') might be implemented in a portable way.



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

Re: [VOTE][RESULT] Release Apache Meecrowave-1.2.15

[Mark Struberg]

Hi!

Sorry for taking so long!

The VOTE is closed with 4 +1:
Reinhard, Romain, Jean-Babtiste, Mark

I'll continue with the release steps.

txs and LieGrue,
strub

> Am 29.12.2022 um 22:57 schrieb Mark Struberg :
> 
> hi!
> 
> I'd like to call a VOTE on releasing Apache Meecrowave 1.2.15
> 
> We've mostly done version upgrades. Including to the latest CXF version.
> 
> The following tickets got resoled:
> Task
> 
> [MEECROWAVE-321 <https://issues.apache.org/jira/browse/MEECROWAVE-321>] - 
> Upgrade to Johnzon 1.2.19
> [MEECROWAVE-322 <https://issues.apache.org/jira/browse/MEECROWAVE-322>] - 
> Upgrade to OpenWebBeans 2.0.27
> [MEECROWAVE-324 <https://issues.apache.org/jira/browse/MEECROWAVE-324>] - 
> upgrade apache parent to 29
> [MEECROWAVE-325 <https://issues.apache.org/jira/browse/MEECROWAVE-325>] - 
> Update to CXF-3.5.5
> [MEECROWAVE-326 <https://issues.apache.org/jira/browse/MEECROWAVE-326>] - 
> Upgrade to log4j2-2.19.0
> 
> The staging repo is at 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1082/
> 
> The source release can be found at
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1082/org/apache/meecrowave/meecrowave/1.2.15/
> sha512 is 
> 95299bee270bcdc931c9ad10da84e1bb0778b544845a15c908cd8f4fac9afa2ccb9f9827c82e0c03c0a8d355b258f702accd07423a4a743c43ff7f925640523d
> 
> My KEY can be found in our repo.
> 
> 
> Please VOTE:
> 
> [+1] let's ship it!
> [+0] meh, don't care
> [+1] yikes no, there is a ${showstopper}
> 
> The VOTE is open for 72h.
> 
> Here is my own +1
> 
> txs and LieGrue,
> strub
> 

[VOTE] Release Apache Meecrowave-1.2.15

[Mark Struberg]

hi!

I'd like to call a VOTE on releasing Apache Meecrowave 1.2.15

We've mostly done version upgrades. Including to the latest CXF version.

The following tickets got resoled:
Task

[MEECROWAVE-321 ] - 
Upgrade to Johnzon 1.2.19
[MEECROWAVE-322 ] - 
Upgrade to OpenWebBeans 2.0.27
[MEECROWAVE-324 ] - 
upgrade apache parent to 29
[MEECROWAVE-325 ] - 
Update to CXF-3.5.5
[MEECROWAVE-326 ] - 
Upgrade to log4j2-2.19.0

The staging repo is at 
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1082/

The source release can be found at
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1082/org/apache/meecrowave/meecrowave/1.2.15/
sha512 is 
95299bee270bcdc931c9ad10da84e1bb0778b544845a15c908cd8f4fac9afa2ccb9f9827c82e0c03c0a8d355b258f702accd07423a4a743c43ff7f925640523d

My KEY can be found in our repo.


Please VOTE:

[+1] let's ship it!
[+0] meh, don't care
[+1] yikes no, there is a ${showstopper}

The VOTE is open for 72h.

Here is my own +1

txs and LieGrue,
strub

[jira] [Updated] (MEECROWAVE-289) Add Jakarta version of specs-api bundle

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MEECROWAVE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated MEECROWAVE-289:
-
Fix Version/s: 1.2.16
   (was: 1.2.15)

> Add Jakarta version of specs-api bundle
> ---
>
> Key: MEECROWAVE-289
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-289
> Project: Meecrowave
>  Issue Type: Improvement
>Affects Versions: 1.2.11
>Reporter: Benjamin Marwell
>Priority: Major
> Fix For: 1.2.16
>
>
> Same what Romain did for -core.
> Added a shaded archive with relocation from javax to jakarta.



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

[jira] [Updated] (MEECROWAVE-262) Ensure disabling tomcat scanning does not require any other customization

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MEECROWAVE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated MEECROWAVE-262:
-
Fix Version/s: 1.2.16
   (was: 1.2.15)

> Ensure disabling tomcat scanning does not require any other customization
> -
>
> Key: MEECROWAVE-262
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-262
> Project: Meecrowave
>  Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.16
>
>
> Currently it fails with:
>  
> {code:java}
> java.lang.IllegalStateException: Error starting 
> childjava.lang.IllegalStateException: Error starting child
>  at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:720)
>  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) 
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:706) at 
> org.apache.meecrowave.Meecrowave.deployWebapp(Meecrowave.java:409) at 
> org.apache.meecrowave.Meecrowave.deployClasspath(Meecrowave.java:190) at 
> org.apache.meecrowave.Meecrowave.deployClasspath(Meecrowave.java:209) at 
> org.apache.meecrowave.Meecrowave.bake(Meecrowave.java:431) at 
> org.apache.meecrowave.Meecrowave.bake(Meecrowave.java:426) at 
> org.apache.meecrowave.MeecrowaveTest.noTomcatScanning(MeecrowaveTest.java:64) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498) at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at 
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
>  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
>  at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
>  at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at 
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at 
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at 
> org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at 
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at 
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at 
> org.junit.runners.ParentRunner.run(ParentRunner.java:413) at 
> org.junit.runner.JUnitCore.run(JUnitCore.java:137) at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>  at 
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
>  at 
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
>  at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)Caused by: 
> org.apache.catalina.LifecycleException: Failed to start component 
> [StandardEngine[Tomcat].StandardHost[localhost].[]] at 
> org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
>  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717)
>  ... 33 moreCaused by: java.lang.NullPointerException at 
> org.apache.meecrowave.tomcat.OWBJarScanner.scan(OWBJarScanner.java:52) at 
> org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(ContextConfig.java:2137)
>  at 
> org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1288) 
> at 
> org.apache.meecrowave.tomcat.MeecrowaveContextConfig.webConfig(MeecrowaveContextConfig.java:96)
>  at 
> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:985)
>  at 
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:303)
>  at 
> org.apache.meecrowave.tomcat.MeecrowaveContextConfig.lifecycleEvent(MeecrowaveContextConfig.java:170)
>  at 
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java

[jira] [Resolved] (MEECROWAVE-324) upgrade apache parent to 29

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MEECROWAVE-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved MEECROWAVE-324.
--
Resolution: Fixed

> upgrade apache parent to 29
> ---
>
> Key: MEECROWAVE-324
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-324
> Project: Meecrowave
>  Issue Type: Task
>Affects Versions: 1.2.14
>Reporter: Mark Struberg
>Priority: Major
> Fix For: 1.2.15
>
>
> upgrade apache parent to 29



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

[jira] [Resolved] (MEECROWAVE-326) Upgrade to log4j2-2.19.0

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MEECROWAVE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved MEECROWAVE-326.
--
  Assignee: Mark Struberg
Resolution: Fixed

> Upgrade to log4j2-2.19.0
> 
>
> Key: MEECROWAVE-326
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-326
> Project: Meecrowave
>  Issue Type: Task
>Affects Versions: 1.2.14
>Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.2.15
>
>
> Upgrade to log4j2-2.19.0



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

[jira] [Resolved] (MEECROWAVE-325) Update to CXF-3.5.5

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MEECROWAVE-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved MEECROWAVE-325.
--
Resolution: Fixed

> Update to CXF-3.5.5
> ---
>
> Key: MEECROWAVE-325
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-325
> Project: Meecrowave
>  Issue Type: Task
>Affects Versions: 1.2.14
>Reporter: Mark Struberg
>Priority: Major
> Fix For: 1.2.15
>
>
> Update to CXF-3.5.5 due to a CVE



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

[jira] [Created] (MEECROWAVE-326) Upgrade to log4j2-2.19.0

[Mark Struberg (Jira)]

Mark Struberg created MEECROWAVE-326:


 Summary: Upgrade to log4j2-2.19.0
 Key: MEECROWAVE-326
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-326
 Project: Meecrowave
  Issue Type: Task
Affects Versions: 1.2.14
Reporter: Mark Struberg
 Fix For: 1.2.15


Upgrade to log4j2-2.19.0



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

[jira] [Created] (MEECROWAVE-325) Update to CXF-3.5.5

[Mark Struberg (Jira)]

Mark Struberg created MEECROWAVE-325:


 Summary: Update to CXF-3.5.5
 Key: MEECROWAVE-325
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-325
 Project: Meecrowave
  Issue Type: Task
Affects Versions: 1.2.14
Reporter: Mark Struberg
 Fix For: 1.2.15


Update to CXF-3.5.5 due to a CVE



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

[jira] [Created] (MEECROWAVE-324) upgrade apache parent to 29

[Mark Struberg (Jira)]

Mark Struberg created MEECROWAVE-324:


 Summary: upgrade apache parent to 29
 Key: MEECROWAVE-324
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-324
 Project: Meecrowave
  Issue Type: Task
Affects Versions: 1.2.14
Reporter: Mark Struberg
 Fix For: 1.2.15


upgrade apache parent to 29



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

Re: [DISCUSS] release a new Meecrowave version tomorrow?

[Mark Struberg]

+1 it's easy to upgrade CXF but I'd like to get the CVE solved officially.

LieGrue,
strub

> Am 20.12.2022 um 23:35 schrieb Jean-Baptiste Onofré :
> 
> I guess 3.5.5 which includes some CVE fixes.
> 
> Regards
> JB
> 
> Le mar. 20 déc. 2022 à 21:20, Romain Manni-Bucau  a
> écrit :
> 
>> Hi Mark,
>> 
>> Do you mean 4.0.0 ir 3.5.5?
>> Seems not done on master but we need to check deps  chnages before since we
>> must exclude most of them in general with cxf heterogeneous tree.
>> 
>> Romain
>> 
>> 
>> 
>> Le mar. 20 déc. 2022 à 21:10, Mark Struberg  a
>> écrit :
>> 
>>> I'd like to roll the release for a new Meecrowave version tomorrow with
>> an
>>> updated CXF.
>>> 
>>> You've got about 12h to stop me ;)
>>> 
>>> txs and LieGrue,
>>> strub
>>> 
>>> 
>> 

[jira] [Commented] (OWB-1416) Possible misintepretation of spec regarding Unproxyable bean types

[Mark Struberg (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17650004#comment-17650004
 ] 

Mark Struberg commented on OWB-1416:


I agree with Romain that a) the spec is not clear and b) our approach is much 
more safe.
Consider some code accessing the Contextual Reference via Instance or 
BeanManager.getContextualReference() etc. In that case there is not even an 
injection point. Does this mean Weld will serve broken CDI beans out to user 
code? Sounds really wrong to me.

> Possible misintepretation of spec regarding Unproxyable bean types
> --
>
> Key: OWB-1416
> URL: https://issues.apache.org/jira/browse/OWB-1416
> Project: OpenWebBeans
>  Issue Type: Bug
>Reporter: Alexander Larsen
>Priority: Major
>
> OWB seems to throw an exception for all unproxyable normal scoped beans. I 
> think that this might be incorrect.
> The 
> [specification|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#unproxyable] 
> says the "A bean type must be proxyable if an injection point resolves to a 
> bean", not that all the types of the bean must be proxyable. In other words, 
> as long as the bean is a legal bean, and all injection point resolving to 
> this bean is a proxyable type - no exception should be thrown.
> In the part about [contextual 
> references|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#contextual_reference],
>  there is further indications that unproxyable types should be allowed in the 
> set of types for the bean. It's only when you try to get a reference(injected 
> or by bean manager) to an unproxyable type, and the bean must be proxied 
> (normal scoped, intercepted or decorated) an exception should thrown.
> Also, the [Weld user guide suggests introducing an interface as a solution to 
> having an unproxyable 
> bean|https://docs.jboss.org/weld/reference/latest/en-US/html_single/#_client_proxies].
> The current OWB implementation makes a pattern of having an interface and 
> (one or more) implementation class with final fields/methods somewhat 
> difficult :)



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

[DISCUSS] release a new Meecrowave version tomorrow?

[Mark Struberg]

I'd like to roll the release for a new Meecrowave version tomorrow with an 
updated CXF.

You've got about 12h to stop me ;)

txs and LieGrue,
strub

Re: [DISCUSS] CDI-4.0 core

[Mark Struberg]

> 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.  

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 :
> 
> 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 :
>>> 
>>> 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
>>> proper

Re: [DISCUSS] CDI-4.0 core

[Mark Struberg]

s.protection.outlook.com/?url=https%3A%2F%2Fwww.packtpub.com%2Fapplication-development%2Fjava-ee-8-high-performancedata=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=FS%2F%2F76e3K11L6i5o%2FKe0w1y4lDXzmStTql6kv1hOb4A%3Dreserved=0>>
> 
> 
> Le mer. 12 oct. 2022 à 17:48, Arne Limburg  <mailto:arne.limb...@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.limb...@openknowledge.de 
>> <mailto:arne.limb...@openknowledge.de><mailto:arne.limb...@openknowledge.de 
>> <mailto:arne.limb...@openknowledge.de>>
>> https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openknowledge.de%2Fdata=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=6MSnRSFohYLdkn8mLT7v9C%2B0uEk62YK0L7uvWmjAHZs%3Dreserved=0<<https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openknowledge.de%2Fdata=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=6MSnRSFohYLdkn8mLT7v9C%2B0uEk62YK0L7uvWmjAHZs%3Dreserved=0%3c>
>>  
>> <https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openknowledge.de%2Fdata=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=6MSnRSFohYLdkn8mLT7v9C%2B0uEk62YK0L7uvWmjAHZs%3Dreserved=0%3C%3Chttps://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openknowledge.de%2Fdata=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=6MSnRSFohYLdkn8mLT7v9C%2B0uEk62YK0L7uvWmjAHZs%3Dreserved=0%3c%3E>
>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fdata=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=y7QuEZpzyr9lvmxko%2Fx4V6hZeDGpaa8Bx%2Bzgd3pgIcE%3Dreserved=0
>>  
>> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fdata=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=y7QuEZpzyr9lvmxko%2Fx4V6hZeDGpaa8Bx%2Bzgd3pgIcE%3Dreserved=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%2Fdata=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=3GUY2OqKe9DsuAtEhfHx5J8ztt%2BaHze2GWT%2Fqkkftvw%3Dreserved=0
>>  
>> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fevent%2Fdata=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848558068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=3GUY2OqKe9DsuAtEhfHx5J8ztt%2BaHze2GWT%2Fqkkftvw%3Dreserved=

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 
<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 <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  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
>> 
>> 

[jira] [Resolved] (OWB-1415) gradle module fails to build because bintray doesn't exist anymore

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1415.

Resolution: Fixed

> gradle module fails to build because bintray doesn't exist anymore
> --
>
> Key: OWB-1415
> URL: https://issues.apache.org/jira/browse/OWB-1415
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 2.0.27
>Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.28
>
>
> webbeans-gradle module relies on jcenter.bintray.com. But this repo does not 
> exist anymore. We should switch to the official gradle m2 repo instead.



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

[jira] [Created] (OWB-1415) gradle module fails to build because bintray doesn't exist anymore

[Mark Struberg (Jira)]

Mark Struberg created OWB-1415:
--

 Summary: gradle module fails to build because bintray doesn't 
exist anymore
 Key: OWB-1415
 URL: https://issues.apache.org/jira/browse/OWB-1415
 Project: OpenWebBeans
  Issue Type: Bug
Affects Versions: 2.0.27
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 2.0.28


webbeans-gradle module relies on jcenter.bintray.com. But this repo does not 
exist anymore. We should switch to the official gradle m2 repo instead.



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

[jira] [Resolved] (OWB-1414) build broken on Java8

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved OWB-1414.

Resolution: Fixed

> build broken on Java8
> -
>
> Key: OWB-1414
> URL: https://issues.apache.org/jira/browse/OWB-1414
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: TCK
>Affects Versions: 2.0.27
>    Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.28
>
>
> Right now our build is broken on Java8. Seems we killed it with a new testng 
> version in the jakarta TCK module. The new testng version requires Java16.



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

[jira] [Created] (OWB-1414) build broken on Java8

[Mark Struberg (Jira)]

Mark Struberg created OWB-1414:
--

 Summary: build broken on Java8
 Key: OWB-1414
 URL: https://issues.apache.org/jira/browse/OWB-1414
 Project: OpenWebBeans
  Issue Type: Bug
  Components: TCK
Affects Versions: 2.0.27
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 2.0.28


Right now our build is broken on Java8. Seems we killed it with a new testng 
version in the jakarta TCK module. The new testng version requires Java16.



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

some build problems

[Mark Struberg]

hi folks!

Seems we lost the ability to build with Java8.
This is due to a recent upgrade of testng which requires Java16. Will switch 
back to the old version.

I also figured that we have some weird download dependencies. Likely caused by 
some dependency activating a 3rd party repo?

Downloading from jcenter: 
https://jcenter.bintray.com/org/codehaus/groovy/groovy-json/3.0.10/groovy-json-3.0.10.jar
Downloading from jcenter: 
https://jcenter.bintray.com/org/codehaus/groovy/groovy-jsr223/3.0.10/groovy-jsr223-3.0.10.jar
Downloading from jcenter: 
https://jcenter.bintray.com/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
Downloading from jcenter: 
https://jcenter.bintray.com/org/junit/platform/junit-platform-launcher/1.8.2/junit-platform-launcher-1.8.2.jar
Downloading from jcenter: 
https://jcenter.bintray.com/com/github/javaparser/javaparser-core/3.24.0/javaparser-core-3.24.0.jar
Downloaded from jcenter: 
https://jcenter.bintray.com/org/codehaus/groovy/groovy-json/3.0.10/groovy-json-3.0.10.jar
 (133 kB at 148 kB/s)
Downloading from jcenter: 
https://jcenter.bintray.com/org/junit/platform/junit-platform-engine/1.8.2/junit-platform-engine-1.8.2.jar
Downloaded from jcenter: 
https://jcenter.bintray.com/org/junit/platform/junit-platform-launcher/1.8.2/junit-platform-launcher-1.8.2.jar
 (159 kB at 177 kB/s)
Downloading from jcenter: 
https://jcenter.bintray.com/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
Downloaded from jcenter: 
https://jcenter.bintray.com/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
 (194 kB at 205 kB/s)
Downloading from jcenter: 
https://jcenter.bintray.com/org/junit/jupiter/junit-jupiter-engine/5.8.2/junit-jupiter-engine-5.8.2.jar
Downloaded from jcenter: 
https://jcenter.bintray.com/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
 (100 kB at 73 kB/s)
Downloading from jcenter: 
https://jcenter.bintray.com/org/codehaus/groovy/groovy-testng/3.0.10/groovy-testng-3.0.10.jar
Downloaded from jcenter: 
https://jcenter.bintray.com/org/junit/platform/junit-platform-engine/1.8.2/junit-platform-engine-1.8.2.jar
 (186 kB at 120 kB/s)
Downloading from jcenter: 
https://jcenter.bintray.com/org/testng/testng/7.5/testng-7.5.jar
Downloaded from jcenter: 
https://jcenter.bintray.com/org/junit/jupiter/junit-jupiter-engine/5.8.2/junit-jupiter-engine-5.8.2.jar
 (230 kB at 144 kB/s)
Downloading from jcenter: 
https://jcenter.bintray.com/org/webjars/jquery/3.5.1/jquery-3.5.1.jar
Downloaded from jcenter: 
https://jcenter.bintray.com/org/codehaus/groovy/groovy-jsr223/3.0.10/groovy-jsr223-3.0.10.jar
 (21 kB at 13 kB/s)
Downloaded from jcenter: 
https://jcenter.bintray.com/org/codehaus/groovy/groovy-testng/3.0.10/groovy-testng-3.0.10.jar
 (9.8 kB at 4.2 kB/s)
Downloaded from jcenter: 
https://jcenter.bintray.com/org/webjars/jquery/3.5.1/jquery-3.5.1.jar (313 kB 
at 114 kB/s)

Trying to check where this comes from.

LieGrue,
strub

Re: [DISCUSS] CDI-4.0 core

[Mark Struberg]

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

LieGrue,
strub


> Am 03.06.2022 um 08:31 schrieb Romain Manni-Bucau :
> 
> Le jeu. 2 juin 2022 à 22:44, Mark Struberg  a
> écrit :
> 
>> would imo introduce too many layers which might be hard to maintain in the
>> long run. With the current plugin structure you can already run without
>> even class scanning and dynamic bytecode tinkering if one wants.
>> So don't think it's worth to add another layer of abstraction in the
>> middle.
>> 
> 
> Thing is that currently you dont get most benefit, just tech extension
> points to make the run work:
> 
> - you leverage jakarta/javax and their mess+breaking
> changes+inconsistencies from v4
> - you get more than needed in api
> - you have constraints on beans you dont need
> 
> Your proposal is just the same but half baked since we are compatible or we
> are not, this is why I think we should propose something really stable or
> maybe just stick to impl the spec (modularly or not is a detail but tck
> require both parts of the spec so passing only one is pointless for users
> IMHO).
> 
> 
> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 02.06.2022 um 21:32 schrieb Romain Manni-Bucau >> :
>>> 
>>> Hi,
>>> 
>>> Some times ago I proposed to extract a cdi-like-light owb bundle which
>>> would be a minimal IoC without the cdi 2.0 boilerplate and probably
>> unsafe
>>> free to be "all env friendly". This is very close to owb-se except a few
>>> spi, defaults and jakarta dep.
>>> 
>>> Making it cdi-se/ee as an impl sounds more valuable today for the project
>>> IMHO - because we tend to go lightweight cause of the cloud move and
>>> projects stacking too much are not that adopted - and is still compatible
>>> with your idea so can be worth starting owb 3 from these basis with a
>> light
>>> owb IoC api/spi (TBD if we inherit from jakarta or not) and then back
>>> owb-impl by this "owb-core" and finally impl your idea on this new api?
>>> 
>>> 
>>> 
>>> Le jeu. 2 juin 2022 à 21:04, Mark Struberg > <mailto:strub...@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

[Mark Struberg]

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 :
> 
> 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  <mailto:strub...@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

[DISCUSS] CDI-4.0 core

[Mark Struberg]

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 


I'd like to do the same, but for now just implement the clasic Jakarta EE part 
without the 'CDI lite' overhead. 
If we later find some time we can still implement CDI-lite as either an OWB 
plugin or even as a standard portable extension. This can be done here or as 
part of TomEE for example. 

I think we might be rather quick to get things going that way.

Wdyt about that idea?

LieGrue,
strub

Re: Tomcat 7.x EOL

[Mark Struberg]

+1 let's get rid of it!

LieGrue,
strub

> Am 24.05.2022 um 15:48 schrieb Jean-Louis MONTEIRO :
> 
> I don't think they do much with it either to be honest.
> If we keep it, I would upgrade Tomcat in OWB.
> If we yank the integration because it's not used anyways, I'm ok with it.
> 
> Le mar. 24 mai 2022 à 14:10, Romain Manni-Bucau  a
> écrit :
> 
>> Hi,
>> 
>> Since Tomcat enhanced InstanceManager I guess we can upgrade and decrease a
>> lot the hacks/reflection we used by the past.
>> Only open point on my side is: is it worth having a tomcat integration? I
>> know very few users of that but generally speaking the web integration is
>> really sufficient so do we want to keep it or let tomcat handle it -
>> https://github.com/apache/tomcat/tree/main/modules/owb?
>> 
>> 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 mar. 24 mai 2022 à 13:09, Jean-Louis Monteiro >> 
>> a écrit :
>> 
>>> Hi,
>>> 
>>> I was doing some dependency updates on OpenWebBeans and wanted to do a
>>> release and I noticed we still have Tomcat 7.x in OWB.
>>> 
>>> Shouldn't we try to move to the latest javax compatible version (aka
>> 9.x)?
>>> Tomcat 7.x is EOL and has many CVEs.
>>> 
>>> What do you think?
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>> 
>> 
> 
> 
> -- 
> Jean-Louis

Re: [VOTE] Apache OpenWebBeans 2.0.27

[Mark Struberg]

+1

txs and LieGrue,
strub


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

Re: [VOTE][RESULT] Release Apache Meecrowave 1.2.14

[Mark Struberg]

hi!

The VOTE did pass with the following:

+1: Romain, Jean-Baptiste, Reini, Mark

No -1 nor 0 got casted.

I'll continue with the release steps.

txs and LieGrue,
strub


> Am 30.04.2022 um 15:21 schrieb Mark Struberg :
> 
> Hi lords and ladies!
> 
> 
> I'd like to call a VOTE for releasing Apache Meecrowave 1.2.14
> 
> Please note that this VOTE is depending on Johnzon-1.2.18 which is currently 
> under release as well.
> Information can be found here: 
> https://lists.apache.org/thread/6m9zc1p60f8wod5ycj1c290835n363sh 
> <https://lists.apache.org/thread/6m9zc1p60f8wod5ycj1c290835n363sh>
> 
> 
> The following tickets got fixed:
> Improvement
> 
> [MEECROWAVE-307 <https://issues.apache.org/jira/browse/MEECROWAVE-307>] - 
> Upgrade to cxf 3.5.0
> [MEECROWAVE-308 <https://issues.apache.org/jira/browse/MEECROWAVE-308>] - 
> Upgrade to log4j 2.17.0
> [MEECROWAVE-309 <https://issues.apache.org/jira/browse/MEECROWAVE-309>] - 
> Upgrade to Johnzon 1.2.18
> [MEECROWAVE-310 <https://issues.apache.org/jira/browse/MEECROWAVE-310>] - 
> Upgrade to Tomcat 9.0.58
> [MEECROWAVE-311 <https://issues.apache.org/jira/browse/MEECROWAVE-311>] - 
> Upgrade to Log4j 2.17.1
> Task
> 
> [MEECROWAVE-312 <https://issues.apache.org/jira/browse/MEECROWAVE-312>] - 
> Upgrade to Tomcat 9.0.59
> [MEECROWAVE-313 <https://issues.apache.org/jira/browse/MEECROWAVE-313>] - 
> Upgrade to OpenWebBeans 2.0.26
> [MEECROWAVE-314 <https://issues.apache.org/jira/browse/MEECROWAVE-314>] - 
> Upgrade to CXF 3.5.1
> [MEECROWAVE-315 <https://issues.apache.org/jira/browse/MEECROWAVE-315>] - 
> Upgrade to Johnzon 1.2.16
> [MEECROWAVE-316 <https://issues.apache.org/jira/browse/MEECROWAVE-316>] - 
> Upgrade to tomcat 9.0.60
> [MEECROWAVE-318 <https://issues.apache.org/jira/browse/MEECROWAVE-318>] - CXF 
> 3.5.2
> [MEECROWAVE-319 <https://issues.apache.org/jira/browse/MEECROWAVE-319>] - 
> Log4j 2.17.2
> [MEECROWAVE-320 <https://issues.apache.org/jira/browse/MEECROWAVE-320>] - 
> Upgrade to johnzon 1.2.17
> 
> 
> The staging repo is:
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1080/
>  
> <https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1080/>
> 
> The source zip can be found at
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1080/org/apache/meecrowave/meecrowave/1.2.14/
>  
> <https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1080/org/apache/meecrowave/meecrowave/1.2.14/>
> sha1 is 5c53e44ba31213a46e6e05083ffb8f90e665be45
> 
> Please VOTE:
> 
> [+1] let's ship it!
> [+0] meh, don't care
> [-1] nope, there is a ${showstopper}
> 
> The VOTE is open for 72h
> 
> LieGrue,
> strub
> 
> 

Re: [VOTE] Release Apache Meecrowave 1.2.14

[Mark Struberg]

+1

LieGrue,
strub


> Am 30.04.2022 um 15:21 schrieb Mark Struberg :
> 
> Hi lords and ladies!
> 
> 
> I'd like to call a VOTE for releasing Apache Meecrowave 1.2.14
> 
> Please note that this VOTE is depending on Johnzon-1.2.18 which is currently 
> under release as well.
> Information can be found here: 
> https://lists.apache.org/thread/6m9zc1p60f8wod5ycj1c290835n363sh 
> <https://lists.apache.org/thread/6m9zc1p60f8wod5ycj1c290835n363sh>
> 
> 
> The following tickets got fixed:
> Improvement
> 
> [MEECROWAVE-307 <https://issues.apache.org/jira/browse/MEECROWAVE-307>] - 
> Upgrade to cxf 3.5.0
> [MEECROWAVE-308 <https://issues.apache.org/jira/browse/MEECROWAVE-308>] - 
> Upgrade to log4j 2.17.0
> [MEECROWAVE-309 <https://issues.apache.org/jira/browse/MEECROWAVE-309>] - 
> Upgrade to Johnzon 1.2.18
> [MEECROWAVE-310 <https://issues.apache.org/jira/browse/MEECROWAVE-310>] - 
> Upgrade to Tomcat 9.0.58
> [MEECROWAVE-311 <https://issues.apache.org/jira/browse/MEECROWAVE-311>] - 
> Upgrade to Log4j 2.17.1
> Task
> 
> [MEECROWAVE-312 <https://issues.apache.org/jira/browse/MEECROWAVE-312>] - 
> Upgrade to Tomcat 9.0.59
> [MEECROWAVE-313 <https://issues.apache.org/jira/browse/MEECROWAVE-313>] - 
> Upgrade to OpenWebBeans 2.0.26
> [MEECROWAVE-314 <https://issues.apache.org/jira/browse/MEECROWAVE-314>] - 
> Upgrade to CXF 3.5.1
> [MEECROWAVE-315 <https://issues.apache.org/jira/browse/MEECROWAVE-315>] - 
> Upgrade to Johnzon 1.2.16
> [MEECROWAVE-316 <https://issues.apache.org/jira/browse/MEECROWAVE-316>] - 
> Upgrade to tomcat 9.0.60
> [MEECROWAVE-318 <https://issues.apache.org/jira/browse/MEECROWAVE-318>] - CXF 
> 3.5.2
> [MEECROWAVE-319 <https://issues.apache.org/jira/browse/MEECROWAVE-319>] - 
> Log4j 2.17.2
> [MEECROWAVE-320 <https://issues.apache.org/jira/browse/MEECROWAVE-320>] - 
> Upgrade to johnzon 1.2.17
> 
> 
> The staging repo is:
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1080/
>  
> <https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1080/>
> 
> The source zip can be found at
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1080/org/apache/meecrowave/meecrowave/1.2.14/
>  
> <https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1080/org/apache/meecrowave/meecrowave/1.2.14/>
> sha1 is 5c53e44ba31213a46e6e05083ffb8f90e665be45
> 
> Please VOTE:
> 
> [+1] let's ship it!
> [+0] meh, don't care
> [-1] nope, there is a ${showstopper}
> 
> The VOTE is open for 72h
> 
> LieGrue,
> strub
> 
> 

[VOTE] Release Apache Meecrowave 1.2.14

[Mark Struberg]

Hi lords and ladies!


I'd like to call a VOTE for releasing Apache Meecrowave 1.2.14

Please note that this VOTE is depending on Johnzon-1.2.18 which is currently 
under release as well.
Information can be found here: 
https://lists.apache.org/thread/6m9zc1p60f8wod5ycj1c290835n363sh 



The following tickets got fixed:
Improvement

[MEECROWAVE-307 ] - 
Upgrade to cxf 3.5.0
[MEECROWAVE-308 ] - 
Upgrade to log4j 2.17.0
[MEECROWAVE-309 ] - 
Upgrade to Johnzon 1.2.18
[MEECROWAVE-310 ] - 
Upgrade to Tomcat 9.0.58
[MEECROWAVE-311 ] - 
Upgrade to Log4j 2.17.1
Task

[MEECROWAVE-312 ] - 
Upgrade to Tomcat 9.0.59
[MEECROWAVE-313 ] - 
Upgrade to OpenWebBeans 2.0.26
[MEECROWAVE-314 ] - 
Upgrade to CXF 3.5.1
[MEECROWAVE-315 ] - 
Upgrade to Johnzon 1.2.16
[MEECROWAVE-316 ] - 
Upgrade to tomcat 9.0.60
[MEECROWAVE-318 ] - CXF 
3.5.2
[MEECROWAVE-319 ] - Log4j 
2.17.2
[MEECROWAVE-320 ] - 
Upgrade to johnzon 1.2.17


The staging repo is:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1080/ 


The source zip can be found at
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1080/org/apache/meecrowave/meecrowave/1.2.14/
 

sha1 is 5c53e44ba31213a46e6e05083ffb8f90e665be45

Please VOTE:

[+1] let's ship it!
[+0] meh, don't care
[-1] nope, there is a ${showstopper}

The VOTE is open for 72h

LieGrue,
strub

[jira] [Updated] (MEECROWAVE-289) Add Jakarta version of specs-api bundle

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MEECROWAVE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated MEECROWAVE-289:
-
Fix Version/s: 1.2.15
   (was: 1.2.14)

> Add Jakarta version of specs-api bundle
> ---
>
> Key: MEECROWAVE-289
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-289
> Project: Meecrowave
>  Issue Type: Improvement
>Affects Versions: 1.2.11
>Reporter: Benjamin Marwell
>Priority: Major
> Fix For: 1.2.15
>
>
> Same what Romain did for -core.
> Added a shaded archive with relocation from javax to jakarta.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Updated] (MEECROWAVE-262) Ensure disabling tomcat scanning does not require any other customization

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MEECROWAVE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated MEECROWAVE-262:
-
Fix Version/s: 1.2.15
   (was: 1.2.14)

> Ensure disabling tomcat scanning does not require any other customization
> -
>
> Key: MEECROWAVE-262
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-262
> Project: Meecrowave
>  Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.15
>
>
> Currently it fails with:
>  
> {code:java}
> java.lang.IllegalStateException: Error starting 
> childjava.lang.IllegalStateException: Error starting child
>  at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:720)
>  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) 
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:706) at 
> org.apache.meecrowave.Meecrowave.deployWebapp(Meecrowave.java:409) at 
> org.apache.meecrowave.Meecrowave.deployClasspath(Meecrowave.java:190) at 
> org.apache.meecrowave.Meecrowave.deployClasspath(Meecrowave.java:209) at 
> org.apache.meecrowave.Meecrowave.bake(Meecrowave.java:431) at 
> org.apache.meecrowave.Meecrowave.bake(Meecrowave.java:426) at 
> org.apache.meecrowave.MeecrowaveTest.noTomcatScanning(MeecrowaveTest.java:64) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498) at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at 
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
>  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
>  at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
>  at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at 
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at 
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at 
> org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at 
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at 
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at 
> org.junit.runners.ParentRunner.run(ParentRunner.java:413) at 
> org.junit.runner.JUnitCore.run(JUnitCore.java:137) at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>  at 
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
>  at 
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
>  at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)Caused by: 
> org.apache.catalina.LifecycleException: Failed to start component 
> [StandardEngine[Tomcat].StandardHost[localhost].[]] at 
> org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
>  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717)
>  ... 33 moreCaused by: java.lang.NullPointerException at 
> org.apache.meecrowave.tomcat.OWBJarScanner.scan(OWBJarScanner.java:52) at 
> org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(ContextConfig.java:2137)
>  at 
> org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1288) 
> at 
> org.apache.meecrowave.tomcat.MeecrowaveContextConfig.webConfig(MeecrowaveContextConfig.java:96)
>  at 
> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:985)
>  at 
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:303)
>  at 
> org.apache.meecrowave.tomcat.MeecrowaveContextConfig.lifecycleEvent(MeecrowaveContextConfig.java:170)
>  at 
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java

[jira] [Updated] (MEECROWAVE-309) Upgrade to Johnzon 1.2.18

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MEECROWAVE-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated MEECROWAVE-309:
-
Summary: Upgrade to Johnzon 1.2.18  (was: Upgrade to Johnzon 1.2.15)

> Upgrade to Johnzon 1.2.18
> -
>
> Key: MEECROWAVE-309
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-309
> Project: Meecrowave
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.14
>
>




--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: [DISCUSS] Release Meecrowave-1.2.14

[Mark Struberg]

Johnzon is pretty much ready. Will likely start a release soonish and then 
immediately also run the release tasks for MW, ok?

LieGrue,
strub


> Am 26.04.2022 um 12:01 schrieb Romain Manni-Bucau :
> 
> Well it is a matter of a week, since we didn't release for upgrades since
> the beginning of the year and several were containing CVE fixes - but all
> upgradable without patching our code - I don't think we have to urge so we
> can likely wait for it and not chain releases which is always perceived as
> a negative sign (bad quality) even if it is not in practise.
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le mar. 26 avr. 2022 à 11:03, Mark Struberg  a
> écrit :
> 
>> I read it and it doesn't sound like that is something which is just around
>> the corner.
>> So I'd rather release mw now and let's do a follow up release in a few
>> weeks?
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 26.04.2022 um 10:18 schrieb Romain Manni-Bucau >> :
>>> 
>>> Can we await for David's fix on johnzon? Would love to get that out ASAP,
>>> should be max a week I think.
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>>> 
>>> 
>>> Le mar. 26 avr. 2022 à 09:18, Mark Struberg 
>> a
>>> écrit :
>>> 
>>>> Hi folks!
>>>> 
>>>> Any reason not to start a mw release today?
>>>> We've ironed out a few glitches and updated some libs.
>>>> 
>>>> Will start in about 3 hours if nobody speaks out against it.
>>>> 
>>>> txs and LieGrue,
>>>> strub
>>>> 
>>>> 
>> 
>> 

Re: [DISCUSS] Release Meecrowave-1.2.14

[Mark Struberg]

I read it and it doesn't sound like that is something which is just around the 
corner. 
So I'd rather release mw now and let's do a follow up release in a few weeks?

LieGrue,
strub


> Am 26.04.2022 um 10:18 schrieb Romain Manni-Bucau :
> 
> Can we await for David's fix on johnzon? Would love to get that out ASAP,
> should be max a week I think.
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le mar. 26 avr. 2022 à 09:18, Mark Struberg  a
> écrit :
> 
>> Hi folks!
>> 
>> Any reason not to start a mw release today?
>> We've ironed out a few glitches and updated some libs.
>> 
>> Will start in about 3 hours if nobody speaks out against it.
>> 
>> txs and LieGrue,
>> strub
>> 
>> 

[DISCUSS] Release Meecrowave-1.2.14

[Mark Struberg]

Hi folks!

Any reason not to start a mw release today?
We've ironed out a few glitches and updated some libs.

Will start in about 3 hours if nobody speaks out against it.

txs and LieGrue,
strub

Re: [VOTE] Release Apache OpenWebBeans 2.0.26

[Mark Struberg]

+1

LieGrue,
strub

> Am 06.02.2022 um 15:30 schrieb Romain Manni-Bucau :
> 
> My own +1, we still miss one binding to close this vote guys
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le jeu. 3 févr. 2022 à 10:33, Thomas Andraschko 
> a écrit :
> 
>> +1
>> 
>> Am Do., 3. Feb. 2022 um 10:24 Uhr schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com>:
>> 
>>> Hi all,
>>> 
>>> Here is the vote for Apache OpenWebBeans 2.0.26.
>>> 
>>> Here is the changelog:
>>> 
>>> [image: Major] [image: Task] OWB-1401
>>>  Make interceptor
>> injected
>>> method array sorted to be deterministic in proxy classes
>>>  Romain Manni-Bucau
>>> <
>>> 
>> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau
 
>>> RESOLVED
>>> [image: Major] [image: Bug] OWB-1402
>>>  CDI iterated
>>> Instance#select broken 
>>> Romain
>>> Manni-Bucau
>>> <
>>> 
>> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau
 
>>> RESOLVED
>>> 
>>> Tag (note: uses a http repo for the tck so ensure to build with maven <
>> 3.8
>>> or enable http mirrors with maven):
>>> 
>>> 
>> https://gitbox.apache.org/repos/asf?p=openwebbeans.git;a=commit;h=0f06ed15bfe3e53923971188e96ecc721242c2e0
>>> Staging:
>>> 
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1079/
>>> Dist: https://dist.apache.org/repos/dist/dev/openwebbeans/owb/
>>> My key is the same than last time.
>>> 
>>> Please vote
>>> 
>>> [ ] +1
>>> [ ] -1 ${cause}
>>> 
>>> Vote will be opened for 3 days as usual or until we get enough binding
>>> votes.
>>> 
>>> 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
 
>>> 
>> 

Re: [VOTE] [RESULT] Release Apache Meecrowave-1.2.13

[Mark Struberg]

Hi!

The VOTE did pass with the following

+1: Romain, Jean-Louis, Reinhard, Arne, Mark

txs all!

gonna continue with the release steps.


LieGrue,
strub



> Am 14.12.2021 um 23:32 schrieb Mark Struberg :
> 
> Good evening!
> 
> I'd like to call a VOTE on Releasing Apache Meecrowave 1.2.13.
> 
> The following tickets got resolved:
> Bug
> 
> [MEECROWAVE-304 <https://issues.apache.org/jira/browse/MEECROWAVE-304>] - 
> upgrade to log4j2 2.16.0
> Task
> 
> [MEECROWAVE-261 <https://issues.apache.org/jira/browse/MEECROWAVE-261>] - 
> upgrade to java16 ready versions
> [MEECROWAVE-300 <https://issues.apache.org/jira/browse/MEECROWAVE-300>] - 
> Upgrade to johnzon 1.2.14
> [MEECROWAVE-301 <https://issues.apache.org/jira/browse/MEECROWAVE-301>] - 
> Upgrade to tomcat 9.0.54
> [MEECROWAVE-302 <https://issues.apache.org/jira/browse/MEECROWAVE-302>] - 
> Upgrade to cxf 3.4.5
> [MEECROWAVE-303 <https://issues.apache.org/jira/browse/MEECROWAVE-303>] - 
> [jpa] extension can leak closed entity managers
> [MEECROWAVE-305 <https://issues.apache.org/jira/browse/MEECROWAVE-305>] - 
> upgrade various dependencies to latest versions
> [MEECROWAVE-306 <https://issues.apache.org/jira/browse/MEECROWAVE-306>] - 
> Update to OpenWebBeans-2.0.25
> 
> Note that this release requires OWB-2.0.25 which is available in the staging 
> repo as posted in the other VOTE thread.
> 
> 
> The staging repo can be found at:
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1078/
>  
> <https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1078/>
> 
> The source release is available at 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1078/org/apache/meecrowave/meecrowave/1.2.13/
>  
> <https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1078/org/apache/meecrowave/meecrowave/1.2.13/>
> 
> sha1 is 4619a441a8bce34e55cc2d99281089667d9d7b26
> 
> 
> Please VOTE:
> 
> [+1] let's ship it!
> [+0] meh, don't care
> [-1] gnah, there is a ${showstopper}
> 
> The VOTE is open for 72h.
> 
> txs and LieGrue,
> strub

Re: [VOTE][RESULT] Release Apache OpenWebBeans-2.0.25 - take 2

[Mark Struberg]

Time to tally the VOTE.

The VOTE did pass with the following

+1: Romain, Jean-Louis, Jon, Reinhard, Arne, Mark
No -1 nor 0

thank you all!

I'll gonna continue with the release steps.

LieGrue,
strub


> Am 14.12.2021 um 23:24 schrieb Mark Struberg :
> 
> Hi lords and ladies!
> 
> I'd like to call a VOTE on releasing Apache OpenWebBeans-2.0.25.
> 
> The following tickets have been resolved:
> Bug
> 
> [OWB-1393 <https://issues.apache.org/jira/browse/OWB-1393>] - OWB stops 
> firing ProcessObserverMethods event, when Extension with non system event 
> observer exists
> [OWB-1395 <https://issues.apache.org/jira/browse/OWB-1395>] - Jar not scanned 
> after 2.0.24 upgrade
> [OWB-1397 <https://issues.apache.org/jira/browse/OWB-1397>] - @Scope scopes 
> are NOT Bean defining annotations!
> [OWB-1398 <https://issues.apache.org/jira/browse/OWB-1398>] - Scanner doesnt 
> filter JARs by exclusions in all cases
> Task
> 
> [OWB-1396 <https://issues.apache.org/jira/browse/OWB-1396>] - upgrade to 
> log4j2 2.16.0
> 
> 
> The staging repo is 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1077 
> <https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1077>
> 
> The source jar can be found here:
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1077/org/apache/openwebbeans/openwebbeans/2.0.25/
>  
> <https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1077/org/apache/openwebbeans/openwebbeans/2.0.25/>
> 
> sha1 is 3136dd1f8515487c6c8d88e77bdaca7c6066680d
> 
> 
> Please VOTE:
> 
> [+1] let's ship it!
> [+0] meh, don't care
> [-1] gnah, there is a ${showstopper}
> 
> The VOTE is open for 72h.
> 
> txs and LieGrue,
> strub

Re: [VOTE] Release Apache Meecrowave-1.2.13

[Mark Struberg]

+1

LieGrue,
strub


> Am 16.12.2021 um 20:15 schrieb Arne Limburg :
> 
> +1
> 
> 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<mailto:arne.limb...@openknowledge.de>
> www.openknowledge.de<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=9vRVYZVZ%2Feqk%2BvFxU5COofNvgs8U0AxtxRqwVEwqXHA%3D=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=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=8tjmukdm1NxhXQMkn4VnESiBI216kXvh%2Fjb7%2FFYI0kE%3D=0>
> 
> Von: Jean-Louis MONTEIRO 
> Datum: Mittwoch, 15. Dezember 2021 um 15:04
> An: dev@openwebbeans.apache.org 
> Betreff: Re: [VOTE] Release Apache Meecrowave-1.2.13
> +1
> 
> Le mer. 15 déc. 2021 à 08:33, Romain Manni-Bucau  a
> écrit :
> 
>> +1
>> 
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau><https://github.com/rmannibucau%3e> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>> 
>> 
>> Le mar. 14 déc. 2021 à 23:32, Mark Struberg  a
>> écrit :
>> 
>>> Good evening!
>>> 
>>> I'd like to call a VOTE on Releasing Apache Meecrowave 1.2.13.
>>> 
>>> The following tickets got resolved:
>>> Bug
>>> 
>>> [MEECROWAVE-304 <https://issues.apache.org/jira/browse/MEECROWAVE-304>]
>> -
>>> upgrade to log4j2 2.16.0
>>> Task
>>> 
>>> [MEECROWAVE-261 <https://issues.apache.org/jira/browse/MEECROWAVE-261>]
>> -
>>> upgrade to java16 ready versions
>>> [MEECROWAVE-300 <https://issues.apache.org/jira/browse/MEECROWAVE-300>]
>> -
>>> Upgrade to johnzon 1.2.14
>>> [MEECROWAVE-301 <https://issues.apache.org/jira/browse/MEECROWAVE-301>]
>> -
>>> Upgrade to tomcat 9.0.54
>>> [MEECROWAVE-302 <https://issues.apache.org/jira/browse/MEECROWAVE-302>]
>> -
>>> Upgrade to cxf 3.4.5
>>> [MEECROWAVE-303 <https://issues.apache.org/jira/browse/MEECROWAVE-303>]
>> -
>>> [jpa] extension can leak closed entity managers
>>> [MEECROWAVE-305 <https://issues.apache.org/jira/browse/MEECROWAVE-305>]
>> -
>>> upgrade various dependencies to latest versions
>>> [MEECROWAVE-306 <https://issues.apache.org/jira/browse/MEECROWAVE-306>]
>> -
>>> Update to OpenWebBeans-2.0.25
>>> 
>>> Note that this release requires OWB-2.0.25 which is available in the
>>> staging repo as posted in the other VOTE thread.
>>> 
>>> 
>>> The staging repo can be found at:
>>> 
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1078/
>>> <
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1078/
>>>> 
>>> 
>>> The source release is available at
>>> 
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1078/org/apache/meecrowave/meecrowave/1.2.13/
>>> <
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1078/org/apache/meecrowave/meecrowave/1.2.13/
>>>> 
>>> 
>>> sha1 is 4619a441a8bce34e55cc2d99281089667d9d7b26
>>> 
>>> 
>>> Please VOTE:
>>> 
>>> [+1] let's ship it!
>>> [+0] meh, don't care
>>> [-1] gnah, there is a ${showstopper}
>>> 
>>> The VOTE is open for 72h.
>>> 
>>> txs and LieGrue,
>>> strub
>> 
> 
> 
> --
> Jean-Louis

Re: [VOTE] Release Apache OpenWebBeans-2.0.25 - take 2

[Mark Struberg]

+1

LieGrue,
strub


> Am 16.12.2021 um 20:15 schrieb Arne Limburg :
> 
> +1 from me
> 
> 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<mailto:arne.limb...@openknowledge.de>
> www.openknowledge.de<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=9vRVYZVZ%2Feqk%2BvFxU5COofNvgs8U0AxtxRqwVEwqXHA%3D=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=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=8tjmukdm1NxhXQMkn4VnESiBI216kXvh%2Fjb7%2FFYI0kE%3D=0>
> 
> Von: Jean-Louis MONTEIRO 
> Datum: Mittwoch, 15. Dezember 2021 um 15:04
> An: dev@openwebbeans.apache.org 
> Betreff: Re: [VOTE] Release Apache OpenWebBeans-2.0.25 - take 2
> +1
> 
> Le mer. 15 déc. 2021 à 08:33, Romain Manni-Bucau  a
> écrit :
> 
>> +1
>> 
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau><https://github.com/rmannibucau%3e> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>> 
>> 
>> Le mar. 14 déc. 2021 à 23:24, Mark Struberg  a
>> écrit :
>> 
>>> Hi lords and ladies!
>>> 
>>> I'd like to call a VOTE on releasing Apache OpenWebBeans-2.0.25.
>>> 
>>> The following tickets have been resolved:
>>> Bug
>>> 
>>> [OWB-1393 <https://issues.apache.org/jira/browse/OWB-1393>] - OWB stops
>>> firing ProcessObserverMethods event, when Extension with non system event
>>> observer exists
>>> [OWB-1395 <https://issues.apache.org/jira/browse/OWB-1395>] - Jar not
>>> scanned after 2.0.24 upgrade
>>> [OWB-1397 <https://issues.apache.org/jira/browse/OWB-1397>] - @Scope
>>> scopes are NOT Bean defining annotations!
>>> [OWB-1398 <https://issues.apache.org/jira/browse/OWB-1398>] - Scanner
>>> doesnt filter JARs by exclusions in all cases
>>> Task
>>> 
>>> [OWB-1396 <https://issues.apache.org/jira/browse/OWB-1396>] - upgrade to
>>> log4j2 2.16.0
>>> 
>>> 
>>> The staging repo is
>>> 
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1077
>>> <
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1077
>>>> 
>>> 
>>> The source jar can be found here:
>>> 
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1077/org/apache/openwebbeans/openwebbeans/2.0.25/
>>> <
>>> 
>> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1077/org/apache/openwebbeans/openwebbeans/2.0.25/
>>>> 
>>> 
>>> sha1 is 3136dd1f8515487c6c8d88e77bdaca7c6066680d
>>> 
>>> 
>>> Please VOTE:
>>> 
>>> [+1] let's ship it!
>>> [+0] meh, don't care
>>> [-1] gnah, there is a ${showstopper}
>>> 
>>> The VOTE is open for 72h.
>>> 
>>> txs and LieGrue,
>>> strub
>> 
> 
> 
> --
> Jean-Louis

[VOTE] Release Apache Meecrowave-1.2.13

[Mark Struberg]

Good evening!

I'd like to call a VOTE on Releasing Apache Meecrowave 1.2.13.

The following tickets got resolved:
Bug

[MEECROWAVE-304 ] - 
upgrade to log4j2 2.16.0
Task

[MEECROWAVE-261 ] - 
upgrade to java16 ready versions
[MEECROWAVE-300 ] - 
Upgrade to johnzon 1.2.14
[MEECROWAVE-301 ] - 
Upgrade to tomcat 9.0.54
[MEECROWAVE-302 ] - 
Upgrade to cxf 3.4.5
[MEECROWAVE-303 ] - [jpa] 
extension can leak closed entity managers
[MEECROWAVE-305 ] - 
upgrade various dependencies to latest versions
[MEECROWAVE-306 ] - 
Update to OpenWebBeans-2.0.25

Note that this release requires OWB-2.0.25 which is available in the staging 
repo as posted in the other VOTE thread.


The staging repo can be found at:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1078/ 


The source release is available at 
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1078/org/apache/meecrowave/meecrowave/1.2.13/
 


sha1 is 4619a441a8bce34e55cc2d99281089667d9d7b26


Please VOTE:

[+1] let's ship it!
[+0] meh, don't care
[-1] gnah, there is a ${showstopper}

The VOTE is open for 72h.

txs and LieGrue,
strub

[jira] [Resolved] (MEECROWAVE-305) upgrade various dependencies to latest versions

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MEECROWAVE-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved MEECROWAVE-305.
--
Resolution: Fixed

> upgrade various dependencies to latest versions
> ---
>
> Key: MEECROWAVE-305
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-305
> Project: Meecrowave
>  Issue Type: Task
>Affects Versions: 1.2.12
>Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.2.13
>
>
> there are quite a few deps which might get bumped. E.g. tomcat and deltaspike.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (MEECROWAVE-262) Ensure disabling tomcat scanning does not require any other customization

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MEECROWAVE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated MEECROWAVE-262:
-
Fix Version/s: (was: 1.2.12)

> Ensure disabling tomcat scanning does not require any other customization
> -
>
> Key: MEECROWAVE-262
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-262
> Project: Meecrowave
>  Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Assignee: Romain Manni-Bucau
>Priority: Major
>
> Currently it fails with:
>  
> {code:java}
> java.lang.IllegalStateException: Error starting 
> childjava.lang.IllegalStateException: Error starting child
>  at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:720)
>  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) 
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:706) at 
> org.apache.meecrowave.Meecrowave.deployWebapp(Meecrowave.java:409) at 
> org.apache.meecrowave.Meecrowave.deployClasspath(Meecrowave.java:190) at 
> org.apache.meecrowave.Meecrowave.deployClasspath(Meecrowave.java:209) at 
> org.apache.meecrowave.Meecrowave.bake(Meecrowave.java:431) at 
> org.apache.meecrowave.Meecrowave.bake(Meecrowave.java:426) at 
> org.apache.meecrowave.MeecrowaveTest.noTomcatScanning(MeecrowaveTest.java:64) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498) at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at 
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
>  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
>  at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
>  at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at 
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at 
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at 
> org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at 
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at 
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at 
> org.junit.runners.ParentRunner.run(ParentRunner.java:413) at 
> org.junit.runner.JUnitCore.run(JUnitCore.java:137) at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>  at 
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
>  at 
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
>  at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)Caused by: 
> org.apache.catalina.LifecycleException: Failed to start component 
> [StandardEngine[Tomcat].StandardHost[localhost].[]] at 
> org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
>  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717)
>  ... 33 moreCaused by: java.lang.NullPointerException at 
> org.apache.meecrowave.tomcat.OWBJarScanner.scan(OWBJarScanner.java:52) at 
> org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(ContextConfig.java:2137)
>  at 
> org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1288) 
> at 
> org.apache.meecrowave.tomcat.MeecrowaveContextConfig.webConfig(MeecrowaveContextConfig.java:96)
>  at 
> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:985)
>  at 
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:303)
>  at 
> org.apache.meecrowave.tomcat.MeecrowaveContextConfig.lifecycleEvent(MeecrowaveContextConfig.java:170)
>  at 
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
>  at 
> org.apache.catalina.core.StandardContext.startInterna