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

[Romain Manni-Bucau (Jira)]

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

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

[~arne] cxf just released 4.0.4, if it does not work we should clearly request 
them to fix it since there are solution for the dropped API. +1 to not fork now

> 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] [Commented] (MEECROWAVE-337) Migrate javax to jakarta

[Romain Manni-Bucau (Jira)]

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

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

Sure, while needed no issue but no reordering for ex. Idea is in the diff only 
required changes when possible...after we are not PR extremists ;).

> 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] [Commented] (MEECROWAVE-337) Migrate javax to jakarta

[Romain Manni-Bucau (Jira)]

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

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

[~shaikezam] we move to the min of cxf/owb for java version, yes. No strong 
guidelines, idea is to limit the changes to the minimum, avoid wildcard imports 
or full style refactoring and ensure tests still pass and add tests if you add 
something new. Nothing crazy normally.

> 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] [Commented] (MEECROWAVE-337) Migrate javax to jakarta

[Romain Manni-Bucau (Jira)]

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

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

[~rzo1] this is the kind of thing I was thinking about, we can just override 
`public void injectBus` and restore an override of the extension (just needs to 
register an openwebbeans loaderservice filtering cxf extension and replacing it 
by ours which is disabled if cxf is not in the cp, nothing crazy IMHO if there 
is some will to do it early).

> 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] [Commented] (MEECROWAVE-337) Migrate javax to jakarta

[Romain Manni-Bucau (Jira)]

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

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

[~rzo1] which issue ? We worked around multiple times cxf limitations so can be 
done yet another time depending what it is.

> 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] [Commented] (MEECROWAVE-337) Migrate javax to jakarta

[Romain Manni-Bucau (Jira)]

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

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

Hi [~shaikezam] ,
 # I guess we upgrade transitive deps in project forcing the versions so we 
don't release meecrowave that often but there is no real blocker to do it
 # We had the jakarta bundle 
([https://repo1.maven.org/maven2/org/apache/meecrowave/meecrowave-core/1.2.15/meecrowave-core-1.2.15-jakarta.jar)]
 which was covering it until the full stack migrates to jakarta, now 
openwebbeans, tomcat and cxf migrated and some years passed we can likely do it
 # probably check 1. which enables to be CVE free with last release

feel free to do a PR to work on 2 if you are interested?

> 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] [Commented] (OWB-1438) Synthetic InjectionPoint for CDI.current() and similar usages

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1438:
-

-1, this goes against the spec (see CDI/Instance doc) plus it keeps the same 
exact bug with a producer using getMember or getAnnotated so no good reason to 
pollute our code IMHO until you find a way to fix other methods.

> 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
>Priority: Major
> 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] [Commented] (OWB-1434) upgrade various dependencies to more recent versions

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1434:
-

We should list the impacting one explicitly (others are not very important for 
end user) to ensure it surfaces in release notes otherwise this kind of ticket 
is pretty useless for everybody - as dependabot commits.

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

Re: rolling a release

[Romain Manni-Bucau]

+1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 29 janv. 2024 à 09:00, Thomas Andraschko <
andraschko.tho...@gmail.com> a écrit :

> +1
>
> Am Mo., 29. Jan. 2024 um 08:17 Uhr schrieb Mark Struberg
> :
>
> > hi folks!
> >
> > FYI, I gonna trigger a release now.
> >
> > LieGrue,
> > strub
> >
> >
>

Re: [VOTE] Release Apache OpenWebBeans-4.0.1

[Romain Manni-Bucau]

+1

Le lun. 13 nov. 2023 à 07:16, Daniel Dias Dos Santos <
daniel.dias.analist...@gmail.com> a écrit :

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

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

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1429:
-

Hi, it needs  a new xbean-asm release, you can use a snapshot, build it 
yourself or ensure your bytecode uses java 17 (even if it runs on java21).

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

Re: [VOTE] Release Apache OpenWebBeans-4.0.0

[Romain Manni-Bucau]

Guess the main "blocker" will be to await for johnzon 2.0.0 release ot
switch to a native jakarta stack.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 14 sept. 2023 à 16:31, Arne Limburg 
a écrit :

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

Re: [VOTE] Release Apache OpenWebBeans-4.0.0

[Romain Manni-Bucau]

+1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 5 sept. 2023 à 19:21, Daniel Dias Dos Santos <
daniel.dias.analist...@gmail.com> a écrit :

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

Re: Gonna release the OWB master

[Romain Manni-Bucau]

+1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 4 sept. 2023 à 13:42, Mark Struberg  a
écrit :

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

Re: Meecrowave Deps Update + Release?

[Romain Manni-Bucau]

Hi Richard,

Think h2 upgrade will need openjpa 3.2.2 upgrade (think we supported h2 v2
in 3.2.1 only).
Rest looks ok to me.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 7 juil. 2023 à 15:23, Richard Zowalla  a écrit :

> Hi,
>
> can someone take a look at [1] to get up 2 date dependencies into
> Meecrowave?
>
> I would love to see a version with updated deps soon? Any chance to
> have a minor release soon?
>
> Thanks & Gruß
> Richard
>
>
>
> [1] https://github.com/apache/openwebbeans-meecrowave/pull/20
>

Re: CDI TCK: Lifecycle container events

[Romain Manni-Bucau]

My main concern is to not break existing applications or at least not in a
way forcing them to be rewritten.
The default discovery got a toggle cause we can't do magic, for events it
is about ensuring if you got 3 events because inheritance was taken into
account, it should still be there (a bit like fastmatching toggle
probably?), for specialization I geuss spec is unclear cause there is no
specialization before events cause you can veto or change annotations.

So if it is the only issues no need of a module but maybe a new toggle and
challenge?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 28 févr. 2023 à 00:06, Jean-Louis Monteiro 
a écrit :

> Hello guys,
>
> We have 3 issues I identified with lifecycle events in OWB.
>
> 1/ lifecycle container events order: we trigger the PBA in the first place.
> The spec is very clear with the order and PBA should come after PIP, PIT
> and before PB or POM
>
> I am aware of the specialization and the veto problematics. See 2/
> I don't see other options than moving the PBA event to the right place. The
> spec phrasing, unless I missed something, is quite clear.
>
>
> https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#initialization_full
> and
>
> https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#bean_discovery_steps_full
>
> 2/ "for each enabled bean"
>
> The spec says "for each enabled bean". I asked the mailing list, they
> mentioned it's when we process the beans. I'm planning to challenge
>
>
> org.jboss.cdi.tck.tests.full.extensions.lifecycle.processBeanAttributes.specialization.VetoTest
>
> But this is because after veto is called on PBA, the TCK expects
> that we re-evaluate the "for each enabled bean" and then fire PBA which
> became enabled because C was vetoed.
>
> There is nothing in the spec that mentions the order in which discovered
> beans have to be processed. And there is nothing that mentions that we need
> to reevaluate the beans after a PBA is a veto() is called on a PBA
>
> 3/ We have 3 beans
> C extends B extends A
> And we have 3 lifecycle observers
> public void a(@Observes ProcessBeanAttributes event) {}
> public void b(@Observes ProcessBeanAttributes event) {}
> public void c(@Observes ProcessBeanAttributes event) {}
> The notification order for observer methods within extensions follows the
> same ordering rule as defined in Observer ordering for non-extension
> observers.
>
>
> https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#observer_ordering
> To my understanding, lifecycle events ordering are similar to "plain"
> application events.
>
>
> https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#observer_resolution
> This part mentions container events such as lifecycle events.
>
> The TCK expects a(), b() and c() being invoked only once for the exact
> type. In OWB we notify a() 3 times, one for A, then B then C, we notify b()
> twice for B and C, and finally we notify c() for C.
>
> If we use A, B and C for an application observer libe
> @Dependent
> public static class ListObserver {
> public void alpha(@Observes List event) {
> System.out.println("A:" + event);
> }
> public void bravo(@Observes List event) {
> System.out.println("B:" + event);
> }
> public void charly(@Observes List event) {
> System.out.println("C:" + event);
> }
> }
> Looks like for application events, we do it the right way, but the spec
> seems to indicate lifecycle events are no different and we should treat
> them consistently.
>
> What do you think?
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

Re: [DISCUSS] CDI Compliance and breaking changes

[Romain Manni-Bucau]

Hi,

Think there are multiple points there and we should absolutely avoid a
compliance flag in owb-core/se modules until it is requires and we ack the
change.
For other changes (the one we dont want, we can just use our spi mecanism
and change the behavior in an owb-compliancy module maybe.

For me the points are:

* Did the spec broke something for good -> add a toggle
* Did the spec broke without reason -> need to check if intended, if so
compliancy module else ignore
* Is the spec clear about the impl it expects (for ex it is not for
container events) -> if yes then impl else discuss and if no compromise
then compliancy module

Side note: if the toggle is a one liner the compliancy module just enables
it in openwebbeans.properties, no need to split the impl in multiple parts
or add a SPI if simple.

Overall my fear right now is core become bloated because each version of
the spec adds what is already there but in a new package or way so I hope
we can keep a core light and be compliant in a module marked as "they did
it wrong but you can get it too".

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 27 févr. 2023 à 20:58, Jean-Louis Monteiro 
a écrit :

> Hello guys,
>
> I've been spending a couple of days trying to figure out what the spec says
> or does not. I also looked at the TCK tests we currently do not pass as
> well as what OWB/Weld do in both situations. I've also augmented the TCK
> tests to understand and test some other edge cases.
>
> *Important note*: I created a couple of challenges already and PRs to fix
> the spec/TCK and I'm happy to create more challenges. Mind that the process
> to create challenges is very well defined
> https://jakarta.ee/committees/specification/tckprocess/
>
> In essence, a challenge cannot be filed if we don't agree with the spec or
> if the spec is stupid, or else. We can only fill a challenge, if the TCK
> does not match something in the spec, if it's more restrictive, etc.
>
> << Good or bad, the spec is as it is now. The past/future does not matter
> >>
>
> I'm not sure about the history and if the spec evolved in the past and we
> did not follow, or if the spec introduced things we did not agree on and
> decided to not implement. As of now, we need changes if we want to ever be
> compliant.
>
> I'd like to discuss how to handle the breaking changes. I do think if we
> claim to implement CDI we must implement it all and correctly.
>
> I'm ok if we have a "compliance" flag if we don't want to break backward
> compatibility. But to me, it's a major version and jakarta namespace is
> already a huge backward compatibility issue. So for sure it's preferred we
> catch up with all breaking changes now and participate in the spec so we
> avoid future backward compatibility issues. If we don't do it now, of
> course it will be harder to do it later for our users and it means we'll
> never be able to claim compliance.
>
> It is obviously not a vote. But I think it's an important discussion.
> What do you think?
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

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

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1423:
-

[~Tsakumagos] guess you need to put a project on github reproducing the issue 
since this setup is known working. can come from something else.

> 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
>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-1423) openwebbeans-impl-jakarta is using old javax namespace

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1423:
-

