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

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

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

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

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

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

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

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

[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:123)
>  at 
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5082)
>  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 
> 34 more
> [09:16:44.112][INFO 

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

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

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

[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:123)
>  at 
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5082)
>  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 
> 34 more
> [09:16:44.112][INFO 

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

[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.startInternal(StandardContext.java:5082)
>  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 
> 34 more
> [09:16:44.112][INFO ][owave-stop-hook][oyote.http11.Http11NioProtocol] 
> Pausing ProtocolHandler 

[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.14
   (was: 1.2.12)

> 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.14
>
>
> 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.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: 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.14
>
>
> 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.startInternal(StandardContext.java:5082)
>  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 
> 34 more
> [09:16:44.112][INFO ][owave-stop-hook][oyote.http11.Http11NioProtocol] 
> Pausing ProtocolHandler 

[jira] [Resolved] (MEECROWAVE-261) upgrade to java16 ready versions

[Mark Struberg (Jira)]

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

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

> upgrade to java16 ready versions
> 
>
> Key: MEECROWAVE-261
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-261
> Project: Meecrowave
>  Issue Type: Task
>Affects Versions: 1.2.9
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.2.13
>
>
> We've got some fixes in the chain which makes it possible to also run MW 
> under the upcoming Java16 release. This includes CXF, OpenWebBeans and 
> OpenJPA plus a few spec updates.



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

[jira] [Updated] (MEECROWAVE-261) upgrade to java16 ready versions

[Mark Struberg (Jira)]

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

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

> upgrade to java16 ready versions
> 
>
> Key: MEECROWAVE-261
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-261
> Project: Meecrowave
>  Issue Type: Task
>Affects Versions: 1.2.9
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.2.13
>
>
> We've got some fixes in the chain which makes it possible to also run MW 
> under the upcoming Java16 release. This includes CXF, OpenWebBeans and 
> OpenJPA plus a few spec updates.



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

[jira] [Resolved] (MEECROWAVE-306) Update to OpenWebBeans-2.0.25

[Mark Struberg (Jira)]

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

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

> Update to OpenWebBeans-2.0.25
> -
>
> Key: MEECROWAVE-306
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-306
> Project: Meecrowave
>  Issue Type: Task
>Affects Versions: 1.2.12
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.2.13
>
>
> Update to OpenWebBeans-2.0.25



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

[jira] [Updated] (MEECROWAVE-261) upgrade to java16 ready versions

[Mark Struberg (Jira)]

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

Mark Struberg updated MEECROWAVE-261:
-
Summary: upgrade to java16 ready versions  (was: upgrde to java16 ready 
versions)

> upgrade to java16 ready versions
> 
>
> Key: MEECROWAVE-261
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-261
> Project: Meecrowave
>  Issue Type: Task
>Affects Versions: 1.2.9
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.2.12
>
>
> We've got some fixes in the chain which makes it possible to also run MW 
> under the upcoming Java16 release. This includes CXF, OpenWebBeans and 
> OpenJPA plus a few spec updates.



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

[jira] [Created] (MEECROWAVE-306) Update to OpenWebBeans-2.0.25

[Mark Struberg (Jira)]

Mark Struberg created MEECROWAVE-306:


 Summary: Update to OpenWebBeans-2.0.25
 Key: MEECROWAVE-306
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-306
 Project: Meecrowave
  Issue Type: Task
Affects Versions: 1.2.12
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 1.2.13


Update to OpenWebBeans-2.0.25



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

[jira] [Updated] (MEECROWAVE-304) upgrade to log4j2 2.16.0

[Mark Struberg (Jira)]

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

Mark Struberg updated MEECROWAVE-304:
-
Description: 
Log4j2-2.14.1 contains a CVE related but which allows code injection via JNDI 
in the log string.

This is prevented with more recent Java JDK versions but is now also fixed in 
log4j2 directly.

Please use this MW version or update your installations by replacing the 
log4j2.jars with 2.16.0 manually.

  was:
Log4j2-2.14.1 contains a CVE related but which allows code injection via JNDI 
in the log string.

This is prevented with more recent Java JDK versions but is now also fixed in 
log4j2 directly.

Please use this MW version or update your installations by replacing the 
log4j2.jars with 2.15.0 manually.


> upgrade to log4j2 2.16.0
> 
>
> Key: MEECROWAVE-304
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-304
> Project: Meecrowave
>  Issue Type: Bug
>Affects Versions: 1.2.12
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.2.13
>
>
> Log4j2-2.14.1 contains a CVE related but which allows code injection via JNDI 
> in the log string.
> This is prevented with more recent Java JDK versions but is now also fixed in 
> log4j2 directly.
> Please use this MW version or update your installations by replacing the 
> log4j2.jars with 2.16.0 manually.



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

[jira] [Updated] (MEECROWAVE-304) upgrade to log4j2 2.16.0

[Mark Struberg (Jira)]

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

Mark Struberg updated MEECROWAVE-304:
-
Summary: upgrade to log4j2 2.16.0  (was: upgrade to log4j2 2.15.0)

> upgrade to log4j2 2.16.0
> 
>
> Key: MEECROWAVE-304
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-304
> Project: Meecrowave
>  Issue Type: Bug
>Affects Versions: 1.2.12
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.2.13
>
>
> Log4j2-2.14.1 contains a CVE related but which allows code injection via JNDI 
> in the log string.
> This is prevented with more recent Java JDK versions but is now also fixed in 
> log4j2 directly.
> Please use this MW version or update your installations by replacing the 
> log4j2.jars with 2.15.0 manually.



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

[jira] [Commented] (OWB-1396) upgrade to log4j2 2.16.0

[Mark Struberg (Jira)]

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

Mark Struberg commented on OWB-1396:


Even upgrde to 2.16.0

> upgrade to log4j2 2.16.0
> 
>
> Key: OWB-1396
> URL: https://issues.apache.org/jira/browse/OWB-1396
> Project: OpenWebBeans
>  Issue Type: Task
>  Components: Core
>Affects Versions: 2.0.24
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 2.0.25
>
>
> We gonna bump our log4j 2 version to the CVE free 2.15.0.
> Note that we did not ship this but only used it as a provided compile time 
> dependency for compiling our optional log4j2 support against it! So this is 
> not strictly a CVE related issue but just to make sure we don't get too many 
> reports that we are using an evil version.



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

[jira] [Updated] (OWB-1396) upgrade to log4j2 2.16.0

[Mark Struberg (Jira)]

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

Mark Struberg updated OWB-1396:
---
Summary: upgrade to log4j2 2.16.0  (was: upgrade to log4j2 2.15.0)

> upgrade to log4j2 2.16.0
> 
>
> Key: OWB-1396
> URL: https://issues.apache.org/jira/browse/OWB-1396
> Project: OpenWebBeans
>  Issue Type: Task
>  Components: Core
>Affects Versions: 2.0.24
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 2.0.25
>
>
> We gonna bump our log4j 2 version to the CVE free 2.15.0.
> Note that we did not ship this but only used it as a provided compile time 
> dependency for compiling our optional log4j2 support against it! So this is 
> not strictly a CVE related issue but just to make sure we don't get too many 
> reports that we are using an evil version.



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

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

[Mark Struberg (Jira)]

Mark Struberg created MEECROWAVE-305:


 Summary: 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
 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] [Resolved] (MEECROWAVE-304) upgrade to log4j2 2.15.0

[Mark Struberg (Jira)]

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

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

> upgrade to log4j2 2.15.0
> 
>
> Key: MEECROWAVE-304
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-304
> Project: Meecrowave
>  Issue Type: Bug
>Affects Versions: 1.2.12
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.2.13
>
>
> Log4j2-2.14.1 contains a CVE related but which allows code injection via JNDI 
> in the log string.
> This is prevented with more recent Java JDK versions but is now also fixed in 
> log4j2 directly.
> Please use this MW version or update your installations by replacing the 
> log4j2.jars with 2.15.0 manually.



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

[jira] [Resolved] (OWB-1397) @Scope scopes are NOT Bean defining annotations!

[Mark Struberg (Jira)]

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

Mark Struberg resolved OWB-1397.

Resolution: Fixed

> @Scope scopes are NOT Bean defining annotations! 
> -
>
> Key: OWB-1397
> URL: https://issues.apache.org/jira/browse/OWB-1397
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.24
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.25
>
>
> Right now we also interpret non normal scopes (like 
> {{javax.inject.Singleton}}) as {_}Bean Defining Annotations{_}, but that is 
> wrong.



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

[jira] [Created] (OWB-1397) @Scope scopes are NOT Bean defining annotations!

[Mark Struberg (Jira)]

Mark Struberg created OWB-1397:
--

 Summary: @Scope scopes are NOT Bean defining annotations! 
 Key: OWB-1397
 URL: https://issues.apache.org/jira/browse/OWB-1397
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.24
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 2.0.25


Right now we also interpret non normal scopes (like {{javax.inject.Singleton}}) 
as {_}Bean Defining Annotations{_}, but that is wrong.



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

[jira] [Updated] (MEECROWAVE-304) upgrade to log4j2 2.15.0

[Mark Struberg (Jira)]

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

Mark Struberg updated MEECROWAVE-304:
-
Description: 
Log4j2-2.14.1 contains a CVE related but which allows code injection via JNDI 
in the log string.

This is prevented with more recent Java JDK versions but is now also fixed in 
log4j2 directly.

Please use this MW version or update your installations by replacing the 
log4j2.jars with 2.15.0 manually.

> upgrade to log4j2 2.15.0
> 
>
> Key: MEECROWAVE-304
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-304
> Project: Meecrowave
>  Issue Type: Bug
>Affects Versions: 1.2.12
>Reporter: Mark Struberg
>Priority: Major
> Fix For: 1.2.13
>
>
> Log4j2-2.14.1 contains a CVE related but which allows code injection via JNDI 
> in the log string.
> This is prevented with more recent Java JDK versions but is now also fixed in 
> log4j2 directly.
> Please use this MW version or update your installations by replacing the 
> log4j2.jars with 2.15.0 manually.



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

[jira] [Updated] (MEECROWAVE-304) upgrade to log4j2 2.15.0

[Mark Struberg (Jira)]

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

Mark Struberg updated MEECROWAVE-304:
-
Summary: upgrade to log4j2 2.15.0  (was: Upgrade)

> upgrade to log4j2 2.15.0
> 
>
> Key: MEECROWAVE-304
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-304
> Project: Meecrowave
>  Issue Type: Bug
>Affects Versions: 1.2.12
>Reporter: Mark Struberg
>Priority: Major
> Fix For: 1.2.13
>
>




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

[jira] [Updated] (MEECROWAVE-304) Upgrade

[Mark Struberg (Jira)]

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

Mark Struberg updated MEECROWAVE-304:
-
Fix Version/s: 1.2.13

> Upgrade
> ---
>
> Key: MEECROWAVE-304
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-304
> Project: Meecrowave
>  Issue Type: Bug
>Affects Versions: 1.2.12
>Reporter: Mark Struberg
>Priority: Major
> Fix For: 1.2.13
>
>




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

[jira] [Updated] (MEECROWAVE-304) Upgrade

[Mark Struberg (Jira)]

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

Mark Struberg updated MEECROWAVE-304:
-
Affects Version/s: 1.2.12

> Upgrade
> ---
>
> Key: MEECROWAVE-304
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-304
> Project: Meecrowave
>  Issue Type: Bug
>Affects Versions: 1.2.12
>Reporter: Mark Struberg
>Priority: Major
>




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

[jira] [Created] (MEECROWAVE-304) Upgrade

[Mark Struberg (Jira)]

Mark Struberg created MEECROWAVE-304:


 Summary: Upgrade
 Key: MEECROWAVE-304
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-304
 Project: Meecrowave
  Issue Type: Bug
Reporter: Mark Struberg






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

[jira] [Resolved] (OWB-1396) upgrade to log4j2 2.15.0

[Mark Struberg (Jira)]

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

Mark Struberg resolved OWB-1396.

Resolution: Fixed

> upgrade to log4j2 2.15.0
> 
>
> Key: OWB-1396
> URL: https://issues.apache.org/jira/browse/OWB-1396
> Project: OpenWebBeans
>  Issue Type: Task
>  Components: Core
>Affects Versions: 2.0.24
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 2.0.25
>
>
> We gonna bump our log4j 2 version to the CVE free 2.15.0.
> Note that we did not ship this but only used it as a provided compile time 
> dependency for compiling our optional log4j2 support against it! So this is 
> not strictly a CVE related issue but just to make sure we don't get too many 
> reports that we are using an evil version.



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

[jira] [Created] (OWB-1396) upgrade to log4j2 2.15.0

[Mark Struberg (Jira)]

Mark Struberg created OWB-1396:
--

 Summary: upgrade to log4j2 2.15.0
 Key: OWB-1396
 URL: https://issues.apache.org/jira/browse/OWB-1396
 Project: OpenWebBeans
  Issue Type: Task
  Components: Core
Affects Versions: 2.0.24
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 2.0.25


We gonna bump our log4j 2 version to the CVE free 2.15.0.

Note that we did not ship this but only used it as a provided compile time 
dependency for compiling our optional log4j2 support against it! So this is not 
strictly a CVE related issue but just to make sure we don't get too many 
reports that we are using an evil version.



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

[jira] [Updated] (OWB-1074) implement automatic supportsConversation() detection

[Mark Struberg (Jira)]

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

Mark Struberg updated OWB-1074:
---
Fix Version/s: 2.0.26
   (was: 2.0.25)

> implement automatic supportsConversation() detection
> 
>
> Key: OWB-1074
> URL: https://issues.apache.org/jira/browse/OWB-1074
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Context and Scopes
>Affects Versions: 1.5.0
>Reporter: Mark Struberg
>Priority: Major
> Fix For: 2.0.26
>
>
> Currently we rely on the user to define the configuration option in 
> OpenWebBeansConfiguration
> {code}
> APPLICATION_SUPPORTS_CONVERSATION = 
> "org.apache.webbeans.application.supportsConversation";
> {code}
> This is by default disabled in owb-impl (core) and gets enabled by adding the 
> web or jsf plugins.
> We could improve this by not only allowing {{true}} or {{false}} but also 
> with an {{auto}} mode. 
> In this mode the BeanManager can walk through all registered beans and check 
> whether there is a single @ConversationScoped bean. In that case we will 
> automagically enable CDI conversations, otherwise OWB will dynamically 
> disable conversation support and don't need to do all kinds of work in 
> WebContextsService for example.



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

[jira] [Resolved] (OWB-1393) OWB stops firing ProcessObserverMethods event, when Extension with non system event observer exists

[Mark Struberg (Jira)]

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

Mark Struberg resolved OWB-1393.

Fix Version/s: 2.0.25
   (was: 2.0.24)
   Resolution: Fixed

> OWB stops firing ProcessObserverMethods event, when Extension with non system 
> event observer exists
> ---
>
> Key: OWB-1393
> URL: https://issues.apache.org/jira/browse/OWB-1393
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 2.0.23
>Reporter: Arne Limburg
>Assignee: Arne Limburg
>Priority: Major
> Fix For: 2.0.25
>
>
> When an extension is in the classpath, that observes an event that is no 
> system event (like org.apache.cxf.cdi.JAXRSCdiResourceExtension), every 
> extension that is registered after that extension will not receive 
> ProcessObserverMethod events any more.



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

[jira] [Reopened] (OWB-1393) OWB stops firing ProcessObserverMethods event, when Extension with non system event observer exists

[Mark Struberg (Jira)]

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

Mark Struberg reopened OWB-1393:


It appears that this still randomly happens. Just got this in my local build.

> OWB stops firing ProcessObserverMethods event, when Extension with non system 
> event observer exists
> ---
>
> Key: OWB-1393
> URL: https://issues.apache.org/jira/browse/OWB-1393
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: 2.0.23
>Reporter: Arne Limburg
>Assignee: Arne Limburg
>Priority: Major
> Fix For: 2.0.24
>
>
> When an extension is in the classpath, that observes an event that is no 
> system event (like org.apache.cxf.cdi.JAXRSCdiResourceExtension), every 
> extension that is registered after that extension will not receive 
> ProcessObserverMethod events any more.



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

[jira] [Resolved] (OWB-1389) Remove destroyed instance from memory

[Mark Struberg (Jira)]

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

Mark Struberg resolved OWB-1389.

Fix Version/s: 2.0.24
 Assignee: Mark Struberg
   Resolution: Fixed

txs for the PR!

> Remove destroyed instance from memory
> -
>
> Key: OWB-1389
> URL: https://issues.apache.org/jira/browse/OWB-1389
> Project: OpenWebBeans
>  Issue Type: Improvement
>Affects Versions: 1.7.6, 2.0.23
>Reporter: Sebastian Schlatow
>Assignee: Mark Struberg
>Priority: Major
>  Labels: github-import, patch, pull-request-available
> Fix For: 2.0.24
>
>
> Avoids memory leak
> cdi-2.0: [https://github.com/apache/openwebbeans/pull/36]
> owb_1.7.x: https://github.com/apache/openwebbeans/pull/37



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (MEECROWAVE-155) Kotlin based sample

[Mark Struberg (Jira)]

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

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

already got merged into meecrowave-examples a long time ago.
Txs for the patch [~elexx]!

> Kotlin based sample
> ---
>
> Key: MEECROWAVE-155
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-155
> Project: Meecrowave
>  Issue Type: Improvement
>Reporter: Alexander Falb
>Assignee: Mark Struberg
>Priority: Minor
>
> If you are interested, I'd be happy to contribute a small Kotlin based sample



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (MEECROWAVE-184) MeecrowaveSeContainerInitializerTest does not pass with openjdk-8-jdk version 8u191-b12-2 on Debian

[Mark Struberg (Jira)]

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

Mark Struberg resolved MEECROWAVE-184.
--
Resolution: Cannot Reproduce

moving to cannot reproduce. 
hope that is fine for you as well [~lpenet]!

> MeecrowaveSeContainerInitializerTest does not pass with openjdk-8-jdk version 
> 8u191-b12-2 on Debian
> ---
>
> Key: MEECROWAVE-184
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-184
> Project: Meecrowave
>  Issue Type: Bug
>Affects Versions: 1.2.7
>Reporter: Ludovic Pénet
>Assignee: Mark Struberg
>Priority: Minor
>
> ---
> Test set: org.apache.meecrowave.cdi.MeecrowaveSeContainerInitializerTest
> ---
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.021 s <<< 
> FAILURE! - in org.apache.meecrowave.cdi.MeecrowaveSeContainerInitializerTest
> run(org.apache.meecrowave.cdi.MeecrowaveSeContainerInitializerTest) Time 
> elapsed: 0.021 s <<< ERROR!
> java.lang.IllegalArgumentException: sun.misc.Launcher$AppClassLoader@7f31245a 
> is already registered
>  at 
> org.apache.webbeans.corespi.DefaultSingletonService.register(DefaultSingletonService.java:67)
>  at 
> org.apache.openwebbeans.se.OWBInitializer.initialize(OWBInitializer.java:89)
>  at 
> org.apache.meecrowave.cdi.MeecrowaveSeContainerInitializerTest.run(MeecrowaveSeContainerInitializerTest.java:45)
>  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:50)
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>  at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>  at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>  at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>  at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>  at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>  at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>  at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>  at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
>  at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
>  at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
>  at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (MEECROWAVE-184) MeecrowaveSeContainerInitializerTest does not pass with openjdk-8-jdk version 8u191-b12-2 on Debian

[Mark Struberg (Jira)]

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

Mark Struberg reassigned MEECROWAVE-184:


Assignee: Mark Struberg

> MeecrowaveSeContainerInitializerTest does not pass with openjdk-8-jdk version 
> 8u191-b12-2 on Debian
> ---
>
> Key: MEECROWAVE-184
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-184
> Project: Meecrowave
>  Issue Type: Bug
>Affects Versions: 1.2.7
>Reporter: Ludovic Pénet
>Assignee: Mark Struberg
>Priority: Minor
>
> ---
> Test set: org.apache.meecrowave.cdi.MeecrowaveSeContainerInitializerTest
> ---
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.021 s <<< 
> FAILURE! - in org.apache.meecrowave.cdi.MeecrowaveSeContainerInitializerTest
> run(org.apache.meecrowave.cdi.MeecrowaveSeContainerInitializerTest) Time 
> elapsed: 0.021 s <<< ERROR!
> java.lang.IllegalArgumentException: sun.misc.Launcher$AppClassLoader@7f31245a 
> is already registered
>  at 
> org.apache.webbeans.corespi.DefaultSingletonService.register(DefaultSingletonService.java:67)
>  at 
> org.apache.openwebbeans.se.OWBInitializer.initialize(OWBInitializer.java:89)
>  at 
> org.apache.meecrowave.cdi.MeecrowaveSeContainerInitializerTest.run(MeecrowaveSeContainerInitializerTest.java:45)
>  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:50)
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>  at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>  at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>  at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>  at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>  at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>  at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>  at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>  at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
>  at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
>  at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
>  at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (MEECROWAVE-294) Upgrade to Apache-parent 23

[Mark Struberg (Jira)]

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

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

> Upgrade to Apache-parent 23
> ---
>
> Key: MEECROWAVE-294
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-294
> Project: Meecrowave
>  Issue Type: Task
>Affects Versions: 1.2.11
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.2.12
>
>
> Upgrade to Apache-parent 23



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MEECROWAVE-294) Upgrade to Apache-parent 23

