January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1410) Add pause/restart features to drools workbench rules

by angelo difino (JIRA)

angelo difino created DROOLS-1410: ------------------------------------- Summary: Add pause/restart features to drools workbench rules Key: DROOLS-1410 URL: https://issues.jboss.org/browse/DROOLS-1410 Project: Drools Issue Type: Feature Request Components: core engine, tools Affects Versions: 6.5.0.Final Reporter: angelo difino Assignee: Mario Fusco Priority: Minor It should be nice to have a features in the Drools Workbench to signal a Rule for PAUSE/RESTART, so it can be possible to temporarly remove or insert again the Rule in the overall reasoning. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3316) Multi threaded ejb invocations via remote-naming produce EJBCLIENT000025 if the Context is closed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3316?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3316: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1094380|https://bugzilla.redhat.com/show_bug.cgi?id=1094380] from VERIFIED to CLOSED > Multi threaded ejb invocations via remote-naming produce EJBCLIENT000025 if the Context is closed > ------------------------------------------------------------------------------------------------- > > Key: WFLY-3316 > URL: https://issues.jboss.org/browse/WFLY-3316 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Wolf-Dieter Fink > Assignee: Enrique González Martínez > Labels: ejb, naming, remote-clients, remote-ejb-connection > Attachments: reproducer.zip > > > If a client run multi threads and each Thread use it's own InitialContext the behaviour is unexpected. > The behaviour is as followed: > if each invocation create it's own IC and lookup the EJB there is sometimes a EJBCLIENT000025 because one of the one thread has closed the IC until another thread try to invoke an EJB. > If the IC is reused the failure might happen only if the first Thread has finished the invocations and close the IC during other Threads are still running. > It looks that the underlying remote connection will be closed if the first IC is closed without respect that there are different IC's created and still in use. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-29) An ear file with modules in subfolders can not deploy under AS 7.0

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-29?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration commented on WFLY-29: --------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1206635|https://bugzilla.redhat.com/show_bug.cgi?id=1206635] from VERIFIED to CLOSED > An ear file with modules in subfolders can not deploy under AS 7.0 > ------------------------------------------------------------------ > > Key: WFLY-29 > URL: https://issues.jboss.org/browse/WFLY-29 > Project: WildFly > Issue Type: Bug > Components: EE > Reporter: Adrian Zuo > Assignee: Stuart Douglas > Fix For: 8.1.0.CR2, 8.1.0.Final > > Attachments: migrate.ear, migrate.ear > > > I have an ear file names migrate.ear which contains one ejb jar (ejb.jar) and one war file (war.war), if I put the ejb jar to a ejb folder and war file to war folder, the ear can not be depoyed. > If I move the ejb jar and war file out, it can be deployed. > Below structuer can be deployed: > ejb.jar > lib/ > lib/util-1.0-SNAPSHOT.jar > lib/version.jar > META-INF/ > META-INF/application.xml > META-INF/MANIFEST.MF > war.war > > Below structure can not be deployed: > ejb/ > ejb/ejb.jar > lib/ > lib/util-1.0-SNAPSHOT.jar > lib/version.jar > META-INF/ > META-INF/application.xml > META-INF/MANIFEST.MF > war/ > war/war.war > Below is the error: > http://community.jboss.org/message/630869#630869 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3947) Incorrect EJB Calendar Based Timeouts

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3947?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3947: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1213875|https://bugzilla.redhat.com/show_bug.cgi?id=1213875] from VERIFIED to CLOSED > Incorrect EJB Calendar Based Timeouts > -------------------------------------- > > Key: WFLY-3947 > URL: https://issues.jboss.org/browse/WFLY-3947 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Fix For: 9.0.0.Beta1 > > > EJB3 CalendarBasedTimeout computes incorrects timeouts due to bad Calendar time fields manipulation, specially on DST. > A couple of examples: > 1) Timezone: "Europe/Lisbon" > Schedule Expression: any day at 1h30m > Start: 2013/03/31 03h30m > First timeout currently is 2h30m > 2) Timezone: "Australia/Lord_Howe" > Schedule Expression: any day at 2h20m, 2h40m, 3h20m, 3h40m > Start: 2013/10/06 02h41m > First timeout currently is 3h50m -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4470) Duplicate message deliveries when start an MDB twice via CLI

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4470?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4470: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1159572|https://bugzilla.redhat.com/show_bug.cgi?id=1159572] from VERIFIED to CLOSED > Duplicate message deliveries when start an MDB twice via CLI > ------------------------------------------------------------- > > Key: WFLY-4470 > URL: https://issues.jboss.org/browse/WFLY-4470 > Project: WildFly > Issue Type: Bug > Components: EJB, JMS > Affects Versions: 9.0.0.Beta2 > Reporter: Chao Wang > Assignee: Chao Wang > Fix For: 9.0.0.CR1 > > > Description of problem: > A singleton MDB delivers duplicate messages when start-delivery() is invoked twice while the message being delivered > Steps to Reproduce: > 1. Create a producer, which keeps sending messages for every second > 2. Deploy a singleton consumer MDB > 3. Invoke start-delivery() method on the MDB while the messages being delivered > Actual results: > MDB delivers duplicate messages > Expected results: > MDB needs to ignore start-delivery() call if the MDB has already been started. > Additional info: -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3778) Tests in Manualmode test suite fail occasionally

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3778?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3778: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1105003|https://bugzilla.redhat.com/show_bug.cgi?id=1105003] from VERIFIED to CLOSED > Tests in Manualmode test suite fail occasionally > ------------------------------------------------ > > Key: WFLY-3778 > URL: https://issues.jboss.org/browse/WFLY-3778 > Project: WildFly > Issue Type: Bug > Components: Remoting, Test Suite > Affects Versions: 9.0.0.Alpha1 > Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_67. > Reporter: Frank Langelage > Assignee: David Lloyd > Fix For: 10.0.0.CR4 > > Attachments: TEST-org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.xml, org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase-output.txt, org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.txt > > > I always see failures in one or few test of manualmode test suite on this platform. I not remember to have seen them on Windows 7. > But I saw a very similar failure today on Linux first time for PR 6638. > See https://github.com/wildfly/wildfly/pull/6638. > Last failure on my machine: > {noformat} > Running org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase > Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.186 sec <<< FAILURE! - in org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase > testRightVaultPassword(org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase) Time elapsed: 6.23 sec <<< FAILURE! > java.lang.AssertionError: Password should be right and authentication successful > Expected: a string containing "\"outcome\" => \"success\"" > but: was "0: INFO [org.jboss.modules] JBoss Modules version 1.3.4.Final > INFO [org.jboss.security] PBOX000361: Default Security Vault Implementation Initialized and Ready > INFO [org.xnio] XNIO version 3.3.0.Beta1 > INFO [org.xnio.nio] XNIO NIO Implementation Version 3.3.0.Beta1 > INFO [org.jboss.remoting] JBoss Remoting version 4.0.3.Final > " > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) > at org.junit.Assert.assertThat(Assert.java:865) > at org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.testRightVaultPassword(VaultPasswordsInCLITestCase.java:158) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-385) Add overridable flag to servlet metadata

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBMETA-385?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBMETA-385: ------------------------------------------------ Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1196515|https://bugzilla.redhat.com/show_bug.cgi?id=1196515] from VERIFIED to CLOSED > Add overridable flag to servlet metadata > ---------------------------------------- > > Key: JBMETA-385 > URL: https://issues.jboss.org/browse/JBMETA-385 > Project: JBoss Metadata > Issue Type: Enhancement > Components: web > Affects Versions: 7.2.1.Final > Reporter: James Livingston > Assignee: Bartosz Baranowski > Fix For: 7.2.2.Final > > > To resolve https://bugzilla.redhat.com/show_bug.cgi?id=1094248, I believe we need an additional 'overridable' flag on the servlet metadata which indicates whether ServletContainerInitializers (and other code using servlet dynamic registration) should be allowed to override the servlet. Normally this is not allowed, however JBWeb's internal use of DefaultServlet to handle static resources should be. > This only needs to go into 7, since the Undertow subsystem in Wildfly handles this quite differently, so does not need to pass a flag between components. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2152) ASYM_ENCRYPT failure on Wildfly 10.1.0

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2152?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2152: -------------------------------- [~mwringe] [~rachmato] Can we close this issue? > ASYM_ENCRYPT failure on Wildfly 10.1.0 > -------------------------------------- > > Key: JGRP-2152 > URL: https://issues.jboss.org/browse/JGRP-2152 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Matt Wringe > Assignee: Bela Ban > Fix For: 4.0, 3.6.13 > > Attachments: hawkular-metrics-1.log, hawkular-metrics-2.log, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean.txt, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean2.txt, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output.txt, standalone.xml > > > Using ASYM_ENCRYPT on Wildfly 10.1.0 seems to be broken. > I am using the parameters for ASYM_ENCRYPT specified in http://www.jgroups.org/manual/index.html#Security > Note: running with SYM_ENCRYPT doesn't cause any issues and it works fine with my setup. Its only ASYM_ENCRYPT which is currently failing. > Note: running this on EAP fails in a similar manner. > Eg: > <protocol type="ASYM_ENCRYPT"> > <property name="encrypt_entire_message">true</property> > <property name="sym_keylength">128</property> > <property name="sym_algorithm">AES/ECB/PKCS5Padding</property> > <property name="asym_keylength">512</property> > <property name="asym_algorithm">RSA</property> > </protocol> > If I run a single instance, then I don't see any problems appear in the logs. Its when I start a second instance that I start to see errors about unrecognised ciphers and timeouts. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7894) logging statement to trace remoting heartbeat