Hi [~Tsakumagos] ,

 

Think you didn't use the jakarta stack but just one artifact leading to this 
error, either define the owb artifacts to use jakarta or reuse this dependency 
which already does it:

 

```

    io.yupiik.uship
    backbone-owb
    1.0.16
    pom


```

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

Re: [DISCUSS] Release OWB-4.0.0?

[Romain Manni-Bucau]

For reference:

> The TCKs will be compiled at the Java SE 11 level. In order to allow for
runtimes beyond Java SE 11, the TCK will also need to be (successfully)
executed with Java SE 17.

> How a Compatible Implementation supports the Java SE 11 runtime (or
above) will be left as a vendor-defined solution.

>
https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlanFAQ#why-require-java-se-17-for-tck-execution

Which means only java 17 is a requirement of the specs even if java 11 is
ok-ish. Have to admit this is a very weird writing and it looks like people
disagreed so everything was put in the specs to make everyone happy so the
spec does not cover the actual requirement.

However since spec jars are java 11 I think it is ok to relax the compiler
settings.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 9 févr. 2023 à 18:56, David Blevins  a
écrit :

> Both CDI 4.0 and the Jakarta EE Core/Webprofile/Platform specs all support
> Java 11 or higher in the spec and on the spec page.
>
>  - https://jakarta.ee/specifications/cdi/4.0/
>  - https://jakarta.ee/specifications/coreprofile/10/
>
>
> -David
>
> > On Feb 8, 2023, at 10:48 PM, Romain Manni-Bucau 
> wrote:
> >
> > Hi David,
> >
> > Guess 17 is a prerequisite of the spec so no real choice afaik until we
> > dont comply to the api.
> > For j11/cdi3 our previous shades do the job.
> >
> > Tck filters+jira links are in the testng xml config if it helps.
> >
> > Romain
> >
> > Le jeu. 9 févr. 2023 à 02:17, David Blevins  a
> > écrit :
> >
> >>
> >>
> >>> On Jan 30, 2023, at 5:40 AM, Mark Struberg 
> >> wrote:
> >>> * Some challenged tests, some unspecified behaviour in some tests. E.g.
> >> they assume a specified order class annotations before method
> annotations
> >> for Interceptors. But the spec *explicitly* says that for Interceptors
> with
> >> the same @Priority the order is unspecified.
> >>
> >> Do you have links to the challenges you filed and does it look like
> >> they’ll be accepted?
> >>
> >>
> >> -David
> >>
> >>
>
>

Re: [DISCUSS] Release OWB-4.0.0?

[Romain Manni-Bucau]

Hi David,

Guess 17 is a prerequisite of the spec so no real choice afaik until we
dont comply to the api.
For j11/cdi3 our previous shades do the job.

Tck filters+jira links are in the testng xml config if it helps.

Romain

Le jeu. 9 févr. 2023 à 02:17, David Blevins  a
écrit :

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

Re: [DISCUSS] Release OWB-4.0.0?

[Romain Manni-Bucau]

Le mar. 31 janv. 2023 à 09:31, Mark Struberg  a
écrit :

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

Please don't mix things up Mark:

1. You don't want to impl it -> once again it is more than fine, no issue,
2. OWB targets CDI standalone and servlet, nothing more but unfortunately
CDI lite is part of any CDI scope so we have to cover it, no SPI needed (it
is mainly a CDI extension) but must be supported OOTB to be a final release,
3. Nothing is blocked once again, doing an pre-release does not block
anything, just reflect the status of the project.

If we want to do a final which does not target CDI (current main) we have
to:

1. change the project scope and communicate about it
2. find a way to create our own API without ambiguity on jakarta one
3. find a way to validate applications at build time

3 can be a maven plugin to start, 1 is a matter of doing the homework and
waiting ~2months, 2 is almost impossible and failed each time it got tried
(our resource module, quarkus, ).
So I really think it would deserve the project to fake we are CDI 4 in our
releases.


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

Re: [DISCUSS] Release OWB-4.0.0?

[Romain Manni-Bucau]

Le lun. 30 janv. 2023 à 21:27, Mark Struberg  a
écrit :

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

But we implemented all api, here it is way more obvious it is wrong since
it is having CDI core dead api, nothing ambiguous as the bda so not the
same story at all IMHO.


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

Strictly speaking it was a stupid spec decision but it is not a mess.
Make it optional, yes, but not missing in a final release targetting this
spec version. Literally means project goal we write on each report would
either be totally wrong or we freeze the project to jakartaee 9.

Both are wrong IMHO on the community+project sides.


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

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

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1417:
-

For future readers: core minus lite part as of today.

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



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

Re: [DISCUSS] Release OWB-4.0.0?

[Romain Manni-Bucau]

Le lun. 30 janv. 2023 à 17:10, Mark Struberg  a
écrit :

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

We always went the spec side even if we add toggles to disable/enable
things, but ultimately we cover the full API.
Not providing any way to get it means we don't implement CDI anymore,
nothing else. Can be fine but should be promoted and we should also see
with TomEE what it means for them.
Holding a release is not a goal but doing a final which looks like it
covers the spec whereas it does not cover a third of it would be way more
negative for the project IMHO so let's not be the bad guys and just expose
explicitly our state with a pre-final whatever name fits for you.


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

Once again, no issue to not do it now, should just be a goal of 4.0.0.


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

Re: [DISCUSS] Release OWB-4.0.0?

[Romain Manni-Bucau]

* +1 to drop jetty plugin for now
* +-0 to shade cdi-api (nobody will consume it anyway)
* -1 to release to not milestone without being spec compliant - including
cdi-lite which is part of cdi-core (even if we all disagree), minimum for
me is to provide an openwebbeans-lite module implementing the cdi extension
making it supported, +1 to get a 4.0.0-alpha1 if it helps


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 30 janv. 2023 à 14:43, Thomas Andraschko <
andraschko.tho...@gmail.com> a écrit :

> all sounds good to me
>
> Am Mo., 30. Jan. 2023 um 14:41 Uhr schrieb Mark Struberg
> :
>
> > hi folks!
> >
> > We are up and running with passing most CDI-4.0 TCK tests.
> > There are a few areas where we have excluded some tests:
> >
> > * CDI-lite. I'll not gonna implement this in OWB as it is purely for
> > Quarkus and I don't care. It should be straight forward to implement the
> > functionality as  OWB plugin if someone really needs it though.
> > * Some challenged tests, some unspecified behaviour in some tests. E.g.
> > they assume a specified order class annotations before method annotations
> > for Interceptors. But the spec *explicitly* says that for Interceptors
> with
> > the same @Priority the order is unspecified.
> > * backward incompatible reversing the default bean-discovery-mode for
> > empty beans.xmls. I'll not gonna implement this as it also did break the
> > JakartaEE rules alltogether.
> >
> >
> > Things I want to change yet before the release:
> >
> > * Decide about the jetty9 plugin. Tbh I'd keep it excluded until someone
> > wants to contribute fixes to it.
> > * provide a shaded version of the CDI api jar without all the CDI-lite
> > parts.
> >
> >
> > Wdyt?
> >
> > LieGrue,
> > strub
> >
> >
> >
>

Re: some CDI-4.0 work

[Romain Manni-Bucau]

+1 to drop resource module, was a bad good idea i think

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 24 janv. 2023 à 15:45, Mark Struberg  a
écrit :

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

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

[Romain Manni-Bucau]

I'd keep master and create  a 2.x to not redo the tooling and break
consumers

Le mar. 24 janv. 2023 à 10:49, Mark Struberg  a
écrit :

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

Re: some CDI-4.0 work

[Romain Manni-Bucau]

s/trunk/master/ ;)

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 23 janv. 2023 à 10:43, Mark Struberg  a
écrit :

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

Re: some CDI-4.0 work

[Romain Manni-Bucau]

Hi,

We released everything so maybe move to our trunk branch to not redo
tooling setup.
Then we need to drop @New support and impl a runtime extension for light
support and release a 4.0.0?

Le dim. 22 janv. 2023 à 23:23, Mark Struberg  a
écrit :

> Hi!
>
> I've started with some work on implementing CDI-4.0.
>
> Not sure how we do with out build-tools, so did not yet commit anything to
> our repo.
> But a preview work can be seen here
> [image: openwebbeans.png]
>
> struberg/openwebbeans at fb_jakarta
> 
> github.com 
> 
>
> Trying to improve things in the next few days and then push it to our repo.
>
> Question is also whether we use this moment and move from master to trunk
> or main? What do you folks prefer?
>
> LieGrue,
> strub
>

Re: [VOTE] Release Apache Meecrowave-1.2.15

[Romain Manni-Bucau]

+1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 30 déc. 2022 à 06:30, Jean-Baptiste Onofré  a
écrit :

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

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

[Romain Manni-Bucau]

Ok,

just checked and seems we are good just upgrading the version this time
so +1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 21 déc. 2022 à 14:15, Mark Struberg  a
écrit :

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

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

[Romain Manni-Bucau]

Hi Mark,

Do you mean 4.0.0 ir 3.5.5?
Seems not done on master but we need to check deps  chnages before since we
must exclude most of them in general with cxf heterogeneous tree.

Romain



Le mar. 20 déc. 2022 à 21:10, Mark Struberg  a
écrit :

> I'd like to roll the release for a new Meecrowave version tomorrow with an
> updated CXF.
>
> You've got about 12h to stop me ;)
>
> txs and LieGrue,
> strub
>
>

Re: InjectionResolver query

[Romain Manni-Bucau]

Le mar. 8 nov. 2022 à 22:18, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> On Tue, Nov 8, 2022 at 6:56 PM Romain Manni-Bucau 
> wrote:
>
> > Indeed we can always add a pluggable (by config) cache but how many cases
> > does it cover?
> >
>
> To be fair, OWB is pretty friendly in terms of being pluggable. If the 2
> hash maps in InjectionResolver had protected access rather than private,
> I'd just tweak the extended class in TomEE and be done. If that's something
> that could be considered, that would be very much appreciated.
>

Nothing strong against but two notes:

1. TomEE can already handle that - same tech solution than the webapp bean
manager
2. I'd like OWB and TomEE to keep a consistent behavior at runtime if
possible so not sure it is that good