[Mark Struberg (Jira)]

Mark Struberg created MEECROWAVE-294:


 Summary: Upgrade to Apache-parent 23
 Key: MEECROWAVE-294
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-294
 Project: Meecrowave
  Issue Type: Task
Affects Versions: 1.2.11
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 1.2.12


Upgrade to Apache-parent 23



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (MEECROWAVE-293) Upgrade to Johnzon- 1.2.12

[Mark Struberg (Jira)]

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

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

> Upgrade to Johnzon- 1.2.12
> --
>
> Key: MEECROWAVE-293
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-293
> Project: Meecrowave
>  Issue Type: Task
>Affects Versions: 1.2.11
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.2.12
>
>
> Upgrade to Johnzon- 1.2.12.
> Johnzon-1.2.11 had a bug regarding JsonbSerializers.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MEECROWAVE-293) Upgrade to Johnzon- 1.2.12

[Mark Struberg (Jira)]

Mark Struberg created MEECROWAVE-293:


 Summary: Upgrade to Johnzon- 1.2.12
 Key: MEECROWAVE-293
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-293
 Project: Meecrowave
  Issue Type: Task
Affects Versions: 1.2.11
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 1.2.12


Upgrade to Johnzon- 1.2.12.
Johnzon-1.2.11 had a bug regarding JsonbSerializers.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MEECROWAVE-261) upgrde to java16 ready versions

