November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-900) java.lang.IncompatibleClassChangeError error while using HashSets

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-900?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-900: ------------------------------------------------ Edson Tirelli <etirelli(a)redhat.com> changed the Status of [bug 1278059|https://bugzilla.redhat.com/show_bug.cgi?id=1278059] from ASSIGNED to MODIFIED > java.lang.IncompatibleClassChangeError error while using HashSets > ----------------------------------------------------------------- > > Key: DROOLS-900 > URL: https://issues.jboss.org/browse/DROOLS-900 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 5.6.0.Final > Reporter: Pravasis Pattnaik > Assignee: Mario Fusco > Priority: Minor > Fix For: 6.3.0.Final > > Attachments: compiled-drl.txt, req.txt > > > In the compiled drl file we were using (Sets.newHashSet(e1,e2,..)).contains(input) then we get an exception java.lang.IncompatibleClassChangeError: Class XYZ does not implement the requested interface java.util.Collection on large input sets.Here XYZ is our input ruleRequest to be evaluated. If I change it to Sets.newHashSet(e1,e2,..).contains(input) it fixes everything. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1073) HcExtensionAndSubsystemManagementTestCase intermittently fails

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1073?page=com.atlassian.jira.plugi... ] Petr Kremensky commented on WFCORE-1073: ---------------------------------------- I retested this with 2.0.0.CR8 and test no longer fails, thus closing. https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-HcExtensionAn... > HcExtensionAndSubsystemManagementTestCase intermittently fails > -------------------------------------------------------------- > > Key: WFCORE-1073 > URL: https://issues.jboss.org/browse/WFCORE-1073 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.0.0.CR7 > Reporter: Petr Kremensky > Assignee: Brian Stansberry > Attachments: TEST-org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.xml > > > org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase intermittently fails in getRunningServers(). > {noformat} > org.junit.ComparisonFailure: { > "outcome" => "failed", > "rolled-back" => true > } expected:<[success]> but was:<[failed]> > at org.junit.Assert.assertEquals(Assert.java:115) > at org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.getRunningServers(HcExtensionAndSubsystemManagementTestCase.java:134) > at org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.awaitServers(HcExtensionAndSubsystemManagementTestCase.java:475) > at org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.reloadHostsIfReloadRequired(HcExtensionAndSubsystemManagementTestCase.java:461) > at org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.reloadHostsIfReloadRequired(HcExtensionAndSubsystemManagementTestCase.java:439) > at org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.checkSocketBindingCapabilities(HcExtensionAndSubsystemManagementTestCase.java:350) > at org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.testSocketBindingCapabilities(HcExtensionAndSubsystemManagementTestCase.java:184) > {noformat} > reproducer job running the testcase in i=20 loop: > \- [eap-7x-HcExtensionAndSubsystemManagementTestCase-reproducer|https://jenki...] > Attaching surefire report from one of failed configuration (although it doesn't seem to contain any kind of useful information in this case), server logs can be found in jobs [console|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-HcExt...] or among the stored [artifacts|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-HcE...]. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1073) HcExtensionAndSubsystemManagementTestCase intermittently fails

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1073?page=com.atlassian.jira.plugi... ] Petr Kremensky closed WFCORE-1073. ---------------------------------- Resolution: Done > HcExtensionAndSubsystemManagementTestCase intermittently fails > -------------------------------------------------------------- > > Key: WFCORE-1073 > URL: https://issues.jboss.org/browse/WFCORE-1073 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.0.0.CR7 > Reporter: Petr Kremensky > Assignee: Brian Stansberry > Attachments: TEST-org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.xml > > > org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase intermittently fails in getRunningServers(). > {noformat} > org.junit.ComparisonFailure: { > "outcome" => "failed", > "rolled-back" => true > } expected:<[success]> but was:<[failed]> > at org.junit.Assert.assertEquals(Assert.java:115) > at org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.getRunningServers(HcExtensionAndSubsystemManagementTestCase.java:134) > at org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.awaitServers(HcExtensionAndSubsystemManagementTestCase.java:475) > at org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.reloadHostsIfReloadRequired(HcExtensionAndSubsystemManagementTestCase.java:461) > at org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.reloadHostsIfReloadRequired(HcExtensionAndSubsystemManagementTestCase.java:439) > at org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.checkSocketBindingCapabilities(HcExtensionAndSubsystemManagementTestCase.java:350) > at org.jboss.as.test.integration.domain.suites.HcExtensionAndSubsystemManagementTestCase.testSocketBindingCapabilities(HcExtensionAndSubsystemManagementTestCase.java:184) > {noformat} > reproducer job running the testcase in i=20 loop: > \- [eap-7x-HcExtensionAndSubsystemManagementTestCase-reproducer|https://jenki...] > Attaching surefire report from one of failed configuration (although it doesn't seem to contain any kind of useful information in this case), server logs can be found in jobs [console|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-HcExt...] or among the stored [artifacts|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-HcE...]. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5633) Resurrect ARQ domain managed container

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-5633?page=com.atlassian.jira.plugin.... ] Thomas Diesler updated WFLY-5633: --------------------------------- Summary: Resurrect ARQ domain managed container (was: Resurrect ARQ managed domain container) > Resurrect ARQ domain managed container > -------------------------------------- > > Key: WFLY-5633 > URL: https://issues.jboss.org/browse/WFLY-5633 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Thomas Diesler > Assignee: Thomas Diesler > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5633) Resurrect ARQ container domain managed

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-5633?page=com.atlassian.jira.plugin.... ] Thomas Diesler updated WFLY-5633: --------------------------------- Summary: Resurrect ARQ container domain managed (was: Resurrect ARQ domain managed container) > Resurrect ARQ container domain managed > -------------------------------------- > > Key: WFLY-5633 > URL: https://issues.jboss.org/browse/WFLY-5633 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Thomas Diesler > Assignee: Thomas Diesler > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1009) Treat intra-domain transactional ":reload" and ":shutdown" requests similarly to how we handle end user requests

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1009?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet commented on WFCORE-1009: ------------------------------------------- The having the reload working this way is quite difficult as the restarting server tries to register itself in the same 'transaction' as when it stopped thus making the operation 'blocking'. There is no simple workaround for this behaviour and changing it might result in unexpected changes. > Treat intra-domain transactional ":reload" and ":shutdown" requests similarly to how we handle end user requests > ---------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1009 > URL: https://issues.jboss.org/browse/WFCORE-1009 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > > ModelControllerClientOperationHandler.ExecuteRequestHandler has special logic for the ":reload" op such that once the operation notifies that it is prepared, it immediately sends the final "success" result to the client, not waiting for the op execution to return to send it. This allows the response to go out to the client before the reload starts shutting down services. WFCORE-1008 proposes expanding this to the ":shutdown" operation as well. > This JIRA proposes expanding this to the TransactionalProtocolOperationHandler used for intra-domain process requests as well. > The implementation here would be slightly different in that the response to the prepared notification from the op would be unchanged. What would change would be the handling of the tx commit coming from the client. The tx commit message handling would send the response instead of waiting for the original op to complete. > The client side state related to the status of the reloading/shutting down slave HC or server should be fine. A master HC's tracking of slaves is unaffected by proxying a reload or shutdown op; it monitors the master<->slave comm channel to track the slave. Same thing for an HC reloading a server. For the case where an HC is stopping a server by sending a ":shutdown" request, the response to the request puts the HC's view of the server's state into InternalState.PROCESS_STOPPING. This state is valid as soon as the HC commits the ":shutdown" request, so this JIRA is consistent with that handling. > (Note: This special handling of ":reload" isn't a perfect thing, as it only covers the direct use of the ":reload" op. It doesn't cover things like a reload as a step in a composite. For the composite case, we need to give the step handlers for the other steps a chance to run any ResultHandlers they have registered and fix up the response before we send it back, so we can't just ignore that part of the execution.) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-362) Where we use RealmCallback we should fallback to getDefaultText if getTest returns null.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-362: ------------------------------------ Summary: Where we use RealmCallback we should fallback to getDefaultText if getTest returns null. Key: ELY-362 URL: https://issues.jboss.org/browse/ELY-362 Project: WildFly Elytron Issue Type: Bug Components: API / SPI Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta2 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5643) h:graphicImage cannot show