Did you think about a "debug" - word is bad - mode where this kind of
lookup would be detected and logged as a warning?
Can enable end users to detect it and potentially fix it


>
>
> > From what I saw it always hides another issue - in the ActionServlet the
> > other issue is the usage of CDI.current() for ex which is itself a
> hotspot
> > and not defined in the sample case (ear).
> > So is it worth? Not 100% sure.
> >
>
> Using CDI.current() in a servlet specifically perhaps feels a bit wild, and
> I've just done it as an illustration. You could imagine something like a
> tag library calling out to a common jar that does CDI.current() though, and
> the effect would be the same as the example I've provided. I'm not sure
> that programmatically looking up a bean in an application is contentious.


current will go through a SPI which is an issue by itself and then the
lookup goes through at least 2 levels you never need more than once so it
should really be a computeIfAbsent for the bean resolution in any lib.


>
>
> >
> > Anyway if there is a real will to have a configurable cache there, it
> must
> > ensure to not cache anything in the resolution (startup) phase nor cache
> > anything from an app scoped @Inject constructor or postconstruct callback
> > for ex - ie dont pollute the app with workaround meta when code is well
> > done.
> >
>
> Agreed. I'm specifically *not* proposing changing anything in the startup
> phase. In addition to that, I did suggest keeping the existing
> functionality as the default, and only caching the empty set if a flag is
> set. If I change this on the TomEE side, that's the approach I'd take there
> too.
>

Sounds wise.


>
>
> > It is doable but just want to highlight we should probably avoid a quick
> > and dirty workaround in the main codebase.
> >
> > That said I like the proposal for the JSF case, sounds like being better
> > than what we have currently + we know we are in the ELResolver so we can
> > clearly be more clever there anyway IMHO.
> >
>
> I'm not fully sure what you're suggesting here, or if its different to what
> I'm suggesting.
>

Just saying that you spotted an inconsistency - and likely something missed
- with name based resolution we could enhance to keep the JSF boost but
align the other cases on the type based resolution.
Maybe just an issue to open ;).


>
> We are in a position where EAR applications performed well on older
> versions of TomEE now really struggle performance-wise because the type
> resolution failure isn't cached any more. While I understand your view of
> fixing the app, I'd like to be able to offer the "old" functionality -
> whether that's through a change in OWB or TomEE.
>

Maybe let's catch when it got changed but AFAIK all the changes are startup
related so maybe an actual regression even if current behavior does not
shock me more than that.


Side note: it is quite trivial to fix adding a CDI decorator normally -
using a container extension or app extension, can be easier than patching
the container itself and enable to get the app related config injected
instead of relying on container config - it is sometimes easier to deploy
depending the env.

@Decorator @Priority(...)
public abstract class BeanManagerDecorator implements BeanManager,
Serializable {

@Inject
@Delegate
BeanManager beanManager;

// override getBeans/resolve/whatever you need to get cache ;)
}



>
> Jon
>
>
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-perfo

Re: InjectionResolver query

[Romain Manni-Bucau]

Indeed we can always add a pluggable (by config) cache but how many cases
does it cover?
>From what I saw it always hides another issue - in the ActionServlet the
other issue is the usage of CDI.current() for ex which is itself a hotspot
and not defined in the sample case (ear).
So is it worth? Not 100% sure.

Anyway if there is a real will to have a configurable cache there, it must
ensure to not cache anything in the resolution (startup) phase nor cache
anything from an app scoped @Inject constructor or postconstruct callback
for ex - ie dont pollute the app with workaround meta when code is well
done.
It is doable but just want to highlight we should probably avoid a quick
and dirty workaround in the main codebase.

That said I like the proposal for the JSF case, sounds like being better
than what we have currently + we know we are in the ELResolver so we can
clearly be more clever there anyway IMHO.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 8 nov. 2022 à 19:19, David Blevins  a
écrit :

> > On Nov 8, 2022, at 7:50 AM, Romain Manni-Bucau 
> wrote:
> >
> > Hi Jon,
> >
> > It is intended to not cache the missed hits since they shouldn't occur at
> > runtime and would open the door to OOME issues.
> > I looked at your sample, there is indeed a bug in ActionServlet#process
> > which should do that resolution in init().
> >
> > From my XP frameworks using that kind of resolution cache it themselves
> > (JSF for ex) if relevant or don't cache it cause it is not a big perf
> issue
> > (could be for jbatch) else it looks like bugs.
>
> My experience is a bit different.  Systems like DNS will cache both hits
> and misses.  There's an entire RFC dedicated to caching misses
> specifically: https://www.rfc-editor.org/rfc/rfc2308
>
> Yes, it can result in OOME issues, but some users may prefer that issue to
> the performance issue.
>
> A reasonable way to implement this could be to count the misses we've
> cached and if the number exceeds a certain threshold we could do any of the
> following:
>
>  - stop caching misses
>  - log warnings
>  - purge old cache misses
>
> There could be a flag to control the desired behavior with the default to
> be the current strategy no caching of misses.
>
>
> -David
>
>
>
>

Re: InjectionResolver query

[Romain Manni-Bucau]

Le mar. 8 nov. 2022 à 17:26, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> Thanks for the reply. Its possibly a tangent, but if the intention is to
> not cache misses, I'm curious as to why misses are cached when resolving by
> name:
>
>
> https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/container/InjectionResolver.java#L395


100% JSF case (even if you are right it is not the case on an strict API
standpoint but name is not intended to be much used in all other libs)
due to the ELResolver nature and impls out there it would be too slow
otherwise and keyset is quite closed compared to potential types (no issue
with equals/hashcode there ;)) AFAIK.


>
>
> ActionServlet#process is obviously not a great example - I could
> just @Inject into a field, or cache the lookup, as you say. I can't however
> do that in, say, a 3rd party library that I don't control.
>

yes and no, normally from a spec standpoint you can decorate the bean
manager so you can handle the resolution for the lib transparently for the
lib - if it is for TomEE and not a customer/3rd party I would still
encourage to fix the upstream if possible.


>
> Anyway, thank you for the feedback, and the quick responses. It sounds like
> there's no appetite for either change I've suggested in OWB, and that we
> should handle this elsewhere if we need it.
>
> Thanks
>
> Jon
>
> On Tue, Nov 8, 2022 at 3:51 PM Romain Manni-Bucau 
> wrote:
>
> > Hi Jon,
> >
> > It is intended to not cache the missed hits since they shouldn't occur at
> > runtime and would open the door to OOME issues.
> > I looked at your sample, there is indeed a bug in ActionServlet#process
> > which should do that resolution in init().
> >
> > From my XP frameworks using that kind of resolution cache it themselves
> > (JSF for ex) if relevant or don't cache it cause it is not a big perf
> issue
> > (could be for jbatch) else it looks like bugs.
> >
> > Hope it helps
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mar. 8 nov. 2022 à 15:36, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> a écrit :
> >
> > > Thanks for the reply, Romain!
> > >
> > > There's a couple of points on this one. Firstly, it's not startup
> > behaviour
> > > that's an issue in this specific case, it's actually resolution at
> > runtime.
> > > In effect, because the child InjectionResolver cannot resolve the bean,
> > and
> > > never caches that fact, it tries to work through the beans available
> each
> > > and every time an attempt is made to resolve the bean. Only once that
> has
> > > happened, do we delegate to the parent InjectionResolver (which does
> have
> > > the bean cached).
> > >
> > > On the TomEE-side, WebappInjectionResolver is a very thin extension of
> > > InjectionResolver, and it hasn't changed in 7 years:
> > >
> > >
> >
> https://github.com/apache/tomee/blob/tomee-8.x/container/openejb-core/src/main/java/org/apache/openejb/cdi/WebAppInjectionResolver.java
> > > .
> > > If there's a specific change you think might be useful, I'm happy to
> give
> > > it a go. We could, theoretically, do the caching in
> > > WebappInjectionResolver, although I'm hesitant to double the number of
> > > HashMaps we're keeping around for caching these resolutions. Making
> > > InjectionResolver.resolvedBeansByType (and maybe
> > > InjectionResolver.resolvedBeansByName) protected rather than private
> > could
> > > offer an easy way for anyone consuming OpenWebBeans to extend its
> > behaviour
> > > in this regard. We could then add any settings, etc on the TomEE side
> and
> > > just use the existing caching hash maps - for example we could check
> the
> > > cache of both the child and the parent InjectionResolvers before doing
> > > anything else.
> > >
> > > I did put together a sample project to demonstrate what I'm seeing:
> > > https://github.com/jgallimore/cdi-resolve-type-perf.
> > >
> > > It can be built with:
> > >
> > > mvn clean install
> > >
> &g

Re: InjectionResolver query

[Romain Manni-Bucau]

Hi Jon,

It is intended to not cache the missed hits since they shouldn't occur at
runtime and would open the door to OOME issues.
I looked at your sample, there is indeed a bug in ActionServlet#process
which should do that resolution in init().

>From my XP frameworks using that kind of resolution cache it themselves
(JSF for ex) if relevant or don't cache it cause it is not a big perf issue
(could be for jbatch) else it looks like bugs.