[Mark Struberg (Jira)]

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

Mark Struberg commented on MEECROWAVE-261:
--

This was initially about the OWB update, but figured that we have a few more 
minor nitpicks. MW itself runs fine, but our Oauth2 integration could need some 
improvements:
{noformat}
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.404 s 
<<< FAILURE! - in org.apache.meecrowave.oauth2.OAuth2Test
[ERROR] org.apache.meecrowave.oauth2.OAuth2Test  Time elapsed: 2.404 s  <<< 
ERROR!
java.lang.IllegalAccessError: class org.apache.meecrowave.oauth2.Keystores (in 
unnamed module @0x11739fa6) cannot access class 
sun.security.tools.keytool.CertAndKeyGen (in module java.base) because module 
java.base does not export sun.security.tools.keytool to unnamed module 
@0x11739fa6
at org.apache.meecrowave.oauth2.Keystores.create(Keystores.java:49)
at 
org.apache.meecrowave.oauth2.OAuth2Test.createKeyStore(OAuth2Test.java:105)
{noformat}

> upgrde to java16 ready versions
> ---
>
> Key: MEECROWAVE-261
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-261
> Project: Meecrowave
>  Issue Type: Task
>Affects Versions: 1.2.9
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.2.12
>
>
> We've got some fixes in the chain which makes it possible to also run MW 
> under the upcoming Java16 release. This includes CXF, OpenWebBeans and 
> OpenJPA plus a few spec updates.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OWB-1078) create Dockerfiles for installing OpenWebBeans as Docker Image based on Tomcat8

