[jira] [Resolved] (OWB-1427) Support for dotted bean names with EL
[ https://issues.apache.org/jira/browse/OWB-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1427. -- Resolution: Fixed > Support for dotted bean names with EL > - > > Key: OWB-1427 > URL: https://issues.apache.org/jira/browse/OWB-1427 > Project: OpenWebBeans > Issue Type: New Feature >Reporter: Jean-Louis Monteiro >Priority: Major > Labels: pull-request-available > Fix For: 4.0.0 > > > {color:#067d17}org.jboss.cdi.tck.tests.full.lookup.el.ResolutionByNameTest{color} > uses a bean name @Named("magic.golden.fish") and it tests retrieving it with > #\{magic.golden.fish}. We need some kind of a hack to support this use case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OWB-1427) Support for dotted bean names with EL
Jean-Louis Monteiro created OWB-1427: Summary: Support for dotted bean names with EL Key: OWB-1427 URL: https://issues.apache.org/jira/browse/OWB-1427 Project: OpenWebBeans Issue Type: New Feature Reporter: Jean-Louis Monteiro Fix For: 4.0.0 {color:#067d17}org.jboss.cdi.tck.tests.full.lookup.el.ResolutionByNameTest{color} uses a bean name @Named("magic.golden.fish") and it tests retrieving it with #\{magic.golden.fish}. We need some kind of a hack to support this use case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OWB-1424) org.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTestorg.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin
[ https://issues.apache.org/jira/browse/OWB-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1424. -- Resolution: Fixed Challenge accepted and PR accepted so we can safely exclude from the TCK run > org.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTestorg.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTest > > > Key: OWB-1424 > URL: https://issues.apache.org/jira/browse/OWB-1424 > Project: OpenWebBeans > Issue Type: TCK Challenge > Components: TCK >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 4.0.0 > > > https://github.com/jakartaee/cdi-tck/issues/424 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OWB-1422) org.jboss.cdi.tck.tests.interceptors.definition.InterceptorDefinitionTest
[ https://issues.apache.org/jira/browse/OWB-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1422. -- Resolution: Fixed Challenge accepted and PR accepted so we can safely exclude from the TCK run > org.jboss.cdi.tck.tests.interceptors.definition.InterceptorDefinitionTest > - > > Key: OWB-1422 > URL: https://issues.apache.org/jira/browse/OWB-1422 > Project: OpenWebBeans > Issue Type: TCK Challenge > Components: TCK >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 4.0.0 > > > https://github.com/jakartaee/cdi-tck/issues/421 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OWB-1419) org.jboss.cdi.tck.interceptors.tests.bindings.aroundConstruct.ConstructorInterceptionTest
[ https://issues.apache.org/jira/browse/OWB-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1419. -- Resolution: Fixed Challenge accepted and PR accepted so we can safely exclude from the TCK run > org.jboss.cdi.tck.interceptors.tests.bindings.aroundConstruct.ConstructorInterceptionTest > - > > Key: OWB-1419 > URL: https://issues.apache.org/jira/browse/OWB-1419 > Project: OpenWebBeans > Issue Type: TCK Challenge > Components: TCK >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 4.0.0 > > > Interceptor ordering issue in TCK. Challenge created > https://github.com/jakartaee/cdi-tck/issues/418 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OWB-1420) org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.bindings.LifecycleInterceptorDefinitionTest
[ https://issues.apache.org/jira/browse/OWB-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1420. -- Resolution: Fixed Challenge accepted and PR accepted so we can safely exclude from the TCK run > org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.bindings.LifecycleInterceptorDefinitionTest > --- > > Key: OWB-1420 > URL: https://issues.apache.org/jira/browse/OWB-1420 > Project: OpenWebBeans > Issue Type: TCK Challenge > Components: TCK >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 4.0.0 > > > https://github.com/jakartaee/cdi-tck/issues/419 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OWB-1421) org.jboss.cdi.tck.interceptors.tests.bindings.overriding.InterceptorBindingOverridingTest
[ https://issues.apache.org/jira/browse/OWB-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1421. -- Resolution: Fixed Challenge accepted and PR accepted so we can safely exclude from the TCK run > org.jboss.cdi.tck.interceptors.tests.bindings.overriding.InterceptorBindingOverridingTest > - > > Key: OWB-1421 > URL: https://issues.apache.org/jira/browse/OWB-1421 > Project: OpenWebBeans > Issue Type: TCK Challenge > Components: TCK >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 4.0.0 > > > https://github.com/jakartaee/cdi-tck/issues/420 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OWB-1426) Missing bean types for indirectly implemented interfaces
Jean-Louis Monteiro created OWB-1426: Summary: Missing bean types for indirectly implemented interfaces Key: OWB-1426 URL: https://issues.apache.org/jira/browse/OWB-1426 Project: OpenWebBeans Issue Type: Bug Components: Core, TCK Reporter: Jean-Louis Monteiro Fix For: 4.0.0 The following TCK test is failing in OWB and I think it's a good one from the spec point of view. {color:#067d17}org.jboss.cdi.tck.tests.definition.bean.BeanDefinitionTest{color} The spec says [https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#managed_bean_types] {quote}The unrestricted set of bean types for a managed bean contains the bean class, every superclass and all interfaces it implements directly or indirectly. The resulting set of bean types for a managed bean consists only of [legal bean types|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#legal_bean_types], all other types are removed from the set of bean types. Note the additional restrictions upon bean types of beans with normal scopes defined in [Unproxyable bean types|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#unproxyable]. {quote} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OWB-1425) Interceptors not being called on UnmanagedInstance
Jean-Louis Monteiro created OWB-1425: Summary: Interceptors not being called on UnmanagedInstance Key: OWB-1425 URL: https://issues.apache.org/jira/browse/OWB-1425 Project: OpenWebBeans Issue Type: Bug Components: Core, TCK Reporter: Jean-Louis Monteiro Fix For: 4.0.0 OWB does not interceptors on UnmanagedInstance even though the specification is quite clear in that area. https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#biz_method_full {quote}When the application invokes: * a method of a bean via a contextual reference to the bean, as defined in [Contextual reference for a bean|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#contextual_reference], * a method of a bean via a non-contextual reference to the bean, if the instance was created by the container (e.g. using {{InjectionTarget.produce()}} or {{{}*UnmanagedInstance.produce()*{}}}, or * a method of a bean via a non-contextual reference to the bean, if the instance was enhanced with the {{InterceptionFactory}} interface as defined in [The {{InterceptionFactory}} interface|https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#interception_factory], the invocation is treated as a {_}business method invocation{_}. {quote} The spec also says {quote}A method invocation passes through method interceptors and decorators if, and only if, it is a business method invocation. Otherwise, the invocation is treated as a normal Java method call and is not intercepted by the container. {quote} We can't pass the following TCK test org.jboss.cdi.tck.tests.full.extensions.beanManager.unmanaged.UnmanagedInstanceTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OWB-1424) org.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTestorg.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.
Jean-Louis Monteiro created OWB-1424: Summary: org.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTestorg.jboss.cdi.tck.tests.full.context.passivating.dependency.builtin.BuiltinBeanPassivationDependencyTest Key: OWB-1424 URL: https://issues.apache.org/jira/browse/OWB-1424 Project: OpenWebBeans Issue Type: TCK Challenge Components: TCK Reporter: Jean-Louis Monteiro Fix For: 4.0.0 https://github.com/jakartaee/cdi-tck/issues/424 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OWB-1422) org.jboss.cdi.tck.tests.interceptors.definition.InterceptorDefinitionTest
Jean-Louis Monteiro created OWB-1422: Summary: org.jboss.cdi.tck.tests.interceptors.definition.InterceptorDefinitionTest Key: OWB-1422 URL: https://issues.apache.org/jira/browse/OWB-1422 Project: OpenWebBeans Issue Type: TCK Challenge Components: TCK Reporter: Jean-Louis Monteiro Fix For: 4.0.0 https://github.com/jakartaee/cdi-tck/issues/421 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OWB-1421) org.jboss.cdi.tck.interceptors.tests.bindings.overriding.InterceptorBindingOverridingTest
Jean-Louis Monteiro created OWB-1421: Summary: org.jboss.cdi.tck.interceptors.tests.bindings.overriding.InterceptorBindingOverridingTest Key: OWB-1421 URL: https://issues.apache.org/jira/browse/OWB-1421 Project: OpenWebBeans Issue Type: TCK Challenge Components: TCK Reporter: Jean-Louis Monteiro Fix For: 4.0.0 https://github.com/jakartaee/cdi-tck/issues/420 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OWB-1420) org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.bindings.LifecycleInterceptorDefinitionTest
Jean-Louis Monteiro created OWB-1420: Summary: org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.bindings.LifecycleInterceptorDefinitionTest Key: OWB-1420 URL: https://issues.apache.org/jira/browse/OWB-1420 Project: OpenWebBeans Issue Type: TCK Challenge Components: TCK Reporter: Jean-Louis Monteiro Fix For: 4.0.0 https://github.com/jakartaee/cdi-tck/issues/419 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OWB-1419) org.jboss.cdi.tck.interceptors.tests.bindings.aroundConstruct.ConstructorInterceptionTest
Jean-Louis Monteiro created OWB-1419: Summary: org.jboss.cdi.tck.interceptors.tests.bindings.aroundConstruct.ConstructorInterceptionTest Key: OWB-1419 URL: https://issues.apache.org/jira/browse/OWB-1419 Project: OpenWebBeans Issue Type: TCK Challenge Components: TCK Reporter: Jean-Louis Monteiro Fix For: 4.0.0 Interceptor ordering issue in TCK. Challenge created https://github.com/jakartaee/cdi-tck/issues/418 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OWB-1404) Cannot build
[ https://issues.apache.org/jira/browse/OWB-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1404. -- Fix Version/s: 2.0.27 Resolution: Not A Problem This is outside of what we can do. > 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 > Fix For: 2.0.27 > > > 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] [Resolved] (OWB-1413) Fix jakarta relocations
[ https://issues.apache.org/jira/browse/OWB-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1413. -- Fix Version/s: 2.0.27 Resolution: Fixed > Fix jakarta relocations > --- > > Key: OWB-1413 > URL: https://issues.apache.org/jira/browse/OWB-1413 > Project: OpenWebBeans > Issue Type: Bug >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 2.0.27 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (OWB-1413) Fix jakarta relocations
Jean-Louis Monteiro created OWB-1413: Summary: Fix jakarta relocations Key: OWB-1413 URL: https://issues.apache.org/jira/browse/OWB-1413 Project: OpenWebBeans Issue Type: Bug Reporter: Jean-Louis Monteiro -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (OWB-1407) Apache Commons Validator 1.4.1
[ https://issues.apache.org/jira/browse/OWB-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1407. -- Fix Version/s: 2.0.27 Resolution: Fixed > Apache Commons Validator 1.4.1 > -- > > Key: OWB-1407 > URL: https://issues.apache.org/jira/browse/OWB-1407 > Project: OpenWebBeans > Issue Type: Dependency upgrade > Components: Samples & Documentation >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 2.0.27 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (OWB-1410) SLF 1.7.36
[ https://issues.apache.org/jira/browse/OWB-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1410. -- Fix Version/s: 2.0.27 Resolution: Fixed > SLF 1.7.36 > -- > > Key: OWB-1410 > URL: https://issues.apache.org/jira/browse/OWB-1410 > Project: OpenWebBeans > Issue Type: Dependency upgrade >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 2.0.27 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (OWB-1411) Apache Tomcat 10.0.21
[ https://issues.apache.org/jira/browse/OWB-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1411. -- Fix Version/s: 2.0.27 Resolution: Fixed > Apache Tomcat 10.0.21 > - > > Key: OWB-1411 > URL: https://issues.apache.org/jira/browse/OWB-1411 > Project: OpenWebBeans > Issue Type: Dependency upgrade > Components: TCK >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 2.0.27 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (OWB-1412) Geronimo interceptor_1.2_spec 1.2
[ https://issues.apache.org/jira/browse/OWB-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1412. -- Fix Version/s: 2.0.27 Resolution: Fixed > Geronimo interceptor_1.2_spec 1.2 > - > > Key: OWB-1412 > URL: https://issues.apache.org/jira/browse/OWB-1412 > Project: OpenWebBeans > Issue Type: Dependency upgrade >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 2.0.27 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (OWB-1409) Groovy 3.0.10
[ https://issues.apache.org/jira/browse/OWB-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1409. -- Fix Version/s: 2.0.27 Resolution: Fixed > Groovy 3.0.10 > - > > Key: OWB-1409 > URL: https://issues.apache.org/jira/browse/OWB-1409 > Project: OpenWebBeans > Issue Type: Dependency upgrade >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 2.0.27 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (OWB-1408) Gradle 3.5.1
[ https://issues.apache.org/jira/browse/OWB-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1408. -- Fix Version/s: 2.0.27 Resolution: Fixed > Gradle 3.5.1 > > > Key: OWB-1408 > URL: https://issues.apache.org/jira/browse/OWB-1408 > Project: OpenWebBeans > Issue Type: Dependency upgrade >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 2.0.27 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (OWB-1405) Apache Tomcat 7.0.109
[ https://issues.apache.org/jira/browse/OWB-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1405. -- Fix Version/s: 2.0.27 Resolution: Fixed > Apache Tomcat 7.0.109 > - > > Key: OWB-1405 > URL: https://issues.apache.org/jira/browse/OWB-1405 > Project: OpenWebBeans > Issue Type: Dependency upgrade >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 2.0.27 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (OWB-1406) XBean 4.21
[ https://issues.apache.org/jira/browse/OWB-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1406. -- Fix Version/s: 2.0.27 Resolution: Fixed > XBean 4.21 > -- > > Key: OWB-1406 > URL: https://issues.apache.org/jira/browse/OWB-1406 > Project: OpenWebBeans > Issue Type: Dependency upgrade >Reporter: Jean-Louis Monteiro >Priority: Major > Fix For: 2.0.27 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (OWB-1412) Geronimo interceptor_1.2_spec 1.2
Jean-Louis Monteiro created OWB-1412: Summary: Geronimo interceptor_1.2_spec 1.2 Key: OWB-1412 URL: https://issues.apache.org/jira/browse/OWB-1412 Project: OpenWebBeans Issue Type: Dependency upgrade Reporter: Jean-Louis Monteiro -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (OWB-1411) Apache Tomcat 10.0.21
Jean-Louis Monteiro created OWB-1411: Summary: Apache Tomcat 10.0.21 Key: OWB-1411 URL: https://issues.apache.org/jira/browse/OWB-1411 Project: OpenWebBeans Issue Type: Dependency upgrade Components: TCK Reporter: Jean-Louis Monteiro -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (OWB-1410) SLF 1.7.36
Jean-Louis Monteiro created OWB-1410: Summary: SLF 1.7.36 Key: OWB-1410 URL: https://issues.apache.org/jira/browse/OWB-1410 Project: OpenWebBeans Issue Type: Dependency upgrade Reporter: Jean-Louis Monteiro -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (OWB-1409) Groovy 3.0.10
Jean-Louis Monteiro created OWB-1409: Summary: Groovy 3.0.10 Key: OWB-1409 URL: https://issues.apache.org/jira/browse/OWB-1409 Project: OpenWebBeans Issue Type: Dependency upgrade Reporter: Jean-Louis Monteiro -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (OWB-1408) Gradle 3.5.1
Jean-Louis Monteiro created OWB-1408: Summary: Gradle 3.5.1 Key: OWB-1408 URL: https://issues.apache.org/jira/browse/OWB-1408 Project: OpenWebBeans Issue Type: Dependency upgrade Reporter: Jean-Louis Monteiro -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (OWB-1407) Apache Commons Validator 1.4.1
Jean-Louis Monteiro created OWB-1407: Summary: Apache Commons Validator 1.4.1 Key: OWB-1407 URL: https://issues.apache.org/jira/browse/OWB-1407 Project: OpenWebBeans Issue Type: Dependency upgrade Components: Samples & Documentation Reporter: Jean-Louis Monteiro -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (OWB-1406) XBean 4.21
Jean-Louis Monteiro created OWB-1406: Summary: XBean 4.21 Key: OWB-1406 URL: https://issues.apache.org/jira/browse/OWB-1406 Project: OpenWebBeans Issue Type: Dependency upgrade Reporter: Jean-Louis Monteiro -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (OWB-1405) Apache Tomcat 7.0.109
Jean-Louis Monteiro created OWB-1405: Summary: Apache Tomcat 7.0.109 Key: OWB-1405 URL: https://issues.apache.org/jira/browse/OWB-1405 Project: OpenWebBeans Issue Type: Dependency upgrade Reporter: Jean-Louis Monteiro -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (OWB-1074) implement automatic supportsConversation() detection
[ https://issues.apache.org/jira/browse/OWB-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro updated OWB-1074: - Fix Version/s: 2.0.25 (was: 2.0.24) > 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.25 > > > 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-1282) Reduce reflection usage for default services in WebBeansContext
[ https://issues.apache.org/jira/browse/OWB-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro updated OWB-1282: - Fix Version/s: 2.0.25 (was: 2.0.24) > 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.25 > > -- 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
[ https://issues.apache.org/jira/browse/OWB-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro updated OWB-1078: - Fix Version/s: 2.0.25 (was: 2.0.24) > 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.25 > > > 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-1088) fix samples with java 8 and update to tomcat7/8
[ https://issues.apache.org/jira/browse/OWB-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro updated OWB-1088: - Fix Version/s: 2.0.25 (was: 2.0.24) > 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.25 > > > some of our samples are currently broken under java 8 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (OWB-1392) Fully abstract defining class service
[ https://issues.apache.org/jira/browse/OWB-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro reassigned OWB-1392: Assignee: Jean-Louis Monteiro > Fully abstract defining class service > - > > Key: OWB-1392 > URL: https://issues.apache.org/jira/browse/OWB-1392 > Project: OpenWebBeans > Issue Type: Improvement >Reporter: Jean-Louis Monteiro >Assignee: Jean-Louis Monteiro >Priority: Major > > Currently it does not allow to choose between the Unsafe.allocate and > reflection call to constructor. > > The allocate is important to not call the constructor. > For TomEE integration it does allow consistency between TomEE proxies and OWB > proxies. And of course, it does allow to go back and forth from TomEE beans > to OWB beans. > > It does not functionaly change OWB behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OWB-1392) Fully abstract defining class service
[ https://issues.apache.org/jira/browse/OWB-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis Monteiro resolved OWB-1392. -- Fix Version/s: 2.0.24 Resolution: Fixed > Fully abstract defining class service > - > > Key: OWB-1392 > URL: https://issues.apache.org/jira/browse/OWB-1392 > Project: OpenWebBeans > Issue Type: Improvement >Reporter: Jean-Louis Monteiro >Assignee: Jean-Louis Monteiro >Priority: Major > Fix For: 2.0.24 > > > Currently it does not allow to choose between the Unsafe.allocate and > reflection call to constructor. > > The allocate is important to not call the constructor. > For TomEE integration it does allow consistency between TomEE proxies and OWB > proxies. And of course, it does allow to go back and forth from TomEE beans > to OWB beans. > > It does not functionaly change OWB behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OWB-1392) Fully abstract defining class service
Jean-Louis Monteiro created OWB-1392: Summary: Fully abstract defining class service Key: OWB-1392 URL: https://issues.apache.org/jira/browse/OWB-1392 Project: OpenWebBeans Issue Type: Improvement Reporter: Jean-Louis Monteiro Currently it does not allow to choose between the Unsafe.allocate and reflection call to constructor. The allocate is important to not call the constructor. For TomEE integration it does allow consistency between TomEE proxies and OWB proxies. And of course, it does allow to go back and forth from TomEE beans to OWB beans. It does not functionaly change OWB behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OWB-1270) "Extracting unsafe proxy code in an Unsafe class" backport into 1.7.* line
[ https://issues.apache.org/jira/browse/OWB-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO reassigned OWB-1270: Assignee: Daniel Cunha > "Extracting unsafe proxy code in an Unsafe class" backport into 1.7.* line > -- > > Key: OWB-1270 > URL: https://issues.apache.org/jira/browse/OWB-1270 > Project: OpenWebBeans > Issue Type: Improvement >Affects Versions: 1.7.5 >Reporter: Bruno Baptista >Assignee: Daniel Cunha >Priority: Major > Fix For: 1.7.6 > > > Trunk has an important fix for JDK11 support that needs to be backported into > the 1.7.* line. > See: > https://github.com/apache/openwebbeans/commit/37e56343b92996ef3bed4535a2728c034f8d7725 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OWB-897) Interceptors do not work on processed injection targets
[ https://issues.apache.org/jira/browse/OWB-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated OWB-897: Fix Version/s: (was: 1.7.6) 1.7.7 > Interceptors do not work on processed injection targets > --- > > Key: OWB-897 > URL: https://issues.apache.org/jira/browse/OWB-897 > Project: OpenWebBeans > Issue Type: Bug > Components: Interceptor and Decorators >Affects Versions: 1.2.0 >Reporter: Harald Wellmann >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 1.7.7 > > > I have a portable extension which processes injection targets and replaces > them with a custom implementation of > javax.enterprise.inject.spi.InjectionTarget. > This breaks interceptors on beans injected into beans which are processed > injection targets. The injected contextual references are missing the > expected proxy. > The following code snippets look suspicious: > org.apache.webbeans.component.InjectionTargetBean.defineBeanInterceptorStack(): > if (this instanceof InterceptedMarker && getInjectionTarget() > instanceof InjectionTargetImpl) { ... } > . > This means that interceptors only get processed if the injection target is an > instance of InjectionTargetImpl, which does not cover the case of a custom > injection target provided by a portable extension. > org.apache.webbeans.container.InjectionTargetFactoryImpl.createInjectionTarget(Bean): > This method directly returns the injection target processed by the extension. > This target should probably be wrapped by OWB's own implementation to make > interceptors work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OWB-1135) Remove duplication for openwebbeans/Messages
[ https://issues.apache.org/jira/browse/OWB-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072508#comment-16072508 ] Jean-Louis MONTEIRO commented on OWB-1135: -- Thanks Daniel. All applied. > Remove duplication for openwebbeans/Messages > > > Key: OWB-1135 > URL: https://issues.apache.org/jira/browse/OWB-1135 > Project: OpenWebBeans > Issue Type: Improvement > Components: Core >Reporter: Daniel Cunha > Fix For: 2.0.0 > > Attachments: OWB-1135.patch > > > Create a ResourceBundleFactory and change it on: > WebBeansLoggerFacade > JULLoggerFactory > Remove duplication of the openwebbeans/Messages into the code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OWB-986) CreationalContextImpl.toString throws NullPointerException
[ https://issues.apache.org/jira/browse/OWB-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14068492#comment-14068492 ] Jean-Louis MONTEIRO commented on OWB-986: - Ah ok, did not figure that point. Just pushed the fix again > CreationalContextImpl.toString throws NullPointerException > -- > > Key: OWB-986 > URL: https://issues.apache.org/jira/browse/OWB-986 > Project: OpenWebBeans > Issue Type: Bug >Reporter: Andy Gumbrecht >Priority: Minor > Fix For: 2.0.1 > > > CreationalContextImpl.toString throws NullPointerException - This was only > seen in a debugger context, but still should be more safe. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (OWB-986) CreationalContextImpl.toString throws NullPointerException
[ https://issues.apache.org/jira/browse/OWB-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO resolved OWB-986. - Resolution: Fixed Fix Version/s: 2.0.1 Thanks Andy. Fixed for you. @Romain, I did not used bean.toString() It provides much more information as previously. It's a different topic thought. We can change the format after. > CreationalContextImpl.toString throws NullPointerException > -- > > Key: OWB-986 > URL: https://issues.apache.org/jira/browse/OWB-986 > Project: OpenWebBeans > Issue Type: Bug >Reporter: Andy Gumbrecht >Priority: Minor > Fix For: 2.0.1 > > > CreationalContextImpl.toString throws NullPointerException - This was only > seen in a debugger context, but still should be more safe. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OWB-715) Remove EL22 implementation from Core to Own Project
[ https://issues.apache.org/jira/browse/OWB-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated OWB-715: Fix Version/s: (was: 1.1.7) 1.2.0 > Remove EL22 implementation from Core to Own Project > --- > > Key: OWB-715 > URL: https://issues.apache.org/jira/browse/OWB-715 > Project: OpenWebBeans > Issue Type: Improvement > Components: Core, Java EE Integration >Affects Versions: 1.1.6, 1.1.7 >Reporter: Gurkan Erdogdu >Assignee: Gurkan Erdogdu > Fix For: 1.2.0 > > Original Estimate: 24h > Remaining Estimate: 24h > > Currently EL 2.2 integration code is located in the openwebbeans-impl > project. It is more reasonable to include EL 2.2 integration into its own > project and use only SPI logic in core. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OWB-717) Remove Failover implementation from Web to Own Project
[ https://issues.apache.org/jira/browse/OWB-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated OWB-717: Fix Version/s: (was: 1.1.7) 1.2.0 Affects Version/s: 1.1.6 > Remove Failover implementation from Web to Own Project > --- > > Key: OWB-717 > URL: https://issues.apache.org/jira/browse/OWB-717 > Project: OpenWebBeans > Issue Type: Improvement > Components: Core >Affects Versions: 1.1.6, 1.1.7 >Reporter: Gurkan Erdogdu >Assignee: Gurkan Erdogdu > Fix For: 1.2.0 > > Original Estimate: 24h > Remaining Estimate: 24h > > Currently failover logic is located in openwebbeans-web. Move failover logic > to its own project, openwebbeans-clustering -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OWB-715) Remove EL22 implementation from Core to Own Project
[ https://issues.apache.org/jira/browse/OWB-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated OWB-715: Affects Version/s: (was: 1.2.0) 1.1.7 1.1.6 > Remove EL22 implementation from Core to Own Project > --- > > Key: OWB-715 > URL: https://issues.apache.org/jira/browse/OWB-715 > Project: OpenWebBeans > Issue Type: Improvement > Components: Core, Java EE Integration >Affects Versions: 1.1.6, 1.1.7 >Reporter: Gurkan Erdogdu >Assignee: Gurkan Erdogdu > Fix For: 1.1.7 > > Original Estimate: 24h > Remaining Estimate: 24h > > Currently EL 2.2 integration code is located in the openwebbeans-impl > project. It is more reasonable to include EL 2.2 integration into its own > project and use only SPI logic in core. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OWB-715) Remove EL22 implementation from Core to Own Project
[ https://issues.apache.org/jira/browse/OWB-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated OWB-715: Affects Version/s: (was: 1.1.7) 1.2.0 > Remove EL22 implementation from Core to Own Project > --- > > Key: OWB-715 > URL: https://issues.apache.org/jira/browse/OWB-715 > Project: OpenWebBeans > Issue Type: Improvement > Components: Core, Java EE Integration >Affects Versions: 1.2.0 >Reporter: Gurkan Erdogdu >Assignee: Gurkan Erdogdu > Fix For: 1.1.7 > > Original Estimate: 24h > Remaining Estimate: 24h > > Currently EL 2.2 integration code is located in the openwebbeans-impl > project. It is more reasonable to include EL 2.2 integration into its own > project and use only SPI logic in core. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OWB-703) getBeans cache key algorithm must be unique
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455809#comment-13455809 ] Jean-Louis MONTEIRO commented on OWB-703: - Apologise, but I can't (not a committer, then no write access I guess). > getBeans cache key algorithm must be unique > --- > > Key: OWB-703 > URL: https://issues.apache.org/jira/browse/OWB-703 > Project: OpenWebBeans > Issue Type: Bug >Affects Versions: 1.1.4, 1.1.5 > Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7 >Reporter: Udo Schnurpfeil >Assignee: Mark Struberg >Priority: Critical > Fix For: 1.1.6 > > Attachments: OWB-703-2nd-shoot.patch, > OWB-703-hash-cache-as-integer.patch, owb-703.patch, OWB-703-refactored.diff > > > Our application was tested in a Pre-Production environment, and it turns out > a problem which occurs sometime after 2 weeks but sometimes after a short > time: > [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E SRVE0068E: Uncaught > exception thrown in one of the service methods of the servlet: > FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given > bean type : class > org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry > is not applicable for the bean instance : BereitstellungModelLoaderImpl, > Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API > Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable], > > Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default] > at > org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923) > at > org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133) > at > org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215) > at > org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179) > at > org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139) > at > org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668) > at > org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) > at > com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213) > [...] > I think the reason is, that two objects got the same key in the map. > So we got wrong objects. > After this exception the application must be restarted, no request works > anymore. > How can this happen? > Problem number 1: > Looking in the implementation: > There will be computed a key of type Long from all given parameters. > Parameters: injectionPointType, bdaBeansXMLPath, qualifiers > In practice we have one "injectionPointType" (say t) and one "qualifiers" > (say q) and the computed hash code will be: > key = hash(t) + 29 * hash(q) > assume: hash(t)=1000 and hash(q)=100 > we got a key of 1000 + 29 * 100 = 3900 > but that's the same like > 1029 + 29 * 99 = 3900 > 1058 + 29 * 98 = 3900 > 1087 + 29 * 97 = 3900 > and so on. > If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans > with the same key. > With that our map is broken, because the 2nd bean will remove the 1st bean > while adding (with the same key). > Problem number 2: > Hash codes are generally not suitable to be used as keys because there are > not unique. > The JavaDoc of the Object.hashCode() method says: > "It is not required that if two objects are unequal according to the > equals(Object) method, > then calling the hashCode method on each of the two objects must produce > distinct integer results." > The strings "org.apache.kcmdjx" and "java.lang.Object" have the same hash > code (at least in my Apple java VM). > Solution: > I see 3 solutions here: > Solution 1: > Do the same like in 1.1.3: Build a String with all information inside. > Disadvantage: slow > Solution 2: > Create an helper object, which contains the unconverted information analog to > e.g.: org.apache.myfaces.tobago.internal.context.ClientPropertiesKey > This will be faster than string concatenation, but there is to create an > object as well. > Solution 3: > Using a map which can handle more than one key. > E. g. org.apache.commons.collections.map.MultiKeyMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JI
[jira] [Updated] (OWB-703) getBeans cache key algorithm must be unique
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated OWB-703: Attachment: OWB-703-refactored.diff Here is the version a bit refactored as suggested. Jean-Louis > getBeans cache key algorithm must be unique > --- > > Key: OWB-703 > URL: https://issues.apache.org/jira/browse/OWB-703 > Project: OpenWebBeans > Issue Type: Bug >Affects Versions: 1.1.4, 1.1.5 > Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7 >Reporter: Udo Schnurpfeil >Assignee: Mark Struberg >Priority: Critical > Fix For: 1.1.6 > > Attachments: OWB-703-2nd-shoot.patch, > OWB-703-hash-cache-as-integer.patch, owb-703.patch, OWB-703-refactored.diff > > > Our application was tested in a Pre-Production environment, and it turns out > a problem which occurs sometime after 2 weeks but sometimes after a short > time: > [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E SRVE0068E: Uncaught > exception thrown in one of the service methods of the servlet: > FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given > bean type : class > org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry > is not applicable for the bean instance : BereitstellungModelLoaderImpl, > Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API > Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable], > > Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default] > at > org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923) > at > org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133) > at > org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215) > at > org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179) > at > org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139) > at > org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668) > at > org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) > at > com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213) > [...] > I think the reason is, that two objects got the same key in the map. > So we got wrong objects. > After this exception the application must be restarted, no request works > anymore. > How can this happen? > Problem number 1: > Looking in the implementation: > There will be computed a key of type Long from all given parameters. > Parameters: injectionPointType, bdaBeansXMLPath, qualifiers > In practice we have one "injectionPointType" (say t) and one "qualifiers" > (say q) and the computed hash code will be: > key = hash(t) + 29 * hash(q) > assume: hash(t)=1000 and hash(q)=100 > we got a key of 1000 + 29 * 100 = 3900 > but that's the same like > 1029 + 29 * 99 = 3900 > 1058 + 29 * 98 = 3900 > 1087 + 29 * 97 = 3900 > and so on. > If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans > with the same key. > With that our map is broken, because the 2nd bean will remove the 1st bean > while adding (with the same key). > Problem number 2: > Hash codes are generally not suitable to be used as keys because there are > not unique. > The JavaDoc of the Object.hashCode() method says: > "It is not required that if two objects are unequal according to the > equals(Object) method, > then calling the hashCode method on each of the two objects must produce > distinct integer results." > The strings "org.apache.kcmdjx" and "java.lang.Object" have the same hash > code (at least in my Apple java VM). > Solution: > I see 3 solutions here: > Solution 1: > Do the same like in 1.1.3: Build a String with all information inside. > Disadvantage: slow > Solution 2: > Create an helper object, which contains the unconverted information analog to > e.g.: org.apache.myfaces.tobago.internal.context.ClientPropertiesKey > This will be faster than string concatenation, but there is to create an > object as well. > Solution 3: > Using a map which can handle more than one key. > E. g. org.apache.commons.collections.map.MultiKeyMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more
[jira] [Commented] (OWB-703) getBeans cache key algorithm must be unique
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454750#comment-13454750 ] Jean-Louis MONTEIRO commented on OWB-703: - Ok will do that and submit a new refactored patch > getBeans cache key algorithm must be unique > --- > > Key: OWB-703 > URL: https://issues.apache.org/jira/browse/OWB-703 > Project: OpenWebBeans > Issue Type: Bug >Affects Versions: 1.1.4, 1.1.5 > Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7 >Reporter: Udo Schnurpfeil >Assignee: Mark Struberg >Priority: Critical > Fix For: 1.1.6 > > Attachments: OWB-703-2nd-shoot.patch, > OWB-703-hash-cache-as-integer.patch, owb-703.patch > > > Our application was tested in a Pre-Production environment, and it turns out > a problem which occurs sometime after 2 weeks but sometimes after a short > time: > [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E SRVE0068E: Uncaught > exception thrown in one of the service methods of the servlet: > FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given > bean type : class > org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry > is not applicable for the bean instance : BereitstellungModelLoaderImpl, > Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API > Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable], > > Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default] > at > org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923) > at > org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133) > at > org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215) > at > org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179) > at > org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139) > at > org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668) > at > org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) > at > com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213) > [...] > I think the reason is, that two objects got the same key in the map. > So we got wrong objects. > After this exception the application must be restarted, no request works > anymore. > How can this happen? > Problem number 1: > Looking in the implementation: > There will be computed a key of type Long from all given parameters. > Parameters: injectionPointType, bdaBeansXMLPath, qualifiers > In practice we have one "injectionPointType" (say t) and one "qualifiers" > (say q) and the computed hash code will be: > key = hash(t) + 29 * hash(q) > assume: hash(t)=1000 and hash(q)=100 > we got a key of 1000 + 29 * 100 = 3900 > but that's the same like > 1029 + 29 * 99 = 3900 > 1058 + 29 * 98 = 3900 > 1087 + 29 * 97 = 3900 > and so on. > If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans > with the same key. > With that our map is broken, because the 2nd bean will remove the 1st bean > while adding (with the same key). > Problem number 2: > Hash codes are generally not suitable to be used as keys because there are > not unique. > The JavaDoc of the Object.hashCode() method says: > "It is not required that if two objects are unequal according to the > equals(Object) method, > then calling the hashCode method on each of the two objects must produce > distinct integer results." > The strings "org.apache.kcmdjx" and "java.lang.Object" have the same hash > code (at least in my Apple java VM). > Solution: > I see 3 solutions here: > Solution 1: > Do the same like in 1.1.3: Build a String with all information inside. > Disadvantage: slow > Solution 2: > Create an helper object, which contains the unconverted information analog to > e.g.: org.apache.myfaces.tobago.internal.context.ClientPropertiesKey > This will be faster than string concatenation, but there is to create an > object as well. > Solution 3: > Using a map which can handle more than one key. > E. g. org.apache.commons.collections.map.MultiKeyMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA,
[jira] [Updated] (OWB-703) getBeans cache key algorithm must be unique
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated OWB-703: Attachment: OWB-703-2nd-shoot.patch Here is another proposal > getBeans cache key algorithm must be unique > --- > > Key: OWB-703 > URL: https://issues.apache.org/jira/browse/OWB-703 > Project: OpenWebBeans > Issue Type: Bug >Affects Versions: 1.1.4, 1.1.5 > Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7 >Reporter: Udo Schnurpfeil >Assignee: Mark Struberg >Priority: Critical > Fix For: 1.1.6 > > Attachments: OWB-703-2nd-shoot.patch, > OWB-703-hash-cache-as-integer.patch, owb-703.patch > > > Our application was tested in a Pre-Production environment, and it turns out > a problem which occurs sometime after 2 weeks but sometimes after a short > time: > [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E SRVE0068E: Uncaught > exception thrown in one of the service methods of the servlet: > FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given > bean type : class > org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry > is not applicable for the bean instance : BereitstellungModelLoaderImpl, > Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API > Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable], > > Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default] > at > org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923) > at > org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133) > at > org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215) > at > org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179) > at > org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139) > at > org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668) > at > org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) > at > com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213) > [...] > I think the reason is, that two objects got the same key in the map. > So we got wrong objects. > After this exception the application must be restarted, no request works > anymore. > How can this happen? > Problem number 1: > Looking in the implementation: > There will be computed a key of type Long from all given parameters. > Parameters: injectionPointType, bdaBeansXMLPath, qualifiers > In practice we have one "injectionPointType" (say t) and one "qualifiers" > (say q) and the computed hash code will be: > key = hash(t) + 29 * hash(q) > assume: hash(t)=1000 and hash(q)=100 > we got a key of 1000 + 29 * 100 = 3900 > but that's the same like > 1029 + 29 * 99 = 3900 > 1058 + 29 * 98 = 3900 > 1087 + 29 * 97 = 3900 > and so on. > If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans > with the same key. > With that our map is broken, because the 2nd bean will remove the 1st bean > while adding (with the same key). > Problem number 2: > Hash codes are generally not suitable to be used as keys because there are > not unique. > The JavaDoc of the Object.hashCode() method says: > "It is not required that if two objects are unequal according to the > equals(Object) method, > then calling the hashCode method on each of the two objects must produce > distinct integer results." > The strings "org.apache.kcmdjx" and "java.lang.Object" have the same hash > code (at least in my Apple java VM). > Solution: > I see 3 solutions here: > Solution 1: > Do the same like in 1.1.3: Build a String with all information inside. > Disadvantage: slow > Solution 2: > Create an helper object, which contains the unconverted information analog to > e.g.: org.apache.myfaces.tobago.internal.context.ClientPropertiesKey > This will be faster than string concatenation, but there is to create an > object as well. > Solution 3: > Using a map which can handle more than one key. > E. g. org.apache.commons.collections.map.MultiKeyMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/j
[jira] [Updated] (OWB-674) rewrite owb logger api
[ https://issues.apache.org/jira/browse/OWB-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated OWB-674: Attachment: OWB-674.diff Here is a patch file with The JUL Facade and all changes. Build passes, Checkstyle activated and TCK running without any problems. > rewrite owb logger api > -- > > Key: OWB-674 > URL: https://issues.apache.org/jira/browse/OWB-674 > Project: OpenWebBeans > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Attachments: OWB-674.diff, OWB-674.patch > > > Currently the OWB logging facade is pretty useless since it only supports JUL. > It could be nice to: > 1) allow to switch to another logging framework > 2) remove the getStackTrace in JUL implementation since it has bg performance > impacts -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OWB-356) EjbPlugin only looks for DeployementInfo once, so new deployed application won't be discovered
[ https://issues.apache.org/jira/browse/OWB-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated OWB-356: Attachment: OWB-356.patch Here is a first proposal > EjbPlugin only looks for DeployementInfo once, so new deployed application > won't be discovered > -- > > Key: OWB-356 > URL: https://issues.apache.org/jira/browse/OWB-356 > Project: OpenWebBeans > Issue Type: Improvement > Components: Java EE Integration > Environment: OWB + OEJB >Reporter: Jean-Louis MONTEIRO >Assignee: Gurkan Erdogdu > Fix For: 1.0.0 > > Attachments: OWB-356.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OWB-356) EjbPlugin only looks for DeployementInfo once, so new deployed application won't be discovered
EjbPlugin only looks for DeployementInfo once, so new deployed application won't be discovered -- Key: OWB-356 URL: https://issues.apache.org/jira/browse/OWB-356 Project: OpenWebBeans Issue Type: Improvement Components: Java EE Integration Environment: OWB + OEJB Reporter: Jean-Louis MONTEIRO Assignee: Gurkan Erdogdu Fix For: 1.0.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OWB-355) OpenEjbBean should look for @Remove methods
[ https://issues.apache.org/jira/browse/OWB-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated OWB-355: Attachment: OWB-355.patch Here is the proposed patch. IMHO, we should deal with the retainIfException parameter of the @Remove annotation. For that, we have different solutions: * only add a method to the list when the retainIfException is false (or omitted) * change the org.apache.webbeans.ejb.common.proxy.EjbBeanProxyHandler.checkEjbRemoveMethod(Method) method and check the retainIfException attribute too. > OpenEjbBean should look for @Remove methods > --- > > Key: OWB-355 > URL: https://issues.apache.org/jira/browse/OWB-355 > Project: OpenWebBeans > Issue Type: Improvement > Components: Java EE Integration > Environment: OpenWebBeans in OpenEJB >Reporter: Jean-Louis MONTEIRO >Assignee: Gurkan Erdogdu > Fix For: 1.0.0 > > Attachments: OWB-355.patch > > > OpenEjbBean doesn't take care of @Remove methods so when deploying a stateful > EJB we get a NullPointerException. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OWB-355) OpenEjbBean should look for @Remove methods
OpenEjbBean should look for @Remove methods --- Key: OWB-355 URL: https://issues.apache.org/jira/browse/OWB-355 Project: OpenWebBeans Issue Type: Improvement Components: Java EE Integration Environment: OpenWebBeans in OpenEJB Reporter: Jean-Louis MONTEIRO Assignee: Gurkan Erdogdu Fix For: 1.0.0 OpenEjbBean doesn't take care of @Remove methods so when deploying a stateful EJB we get a NullPointerException. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OWB-345) Remove duplicate dependencies
[ https://issues.apache.org/jira/browse/OWB-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated OWB-345: Attachment: patch-OWB-345.txt > Remove duplicate dependencies > - > > Key: OWB-345 > URL: https://issues.apache.org/jira/browse/OWB-345 > Project: OpenWebBeans > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: WinXP >Reporter: Jean-Louis MONTEIRO >Assignee: Gurkan Erdogdu > Attachments: patch-OWB-345.txt > > > Maven 3 does not allow duplicate dependencies. So in order to use Maven 3, > can you remove duplicate entries ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-345) Remove duplicate dependencies
Remove duplicate dependencies - Key: OWB-345 URL: https://issues.apache.org/jira/browse/OWB-345 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.0.0 Environment: WinXP Reporter: Jean-Louis MONTEIRO Assignee: Gurkan Erdogdu Maven 3 does not allow duplicate dependencies. So in order to use Maven 3, can you remove duplicate entries ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.