Hope it helps

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 8 nov. 2022 à 15:36, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> Thanks for the reply, Romain!
>
> There's a couple of points on this one. Firstly, it's not startup behaviour
> that's an issue in this specific case, it's actually resolution at runtime.
> In effect, because the child InjectionResolver cannot resolve the bean, and
> never caches that fact, it tries to work through the beans available each
> and every time an attempt is made to resolve the bean. Only once that has
> happened, do we delegate to the parent InjectionResolver (which does have
> the bean cached).
>
> On the TomEE-side, WebappInjectionResolver is a very thin extension of
> InjectionResolver, and it hasn't changed in 7 years:
>
> https://github.com/apache/tomee/blob/tomee-8.x/container/openejb-core/src/main/java/org/apache/openejb/cdi/WebAppInjectionResolver.java
> .
> If there's a specific change you think might be useful, I'm happy to give
> it a go. We could, theoretically, do the caching in
> WebappInjectionResolver, although I'm hesitant to double the number of
> HashMaps we're keeping around for caching these resolutions. Making
> InjectionResolver.resolvedBeansByType (and maybe
> InjectionResolver.resolvedBeansByName) protected rather than private could
> offer an easy way for anyone consuming OpenWebBeans to extend its behaviour
> in this regard. We could then add any settings, etc on the TomEE side and
> just use the existing caching hash maps - for example we could check the
> cache of both the child and the parent InjectionResolvers before doing
> anything else.
>
> I did put together a sample project to demonstrate what I'm seeing:
> https://github.com/jgallimore/cdi-resolve-type-perf.
>
> It can be built with:
>
> mvn clean install
>
> TomEE run with:
>
> cd hello-perf-test
> mvn tomee:run
>
> And the performance test run with:
>
> cd hello-perf-test
> ./grinder.sh
>
> In essence, the servlet is looking up a CDI bean each time, and always gets
> the InjectionResolver for the web archive. I've deliberately created a
> large number of classes (1) for this to work through in a big jar that
> sits in WEB-INF/lib. The actual bean I want to resolve is in the EJB module
> in the EAR, and is picked up when trying to resolve it from the war file
> fails. Running a performance test on this runs at around 1500 transactions
> per second (*). Allowing the InjectionResolver to cache
> Collections.EMPTY_SET when a type isn't resolved - e.g.:
>
>  if (!startup)
> {
> if (resolvedComponents == null || resolvedComponents.size() ==
> 0)
> {
> resolvedBeansByType.put(cacheKey, Collections.EMPTY_SET);
> }
> else
> {
> resolvedBeansByType.put(cacheKey, resolvedComponents);
> }
>
> if (logger.isLoggable(Level.FINE))
> {
> logger.log(Level.FINE, "DEBUG_ADD_BYTYPE_CACHE_BEANS",
> cacheKey);
> }
> }
>
> this goes up to around 65000 transactions per second (*), so the impact is
> definitely felt.
>
> * WSL2 Ubuntu/Windows 11 on i7-12700H 2.30 GHz, 32GB RAM
>
> Thanks
>
> Jon
>
> On Thu, Nov 3, 2022 at 4:50 PM Romain Manni-Bucau 
> wrote:
>
> > Hi Jon,
> >
> > The fix Thomas did is accurate and needed so think we should be fine like
> > that but I also agree the "pre-fix" implementation of TomEE never caught
> up
> > this change.
> > I guess the fix is to ensure the wrappers we have in TomEE also have this
> > kind of behavior but handling the cache for TomEE startup which is not
> > aligned on OWB startup for an EAR.
> >
> > Hope it makes sense.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau

Re: InjectionResolver query

[Romain Manni-Bucau]

Hi Jon,

The fix Thomas did is accurate and needed so think we should be fine like
that but I also agree the "pre-fix" implementation of TomEE never caught up
this change.
I guess the fix is to ensure the wrappers we have in TomEE also have this
kind of behavior but handling the cache for TomEE startup which is not
aligned on OWB startup for an EAR.

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 3 nov. 2022 à 17:07, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> Hey folks
>
> I've run into an interesting problem on the TomEE-side, running an EAR
> file. This seems to end up with 2 injection resolvers for the application:
> one for the web part of the application, and a parent for the EAR.
>
> When resolving by type at runtime, with large archives, we've seen a
> slowdown from previous versions of OpenWebBeans. This appears to be caused
> by the InjectionResolver.implResolveByType returning an empty set. TomEE
> will then try the parent resolver (successfully), but the result (empty
> set) in the child resolver is not cached, so it searches through the whole
> set of beans each time. The result used to be cached, prior to this commit:
>
> https://github.com/apache/openwebbeans/commit/a6d22d2abf6d6d5a02a14be1367daacca450359d
>
> Could caching the empty result in the InjectionResolver be re-introduced,
> albeit with a switch? (I'm happy for the default to be "don't cache").
> Interestingly, InjectionResolver.implResolveByName does cache the empty
> result. I'm happy to create a PR.
>
> Many thanks
>
> Jon
>

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

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1416:
-

What about doing a pr to fix it? If not too intrusive a toggle can be a good 
compromise no?

> 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] [Commented] (OWB-1416) Possible misintepretation of spec regarding Unproxyable bean types

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1416:
-

Maybe but this quote also does not bring any requirements (compared to other 
parts) so sounds like an useless sentence in current form, I agree.

Both options have pitfalls - not the same indeed ;) - so think our current 
state is likely the safer whereas relaxing it can be convenient in some cases 
it will break others so not sure it is worth the effort being said there are 
solution to handle the case you reference cleanly already, so quite mitigated 
for now.

> 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] [Commented] (OWB-1416) Possible misintepretation of spec regarding Unproxyable bean types

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1416:
-

Well yes and no, `getReference` is a good example of the previous point: "by 
any client proxy that is returned" so it must impl any bean type cause you 
don't know with which value it will be called - keep in mind it can be dynamic 
using reflection too - so to respect the spec (tck+pdf+javadoc) you must impl 
it as OWB did. Agree it can not be the most convenient but weld ecosystem is 
also know to not respect the spec everywhere (bypassing proxies for app scoped 
injections in some cases for ex - it is a good optimization by itself but which 
breaks other parts of the spec for ex) so not sure it is a good reference for 
this particular 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
>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] [Commented] (OWB-1416) Possible misintepretation of spec regarding Unproxyable bean types

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1416:
-

Hmm, for a managed bean (= plain class, not a producer) it is an issue since 
the proxy must be a subclass of the impl, not the typed so this must fail by 
spec AFAIK. I know weld worked it around but it is not 100% spec compliant 
IIRC. The solution would be to use a producer for the bean, this should work 
(use @Vetoed on the class and replace it by a producer which type it 
accordingly).

> 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] [Commented] (OWB-1416) Possible misintepretation of spec regarding Unproxyable bean types

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1416:
-

Hi, since spec requires subclassing, interface usage is not a solution until 
you use `@Typed` or hide the impl class I think.

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

Re: [DISCUSS] CDI-4.0 core

[Romain Manni-Bucau]

Hi David,

I guess SE section == SeContainer and not build time (= not runtime server
job by design ;)) so I assume the point is "an EE container does not need
SE bootstrap classes".
There is the same thing in JAXRS AFAIK.

That said the build time API has a challenge: it is not portable between
build and run phase so it can NOT be implemented by any container - without
repeating it is not needed at all technically, oops I did ;).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 13 oct. 2022 à 23:46, David Blevins  a
écrit :

> Thanks Romain and Mark for the insights.  Note, if something like this
> happens again, let me know.  When wearing the day-job hat we do get a vote
> on if specs should go final.
>
> In terms of Jakarta EE 10, it strangely looks like the Jakarta EE 10
> Platform spec is still using CDI 3.0 while the Jakarta EE 10 Core Profile
> uses CDI 4.0.  Not sure how we'll work that out on the TomEE side.
>
> The Core Profile spec says CDI lite is required:
>
> "Jakarta Contexts and Dependency Injection (CDI) 4.0 (CDI Lite
> section)"
>
>
> https://jakarta.ee/specifications/coreprofile/10/jakarta-coreprofile-spec-10.0.html#required_components
>
> Whereas the optional section says there are some classes that are not
> required:
>
> "The Java SE section of the CDI 4.0 specification is not required for
> Core Profile
> implementations. Only Full CDI implementations are required to support
> the (CDI)
> Java SE API classes."
>
>
> https://jakarta.ee/specifications/coreprofile/10/jakarta-coreprofile-spec-10.0.html#optional-components
>
> Do you have any insight as to what "Java SE" classes are excluded and if
> that eliminates the need to implement the APIs we don't like?
>
> Unrelated side note that annoys the heck out of me: the Spec Committee
> literally had a vote that no specs could have optional parts (I voted -1 on
> that) and then now I'm looking at an "Optional Components" section in the
> new Core Profile spec.  
>
>
> -David
>
>
> > On Oct 13, 2022, at 8:14 AM, Mark Struberg 
> wrote:
> >
> > To be very clear: imo the CDI-4.0 spec should never have been released
> that way. Sorry for the hard words.
> >
> > The whole part of the 'cdi-lite' is actually not a subpart of CDI but
> extends CDI with a (partly vendor specific) build time api. Which is also
> not really technically necessary imo. So far Helidon, Meecrowave,
> micronaut, etc managed to run on Graalvm quite fine without this api.
> >
> > Here is my PR which got rejected. It proves that there is no technical
> requirement to have all this crap in the same spec api jar!
> > https://github.com/jakartaee/cdi/pull/582 <
> https://github.com/jakartaee/cdi/pull/582>
> >
> >
> > My personal approach would be the following:
> > 1.) Enhance our geronimo-jcdi spec api to include the few new changes
> they made to BeanManager etc.
> >
> > 2.) Take the official cdi api (with the lite parts) and 'extract' those
> lite parts into an own jcdi-lite-api.jar
> >
> > 3.) provide a maven plugin and standard CDI Extension to handle the lite
> parts. This is perfectly doable!
> >
> > 4.) It is even possible to support the whole non-reflection features by
> using a dedicated ScannerService etc.
> >
> > That way almost no code change to OWB would be needed. Almost all of the
> changes could be done via an Extension. That way OWB would still remain
> quite small and not get as bloated as other implementations.
> >
> >
> > It's actually a shame that those changes got pushed so hard despite a
> lot of EG members heavily objecting with good arguments!
> >
> > LieGrue,
> > strub
> >
> >
> >
> >> Am 13.10.2022 um 08:25 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
> >>
> >> Hi David,
> >>
> >> It is not about perf but about the cdi "lite" part (build time spec).
> >> We explained why it was unecessary technically on cdi bugtracker and
> >> requested that at least it was excluded from cdi spec jar and considered
> >> another subspec since it is fully unrelated to CDI but it got rejected
> by a
> >> few pushing their vendor API to the spec.
> >>
> >> The idea is to not expose an API we'll not support I 

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

[Romain Manni-Bucau (Jira)]

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

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

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

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

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



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

Re: [DISCUSS] CDI-4.0 core

[Romain Manni-Bucau]

Hi David,

It is not about perf but about the cdi "lite" part (build time spec).
We explained why it was unecessary technically on cdi bugtracker and
requested that at least it was excluded from cdi spec jar and considered
another subspec since it is fully unrelated to CDI but it got rejected by a
few pushing their vendor API to the spec.

The idea is to not expose an API we'll not support I guess and bundle
properly the API.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 13 oct. 2022 à 02:47, David Blevins  a
écrit :

> > On Jun 2, 2022, at 12:03 PM, Mark Struberg 
> wrote:
> >
> > I had an idea about how we could implement CDI-4.0 without all the
> overhead it brings.
>
> Can you elaborate on the overhead you're concerned about? (not a challenge
> -- I'm not very familiar with the details yet)
>
>
> -David
>
>

Re: [DISCUSS] CDI-4.0 core

[Romain Manni-Bucau]

Well, about the scanning we already handle build time scanning thanks se
api (disableDiscovery + extension for explicit registration /
prescannedmetada service, this is what we use to be graal friendly).