by Seigo HOSHI (JIRA)

[ https://issues.jboss.org/browse/WFLY-5643?page=com.atlassian.jira.plugin.... ] Seigo HOSHI closed WFLY-5643. ----------------------------- Resolution: Incomplete Description > h:graphicImage cannot show > -------------------------- > > Key: WFLY-5643 > URL: https://issues.jboss.org/browse/WFLY-5643 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 9.0.2.Final > Reporter: Seigo HOSHI > Assignee: Farah Juma > > The following tag cannot show image in WildFly 9.0.2.Final. > <h:graphicImage library="image/aaa" name="bbb.png"/> > It has shown in 9.0.1.Final. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5645) Use script name for file related to Wildfly to allow multiple instances easily

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5645?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5645: ----------------------------------------------- Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1265740|https://bugzilla.redhat.com/show_bug.cgi?id=1265740] from ASSIGNED to POST > Use script name for file related to Wildfly to allow multiple instances easily > ------------------------------------------------------------------------------ > > Key: WFLY-5645 > URL: https://issues.jboss.org/browse/WFLY-5645 > Project: WildFly > Issue Type: Enhancement > Components: Scripts > Affects Versions: 10.0.0.CR4 > Reporter: Romain Pelisse > Assignee: Tomaz Cerar > Priority: Optional > Original Estimate: 1 day > Remaining Estimate: 1 day > > With the current provided init.d script, one cannot start several instances of Wildfly. Indeed, the script will associate the same files (pid file, log) to both instance. If we rename those files using, for instance, the name of the script we can easily use the *exact same script* for all local instances: > {code:bash} > # ln -s ..../init.d/wildfly-initd-redhat.sh /etc/init.d/wildfly-1 > # ln -s ..../init.d/wildfly-initd-redhat.sh /etc/init.d/wildfly-2 > {code} > And to take the example of the PIDFILE: > {code:bash} > JBOSS_PIDFILE=/var/run/$(basename $0)/jboss-as-domain.pid > {code} > Each links will then look up and creates its own separate file: > /var/run/wildfly-1/jboss-as-domain.pid > /var/run/wildfly-2/jboss-as-domain.pid -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5645) Use script name for file related to Wildfly to allow multiple instances easily

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5645?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-5645: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1265740 > Use script name for file related to Wildfly to allow multiple instances easily > ------------------------------------------------------------------------------ > > Key: WFLY-5645 > URL: https://issues.jboss.org/browse/WFLY-5645 > Project: WildFly > Issue Type: Enhancement > Components: Scripts > Affects Versions: 10.0.0.CR4 > Reporter: Romain Pelisse > Assignee: Tomaz Cerar > Priority: Optional > Original Estimate: 1 day > Remaining Estimate: 1 day > > With the current provided init.d script, one cannot start several instances of Wildfly. Indeed, the script will associate the same files (pid file, log) to both instance. If we rename those files using, for instance, the name of the script we can easily use the *exact same script* for all local instances: > {code:bash} > # ln -s ..../init.d/wildfly-initd-redhat.sh /etc/init.d/wildfly-1 > # ln -s ..../init.d/wildfly-initd-redhat.sh /etc/init.d/wildfly-2 > {code} > And to take the example of the PIDFILE: > {code:bash} > JBOSS_PIDFILE=/var/run/$(basename $0)/jboss-as-domain.pid > {code} > Each links will then look up and creates its own separate file: > /var/run/wildfly-1/jboss-as-domain.pid > /var/run/wildfly-2/jboss-as-domain.pid -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 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 November 2015