April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-622) DomainOperationContext transformation assumes slave host and slave host's servers receive the same ops

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-622?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-622: --------------------------------------- Fix Version/s: 2.0.0.CR1 (was: 1.0.0.CR1) Assignee: (was: Brian Stansberry) https://github.com/wildfly/wildfly-core/pull/597 (for WFCORE-282) has a partial workaround for this issue. > DomainOperationContext transformation assumes slave host and slave host's servers receive the same ops > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-622 > URL: https://issues.jboss.org/browse/WFCORE-622 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 2.0.0.CR1 > > > https://github.com/wildfly/wildfly-core/commit/f5c516f2#diff-dc2038399fc7... assumes that the result transformer for the host request is appropriate for use with the subsequent requests to that host's servers during domain rollout. > That's a shaky supposition, as the server ops generated from a host request have no fixed relationship to the host request itself. Alignment is the norm but not a rule. In particular it can faill apart with composite ops where some steps in the composite are not relevant to all hosts. > Without this extra transformation, test at [1] fails. This indicates the server op is not getting the transformation registered at [2] applied. But if it's not getting the result transformation applied, wouldn't that mean relevant operation transformation isn't being applied as well? > [1] https://github.com/wildfly/wildfly-core/blob/master/testsuite/domain/src/... > [2] https://github.com/wildfly/wildfly-core/blob/master/testsuite/domain/src/... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3290) Cannot use a cluster name other than "ejb"

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3290?page=com.atlassian.jira.plugin.... ] Paul Ferraro resolved WFLY-3290. -------------------------------- Fix Version/s: 9.0.0.CR1 Resolution: Out of Date This is no longer an issue as of WF9. Infinispan transports are configured with a specific channel - so the cluster name can be manipulated via using different channels. > Cannot use a cluster name other than "ejb" > ------------------------------------------ > > Key: WFLY-3290 > URL: https://issues.jboss.org/browse/WFLY-3290 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Final > Reporter: Chris Stillwell > Assignee: Panagiotis Sotiropoulos > Priority: Critical > Fix For: 9.0.0.CR1 > > Attachments: helloworld-test.zip > > > When deploying a clustered session bean the cluster will form only if the cluster name is "ejb". If the standalone-ha.xml is modified to use a different cluster name then the cluster will not form. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-757) Upgrade maven from 3.2.2 to latest 3.2.x release

by Petr Široký (JIRA)

Petr Široký created DROOLS-757: ---------------------------------- Summary: Upgrade maven from 3.2.2 to latest 3.2.x release Key: DROOLS-757 URL: https://issues.jboss.org/browse/DROOLS-757 Project: Drools Issue Type: Task Components: tools Affects Versions: 6.2.0.Final Reporter: Petr Široký Assignee: Petr Široký Currently used maven 3.2.2 has nasty bug related to resolving imported dependencies from additional repos, see https://jira.codehaus.org/browse/MNG-5663 . I believe we should upgrade to the latest 3.2.x release. It seems only {{kie-ci}} and {{kie-maven-plugin}} should directly depend on maven. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4198) NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB

by Sergiy Barlabanov (JIRA)

[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ] Sergiy Barlabanov updated WFLY-4198: ------------------------------------ Attachment: patch.diff > NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB > ------------------------------------------------------------------------------------------------ > > Key: WFLY-4198 > URL: https://issues.jboss.org/browse/WFLY-4198 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.0.Final > Reporter: Sergiy Barlabanov > Assignee: Bartosz Baranowski > Attachments: patch.diff > > > When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below). > The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap. > So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null. > Currently there is no workaround for that :(. > {noformat} > Caused by: java.lang.NullPointerException > at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97) > at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4198) NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB

by Sergiy Barlabanov (JIRA)