by Peter Palaga (JIRA)

Peter Palaga created WFLY-7894: ---------------------------------- Summary: logging statement to trace remoting heartbeat Key: WFLY-7894 URL: https://issues.jboss.org/browse/WFLY-7894 Project: WildFly Issue Type: Enhancement Components: EJB Affects Versions: JBoss AS7 7.2.0.Final Reporter: Peter Palaga Assignee: Peter Palaga Priority: Minor you can set the heartbeat on a remoting connection by setting: remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL What is missing is the option to log on the client when the heartbeat message is fired. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2201) Attempt to remove read-only /path=<x> logs exception to server.log

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2201?page=com.atlassian.jira.plugi... ] Chao Wang commented on WFCORE-2201: ----------------------------------- The exception we see in server.log is from PathManagerService.removePathEntry(), But PathRemoveHandler.execute() should verify it earlier. However, Resource.Tools.readModel(context.readResource(PathAddress.EMPTY_ADDRESS)); ignores runtime-only resource with ALL_BUT_RUNTIME_AND_PROXIES_FILTER, it therefore returns a new empty ModelNode without any READ_ONLY set. > Attempt to remove read-only /path=<x> logs exception to server.log > ------------------------------------------------------------------ > > Key: WFCORE-2201 > URL: https://issues.jboss.org/browse/WFCORE-2201 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha19 > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Minor > > When trying to remove read-only, preset paths, exception is logged in server log. > I think this is not necessary and only the response on CLI or other side is sufficient: {code:java} > [standalone@localhost:9990 /] /path=java.home:remove() > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYCTL0257: Path entry is read-only: 'java.home'", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 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 2017