January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6092) Upgrade Narayana to 5.2.13.Final

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-6092?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on WFLY-6092: ------------------------------------- Narayana PR check: http://albany.eng.hst.ams2.redhat.com/job/release-narayana-AS-PR/92/console > Upgrade Narayana to 5.2.13.Final > -------------------------------- > > Key: WFLY-6092 > URL: https://issues.jboss.org/browse/WFLY-6092 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > https://issues.jboss.org/browse/JBTM/fixforversion/12329358/?selectedTab=... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6092) Upgrade Narayana to 5.2.13.Final

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-6092?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated WFLY-6092: -------------------------------- Description: https://issues.jboss.org/browse/JBTM/fixforversion/12329358/?selectedTab=... > Upgrade Narayana to 5.2.13.Final > -------------------------------- > > Key: WFLY-6092 > URL: https://issues.jboss.org/browse/WFLY-6092 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > https://issues.jboss.org/browse/JBTM/fixforversion/12329358/?selectedTab=... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ] Richard Janík commented on WFLY-5484: ------------------------------------- As with comment on WFLY-5932, I've tried with 1.3.16.Final, but I'm still not getting logged out on first try. > Calling HttpServletRequest.logout() with single sign-on enabled only works every second time > -------------------------------------------------------------------------------------------- > > Key: WFLY-5484 > URL: https://issues.jboss.org/browse/WFLY-5484 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Richard Janík > Assignee: Stuart Douglas > Priority: Blocker > Fix For: 10.0.0.CR5 > > Attachments: reproducer-jbeap-1282.zip > > > See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect > This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1045) kie-ci 6.3.0.Final conflicts with newer versions of Guava

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1045?page=com.atlassian.jira.plugi... ] Petr Široký edited comment on DROOLS-1045 at 1/29/16 6:51 AM: -------------------------------------------------------------- -[~abaxter] could you please attach simple Maven-based reproducer for this issue? I could not reproduce this issue with 6.3.0.Final, 6.4.0-SNAPSHOT and 7.0.0-SNAPSHOT.- Sorry, I was too quick. I added the creation of KieScanner object to your reproducer and can now see the issue. was (Author: psiroky): [~abaxter] could you please attach simple Maven-based reproducer for this issue? I could not reproduce this issue with 6.3.0.Final, 6.4.0-SNAPSHOT and 7.0.0-SNAPSHOT. > kie-ci 6.3.0.Final conflicts with newer versions of Guava > --------------------------------------------------------- > > Key: DROOLS-1045 > URL: https://issues.jboss.org/browse/DROOLS-1045 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Adam Baxter > Assignee: Petr Široký > > When using kie-ci with Google's Guava library (v19), we hit the following error: http://stackoverflow.com/questions/32528042/maven-java-lang-illegalaccess... > We solved this by excluding kie-ci's sisu-guice transitive dependency and including the 3.1.7 version released in 2014. > Please update kie-ci's dependencies such that this is no longer an issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1046) Threads blocking during ReteWorkingMemory initialization of facts

by Akshay Gehi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1046?page=com.atlassian.jira.plugi... ] Akshay Gehi commented on DROOLS-1046: ------------------------------------- Hi, One of the test cases had failed but it may not be related to this change. Do you think it would be safe to check this change in our codebase locally? > Threads blocking during ReteWorkingMemory initialization of facts > ----------------------------------------------------------------- > > Key: DROOLS-1046 > URL: https://issues.jboss.org/browse/DROOLS-1046 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Akshay Gehi > Assignee: Mario Fusco > > While initializing facts for the first time the following method in ReteWorkingMemory is invoked: > {code:java} > private final Integer syncLock = 42; > public void initInitialFact() { > if ( initialFactHandle == null ) { > synchronized ( syncLock ) { > if ( initialFactHandle == null ) { > // double check, inside of sync point incase some other thread beat us to it. > initInitialFact(kBase, null); > } > } > } > } > {code} > Since the synchronized lock is taken on a Integer constant variable, the same object gets used across different threads. This causes the initialization of all the ReteMemoryObjects to wait in the initInitialFact() method across different threads. > The lock should be taken on Object lock = new Object() instead -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1045) kie-ci 6.3.0.Final conflicts with newer versions of Guava

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1045?page=com.atlassian.jira.plugi... ] Petr Široký commented on DROOLS-1045: ------------------------------------- [~abaxter] could you please attach simple Maven-based reproducer for this issue? I could not reproduce this issue with 6.3.0.Final, 6.4.0-SNAPSHOT and 7.0.0-SNAPSHOT. > kie-ci 6.3.0.Final conflicts with newer versions of Guava > --------------------------------------------------------- > > Key: DROOLS-1045 > URL: https://issues.jboss.org/browse/DROOLS-1045 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Adam Baxter > Assignee: Petr Široký > > When using kie-ci with Google's Guava library (v19), we hit the following error: http://stackoverflow.com/questions/32528042/maven-java-lang-illegalaccess... > We solved this by excluding kie-ci's sisu-guice transitive dependency and including the 3.1.7 version released in 2014. > Please update kie-ci's dependencies such that this is no longer an issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5682) Can't define absolute path for object store location

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-5682?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated WFLY-5682: -------------------------------- Fix Version/s: 10.0.0.Final > Can't define absolute path for object store location > ---------------------------------------------------- > > Key: WFLY-5682 > URL: https://issues.jboss.org/browse/WFLY-5682 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 10.0.0.CR4 > Reporter: Ondřej Chaloupka > Assignee: Amos Feng > Fix For: 10.0.0.Final > > > As trying to set absolute path for location of transaction log store I've got to suspicion that's not possible. > If I try to set `object-store-relative-to` to some absolute path or set `object-store-relative-to` to empty string and then `object-store-path` to some absolute path the server starts with exceptions [1][2]. > [1] > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745)Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/' > at org.jboss.as.controller.services.path.PathManagerService.resolveRelativePathEntry(PathManagerService.java:87) at org.jboss.as.txn.service.ArjunaObjectStoreEnvironmentService.start(ArjunaObjectStoreEnvironmentService.java:76) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.txn.ArjunaObjectStoreEnvironment" => "org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service > Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/'"}} > INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status reportWFLYCTL0186: Services which failed to start: service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service > {code} > [2] > {code} > ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) > at org.jboss.as.server.ServerService.boot(ServerService.java:356) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) > at java.lang.Thread.run(Thread.java:745) > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[348,13] > Message: "WFLYCTL0113: '' is an invalid value for parameter relative-to. Values must have a minimum length of 1 characters" > at org.jboss.as.controller.SimpleAttributeDefinition.parse(SimpleAttributeDefinition.java:161) at org.jboss.as.controller.SimpleAttributeDefinition.parseAndSetParameter(SimpleAttributeDefinition.java:186) > at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseObjectStoreEnvironmentElementAndEnrichOperation(TransactionSubsystem14Parser.java:205) > at org.jboss.as.txn.subsystem.TransactionSubsystem30Parser.readElement(TransactionSubsystem30Parser.java:67) at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:111) > at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:54) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:547) > at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:244) at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:143) > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:69) at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:47) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) > ... 3 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6092) Upgrade Narayana to 5.2.13.Final