[Mark Struberg (Jira)]

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

Mark Struberg updated OWB-1078:
---
Fix Version/s: (was: 2.0.22)
   2.0.23

> create Dockerfiles for installing OpenWebBeans as Docker Image based on 
> Tomcat8
> ---
>
> Key: OWB-1078
> URL: https://issues.apache.org/jira/browse/OWB-1078
> Project: OpenWebBeans
>  Issue Type: New Feature
>  Components: Samples  Documentation
>Affects Versions: 1.5.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.23
>
>
> create Dockerfiles for installing OpenWebBeans as Docker Image based on 
> Tomcat8



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OWB-1074) implement automatic supportsConversation() detection

[Mark Struberg (Jira)]

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

Mark Struberg updated OWB-1074:
---
Fix Version/s: (was: 2.0.22)
   2.0.23

> implement automatic supportsConversation() detection
> 
>
> Key: OWB-1074
> URL: https://issues.apache.org/jira/browse/OWB-1074
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Context and Scopes
>Affects Versions: 1.5.0
>Reporter: Mark Struberg
>Priority: Major
> Fix For: 2.0.23
>
>
> Currently we rely on the user to define the configuration option in 
> OpenWebBeansConfiguration
> {code}
> APPLICATION_SUPPORTS_CONVERSATION = 
> "org.apache.webbeans.application.supportsConversation";
> {code}
> This is by default disabled in owb-impl (core) and gets enabled by adding the 
> web or jsf plugins.
> We could improve this by not only allowing {{true}} or {{false}} but also 
> with an {{auto}} mode. 
> In this mode the BeanManager can walk through all registered beans and check 
> whether there is a single @ConversationScoped bean. In that case we will 
> automagically enable CDI conversations, otherwise OWB will dynamically 
> disable conversation support and don't need to do all kinds of work in 
> WebContextsService for example.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (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 updated OWB-1088:
---
Fix Version/s: (was: 2.0.22)
   2.0.23

> 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: 2.0.23
>
>
> some of our samples are currently broken under java 8



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OWB-1282) Reduce reflection usage for default services in WebBeansContext

