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

[Mark Struberg (Jira)]

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

Mark Struberg resolved OWB-1416.

  Assignee: Mark Struberg
Resolution: Won't Fix

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

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

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

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



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

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

[Mark Struberg (Jira)]

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

Mark Struberg resolved OWB-1088.

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

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



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

[GitHub] [openwebbeans-meecrowave] rzo1 opened a new pull request, #22: Several dependency updates

[via GitHub]

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

   Will create Jiras for each upgrade separatly once this is merged.


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

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

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

Re: Gonna release the OWB master

[Richard Zowalla]

+1

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

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

[Mark Struberg (Jira)]

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

Mark Struberg resolved OWB-1368.

Fix Version/s: 4.0.0
   Resolution: Fixed

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



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

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

[Mark Struberg (Jira)]

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

Mark Struberg reassigned OWB-1423:
--

Assignee: Mark Struberg

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



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

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

[Mark Struberg (Jira)]

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

Mark Struberg resolved OWB-1423.

Fix Version/s: 4.0.0
   Resolution: Fixed

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



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

Re: Gonna release the OWB master

[Thomas Andraschko]

+1

Am Mo., 4. Sept. 2023 um 12:07 Uhr schrieb Richard Zowalla :

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

[VOTE] Release Apache OpenWebBeans-4.0.0

[Mark Struberg]

Hi folks!

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

The following tickets got resolved:

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

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

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

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

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

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


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

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

sha512 is 
99f470a2a64e98e292bc6e604377ed7c2f3c9b5593d40dfe079d6b16bf23df5ff17054f76ef0b3ee138d17dc611abdd89285496936f3674f1928c2c2c0faf963



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

The VOTE is open for 72h


txs and LieGrue,
strub

Re: Gonna release the OWB master

[Romain Manni-Bucau]

+1

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



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

Gonna release the OWB master

[Mark Struberg]

hi folks!

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

LieGrue,
strub