[JBoss JIRA] (DROOLS-695) Add ability to disable rules in the workbench
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-695?page=com.atlassian.jira.plugin... ]
Michael Anstis moved GUVNOR-2162 to DROOLS-695:
-----------------------------------------------
Project: Drools (was: Guvnor)
Key: DROOLS-695 (was: GUVNOR-2162)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Affects Version/s: 6.2.0.CR4
(was: drools_6.1.0.Final)
> Add ability to disable rules in the workbench
> ---------------------------------------------
>
> Key: DROOLS-695
> URL: https://issues.jboss.org/browse/DROOLS-695
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR4
> Environment: RedHat Linux 6.3 x86_64; Firefox 10.0.5
> Reporter: Stephen Slaboda
> Labels: drools-wb
>
> Many times while working on rules, it would be helpful to be able to disable other rules. Reasons for doing this would be:
> -Testing outside of the workbench (ensure your process using Drools activates certain rules, without the clutter of other rules firing)
> -Turn off rules if it is determined that they are impacitng the operational environment
> -Allow development of rules in the same space while not breaking the build/deploy of rules
> -Allow for inclusion of rules in the operation system that do not run until approved, while still allowing other updates to occur in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4277) Support annotation-property-replacement option in @JMSConnectionFactory, @JMSPasswordCredential
by Tim Russell (JIRA)
Tim Russell created WFLY-4277:
---------------------------------
Summary: Support annotation-property-replacement option in @JMSConnectionFactory, @JMSPasswordCredential
Key: WFLY-4277
URL: https://issues.jboss.org/browse/WFLY-4277
Project: WildFly
Issue Type: Feature Request
Components: JMS
Affects Versions: 8.2.0.Final
Reporter: Tim Russell
Assignee: Jeff Mesnil
See org.jboss.as.messaging.deployment.JMSContextProducer, getJMSContext. Currently the values in JMSConnectionFactory and JMSPasswordCredential are do not go through the property replacement process. Doing so would be nice in order to externalize configuration settings, e.g.
{code:java}
@Inject
@JMSConnectionFactory("${remoteConnectionFactoryName}")
private JMSContext context;
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-3664) Exceptions during download of webstart libraries
by Christian Bourque (JIRA)
[ https://issues.jboss.org/browse/WFLY-3664?page=com.atlassian.jira.plugin.... ]
Christian Bourque commented on WFLY-3664:
-----------------------------------------
This is a critical problem for us because when this happens we sometimes get a "Too many open files" error and then Wildfly undeploy our application:
2015-01-21 08:17:45,306 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015004: Caught exception writing deployment marker file /home/masterdev/opt/wildfly/standalone/deployments/TEST-1.0-SNAPSHOT.war.isundeploying: java.io.FileNotFoundException: /home/masterdev/opt/wildfly/standalone/deployments/TEST-1.0-SNAPSHOT.war.isundeploying (Too many open files)
at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_72]
at java.io.FileOutputStream.<init>(FileOutputStream.java:221) [rt.jar:1.7.0_72]
at java.io.FileOutputStream.<init>(FileOutputStream.java:171) [rt.jar:1.7.0_72]
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.createMarkerFile(FileSystemDeploymentService.java:984) [wildfly-deployment-scanner-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.access$2800(FileSystemDeploymentService.java:83) [wildfly-deployment-scanner-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScannerTask.recordInProgress(FileSystemDeploymentService.java:1044) [wildfly-deployment-scanner-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:431) [wildfly-deployment-scanner-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:147) [wildfly-deployment-scanner-8.2.0.Final.jar:8.2.0.Final]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_72]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) [rt.jar:1.7.0_72]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_72]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.7.0_72]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
...
> Exceptions during download of webstart libraries
> ------------------------------------------------
>
> Key: WFLY-3664
> URL: https://issues.jboss.org/browse/WFLY-3664
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Windows 7 (64bit), Windows Server 2012 R2 (64bit)
> Reporter: Markus Schwarz
> Assignee: Stuart Douglas
> Priority: Minor
> Attachments: demo-src.zip, server.log
>
>
> I have a webstart application using the JnlpDownloadServlet. If the client cache is empty, launching the JNLP will download the libraries. The webstart application works as expected, but in the server logs there are many errors regarding download of the libraries.
> Just to mention: Not always the same libraries are listed with erros in the logs files. Sometimes I even got now exceptions.
> For my tests I used Wildfly 8.1.0.FINAL as well as a nightly build from 24. of July without any further changes of the configuration files (https://ci.jboss.org/hudson/job/WildFly-latest-master/).
> I tested it under Windows 7 and Windows Server 2012 R2. The demo contains an older JnlpDownloadServlet, but I tested it also with the one coming with JDK 7u65.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-3549) Deadlock during shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3549?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3549:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1184532
> Deadlock during shutdown
> ------------------------
>
> Key: WFLY-3549
> URL: https://issues.jboss.org/browse/WFLY-3549
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: David Lloyd
> Fix For: 8.2.0.Final
>
>
> This deadlock appeared in an Arquillian test:
> {noformat}
> Found one Java-level deadlock:
> =============================
> "undefined":
> waiting to lock monitor 0x00007f67a421bfa8 (object 0x00000000e0700480, a org.jboss.as.threads.ScheduledThreadPoolService),
> which is held by "MSC service thread 1-2"
> "MSC service thread 1-2":
> waiting for ownable synchronizer 0x00000000e0700618, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "undefined"
> Java stack information for the threads listed above:
> ===================================================
> "undefined":
> at org.jboss.as.threads.ScheduledThreadPoolService$ExecutorImpl.terminated(ScheduledThreadPoolService.java:121)
> - waiting to lock <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService)
> at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:704)
> at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1006)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1163)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> "MSC service thread 1-2":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000e0700618> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> at java.util.concurrent.ThreadPoolExecutor.interruptIdleWorkers(ThreadPoolExecutor.java:781)
> at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:695)
> at java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1397)
> at java.util.concurrent.ScheduledThreadPoolExecutor.shutdown(ScheduledThreadPoolExecutor.java:759)
> at org.jboss.as.threads.ManagedScheduledExecutorService.internalShutdown(ManagedScheduledExecutorService.java:53)
> at org.jboss.as.threads.ScheduledThreadPoolService.stop(ScheduledThreadPoolService.java:67)
> - locked <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> 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:724)
> Found 1 deadlock.
> {noformat}
> Looks like two MSC service threads exited and tried to terminate the thread pool at the same time. And because the MSC threads are not daemon threads, the entire JVM hangs and blocks the Arquillian test that was waiting for the container to shut down.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1876:
--------------------------------
Hi Karim,
can you first define what the problem you are looking at is ? Is it the original issue for which I created this JIRA, or the issue that caused it to get re-opened ?
Yes, I'd like to take a look at the PR.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, JGRP-1876-1.pdf, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4250) Manually created CDI producer methods in the Extension are not injected
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-4250?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger commented on WFLY-4250:
---------------------------------------
Confirmed that it is a bug in wildfly-weld integration code.
> 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: Jozef Hartinger
>
> 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, 4 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Karim AMMOUS (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Karim AMMOUS commented on JGRP-1876:
------------------------------------
Bela: I wrote a least intrusive fix to address this problem. If you agree, I can commit it on my fork to check if it is eligible to be a PR.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, JGRP-1876-1.pdf, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4275) All EE components attached to an implicit bean archive are recognized as implicit beans
by Martin Kouba (JIRA)
Martin Kouba created WFLY-4275:
----------------------------------
Summary: All EE components attached to an implicit bean archive are recognized as implicit beans
Key: WFLY-4275
URL: https://issues.jboss.org/browse/WFLY-4275
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 9.0.0.Alpha1
Reporter: Martin Kouba
Assignee: Martin Kouba
This is no longer necessary (see also WELD-1612). Furhtermore, it's producing confusing results. For example, an {{ProcessBeanAttributes}} event is fired for {{com.sun.faces.config.ConfigureListener}}, {{org.jboss.weld.servlet.WeldInitialListener}} and other implicitly added EE components.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months