[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ] Sergiy Barlabanov reopened WFLY-4198: ------------------------------------- I admit that we fail to reproduce it with a simple example. But anyway the NullPointer is there. And the bug is there. JBoss Logging does not expect null coming from SLF4J on that place (org.jboss.logging.MDC#getMap()). SLF4J API says clearly that it may return a null - see javadoc of org.slf4j.MDC#getCopyOfContextMap(). So JBoss Logging has to respect this and have to check the returned value for null. I attach the necessary patch for that (the patch is based on jboss-logging 3.1.4.GA). > NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB > ------------------------------------------------------------------------------------------------ > > Key: WFLY-4198 > URL: https://issues.jboss.org/browse/WFLY-4198 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.0.Final > Reporter: Sergiy Barlabanov > Assignee: Bartosz Baranowski > > When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below). > The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap. > So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null. > Currently there is no workaround for that :(. > {noformat} > Caused by: java.lang.NullPointerException > at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97) > at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-626) Global list-get operation can inadvertently create list elements

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-626?page=com.atlassian.jira.plugin... ] Tomaz Cerar reopened WFCORE-626: -------------------------------- Assignee: Tomaz Cerar (was: Paul Ferraro) Reopening and assigning to me to add test case for this. Fix was already merged. > Global list-get operation can inadvertently create list elements > ---------------------------------------------------------------- > > Key: WFCORE-626 > URL: https://issues.jboss.org/browse/WFCORE-626 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Beta2 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > Fix For: 1.0.0.CR1 > > > Consider the following sequence of operations: > # :list-clear(name=attribute) > # :list-get(name=attribute, index=0) > # :list-add(name=attribute, value=test) > # :list-get(name=attribute, index=0) > #2 will return <undefined> as expected. The expected result of #4 is "test". However, it returns <undefined>. This is because #2 will create the missing element at index 0 causing #3 to operate on index 1. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4487) Unable to inject Web Service Context into CDI Interceptor

by Mustafa Musaji (JIRA)

[ https://issues.jboss.org/browse/WFLY-4487?page=com.atlassian.jira.plugin.... ] Mustafa Musaji updated WFLY-4487: --------------------------------- Attachment: cdi-interceptors.zip Added reproducer > Unable to inject Web Service Context into CDI Interceptor > --------------------------------------------------------- > > Key: WFLY-4487 > URL: https://issues.jboss.org/browse/WFLY-4487 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > Attachments: cdi-interceptors.zip > > > CDI Interceptor cannot inject Web Service context. > When trying to inject WebServiceContext in CDI Interceptor using @Resource annotation but it fails with: NameNotFoundException: env/org.example.MyInterceptor/webServiceContext -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4487) Unable to inject Web Service Context into CDI Interceptor

by Mustafa Musaji (JIRA)

[ https://issues.jboss.org/browse/WFLY-4487?page=com.atlassian.jira.plugin.... ] Mustafa Musaji updated WFLY-4487: --------------------------------- Description: CDI Interceptor cannot inject Web Service context. When trying to inject WebServiceContext in CDI Interceptor using @Resource annotation but it fails with: NameNotFoundException: env/org.example.MyInterceptor/webServiceContext > Unable to inject Web Service Context into CDI Interceptor > --------------------------------------------------------- > > Key: WFLY-4487 > URL: https://issues.jboss.org/browse/WFLY-4487 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > Attachments: cdi-interceptors.zip > > > CDI Interceptor cannot inject Web Service context. > When trying to inject WebServiceContext in CDI Interceptor using @Resource annotation but it fails with: NameNotFoundException: env/org.example.MyInterceptor/webServiceContext -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4487) Unable to inject Web Service Context into CDI Interceptor

by Mustafa Musaji (JIRA)

[ https://issues.jboss.org/browse/WFLY-4487?page=com.atlassian.jira.plugin.... ] Mustafa Musaji updated WFLY-4487: --------------------------------- Bugzilla Update: (was: Perform) > Unable to inject Web Service Context into CDI Interceptor > --------------------------------------------------------- > > Key: WFLY-4487 > URL: https://issues.jboss.org/browse/WFLY-4487 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4487) Unable to inject Web Service Context into CDI Interceptor

by Mustafa Musaji (JIRA)

[ https://issues.jboss.org/browse/WFLY-4487?page=com.atlassian.jira.plugin.... ] Mustafa Musaji updated WFLY-4487: --------------------------------- Description: (was: CDI Interceptor cannot inject EJB session context. If the Interceptor is changed to EJB interceptor by removing the @Interceptor on the interceptor and removing it from the beans.xml, and adding @Interceptors(...) to the EJB, then it is able to inject. See attached reproducer with source and log file. private @Resource SessionContext sessionContext; Caused by: javax.naming.NameNotFoundException: env/test.ServiceLoggedInterceptor/sessionContext -- service jboss.naming.context.java.comp.inject-ejb-context-into-cdi-interceptor.inject-ejb-context-into-cdi-interceptor.HelloEJB.env."test.ServiceLoggedInterceptor".sessionContext at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185) ... 127 more ) Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6759, https://github.com/wildfly/wildfly/pull/6893) > Unable to inject Web Service Context into CDI Interceptor > --------------------------------------------------------- > > Key: WFLY-4487 > URL: https://issues.jboss.org/browse/WFLY-4487 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015