About javax/jakarta: the whole point is to decoralate from the spec which
went in a bad escape lane and only expose supported api and not a set of
api we'll not impl + not fake implementing an api (@inject debate) if we
change the default behavior.

We can still fake the code at build time by monkey matching the spec type
to impl it semi-automatically thanks a build plugin if you find it more
relevant but think if we end up using jakarta spec this idea kind of end in
the status quo since end users will still consume the spec and rely on its
instability and verbosity.

Hope it makes sense.


Le mer. 12 oct. 2022 à 21:02, Arne Limburg 
a écrit :

> Hi Romain,
>
> I would love to elaborate that further. I would remove the scanning part
> in example (or make it pluggable). Then we could easily implement
> compile-time scanning or something like that.
> Maybe the core should start with a set of Beans and only do the runtime
> stuff.
> Setup could be done in different modules (cdi-1, cdi-2, cdi-lite, …)
>
> I like the overall idea also I hate that we would have to wrap Bean
> interface and friends in the CDI module. Maybe we find a better way to do
> that (i.e. extracting a cdi-minmal-api or so, but we still would have to
> decide between javax or jakarta namespace).
>
> Cheers,
> Arne
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limb...@openknowledge.de<mailto:arne.limb...@openknowledge.de>
> www.openknowledge.de<
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=9vRVYZVZ%2Feqk%2BvFxU5COofNvgs8U0AxtxRqwVEwqXHA%3D=0
> >
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
>
> Treffen Sie uns auf kommenden Konferenzen und Workshops:
> Zu unseren Events<
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fevent%2F=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=8tjmukdm1NxhXQMkn4VnESiBI216kXvh%2Fjb7%2FFYI0kE%3D=0
> >
>
> Von: Romain Manni-Bucau 
> Datum: Mittwoch, 12. Oktober 2022 um 18:11
> An: dev@openwebbeans.apache.org 
> Betreff: Re: [DISCUSS] CDI-4.0 core
> Hi Arne,
>
> What I'm looking for is basically be able to use most of CDI programming
> model (contexts, SE scanning, interceptors, ...) maybe not decorators - no
> strong opinion on them.
> The impl would use a default defining service which would be the
> classloader implementation to be any java version friendly without hacks
> and the preloaded flavor impl should be usable (optim or graal native-image
> case - SM case is no more relevant I guess since it will be dropped).
> We could also probably force to have a META-INF/beans.xml (or
> META-INF/owb.xml if we prefer) for the scanning to not get this broken
> implicit annotated mode CDI 2 introduced.
> In terms of extension I guess we can keep it - adding/mutating
> types/interceptors/... at runtime is key, but it would also be fine to go
> back on CDI 1.0 layer since new API are mainly duplicates or synthaxic
> sugar.
> Since it would be an impl I'm not sure we need the interface/impl split so
> we can save some class by just using a direct class (public class
> ProcessAnnotatedType for ex) if it makes sense.
>
> In terms of supported API set (jakarta.inject.Inject vs
> org.apache.openwebbeans.api.Inject for ex) I guess we would add a service
> in WBC to enable to read the set we want.
> Default would be o.a.owb one, cdi impl module would switch to
> o.a.owb+jakarta/javax ones - a bit like our resource service but more
> generic.
>
> In terms of impl, cdi module would mainly wrap the core objects and extend
> it in some locations, a bit like tomee does for OWB@EE.
>
>
> Romain Manni-Bucau
> @rmannibucau <
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Frmannibucaudata=05%7C01%7Carne.limburg%40openknowledge.de%7C7e1fdc465e22428ceea508daac6c6852%7C8486f66fc6f54811813685d3987d78e6%7C0%7C0%7C638011878848401406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=PQbRCzdzdQ8v2

Re: [DISCUSS] CDI-4.0 core

[Romain Manni-Bucau]

Hi Arne,

What I'm looking for is basically be able to use most of CDI programming
model (contexts, SE scanning, interceptors, ...) maybe not decorators - no
strong opinion on them.
The impl would use a default defining service which would be the
classloader implementation to be any java version friendly without hacks
and the preloaded flavor impl should be usable (optim or graal native-image
case - SM case is no more relevant I guess since it will be dropped).
We could also probably force to have a META-INF/beans.xml (or
META-INF/owb.xml if we prefer) for the scanning to not get this broken
implicit annotated mode CDI 2 introduced.
In terms of extension I guess we can keep it - adding/mutating
types/interceptors/... at runtime is key, but it would also be fine to go
back on CDI 1.0 layer since new API are mainly duplicates or synthaxic
sugar.
Since it would be an impl I'm not sure we need the interface/impl split so
we can save some class by just using a direct class (public class
ProcessAnnotatedType for ex) if it makes sense.

In terms of supported API set (jakarta.inject.Inject vs
org.apache.openwebbeans.api.Inject for ex) I guess we would add a service
in WBC to enable to read the set we want.
Default would be o.a.owb one, cdi impl module would switch to
o.a.owb+jakarta/javax ones - a bit like our resource service but more
generic.

In terms of impl, cdi module would mainly wrap the core objects and extend
it in some locations, a bit like tomee does for OWB@EE.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 12 oct. 2022 à 17:48, Arne Limburg 
a écrit :

> Hi,
>
> I know, I am late to the party.
> I actually like the idea of an own API and maybe adding CDI-(and/or
> CDI-lite) support on top of it.
> Romain, could you elaborate further, how this API should look like and
> what part of our current impl could be moved into it (and which parts
> should be moved somewhere else)?
>
> Cheers,
> Arne
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limb...@openknowledge.de<mailto:arne.limb...@openknowledge.de>
> www.openknowledge.de<
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2F=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=9vRVYZVZ%2Feqk%2BvFxU5COofNvgs8U0AxtxRqwVEwqXHA%3D=0
> >
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
>
> Treffen Sie uns auf kommenden Konferenzen und Workshops:
> Zu unseren Events<
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openknowledge.de%2Fevent%2F=04%7C01%7C%7C3004d8758be44c8678c008d93bcc1e23%7C48837bc476f9481d8a76bd7b60b43dec%7C0%7C0%7C637606570139932909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=8tjmukdm1NxhXQMkn4VnESiBI216kXvh%2Fjb7%2FFYI0kE%3D=0
> >
>
> Von: Romain Manni-Bucau 
> Datum: Freitag, 3. Juni 2022 um 13:47
> An: openwebbeans-dev 
> Betreff: Re: [DISCUSS] CDI-4.0 core
> Le ven. 3 juin 2022 à 13:34, Mark Struberg  a
> écrit :
>
> > The point is that most of the new API is really for that Quarkus use
> case.
> > And this can be done in a portable extension as well if one wants. So I
> see
> > zero reason to implement it. And also zero reason to have those api
> classes
> > in my classpath. The rest would be mostly for tomee to be able to go
> > forward.
> >
>
> Hmm, I don't see it this way:
>
> 1. This is not limited to quarkus case even if it got copied form there and
> if I fully agree the spec was wrongly done at technical level (not a single
> valid reason to do it this way but several to NOT do it)
> 2. We have a very valid reason to implement it: we are a CDI impl, if we
> start to not be spec compliant we don't have any value until we have our
> own API as explained (this is the main exit point for us to not respect the
> full spec IMHO)
> 3. About the classpath: agree, there is also a bug in last cdi release for
> jakarta 10 where it brings transitively build classes (no comment)
>
> This is why I think the topic is OWB API vs 100% spec one more than CDI vs
> CDI.custom which would be more misleading for most consumers IMHO.
>
>
> >
> > LieGrue,
> > strub
&g

Re: some build problems

[Romain Manni-Bucau]

Hi Mark,

guess it was just the copy of the jakarta tck setup versions, no issue to
downgrade if it still works for me.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 11 oct. 2022 à 09:13, Mark Struberg  a
écrit :

> hi folks!
>
> Seems we lost the ability to build with Java8.
> This is due to a recent upgrade of testng which requires Java16. Will
> switch back to the old version.
>
> I also figured that we have some weird download dependencies. Likely
> caused by some dependency activating a 3rd party repo?
>
> Downloading from jcenter:
> https://jcenter.bintray.com/org/codehaus/groovy/groovy-json/3.0.10/groovy-json-3.0.10.jar
> Downloading from jcenter:
> https://jcenter.bintray.com/org/codehaus/groovy/groovy-jsr223/3.0.10/groovy-jsr223-3.0.10.jar
> Downloading from jcenter:
> https://jcenter.bintray.com/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
> Downloading from jcenter:
> https://jcenter.bintray.com/org/junit/platform/junit-platform-launcher/1.8.2/junit-platform-launcher-1.8.2.jar
> Downloading from jcenter:
> https://jcenter.bintray.com/com/github/javaparser/javaparser-core/3.24.0/javaparser-core-3.24.0.jar
> Downloaded from jcenter:
> https://jcenter.bintray.com/org/codehaus/groovy/groovy-json/3.0.10/groovy-json-3.0.10.jar
> (133 kB at 148 kB/s)
> Downloading from jcenter:
> https://jcenter.bintray.com/org/junit/platform/junit-platform-engine/1.8.2/junit-platform-engine-1.8.2.jar
> Downloaded from jcenter:
> https://jcenter.bintray.com/org/junit/platform/junit-platform-launcher/1.8.2/junit-platform-launcher-1.8.2.jar
> (159 kB at 177 kB/s)
> Downloading from jcenter:
> https://jcenter.bintray.com/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
> Downloaded from jcenter:
> https://jcenter.bintray.com/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
> (194 kB at 205 kB/s)
> Downloading from jcenter:
> https://jcenter.bintray.com/org/junit/jupiter/junit-jupiter-engine/5.8.2/junit-jupiter-engine-5.8.2.jar
> Downloaded from jcenter:
> https://jcenter.bintray.com/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
> (100 kB at 73 kB/s)
> Downloading from jcenter:
> https://jcenter.bintray.com/org/codehaus/groovy/groovy-testng/3.0.10/groovy-testng-3.0.10.jar
> Downloaded from jcenter:
> https://jcenter.bintray.com/org/junit/platform/junit-platform-engine/1.8.2/junit-platform-engine-1.8.2.jar
> (186 kB at 120 kB/s)
> Downloading from jcenter:
> https://jcenter.bintray.com/org/testng/testng/7.5/testng-7.5.jar
> Downloaded from jcenter:
> https://jcenter.bintray.com/org/junit/jupiter/junit-jupiter-engine/5.8.2/junit-jupiter-engine-5.8.2.jar
> (230 kB at 144 kB/s)
> Downloading from jcenter:
> https://jcenter.bintray.com/org/webjars/jquery/3.5.1/jquery-3.5.1.jar
> Downloaded from jcenter:
> https://jcenter.bintray.com/org/codehaus/groovy/groovy-jsr223/3.0.10/groovy-jsr223-3.0.10.jar
> (21 kB at 13 kB/s)
> Downloaded from jcenter:
> https://jcenter.bintray.com/org/codehaus/groovy/groovy-testng/3.0.10/groovy-testng-3.0.10.jar
> (9.8 kB at 4.2 kB/s)
> Downloaded from jcenter:
> https://jcenter.bintray.com/org/webjars/jquery/3.5.1/jquery-3.5.1.jar
> (313 kB at 114 kB/s)
>
> Trying to check where this comes from.
>
> LieGrue,
> strub