[Mark Struberg (Jira)]

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

Mark Struberg updated OWB-1282:
---
Fix Version/s: (was: 2.0.22)
   2.0.23

> Reduce reflection usage for default services in WebBeansContext
> ---
>
> Key: OWB-1282
> URL: https://issues.apache.org/jira/browse/OWB-1282
> Project: OpenWebBeans
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.23
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (OWB-1375) improve support for Java 9++ hacks

[Mark Struberg (Jira)]

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

Mark Struberg resolved OWB-1375.

Resolution: Fixed

> improve support for Java 9++ hacks
> --
>
> Key: OWB-1375
> URL: https://issues.apache.org/jira/browse/OWB-1375
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.0.21
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.22
>
>
> With Java > 11 sun.misc.Unsafe defineClass finally got removed and 
> setAccessible(true) for java.* classes is not allowed anymore.
> There is a solution via ClassLoaderProxyService as DefiningClassService (see 
> OWB-1325) but this has the downside that package scoped methods are not 
> accessible. A call to a package scope method of a NormalScope proxy thus 
> cannot see the method in the proxy class and thus coerces to the empty 
> original parent class. As this instance is not initialised all values are 
> empty, resulting in NPE and zero values etc.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OWB-1375) improve support for Java 9++ hacks

[Mark Struberg (Jira)]

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