by Tom Jenkinson (JIRA)

Tom Jenkinson created WFLY-6092: ----------------------------------- Summary: Upgrade Narayana to 5.2.13.Final Key: WFLY-6092 URL: https://issues.jboss.org/browse/WFLY-6092 Project: WildFly Issue Type: Component Upgrade Components: Transactions Reporter: Tom Jenkinson Assignee: Tom Jenkinson -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-465) Cannot find KieModule with LATEST

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-465?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-465: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1303018 Bugzilla Update: Perform > Cannot find KieModule with LATEST > --------------------------------- > > Key: DROOLS-465 > URL: https://issues.jboss.org/browse/DROOLS-465 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Beta1 > Reporter: Takami Hirata > Assignee: Mark Proctor > Attachments: reproducer.zip > > > I install a kmodule into local repository with command {{mvn clean install}}. > Loading this kmodule with 'LATEST' works on the day, but will fail on next day. > Maven will find update on next day because of default updatePolicy 'daily', then maven check local repository ({{org.kie.scanner.Aether}} treats as a remote repository) but local artifact cache does not have 'maven-metadata.xml' which remote artifact should have, so finding update fails and {{org.sonatype.aether.connector.file.FileRepositoryWorker}} removes {{maven-metadata-local.xml}} for cleanup. > {{org.kie.scanner.Aether}} adds local repository to remote repositories, but this may be incorrect usage. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5640) No EJB receiver available for handling

by Ivan Straka (JIRA)

[ https://issues.jboss.org/browse/WFLY-5640?page=com.atlassian.jira.plugin.... ] Ivan Straka edited comment on WFLY-5640 at 1/29/16 5:14 AM: ------------------------------------------------------------ Still failing. I did some investigation yesterday and I figured out what the problem is. https://github.com/wildfly/wildfly/tree/master/testsuite/integration/clus... This should be set to 8180. Node1 is listening on this port. If you look into the configuration, you will find out that node0 is listening on 8080. Thats why you weren't able to reproduce it locally (neither were I). Due to the same ip addresses of node0 and node1 8080 was valid (node 0 is listening on 8080), on the other hand, if ip addresses are not same, noone is listening on node1_ip : 8080 I am just about to do a PR to WF. was (Author: istraka): Still failing. I did some investigation yesterday and I figured out what the problem is. https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integration/clus... This should be set to 8180. Node1 is listening on this port. If you look into the configuration, you will find out that node0 is listening on 8080. Thats why you weren't able to reproduce it locally (neither were I). Due to the same ip addresses of node0 and node1 8080 was valid (node 0 is listening on 8080), on the other hand, if ip addresses are not same, noone is listening on node1_ip : 8080 I am just about to do a PR to EAP. > No EJB receiver available for handling > -------------------------------------- > > Key: WFLY-5640 > URL: https://issues.jboss.org/browse/WFLY-5640 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB, Test Suite > Affects Versions: 10.0.0.CR4 > Environment: hp-ux 11v3 - hpjdk1.8 > solaris 10,11 - x86 and x86_64, rhel 6 - x86 and x86_64, rhel 7 x86_64 - openjdk1.8, ibmjdk1.8, oraclejdk1.8 > Reporter: Ivan Straka > Assignee: Richard Achmatowicz > Fix For: 10.0.0.CR5 > > Attachments: logs > > > There are two tests failing in exteded tests in clusteringejb2 package in AS TS. > org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase(SYNC-tcp-extended)#testLoadbalanceSpecifiedByDescriptor > org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase(SYNC-tcp-extended)#testLoadbalanceAnnotatedBean > both with exception > {code} > Error Message > EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:stateless-ejb2-failover-test, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@54acff7d > Stacktrace > java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:stateless-ejb2-failover-test, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@54acff7d > at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:798) > at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:112) > at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) > at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183) > at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146) > at com.sun.proxy.$Proxy28.create(Unknown Source) > at org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase.loadbalance(RemoteStatelessFailoverTestCase.java:262) > at org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase.testLoadbalanceAnnotatedBean(RemoteStatelessFailoverTestCase.java:224) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016