[jira] [Resolved] (MEECROWAVE-321) Upgrade to Johnzon 1.2.19

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-321.
---
Resolution: Fixed

> Upgrade to Johnzon 1.2.19
> -
>
> Key: MEECROWAVE-321
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-321
> Project: Meecrowave
>  Issue Type: Task
>    Reporter: Romain Manni-Bucau
>    Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.15
>
>




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

[jira] [Resolved] (MEECROWAVE-322) Upgrade to OpenWebBeans 2.0.27

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-322.
---
Resolution: Fixed

> Upgrade to OpenWebBeans 2.0.27
> --
>
> Key: MEECROWAVE-322
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-322
> Project: Meecrowave
>  Issue Type: Task
>    Reporter: Romain Manni-Bucau
>    Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.15
>
>




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

[jira] [Created] (MEECROWAVE-321) Upgrade to Johnzon 1.2.19

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-321:
-

 Summary: Upgrade to Johnzon 1.2.19
 Key: MEECROWAVE-321
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-321
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.15






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

[jira] [Created] (MEECROWAVE-322) Upgrade to OpenWebBeans 2.0.27

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-322:
-

 Summary: Upgrade to OpenWebBeans 2.0.27
 Key: MEECROWAVE-322
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-322
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.15






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

Re: [DISCUSS] CDI-4.0 core

[Romain Manni-Bucau]

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

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

Hmm, I don't see it this way:

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

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


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

Re: [DISCUSS] CDI-4.0 core

[Romain Manni-Bucau]

Le jeu. 2 juin 2022 à 22:44, Mark Struberg  a
écrit :

> would imo introduce too many layers which might be hard to maintain in the
> long run. With the current plugin structure you can already run without
> even class scanning and dynamic bytecode tinkering if one wants.
> So don't think it's worth to add another layer of abstraction in the
> middle.
>

Thing is that currently you dont get most benefit, just tech extension
points to make the run work:

- you leverage jakarta/javax and their mess+breaking
changes+inconsistencies from v4
- you get more than needed in api
- you have constraints on beans you dont need

Your proposal is just the same but half baked since we are compatible or we
are not, this is why I think we should propose something really stable or
maybe just stick to impl the spec (modularly or not is a detail but tck
require both parts of the spec so passing only one is pointless for users
IMHO).



> LieGrue,
> strub
>
>
> > Am 02.06.2022 um 21:32 schrieb Romain Manni-Bucau  >:
> >
> > Hi,
> >
> > Some times ago I proposed to extract a cdi-like-light owb bundle which
> > would be a minimal IoC without the cdi 2.0 boilerplate and probably
> unsafe
> > free to be "all env friendly". This is very close to owb-se except a few
> > spi, defaults and jakarta dep.
> >
> > Making it cdi-se/ee as an impl sounds more valuable today for the project
> > IMHO - because we tend to go lightweight cause of the cloud move and
> > projects stacking too much are not that adopted - and is still compatible
> > with your idea so can be worth starting owb 3 from these basis with a
> light
> > owb IoC api/spi (TBD if we inherit from jakarta or not) and then back
> > owb-impl by this "owb-core" and finally impl your idea on this new api?
> >
> >
> >
> > Le jeu. 2 juin 2022 à 21:04, Mark Struberg  <mailto:strub...@yahoo.de.invalid>> a
> > écrit :
> >
> >> hi folks!
> >>
> >> I had an idea about how we could implement CDI-4.0 without all the
> >> overhead it brings.
> >> The goal is to keep OWB as light as possible but as compatible as
> possible.
> >>
> >> The idea is to use the standard eclipse jcdi package and split it in 2
> >> parts via maven-shade plugin or simple unzip/zip repackaging.
> >> This is necessary as JBoss refused to do it properly inside the spec
> >> itself but forced the full 'light' (which is actually adding 30% more
> code
> >> to the CDI api) on all users, regardless whether they need it or not.
> >>
> >> Here you can find more information about the background of the split and
> >> how it's done:
> >> https://github.com/jakartaee/cdi/pull/582 <
> >> https://github.com/jakartaee/cdi/pull/582 <
> https://github.com/jakartaee/cdi/pull/582>>
> >>
> >> I'd like to do the same, but for now just implement the clasic Jakarta
> EE
> >> part without the 'CDI lite' overhead.
> >> If we later find some time we can still implement CDI-lite as either an
> >> OWB plugin or even as a standard portable extension. This can be done
> here
> >> or as part of TomEE for example.
> >>
> >> I think we might be rather quick to get things going that way.
> >>
> >> Wdyt about that idea?
> >>
> >> LieGrue,
> >> strub
>
>

Re: [DISCUSS] CDI-4.0 core

[Romain Manni-Bucau]

Hi,

Some times ago I proposed to extract a cdi-like-light owb bundle which
would be a minimal IoC without the cdi 2.0 boilerplate and probably unsafe
free to be "all env friendly". This is very close to owb-se except a few
spi, defaults and jakarta dep.

Making it cdi-se/ee as an impl sounds more valuable today for the project
IMHO - because we tend to go lightweight cause of the cloud move and
projects stacking too much are not that adopted - and is still compatible
with your idea so can be worth starting owb 3 from these basis with a light
owb IoC api/spi (TBD if we inherit from jakarta or not) and then back
owb-impl by this "owb-core" and finally impl your idea on this new api?



Le jeu. 2 juin 2022 à 21:04, Mark Struberg  a
écrit :

> hi folks!
>
> I had an idea about how we could implement CDI-4.0 without all the
> overhead it brings.
> The goal is to keep OWB as light as possible but as compatible as possible.
>
> The idea is to use the standard eclipse jcdi package and split it in 2
> parts via maven-shade plugin or simple unzip/zip repackaging.
> This is necessary as JBoss refused to do it properly inside the spec
> itself but forced the full 'light' (which is actually adding 30% more code
> to the CDI api) on all users, regardless whether they need it or not.
>
> Here you can find more information about the background of the split and
> how it's done:
> https://github.com/jakartaee/cdi/pull/582 <
> https://github.com/jakartaee/cdi/pull/582>
>
> I'd like to do the same, but for now just implement the clasic Jakarta EE
> part without the 'CDI lite' overhead.
> If we later find some time we can still implement CDI-lite as either an
> OWB plugin or even as a standard portable extension. This can be done here
> or as part of TomEE for example.
>
> I think we might be rather quick to get things going that way.
>
> Wdyt about that idea?
>
> LieGrue,
> strub

Re: [VOTE] Apache OpenWebBeans 2.0.27

[Romain Manni-Bucau]

+1

Le mer. 25 mai 2022 à 02:36, Daniel Dias Dos Santos <
daniel.dias.analist...@gmail.com> a écrit :

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

Re: Tomcat 7.x EOL

[Romain Manni-Bucau]

Hi,

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

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 24 mai 2022 à 13:09, Jean-Louis Monteiro 
a écrit :

> Hi,
>
> I was doing some dependency updates on OpenWebBeans and wanted to do a
> release and I noticed we still have Tomcat 7.x in OWB.
>
> Shouldn't we try to move to the latest javax compatible version (aka 9.x)?
> Tomcat 7.x is EOL and has many CVEs.
>
> What do you think?
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

[jira] [Commented] (OWB-1404) Cannot build

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1404:
-

here 
https://repository.apache.org/content/repositories/snapshots/org/apache/openwebbeans/openwebbeans-distribution/2.0.27-SNAPSHOT/openwebbeans-distribution-2.0.27-20220513.102740-5-binary.zip

> Cannot build
> 
>
> Key: OWB-1404
> URL: https://issues.apache.org/jira/browse/OWB-1404
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: XML Configuration
>Affects Versions: 2.0.26
>Reporter: Hugo
>Priority: Major
>
> Cannot build.
> [ERROR] Plugin org.apache.maven.plugins:maven-remote-resources-plugin:1.5 or 
> one of its dependencies could not be resolved: Failed to read artifact 
> descriptor for 
> org.apache.maven.plugins:maven-remote-resources-plugin:jar:1.5: Could not 
> transfer artifact 
> org.apache.maven.plugins:maven-remote-resources-plugin:pom:1.5 from/to 
> central (http://repo.maven.apache.org/maven2): Failed to transfer file: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-remote-resources-plugin/1.5/maven-remote-resources-plugin-1.5.pom.
>  Return code is: 501 , ReasonPhrase:HTTPS Required. -> [Help 1]



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

[jira] [Comment Edited] (OWB-1404) Cannot build

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau edited comment on OWB-1404 at 5/13/22 6:38 AM:
--

Hi [~hugol] , not sure what's your issue is (tested with success mvn 3.6 and 
3.8+previous config) is but I deployed the snapshot at 
[https://repository.apache.org/content/repositories/snapshots]

 

FYI I fixed the http repository issue on master


was (Author: romain.manni-bucau):
Hi [~hugol] , not sure what's your issue is (tested with success mvn 3.6 and 
3.8+previous config) is but I deployed the snapshot at 
https://repository.apache.org/content/repositories/snapshots

> Cannot build
> 
>
> Key: OWB-1404
> URL: https://issues.apache.org/jira/browse/OWB-1404
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: XML Configuration
>Affects Versions: 2.0.26
>Reporter: Hugo
>Priority: Major
>
> Cannot build.
> [ERROR] Plugin org.apache.maven.plugins:maven-remote-resources-plugin:1.5 or 
> one of its dependencies could not be resolved: Failed to read artifact 
> descriptor for 
> org.apache.maven.plugins:maven-remote-resources-plugin:jar:1.5: Could not 
> transfer artifact 
> org.apache.maven.plugins:maven-remote-resources-plugin:pom:1.5 from/to 
> central (http://repo.maven.apache.org/maven2): Failed to transfer file: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-remote-resources-plugin/1.5/maven-remote-resources-plugin-1.5.pom.
>  Return code is: 501 , ReasonPhrase:HTTPS Required. -> [Help 1]



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

[jira] [Commented] (OWB-1404) Cannot build

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1404:
-

Hi [~hugol] , not sure what's your issue is (tested with success mvn 3.6 and 
3.8+previous config) is but I deployed the snapshot at 
https://repository.apache.org/content/repositories/snapshots