Mark Struberg commented on OWB-1375:


There is so many subtle changes in different Java versions that I really found 
no good solution to work around it yet.
In e.g. Java14 a few subtle changes got made to MethodHandles privateAccess 
handling again.

So probably the most practical way is really to tell people to add an 
{{--add-exports java.base/jdk.internal.misc=ALL-UNNAMED}} as Romain already 
mentioned.

I'd go on and add this as an automatically activated profile. Wdyt?
{noformat}
  
+
+java16-hacks
+
+16
+
+
+
+
+org.apache.maven.plugins
+maven-surefire-plugin
+
+--add-exports 
java.base/jdk.internal.misc=ALL-UNNAMED
+
+
+
+
+
+
{noformat}

> improve support for Java 9++ hacks
> --
>
> Key: OWB-1375
> URL: https://issues.apache.org/jira/browse/OWB-1375
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.0.21
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.22
>
>
> With Java > 11 sun.misc.Unsafe defineClass finally got removed and 
> setAccessible(true) for java.* classes is not allowed anymore.
> There is a solution via ClassLoaderProxyService as DefiningClassService (see 
> OWB-1325) but this has the downside that package scoped methods are not 
> accessible. A call to a package scope method of a NormalScope proxy thus 
> cannot see the method in the proxy class and thus coerces to the empty 
> original parent class. As this instance is not initialised all values are 
> empty, resulting in NPE and zero values etc.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (OWB-1375) improve support for Java 9++ hacks

