January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-684) Drools Work bench not allowing in .XLSX to upload

by Ramesh C (JIRA)

Ramesh C created DROOLS-684: ------------------------------- Summary: Drools Work bench not allowing in .XLSX to upload Key: DROOLS-684 URL: https://issues.jboss.org/browse/DROOLS-684 Project: Drools Issue Type: Bug Affects Versions: 6.2.0.CR4 Environment: Google Chrome Browser / JDK1.7 / Jboss7.1 / WB-6.2.0-CR4 Reporter: Ramesh C Assignee: Mark Proctor while creating a decision table in workbench, if we try to upload .XLSX, java script validation is failing. Alert is showing as "Upload only .xls" files. kindly correct the java script validation. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3285) Domain directory properties only work on specific operating systems

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3285?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-3285. ------------------------------- Assignee: James Perkins (was: Tomaz Cerar) Fix Version/s: 9.0.0.Beta1 Resolution: Done > Domain directory properties only work on specific operating systems > ------------------------------------------------------------------- > > Key: WFLY-3285 > URL: https://issues.jboss.org/browse/WFLY-3285 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.1.0.CR1 > Reporter: Dennis Reed > Assignee: James Perkins > Fix For: 9.0.0.Beta1 > > > domain.sh only parses -Djboss.domain.base.dir, -Djboss.domain.log.dir, and -Djboss.domain.config.dir (used to set -Dlogging.configuration and -Dorg.jboss.boot.log.file) on Linux, Solaris, and OS X. > It does not attempt to parse these (and therefore does not set the logging properties correctly) on any other OS, including AIX. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3285) Domain directory properties only work on specific operating systems

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3285?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3285: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1091198|https://bugzilla.redhat.com/show_bug.cgi?id=1091198] from ON_QA to VERIFIED > Domain directory properties only work on specific operating systems > ------------------------------------------------------------------- > > Key: WFLY-3285 > URL: https://issues.jboss.org/browse/WFLY-3285 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.1.0.CR1 > Reporter: Dennis Reed > Assignee: Tomaz Cerar > > domain.sh only parses -Djboss.domain.base.dir, -Djboss.domain.log.dir, and -Djboss.domain.config.dir (used to set -Dlogging.configuration and -Dorg.jboss.boot.log.file) on Linux, Solaris, and OS X. > It does not attempt to parse these (and therefore does not set the logging properties correctly) on any other OS, including AIX. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

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

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski commented on WFLY-4198: ------------------------------------------ Is there any chance I can get my hands on some sort of reproducer? Ive set up arquillian testcase and so far I wasnt able to trigger NPE. > 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 :(. > 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) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4216) when ever i deploy my ear file, i get this error

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4216?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-4216. ----------------------------- Resolution: Rejected any vague problems like this should be first discussed in forums before creating bug reports you can find forums at https://community.jboss.org/en/wildfly > when ever i deploy my ear file, i get this error > ------------------------------------------------ > > Key: WFLY-4216 > URL: https://issues.jboss.org/browse/WFLY-4216 > Project: WildFly > Issue Type: Bug > Reporter: oma sung > Assignee: Bartosz Baranowski > Priority: Optional > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4184) add listDeliveringMessage to messaging's queue resource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4184?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4184: ----------------------------------------------- Ondřej Kalman <okalman(a)redhat.com> changed the Status of [bug 1174152|https://bugzilla.redhat.com/show_bug.cgi?id=1174152] from ON_QA to VERIFIED > add listDeliveringMessage to messaging's queue resource > ------------------------------------------------------- > > Key: WFLY-4184 > URL: https://issues.jboss.org/browse/WFLY-4184 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > Since HornetQ 2.3.0, the QueueControl interface provides a listDeliveringMessages to list all the message delivered to the queue's consumers (and not acknowledged). > This operation must be made available to the messaging's core-queue (and runtime-queue) resources. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4250) Manually created CDI producer methods in the Extension are not injected

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created WFLY-4250: ----------------------------------------- Summary: Manually created CDI producer methods in the Extension are not injected Key: WFLY-4250 URL: https://issues.jboss.org/browse/WFLY-4250 Project: WildFly Issue Type: Bug Components: CDI / Weld Affects Versions: 8.2.0.Final Environment: Happened on Linux environment Reporter: Sebastian Łaskawiec Assignee: Stuart Douglas h2. Issue description: During migration from Wildfly 8.1 to 8.2 (Weld 2.1.2.Final -> 2.2.6.Final) in Infinispan we discovered a problem with injecting beans created programmatically in Infinispan-cdi integration module. The problem appeared in {{GreetingServiceIT}} and {{GreetingCacheManagerIT}} test. Both those tests use the following modules integrated into Wildfly: * org.infinispan.cdi (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" export="true") * org.infinispan.jcache (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" and "org.infinispan.cdi" slot="ispn-7.1" services="import") [Infinispan's CDI Extension|https://github.com/infinispan/infinispan/blob/master/cdi/src/ma...] invokes [{{embeddedExtension.registerCacheBeans(event, beanManager)}}|https://github.com/infinispan/infinispan/blob/master/cdi/s...], which registers custom {{Cache}} and {{AdvancedCache}} producer beans. Those beans are being successfully added to {{BeanManager}} but are never chosen for injection. All tests fail because of unsatisfied dependencies for {{Cache<CacheKey, String>}} with qualifiers {{@GreetingCache}}. h2. Steps to reproduce: * Download and unzip [https://github.com/slaskawi/infinispan/archive/upgrade_to_wf_8_2_failed_t...] * Run {{./build.sh clean install -pl cdi,as-modules/embedded,integrationtests/as-integration-embedded -am -DskipTests}} * Modify Arquillian xml if breakpoint is needed {{./integrationtests/as-integration-embedded/src/test/resources/arquillian.xml}} * Run test (using IDE or Maven: {{./build.sh test -pl integrationtests/as-integration-embedded -Dtest=GreetingServiceIT}}) h2. Finding during debugging: At first I would suggest creating conditional breakpoints: * {{org.jboss.weld.bootstrap.Validator}} line 370 (WF 8.2) or 366 (WF 8.1), condition {{"[BackedAnnotatedField] @Inject @GreetingCache private org.infinispan.test.integration.as.cdi.GreetingServiceIT.greetingCache".equals(ij.toString())}} - this will stop debugger when validating injection points for {{{GreetingCache}}. * {{org.jboss.weld.resolution.TypeSafeResolver.ResolvableToBeanCollection}} line 51, condition {{from.toString().startsWith("Types: [org.infinispan.Cache<javax.cache.annotation.CacheKey, java.lang.String>]") || from.toString().contains("org.infinispan.Cache")}} - this stops debugger on loading {{Cache}} producer methods (created in Infinispan CDI Extension) to {{resolved}} Loading Cache in Wildfly 8.1. During debugging session we discovered that the beans from Infinispan's CDI Extension are created but never used for injection. This is because {{beanManager.getBeans(ij)}} in {{Validator.java}} always return empty list. In Wildfly 8.1 beans are properly resolved using {{ResolvableToBeanCollection#load}} method, but for some reason it never happens in Wildfly 8.2, because those beans are already preset in {{resolved}} Loading Cache with empty collection value. Unfortunately we couldn't find answer why. h2. Workaround: In order to fix CDI Producer Beans accessibility we need to add a new dependency to our test: {{META-INF/MANIFEST.MF: Dependencies: org.infinispan:ispn-7.1}}. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-629) NullPointerException thrown on next call to insert and fireAllRules after stream garbage collection runs

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-629?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-629: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1181584|https://bugzilla.redhat.com/show_bug.cgi?id=1181584] from NEW to MODIFIED > NullPointerException thrown on next call to insert and fireAllRules after stream garbage collection runs > -------------------------------------------------------------------------------------------------------- > > Key: DROOLS-629 > URL: https://issues.jboss.org/browse/DROOLS-629 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.Beta3 > Reporter: Mike Wilson > Assignee: Mario Fusco > Fix For: 6.2.0.CR1 > > Attachments: drools-gc-causes-npe-example.zip > > > I have observed that the following NullPointerException (NPE) occurs consistently with a very specific set of rules and a very specific set of inputs into a stream session: > {code} > java.lang.NullPointerException > at org.drools.core.util.AbstractHashTable$SingleIndex.equal(AbstractHashTable.java:491) > at org.drools.core.util.index.LeftTupleList.matches(LeftTupleList.java:266) > at org.drools.core.util.index.LeftTupleIndexHashTable.get(LeftTupleIndexHashTable.java:434) > at org.drools.core.util.index.LeftTupleIndexHashTable.getFirst(LeftTupleIndexHashTable.java:217) > at org.drools.core.reteoo.BetaNode.getFirstLeftTuple(BetaNode.java:443) > at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:144) > at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:548) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:534) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:229) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:98) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:988) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1274) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1254) > ... > {code} > The exception always occurs on the next call to "insert" and "fireAllRules" after the following method is invoked within the session: org.drools.core.common.DefaultAgenda$DefaultGarbageCollector.forceGcUnlinkedRules(). > I have attached a maven project that contains a JUnit test, which reproduces this exception using Drools version 6.2.0.Beta3. > A side effect of this exeption occurring in the middle of fireAllRules is that an extra fact is left over in working memory, which is essentially a memory leak. I assume this is because the evaluation of the LHS of the rules is what causes the NPE to occur, so the fact is not deleted, because the RHS of the rules don't execute. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

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

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski reassigned WFLY-4198: ---------------------------------------- Assignee: Bartosz Baranowski (was: David Lloyd) > 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 :(. > 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) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4211) MBean implementation lifecycle methods in MSC threads

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4211?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski resolved WFLY-4211. -------------------------------------- Resolution: Done PR has been merged(2/1/2015), resolving as such. > MBean implementation lifecycle methods in MSC threads > ----------------------------------------------------- > > Key: WFLY-4211 > URL: https://issues.jboss.org/browse/WFLY-4211 > Project: WildFly > Issue Type: Bug > Components: JMX > Affects Versions: 9.0.0.Alpha1 > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Fix For: 9.0.0.Beta1 > > > MBean lifecycle methods should not be invoked from MSC threads, the implementation of these may block the thread, for instance due to a JNDI bind. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015