> Cannot build
> 
>
> Key: OWB-1404
> URL: https://issues.apache.org/jira/browse/OWB-1404
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: XML Configuration
>Affects Versions: 2.0.26
>Reporter: Hugo
>Priority: Major
>
> Cannot build.
> [ERROR] Plugin org.apache.maven.plugins:maven-remote-resources-plugin:1.5 or 
> one of its dependencies could not be resolved: Failed to read artifact 
> descriptor for 
> org.apache.maven.plugins:maven-remote-resources-plugin:jar:1.5: Could not 
> transfer artifact 
> org.apache.maven.plugins:maven-remote-resources-plugin:pom:1.5 from/to 
> central (http://repo.maven.apache.org/maven2): Failed to transfer file: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-remote-resources-plugin/1.5/maven-remote-resources-plugin-1.5.pom.
>  Return code is: 501 , ReasonPhrase:HTTPS Required. -> [Help 1]



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

[jira] [Commented] (OWB-1404) Cannot build

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1404:
-

[~hugol]  you need to enable http repositories in your .m2/settings.xml:

 
{code:java}


maven-default-http-blocker
external:dont-match-anything-mate:*
Pseudo repository to mirror external repositories initially 
using HTTP.
http://0.0.0.0/
false

 {code}
(we don't reference this repository directly, it is due to a transitive 
dependency so we can't help much, if you care about the related security  you 
can refine the whitelisted repo)

> Cannot build
> 
>
> Key: OWB-1404
> URL: https://issues.apache.org/jira/browse/OWB-1404
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: XML Configuration
>Affects Versions: 2.0.26
>Reporter: Hugo
>Priority: Major
>
> Cannot build.
> [ERROR] Plugin org.apache.maven.plugins:maven-remote-resources-plugin:1.5 or 
> one of its dependencies could not be resolved: Failed to read artifact 
> descriptor for 
> org.apache.maven.plugins:maven-remote-resources-plugin:jar:1.5: Could not 
> transfer artifact 
> org.apache.maven.plugins:maven-remote-resources-plugin:pom:1.5 from/to 
> central (http://repo.maven.apache.org/maven2): Failed to transfer file: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-remote-resources-plugin/1.5/maven-remote-resources-plugin-1.5.pom.
>  Return code is: 501 , ReasonPhrase:HTTPS Required. -> [Help 1]



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

[jira] [Commented] (OWB-1404) Cannot build

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1404:
-

[~hugol] did you use maven 3.3, 3.6, 3.8?

> Cannot build
> 
>
> Key: OWB-1404
> URL: https://issues.apache.org/jira/browse/OWB-1404
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: XML Configuration
>Affects Versions: 2.0.26
>Reporter: Hugo
>Priority: Major
>
> Cannot build.
> [ERROR] Plugin org.apache.maven.plugins:maven-remote-resources-plugin:1.5 or 
> one of its dependencies could not be resolved: Failed to read artifact 
> descriptor for 
> org.apache.maven.plugins:maven-remote-resources-plugin:jar:1.5: Could not 
> transfer artifact 
> org.apache.maven.plugins:maven-remote-resources-plugin:pom:1.5 from/to 
> central (http://repo.maven.apache.org/maven2): Failed to transfer file: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-remote-resources-plugin/1.5/maven-remote-resources-plugin-1.5.pom.
>  Return code is: 501 , ReasonPhrase:HTTPS Required. -> [Help 1]



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

[jira] [Commented] (OWB-1403) Observed frequent logs - Could NOT lazily initialize session context because NO active request context

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1403:
-

Hi [~rameshchatty] , I see, it could be worked around by disabling the session 
listener (overriding the methods with a no-op in WebBeansConfigurationListener) 
but I guess you can just configure TomEE to not log this warning, would be 
easier and since you don't use session/conversation scopes it will not hurt.  
Can also be worth to debug to check when the session context is created cause 
your description tend to mention it shouldn't enter into this block (go in 
WebContextService#getCurrentContext and check when SessionScoped.class is 
initialized). It can help to refine a better solution.

> Observed frequent logs - Could NOT lazily initialize session context because 
> NO active request context
> --
>
> Key: OWB-1403
> URL: https://issues.apache.org/jira/browse/OWB-1403
> Project: OpenWebBeans
>  Issue Type: Bug
>Reporter: Ramesh Chatty
>Priority: Major
>
> After upgrading TomEE version from  {*}8.0.6 -> 8.0.10{*}, frequently getting 
> warnings logged as below whenever  session timeout occurs:
>  
> {code:java}
> org.apache.webbeans.web.context.WebContextsService lazyStartSessionContext
> WARNING: Could NOT lazily initialize session context because NO active 
> request context
> {code}
>  
> I have noticed one change in the *WebContextsService >> 
> lazyStartSessionContext* method, where the parameter is sending as *false* 
> for *getRequestContext(false)* method in *openwebbeans-web-2.0.26.jar* with 
> in *TomEE-8.0.10* , where as this value is sent as *true* in 
> *openwebbeans-web-2.0.12.jar* with in *TomEE-8.0.6*
>  
> _Can you please suggest how to handle this scenario? Also are there any other 
> impact scenarios we may be missing due to this change?_



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

[jira] [Commented] (OWB-1403) Observed frequent logs - Could NOT lazily initialize session context because NO active request context

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau commented on OWB-1403:
-

Hi,

It is due to the fact we don't create request context upfront as before 
([https://github.com/apache/openwebbeans/commit/91edc6f3fda6f7b8d65102e9200e331eb1491ceb)]
 so depending your threading model, you can end up not having the request when 
you start using a session scoped bean and therefore the creation does not work 
as expected.

The impact an be that you don't use the session you think and that your bean 
instances are not scoped as expected.

First thing to check is whether you use the servlet container thread or another 
thread pool when it happens.

Romain

> Observed frequent logs - Could NOT lazily initialize session context because 
> NO active request context
> --
>
> Key: OWB-1403
> URL: https://issues.apache.org/jira/browse/OWB-1403
> Project: OpenWebBeans
>  Issue Type: Bug
>Reporter: Ramesh Chatty
>Priority: Major
>
> After upgrading TomEE version from  {*}8.0.6 -> 8.0.10{*}, frequently getting 
> warnings logged as below whenever  session timeout occurs:
>  
> {code:java}
> org.apache.webbeans.web.context.WebContextsService lazyStartSessionContext
> WARNING: Could NOT lazily initialize session context because NO active 
> request context
> {code}
>  
> I have noticed one change in the *WebContextsService >> 
> lazyStartSessionContext* method, where the parameter is sending as *false* 
> for *getRequestContext(false)* method in *openwebbeans-web-2.0.26.jar* with 
> in *TomEE-8.0.10* , where as this value is sent as *true* in 
> *openwebbeans-web-2.0.12.jar* with in *TomEE-8.0.6*
>  
> _Can you please suggest how to handle this scenario? Also are there any other 
> impact scenarios we may be missing due to this change?_



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

Re: [VOTE] Release Apache Meecrowave 1.2.14

[Romain Manni-Bucau]

+1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 3 mai 2022 à 13:41, Mark Struberg  a
écrit :

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

Re: [DISCUSS] Release Meecrowave-1.2.14

[Romain Manni-Bucau]

Sounds good

Le ven. 29 avr. 2022 à 11:36, Mark Struberg  a
écrit :

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

Re: [DISCUSS] Release Meecrowave-1.2.14

[Romain Manni-Bucau]

Well it is a matter of a week, since we didn't release for upgrades since
the beginning of the year and several were containing CVE fixes - but all
upgradable without patching our code - I don't think we have to urge so we
can likely wait for it and not chain releases which is always perceived as
a negative sign (bad quality) even if it is not in practise.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 26 avr. 2022 à 11:03, Mark Struberg  a
écrit :

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

Re: [DISCUSS] Release Meecrowave-1.2.14

[Romain Manni-Bucau]

Can we await for David's fix on johnzon? Would love to get that out ASAP,
should be max a week I think.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 26 avr. 2022 à 09:18, Mark Struberg  a
écrit :

> Hi folks!
>
> Any reason not to start a mw release today?
> We've ironed out a few glitches and updated some libs.
>
> Will start in about 3 hours if nobody speaks out against it.
>
> txs and LieGrue,
> strub
>
>

[jira] [Created] (MEECROWAVE-320) Upgrade to johnzon 1.2.17

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-320:
-

 Summary: Upgrade to johnzon 1.2.17
 Key: MEECROWAVE-320
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-320
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.14






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

[jira] [Resolved] (MEECROWAVE-320) Upgrade to johnzon 1.2.17

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-320.
---
Resolution: Fixed

> Upgrade to johnzon 1.2.17
> -
>
> Key: MEECROWAVE-320
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-320
> Project: Meecrowave
>  Issue Type: Task
>    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-319) Log4j 2.17.2

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-319.
---
Resolution: Fixed

> Log4j 2.17.2
> 
>
> Key: MEECROWAVE-319
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-319
> Project: Meecrowave
>  Issue Type: Task
>    Reporter: Romain Manni-Bucau
>    Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.14
>
>




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

[jira] [Created] (MEECROWAVE-319) Log4j 2.17.2

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-319:
-

 Summary: Log4j 2.17.2
 Key: MEECROWAVE-319
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-319
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.14






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

[jira] [Resolved] (MEECROWAVE-318) CXF 3.5.2

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-318.
---
Resolution: Fixed

> CXF 3.5.2
> -
>
> Key: MEECROWAVE-318
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-318
> Project: Meecrowave
>  Issue Type: Task
>    Reporter: Romain Manni-Bucau
>    Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.14
>
>




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

[jira] [Created] (MEECROWAVE-318) CXF 3.5.2

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-318:
-

 Summary: CXF 3.5.2
 Key: MEECROWAVE-318
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-318
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.14






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

[jira] [Resolved] (MEECROWAVE-317) Tomcat 9.0.62

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-317.
---
Resolution: Fixed

> Tomcat 9.0.62
> -
>
> Key: MEECROWAVE-317
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-317
> Project: Meecrowave
>  Issue Type: Task
>    Reporter: Romain Manni-Bucau
>    Assignee: Romain Manni-Bucau
>Priority: Major
>




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

[jira] [Created] (MEECROWAVE-317) Tomcat 9.0.62

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-317:
-

 Summary: Tomcat 9.0.62
 Key: MEECROWAVE-317
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-317
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau






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

Log level for container is stopping

[Romain Manni-Bucau]

Hi all,

Just realized "container is stopping" message is at fine level whereas
start message is at info
(see org.apache.webbeans.lifecycle.AbstractLifeCycle#stopApplication).
Wonder if there is any rational behind this "not symetric" choice.
Asking cause when you start/stop a container it looks like it didn't stop
whereas all worked fine so I'm tempted to move the stop message to info as
well.

Wdyt?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

[jira] [Resolved] (MEECROWAVE-316) Upgrade to tomcat 9.0.60

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-316.
---
Resolution: Fixed

> Upgrade to tomcat 9.0.60
> 
>
> Key: MEECROWAVE-316
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-316
> Project: Meecrowave
>  Issue Type: Task
>    Reporter: Romain Manni-Bucau
>    Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.14
>
>




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

[jira] [Created] (MEECROWAVE-316) Upgrade to tomcat 9.0.60

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-316:
-

 Summary: Upgrade to tomcat 9.0.60
 Key: MEECROWAVE-316
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-316
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.14






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

[jira] [Resolved] (MEECROWAVE-314) Upgrade to CXF 3.5.1

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-314.
---
Resolution: Fixed

> Upgrade to CXF 3.5.1
> 
>
> Key: MEECROWAVE-314
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-314
> Project: Meecrowave
>  Issue Type: Task
>    Reporter: Romain Manni-Bucau
>    Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.14
>
>




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

[jira] [Resolved] (MEECROWAVE-312) Upgrade to Tomcat 9.0.59

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-312.
---
Resolution: Fixed

> Upgrade to Tomcat 9.0.59
> 
>
> Key: MEECROWAVE-312
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-312
> Project: Meecrowave
>  Issue Type: Task
>    Reporter: Romain Manni-Bucau
>    Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.14
>
>




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

[jira] [Resolved] (MEECROWAVE-315) Upgrade to Johnzon 1.2.16

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-315.
---
Resolution: Fixed

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




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

[jira] [Resolved] (MEECROWAVE-313) Upgrade to OpenWebBeans 2.0.26

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-313.
---
Resolution: Fixed

> Upgrade to OpenWebBeans 2.0.26
> --
>
> Key: MEECROWAVE-313
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-313
> Project: Meecrowave
>  Issue Type: Task
>    Reporter: Romain Manni-Bucau
>    Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.14
>
>




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

[jira] [Created] (MEECROWAVE-315) Upgrade to Johnzon 1.2.16

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-315:
-

 Summary: Upgrade to Johnzon 1.2.16
 Key: MEECROWAVE-315
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-315
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.14






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

[jira] [Created] (MEECROWAVE-313) Upgrade to OpenWebBeans 2.0.26

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-313:
-

 Summary: Upgrade to OpenWebBeans 2.0.26
 Key: MEECROWAVE-313
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-313
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.14






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

[jira] [Created] (MEECROWAVE-314) Upgrade to CXF 3.5.1

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-314:
-

 Summary: Upgrade to CXF 3.5.1
 Key: MEECROWAVE-314
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-314
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.14






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

[jira] [Updated] (MEECROWAVE-312) Upgrade to Tomcat 9.0.59

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau updated MEECROWAVE-312:
--
Fix Version/s: 1.2.14
   (was: 1.2.15)

> Upgrade to Tomcat 9.0.59
> 
>
> Key: MEECROWAVE-312
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-312
> Project: Meecrowave
>  Issue Type: Task
>    Reporter: Romain Manni-Bucau
>    Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.14
>
>




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

[jira] [Created] (MEECROWAVE-312) Upgrade to Tomcat 9.0.59

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-312:
-

 Summary: Upgrade to Tomcat 9.0.59
 Key: MEECROWAVE-312
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-312
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.15






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

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

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau updated OWB-1088:

Fix Version/s: 2.0.27
   (was: 2.0.26)

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



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

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

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau updated OWB-1074:

Fix Version/s: 2.0.27
   (was: 2.0.26)

> 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.27
>
>
> 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] [Updated] (OWB-1078) create Dockerfiles for installing OpenWebBeans as Docker Image based on Tomcat8

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau updated OWB-1078:

Fix Version/s: 2.0.27
   (was: 2.0.26)

> 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.27
>
>
> create Dockerfiles for installing OpenWebBeans as Docker Image based on 
> Tomcat8



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

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

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau updated OWB-1282:

Fix Version/s: 2.0.27
   (was: 2.0.26)

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




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

[RESULT] [VOTE] Release Apache OpenWebBeans 2.0.26

[Romain Manni-Bucau]

Which makes 4 +1 (enough bindings) so this vote passes, thank you all!

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 7 févr. 2022 à 23:49, Jean-Louis MONTEIRO  a
écrit :

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

Re: [VOTE] Release Apache OpenWebBeans 2.0.26

[Romain Manni-Bucau]

My own +1, we still miss one binding to close this vote guys

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 3 févr. 2022 à 10:33, Thomas Andraschko 
a écrit :

> +1
>
> Am Do., 3. Feb. 2022 um 10:24 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
> > Hi all,
> >
> > Here is the vote for Apache OpenWebBeans 2.0.26.
> >
> > Here is the changelog:
> >
> > [image: Major] [image: Task] OWB-1401
> > <https://issues.apache.org/jira/browse/OWB-1401> Make interceptor
> injected
> > method array sorted to be deterministic in proxy classes
> > <https://issues.apache.org/jira/browse/OWB-1401> Romain Manni-Bucau
> > <
> >
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau
> > >
> > RESOLVED
> > [image: Major] [image: Bug] OWB-1402
> > <https://issues.apache.org/jira/browse/OWB-1402> CDI iterated
> > Instance#select broken <https://issues.apache.org/jira/browse/OWB-1402>
> > Romain
> > Manni-Bucau
> > <
> >
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau
> > >
> > RESOLVED
> >
> > Tag (note: uses a http repo for the tck so ensure to build with maven <
> 3.8
> > or enable http mirrors with maven):
> >
> >
> https://gitbox.apache.org/repos/asf?p=openwebbeans.git;a=commit;h=0f06ed15bfe3e53923971188e96ecc721242c2e0
> > Staging:
> >
> >
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1079/
> > Dist: https://dist.apache.org/repos/dist/dev/openwebbeans/owb/
> > My key is the same than last time.
> >
> > Please vote
> >
> > [ ] +1
> > [ ] -1 ${cause}
> >
> > Vote will be opened for 3 days as usual or until we get enough binding
> > votes.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
>

[VOTE] Release Apache OpenWebBeans 2.0.26

[Romain Manni-Bucau]

Hi all,

Here is the vote for Apache OpenWebBeans 2.0.26.

Here is the changelog:

[image: Major] [image: Task] OWB-1401
<https://issues.apache.org/jira/browse/OWB-1401> Make interceptor injected
method array sorted to be deterministic in proxy classes
<https://issues.apache.org/jira/browse/OWB-1401> Romain Manni-Bucau
<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau>
RESOLVED
[image: Major] [image: Bug] OWB-1402
<https://issues.apache.org/jira/browse/OWB-1402> CDI iterated
Instance#select broken <https://issues.apache.org/jira/browse/OWB-1402> Romain
Manni-Bucau
<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau>
RESOLVED

Tag (note: uses a http repo for the tck so ensure to build with maven < 3.8
or enable http mirrors with maven):
https://gitbox.apache.org/repos/asf?p=openwebbeans.git;a=commit;h=0f06ed15bfe3e53923971188e96ecc721242c2e0
Staging:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1079/
Dist: https://dist.apache.org/repos/dist/dev/openwebbeans/owb/
My key is the same than last time.

Please vote

[ ] +1
[ ] -1 ${cause}

Vote will be opened for 3 days as usual or until we get enough binding
votes.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

Starting releasing 2.0.26

[Romain Manni-Bucau]

Hi all,

I'm planning to start release 2.0.26 today, let me know if there is any
issue please

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

[jira] [Resolved] (OWB-1402) CDI iterated Instance#select broken

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved OWB-1402.
-
Fix Version/s: 2.0.26
 Assignee: Romain Manni-Bucau
   Resolution: Fixed

Didn't find the exact reference in the spec where it should behave like that 
but "additionalQualifiers" is more than sufficient for me to behave this way 
even if implicit @Default or/and @Any are treated specifically (this is the bit 
blurry part for me). should be fixed on master

> CDI iterated Instance#select broken
> ---
>
> Key: OWB-1402
> URL: https://issues.apache.org/jira/browse/OWB-1402
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: 2.0.25
> Environment: linux, openjdk 11
>Reporter: Roland Bergler
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 2.0.26
>
>
> I found the following bug within an openejb server (version 8.0.9), but can 
> be reproduced with owb arquillian container, but not with weld.
> I have Managed Beans annotated with two qualifiers each (Examples from my 
> test project, URL below):
> {noformat}
> @FoodQualifier(FoodType.FRUIT)
> @TasteQualifier(TasteType.YUMMY)
> public class Strawberry extends Food {
> ... {noformat}
> I got an injected Instance object, on which I want to select beans in a 
> two-step process:
> {noformat}
> @Inject @Any private Instance allTypesOfFood;
> ...
> Instance vegetables = allTypesOfFood.select(new 
> LiteralFoodType(FoodType.VEGETABLE));  
> Instance yummyVegetables = vegetables.select(new 
> LiteralTasteType(TasteType.YUMMY));
>  {noformat}
> The second call to "select" seems to completely ignore the fact it is meant 
> to be working on a restricted set, it yields all YUMMY foots, not just the 
> vegetables.
> Find code here: [https://github.com/montanero/openejb-bug, 
> |https://github.com/montanero/openejb-bug]type
> {{mvn install -P owb}}
>  



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

2.0.26 release bag

[Romain Manni-Bucau]

Hi all,

I pushed a fix which sorts the intercepted methods in our interceptor
handlers enabling to use interceptors with pre-generated proxies.
I know Geronimo Arthur will want to integrate it for its 1.0.5 (it is
voting on 1.0.4 right now without interceptor support due to that).

Do we have anything pending to release or should we go?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

[jira] [Resolved] (OWB-1401) Make interceptor injected method array sorted to be deterministic in proxy classes

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved OWB-1401.
-
Resolution: Fixed

> Make interceptor injected method array sorted to be deterministic in proxy 
> classes
> --
>
> Key: OWB-1401
> URL: https://issues.apache.org/jira/browse/OWB-1401
> Project: OpenWebBeans
>  Issue Type: Task
>    Reporter: Romain Manni-Bucau
>    Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 2.0.26
>
>




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