May 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3419) beans in module jars are not discovered except the first jar in module

by Petr Sakař (JIRA)

[ https://issues.jboss.org/browse/WFLY-3419?page=com.atlassian.jira.plugin.... ] Petr Sakař updated WFLY-3419: ----------------------------- Description: CDI does not scan module with multiple jars. Only first jar is scanned. Workaround is to package everything in single jar file. To reproduce: {CODE} #download attached files #download and unzip wildfly cd wildfly-9.0.0.Alpha1-SNAPSHOT #or other version > 8.0.0 unzip ../module.multiplejars.zip cp ../servlet-cdi-test3.war standalone/deployments/ ./bin/standalone.sh # observe deployment fails # stop server unzip ../module.ok.zip ./bin/standalone.sh # observe deployment succeeds {CODE} The same scenario succeeds in both cases on EAP 6.2.x. module.ok.zip was created from module.multiplejars.zip by merging jar files into single one > beans in module jars are not discovered except the first jar in module > ---------------------------------------------------------------------- > > Key: WFLY-3419 > URL: https://issues.jboss.org/browse/WFLY-3419 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Petr Sakař > Assignee: Jason Greene > > CDI does not scan module with multiple jars. Only first jar is scanned. > Workaround is to package everything in single jar file. > To reproduce: > {CODE} > #download attached files > #download and unzip wildfly > cd wildfly-9.0.0.Alpha1-SNAPSHOT #or other version > 8.0.0 > unzip ../module.multiplejars.zip > cp ../servlet-cdi-test3.war standalone/deployments/ > ./bin/standalone.sh > # observe deployment fails > # stop server > unzip ../module.ok.zip > ./bin/standalone.sh > # observe deployment succeeds > {CODE} > The same scenario succeeds in both cases on EAP 6.2.x. > module.ok.zip was created from module.multiplejars.zip by merging jar files into single one -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3419) beans in module jars are not discovered except the first jar in module

by Petr Sakař (JIRA)

[ https://issues.jboss.org/browse/WFLY-3419?page=com.atlassian.jira.plugin.... ] Petr Sakař updated WFLY-3419: ----------------------------- Affects Version/s: 8.0.0.Final 8.1.0.Final > beans in module jars are not discovered except the first jar in module > ---------------------------------------------------------------------- > > Key: WFLY-3419 > URL: https://issues.jboss.org/browse/WFLY-3419 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Petr Sakař > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3419) beans in module jars are not discovered except the first jar in module

by Petr Sakař (JIRA)

[ https://issues.jboss.org/browse/WFLY-3419?page=com.atlassian.jira.plugin.... ] Petr Sakař updated WFLY-3419: ----------------------------- Component/s: CDI / Weld > beans in module jars are not discovered except the first jar in module > ---------------------------------------------------------------------- > > Key: WFLY-3419 > URL: https://issues.jboss.org/browse/WFLY-3419 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Petr Sakař > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3418) deployed applications are not distributed to host controller(s)

by Tom Fonteyne (JIRA)

[ https://issues.jboss.org/browse/WFLY-3418?page=com.atlassian.jira.plugin.... ] Tom Fonteyne edited comment on WFLY-3418 at 5/30/14 5:33 AM: ------------------------------------------------------------- yes an no. I agree with Denis his comments. Content should only be copied when an HC is started with "\-\-backup" in other words, then the HC is intended to be promoted to DC when needed. HC's without "\-\-backup" should *not* get all application (only the ones its server instances actually need) was (Author: tfonteyn): yes an no. I agree with Denis his comments. Content should only be copied when an HC is started with "--backup" in other words, then the HC is intended to be promoted to DC when needed. HC's without "--backup" should *not* get all application (only the ones its server instances actually need) > deployed applications are not distributed to host controller(s) > --------------------------------------------------------------- > > Key: WFLY-3418 > URL: https://issues.jboss.org/browse/WFLY-3418 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.CR2 > Environment: Wildfly 8.1.0 CR5 domain mode > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > > when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3419) beans in module jars are not discovered except the first jar in module

by Petr Sakař (JIRA)

Petr Sakař created WFLY-3419: -------------------------------- Summary: beans in module jars are not discovered except the first jar in module Key: WFLY-3419 URL: https://issues.jboss.org/browse/WFLY-3419 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Petr Sakař Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3418) deployed applications are not distributed to host controller(s)

by Tom Fonteyne (JIRA)

[ https://issues.jboss.org/browse/WFLY-3418?page=com.atlassian.jira.plugin.... ] Tom Fonteyne commented on WFLY-3418: ------------------------------------ yes an no. I agree with Denis his comments. Content should only be copied when an HC is started with "--backup" in other words, then the HC is intended to be promoted to DC when needed. HC's without "--backup" should *not* get all application (only the ones its server instances actually need) > deployed applications are not distributed to host controller(s) > --------------------------------------------------------------- > > Key: WFLY-3418 > URL: https://issues.jboss.org/browse/WFLY-3418 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.CR2 > Environment: Wildfly 8.1.0 CR5 domain mode > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > > when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3418) deployed applications are not distributed to host controller(s)

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-3418?page=com.atlassian.jira.plugin.... ] Kabir Khan commented on WFLY-3418: ---------------------------------- It sounds like copying content or not would need to be made configurable? > deployed applications are not distributed to host controller(s) > --------------------------------------------------------------- > > Key: WFLY-3418 > URL: https://issues.jboss.org/browse/WFLY-3418 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.CR2 > Environment: Wildfly 8.1.0 CR5 domain mode > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > > when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3329) EJBs with same Java class name not intercepted by CDI interceptors

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-3329?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-3329: ------------------------------------ In fact, the fix for WELD-1680 (and WELD-1586 respectively) solves a different kind of issue (typesafe resolution). This interception problem cannot be fixed in the Weld code base. It's an integration issue. The {{org.jboss.weld.ejb.spi.EjbServices}} Weld SPI implementation is using ejb-name as a key in a map which stores some interception-related info. As to "overriding", using {{@Stateless(name="...")}} works fine on WildFly. And also on EAP/AS7 if you modify the reproducer app a little bit. EAP/AS7 is shipped with Weld 1.1 (CDI 1.0) which does not parse CDI 1.1 beans.xml correctly. So if you change the {{beans}} element declaration to: {code} <beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd"> {code} interceptors are applied. Also note that the example session beans do not explicitly declare a no-interface view, only Web Service client view (see also EJB spec "4.9.8 Session Bean’s No-Interface View") and so from the CDI point of view, their only bean type should be {{java.lang.Object}} (see [3.2.2. Bean types of a session bean|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#session_bean_types]). And given that the CDI spec does not state whether a JAX-WS endpoint invocation is intercepted ([7.2. Container invocations and interception|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method]) it's rather questionable whether a bean which cannot be injected should be intercepted. You should annotate the session beans with {{javax.ejb.LocalBean}} to expose a no-interface view. On the other hand a no-interface view would not help here ({{EjbServices}} problem mentioned above). > EJBs with same Java class name not intercepted by CDI interceptors > ------------------------------------------------------------------ > > Key: WFLY-3329 > URL: https://issues.jboss.org/browse/WFLY-3329 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: JBoss AS7 7.1.1.Final, JBoss AS7 7.2.0.Final, 8.0.0.Final > Reporter: Maxim Frolov > Assignee: Martin Kouba > Labels: ejb, ejb3.1, interceptor > > h3. Given > Two or more EJBs with the same Java class name but from different Java deployments. > h3. Problem > Interceptor intercepts method calls to only one of the EJBs. > An EJB to be intercepted seems to be chosen randomly after each redeployment. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-501) Propagation context is not set correctly when nodes are shared

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-501?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-501: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1103071 > Propagation context is not set correctly when nodes are shared > -------------------------------------------------------------- > > Key: DROOLS-501 > URL: https://issues.jboss.org/browse/DROOLS-501 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta4 > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.1.0.CR1 > > > The following rules > {code} > package org.drools.compiler.loop > rule "Rule 1" > ruleflow-group "Start" > no-loop > when > $thing1 : String() > $thing2 : Integer() > then > System.out.println( 'At 1' ); > update( $thing2 ); > end > rule "Rule 2" > ruleflow-group "End" > no-loop > when > $thing1 : String() > $thing2 : Integer() > then > System.out.println( 'At 2' ); > update( $thing2 ); > end > {code} > cause an endless loop even if controlled by a jBPM process with two rule tasks -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-501) Propagation context is not set correctly when nodes are shared

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-501?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-501: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1103071|https://bugzilla.redhat.com/show_bug.cgi?id=1103071] from NEW to ASSIGNED > Propagation context is not set correctly when nodes are shared > -------------------------------------------------------------- > > Key: DROOLS-501 > URL: https://issues.jboss.org/browse/DROOLS-501 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta4 > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.1.0.CR1 > > > The following rules > {code} > package org.drools.compiler.loop > rule "Rule 1" > ruleflow-group "Start" > no-loop > when > $thing1 : String() > $thing2 : Integer() > then > System.out.println( 'At 1' ); > update( $thing2 ); > end > rule "Rule 2" > ruleflow-group "End" > no-loop > when > $thing1 : String() > $thing2 : Integer() > then > System.out.println( 'At 2' ); > update( $thing2 ); > end > {code} > cause an endless loop even if controlled by a jBPM process with two rule tasks -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2014