[Mark Struberg (Jira)]

Mark Struberg created OWB-1375:
--

 Summary: improve support for Java 9++ hacks
 Key: OWB-1375
 URL: https://issues.apache.org/jira/browse/OWB-1375
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0.21
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 2.0.22


With Java > 11 sun.misc.Unsafe defineClass finally got removed and 
setAccessible(true) for java.* classes is not allowed anymore.

There is a solution via ClassLoaderProxyService as DefiningClassService (see 
OWB-1325) but this has the downside that package scoped methods are not 
accessible. A call to a package scope method of a NormalScope proxy thus cannot 
see the method in the proxy class and thus coerces to the empty original parent 
class. As this instance is not initialised all values are empty, resulting in 
NPE and zero values etc.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (OWB-1234) generic classes are not correctly proxied when bridge methods are involved

[Mark Struberg (Jira)]

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

Mark Struberg reassigned OWB-1234:
--

Assignee: Mark Struberg

> generic classes are not correctly proxied when bridge methods are involved
> --
>
> Key: OWB-1234
> URL: https://issues.apache.org/jira/browse/OWB-1234
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Interceptor and Decorators
>Affects Versions: 2.0.4
>Reporter: Alexander Zapletal
>Assignee: Mark Struberg
>Priority: Major
>
> Proxies generated by _NormalScopeProxyFactory_ do not contain (overriding) 
> proxy methods for bridge methods, because bridge methods are generally 
> ignored by the proxy generation, see 
> _AbstractProxyFactory.unproxyableMethod()_ and 
> _ClassUtil.addNonPrivateMethods()_ .
> (See also OWB-923)
> But this can lead to wrong proxies:
> {code:java}
> interface Contract {
>   void doIt(Integer param);
> }
> {code}
> {code:java}
> public class BaseBean {
>   public void doIt(T param) {
>   }
> }
> {code}
> {code:java}
> @ApplicationScoped
> public class MyBean extends BaseBean implements Contract { 
> }
> {code}
> When compiling this code the compiler performs type erasure and needs to 
> generate a bridge method. The generated byte code corresponds (roughly) to 
> the following code:
> {code:java}
> public class BaseBean {
>   public void doIt(Number param) {
>   }
> }
> {code}
> {code:java}
> public class MyBean {
>   // bridge method!
>   public void doIt(Integer param) {
>   super.doIt(param);
>   }
> }
> {code}
> _NormalScopeProxyFactory_ generates a proxy class that (roughly) corresponds 
> to the following code:
> {code:java}
> public class MyBean$$OwbNormalScopeProxy extends MyBean {
>   
>   public void doIt(Number var1) {
> ((MyBean)this.owbContextualInstanceProvider.get()).doIt(var1);
>   }
> }
> {code}
> But when we now call, for instance, _doIt(4711)_ on an injected instance of 
> _Contract_ , we actually call _MyBean.doIt(Integer)_ and thereby we bypass 
> the proxy!
> {code:java}
>   @Inject Contract handler;
>   handler.doIt(4711) 
> {code}
> Reason: When _NormalScopeProxyFactory_ generated the proxy for _MyBean,_ it 
> found the following two methods (amongst others):
> {code:java}
> void doIt(Number var1)  // inherited from BaseBean
> void doIt(Integer var1) // bridge method
> {code}
> Since _NormalScopeProxyFactory_ ignores bridge methods, it only generated a 
> proxy method for _doIt(Number)_ . This method *overloads* 
> _MyBean.doIt(Integer)_ , it does not *override* it. So, _handler.doIt(4711)_ 
> actually calls _MyBean.doIt(Integer)_ .
>  
> *IMPORTANT NOTE:* There is a quite simple workaround for this problem: Just 
> implement the bridge method yourself. I.e. in the example above use the 
> following implementation
> {code:java}
> @ApplicationScoped
> public class MyBean extends BaseBean implements Contract { 
>   @Override
>   public void doIt(Integer param) {
> super.doIt(param);
>   }
> }
> {code}
> Now, the method _doIt(Integer)_ is not a bridge method anymore and 
> _NormalScopeProxyFactory_ will generate a proxy method for it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (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 reassigned OWB-1368:
--

Assignee: Mark Struberg

> 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
>
> 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.3.4#803005)

[jira] [Resolved] (OWB-1374) Container Lifecycle events right now only work during startup

[Mark Struberg (Jira)]

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

Mark Struberg resolved OWB-1374.

Resolution: Fixed

> Container Lifecycle events right now only work during startup
> -
>
> Key: OWB-1374
> URL: https://issues.apache.org/jira/browse/OWB-1374
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.21
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.22
>
>
> Some events like e.g. {{ProcessInjectionPoint}} will not only be fired during 
> the startup phase but also at runtime. This happens e.g. via 
> {{BeanManager#createInjectionTarget}}.
> Those later events do not work right now.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (OWB-1374) Container Lifecycle events right now only work during startup

[Mark Struberg (Jira)]

Mark Struberg created OWB-1374:
--

 Summary: Container Lifecycle events right now only work during 
startup
 Key: OWB-1374
 URL: https://issues.apache.org/jira/browse/OWB-1374
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.21
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 2.0.22


Some events like e.g. {{ProcessInjectionPoint}} will not only be fired during 
the startup phase but also at runtime. This happens e.g. via 
{{BeanManager#createInjectionTarget}}.

Those later events do not work right now.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (OWB-1367) Bad filter url-pattern in demos

[Mark Struberg (Jira)]

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

Mark Struberg resolved OWB-1367.

Fix Version/s: 2.0.22
 Assignee: Mark Struberg
   Resolution: Fixed

Greg, txs for the report!

> Bad filter url-pattern in demos
> ---
>
> Key: OWB-1367
> URL: https://issues.apache.org/jira/browse/OWB-1367
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Samples  Documentation
>Reporter: Greg Wilkins
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 2.0.22
>
>
> There is a * in:
>  * 
> [https://github.com/apache/openwebbeans/blob/master/webbeans-tomcat7/src/main/resources/META-INF/web-fragment.xml#L33]
>  * 
> [https://github.com/apache/openwebbeans/blob/master/webbeans-jetty9/src/main/resources/META-INF/web-fragment.xml#L33]
> The pattern '*' is not a legal url-pattern by 
> [https://jakarta.ee/specifications/servlet/5.0/jakarta-servlet-spec-5.0.html#specification-of-mappings]
> Current jetty releases incorrectly accept '*' as a mapping, treating it like 
> a suffix mapping with an empty suffix.   I assume that tomcat must also 
> accept it.
> Future versions of jetty will not accept it and the next version of jetty 
> will accept it only with a warning.
> It should be "/*"
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (OWB-1371) review getCurrentContext to automatically create Contexts

[Mark Struberg (Jira)]

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

Mark Struberg resolved OWB-1371.

Fix Version/s: 2.0.22
   Resolution: Fixed

> review getCurrentContext to automatically create Contexts
> -
>
> Key: OWB-1371
> URL: https://issues.apache.org/jira/browse/OWB-1371
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Context and Scopes
>Affects Versions: 2.0.21
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.22
>
>
> Right now {{ContextsService#getCurrentContext}} creates e.g an active 
> RequestContext if it did not exist before. That might be handy sometimes but 
> also might lead to mem leaks. It should imo rather be an explicit step to 
> activate those Contexts.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (OWB-1373) EventImpl does not resolve Observers properly when running with ParentBM setup

[Mark Struberg (Jira)]

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

Mark Struberg resolved OWB-1373.

Resolution: Fixed

> EventImpl does not resolve Observers properly when running with ParentBM setup
> --
>
> Key: OWB-1373
> URL: https://issues.apache.org/jira/browse/OWB-1373
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Events
>Affects Versions: 2.0.21
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.22
>
>
> EventImpl now caches the resolved ObserverMethods. That's great. But it now 
> uses the NotificationManager directly to resolve those. This works perfectly 
> fine in most standard scenarios. But it does not notify Observers from the 
> Parent BeanManager in an EAR setup because the NotificationManager only 
> handles the 'local' Observers in the WAR.
> The obvious solution is to use {{BeanManager#resolveObserverMethods}} instead.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)