October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-266) KIE resolving dependend artifacts issue

by Kurt Stam (JIRA)

[ https://issues.jboss.org/browse/DROOLS-266?page=com.atlassian.jira.plugin... ] Kurt Stam updated DROOLS-266: ----------------------------- Attachment: kie-load-from-maven-issue.tgz fixed the test run mvn clean install -DskipTests=true mvn package > KIE resolving dependend artifacts issue > --------------------------------------- > > Key: DROOLS-266 > URL: https://issues.jboss.org/browse/DROOLS-266 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR3 > Reporter: Kurt Stam > Assignee: Mario Fusco > Attachments: kie-load-from-maven-issue.tgz, kie-load-from-maven-issue.tgz > > > This happens when for a dependency the scope is > - set to 'provided' and > - a parameter (in the case ${jbpm.version}) is used in the version field. > So the relevant entry in the pom is: > <dependency> > <groupId>org.drools</groupId> > <artifactId>drools-core</artifactId> > <version>${drools.version}</version> > <scope>provided</scope> > </dependency> > which leads to > 11:15:02,584 WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version} > and then the NPE. I'm guessing the parameter is not being resolved. > 1. it probably should resolve parameters > 2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway. > 3. if the dependency cannot be found it should probably stop and not even proceed rather then warn? > 4. it should be interesting to see why it gets the NPE. > If you change the dependency from 'provided' to 'test' things work fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2192) MessageEndpointFactory should use unique RA id

by Stefano Maestri (JIRA)

Stefano Maestri created WFLY-2192: ------------------------------------- Summary: MessageEndpointFactory should use unique RA id Key: WFLY-2192 URL: https://issues.jboss.org/browse/WFLY-2192 Project: WildFly Issue Type: Bug Reporter: Stefano Maestri Assignee: Stefano Maestri Priority: Blocker Fix For: 8.0.0.Beta1 This is causing a regression in TCK -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2191) Intermittent fail of AdvancedLdapLoginModuleTestCase and SPNEGOLoginModuleTestCase due to java.nio.BufferOverflowException

by Josef Cacek (JIRA)

Josef Cacek created WFLY-2191: --------------------------------- Summary: Intermittent fail of AdvancedLdapLoginModuleTestCase and SPNEGOLoginModuleTestCase due to java.nio.BufferOverflowException Key: WFLY-2191 URL: https://issues.jboss.org/browse/WFLY-2191 Project: WildFly Issue Type: Bug Components: Test Suite Affects Versions: 8.0.0.Alpha4 Reporter: Josef Cacek Assignee: Josef Cacek org.jboss.as.test.integration.security.loginmodules.negotiation.AdvancedLdapLoginModuleTestCase and org.jboss.as.test.integration.security.loginmodules.negotiation.SPNEGOLoginModuleTestCase fail intermittently after java.nio.BufferOverflowException in Apache directory server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2181) TempFileProviderService creates a static, non-daemon thread pool

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2181: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1012968|https://bugzilla.redhat.com/show_bug.cgi?id=1012968] from POST to MODIFIED > TempFileProviderService creates a static, non-daemon thread pool > ---------------------------------------------------------------- > > Key: WFLY-2181 > URL: https://issues.jboss.org/browse/WFLY-2181 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 8.0.0.Alpha4 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > This can prevent the server from shutting down -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2096) WeldApplicationFactory doesn't implement setApplication() correctly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2096?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2096: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1008998|https://bugzilla.redhat.com/show_bug.cgi?id=1008998] from NEW to MODIFIED > WeldApplicationFactory doesn't implement setApplication() correctly > ------------------------------------------------------------------- > > Key: WFLY-2096 > URL: https://issues.jboss.org/browse/WFLY-2096 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 8.0.0.Alpha4 > Reporter: Martin Kouba > Assignee: Stuart Douglas > > The problem is described in WELD-913. The fix was only applied to Weld servlet support [1] and not AS7/WildFly8 integration code (most probably because the target environment of the issue was Tomcat). > [1] > https://github.com/weld/core/blob/master/environments/servlet/core/src/ma... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-217) MVEL throws an exception when using bound variables and map accessors

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-217?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-217. -------------------------------- Fix Version/s: 5.5.1.Final 6.0.0.CR5 Resolution: Done > MVEL throws an exception when using bound variables and map accessors > --------------------------------------------------------------------- > > Key: DROOLS-217 > URL: https://issues.jboss.org/browse/DROOLS-217 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final, 6.0.0.CR1 > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Minor > Fix For: 5.5.1.Final, 6.0.0.CR5 > > > Map( $c : this[ "x" ], $c op value ) > throws an exception as MVEL tries to compile the constraint -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-216) Map accessors and custom evaluators do not work together

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-216?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-216. -------------------------------- Fix Version/s: 5.5.1.Final 6.0.0.CR5 Resolution: Done > Map accessors and custom evaluators do not work together > -------------------------------------------------------- > > Key: DROOLS-216 > URL: https://issues.jboss.org/browse/DROOLS-216 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final, 6.0.0.CR1 > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Minor > Fix For: 5.5.1.Final, 6.0.0.CR5 > > > Map( this[ "x" ] custOp value ) fails. > The custom evaluator is passed the map itself, rather than the value > corresponding to the key. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1710: -------------------------------- As discussed on JGRP-1507: FRAG\{2\} cannot be moved over the transport as retransmission of large messages with 1 fragment missing would cause retransmission of the entire message (all fragments). Therefore, the current strategy is to move large data from the header into the message's buffer and - if needed - add a second FRAG\{2\} directly over the transport. This second fragmentation protocol would typically not have to do any work, as fragmentation is done by the first fragmentation protocol. The only case where work would need to be done is when large data are added by a protocol, e.g. view and digest by {{INSTALL_MERGE_VIEW in GMS}}. The advantage of moving large data into the body of a message is that FRAG2.down() can do a cheap {{Message.getLength()}}, compared to a more costly {{Message.size()}} by {{FRAG.down(){{. > Messages get too large due to big headers (in large clusters) > ------------------------------------------------------------- > > Key: JGRP-1710 > URL: https://issues.jboss.org/browse/JGRP-1710 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > In some cases, messages get bigger than the max bundling size because of large headers: > {panel} > ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ... > {panel} > In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size. > Possible SOLUTION > * Place the header fields in the message's buffer instead > * Move FRAG2 *under* GMS > ** Investigate impact on flow control etc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1569) Not possible to reload server when JTS transactions are activated

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1569: ----------------------------------------------- tom.jenkinson(a)redhat.com changed the Status of [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379] from NEW to POST > Not possible to reload server when JTS transactions are activated > ----------------------------------------------------------------- > > Key: WFLY-1569 > URL: https://issues.jboss.org/browse/WFLY-1569 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 8.0.0.Alpha1 > Reporter: Ondřej Chaloupka > Assignee: Stefano Maestri > > When transactions are set for JTS being used > - <jts/> tag under transactions subsystem > - transactions="on" under jacorb subsystem > then it is not possible to reload the server. > The reload causes the following exception being shown. > {code} > 14:30:56,388 WARN [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed > at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409) > at org.jacorb.poa.POA.set_servant(POA.java:1979) > at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17] > 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17] > Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement > at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67) > at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) > at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) > ... 5 more > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1569) Not possible to reload server when JTS transactions are activated

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1569: ----------------------------------------------- tom.jenkinson(a)redhat.com made a comment on [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379] https://github.com/jbossas/jboss-eap/pull/478 > Not possible to reload server when JTS transactions are activated > ----------------------------------------------------------------- > > Key: WFLY-1569 > URL: https://issues.jboss.org/browse/WFLY-1569 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 8.0.0.Alpha1 > Reporter: Ondřej Chaloupka > Assignee: Stefano Maestri > > When transactions are set for JTS being used > - <jts/> tag under transactions subsystem > - transactions="on" under jacorb subsystem > then it is not possible to reload the server. > The reload causes the following exception being shown. > {code} > 14:30:56,388 WARN [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed > at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409) > at org.jacorb.poa.POA.set_servant(POA.java:1979) > at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})] > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17] > 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17] > Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement > at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67) > at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) > at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) > ... 5 more > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 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 October 2013