April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-126) Kiali Traffic Generator For BookInfo

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-126?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo resolved SWSQE-126. ------------------------------------------- Resolution: Done > Kiali Traffic Generator For BookInfo > ------------------------------------ > > Key: SWSQE-126 > URL: https://issues.jboss.org/browse/SWSQE-126 > Project: Kiali QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > > Service Graph automation tests require BookInfo traffic. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-126) Kiali Traffic Generator For BookInfo

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-126?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo reopened SWSQE-126: ------------------------------------------- > Kiali Traffic Generator For BookInfo > ------------------------------------ > > Key: SWSQE-126 > URL: https://issues.jboss.org/browse/SWSQE-126 > Project: Kiali QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > > Service Graph automation tests require BookInfo traffic. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-126) Kiali Traffic Generator For BookInfo

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-126?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-126: ------------------------------------------ Sprint: Kiali QE Sprint 3 (was: Kiali Sprint #3) > Kiali Traffic Generator For BookInfo > ------------------------------------ > > Key: SWSQE-126 > URL: https://issues.jboss.org/browse/SWSQE-126 > Project: Kiali QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > > Service Graph automation tests require BookInfo traffic. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1480) Coverity, Explicit null dereferenced in FileSystemSecurityRealm

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-1480?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev commented on ELY-1480: ------------------------------------ [~honza889] The attribute "algorithm" is optional in elytron-1_0_1.xsd for "credential-type" and "otp-credential-type". We use a default value when "algorithm" is null here [1], but don't you think that we need to throw an exception when parsing a password here [2]? If we don't use a default value for "algorithm", we also need to throw an exception when we parse one time password [3] and make "algorithm" required in "otp-credential-type". [1] https://github.com/ivassile/wildfly-elytron/blob/1342021236374a3ecb9cd39a... [2] https://github.com/ivassile/wildfly-elytron/blob/1342021236374a3ecb9cd39a... [3] https://github.com/ivassile/wildfly-elytron/blob/1342021236374a3ecb9cd39a... > Coverity, Explicit null dereferenced in FileSystemSecurityRealm > --------------------------------------------------------------- > > Key: ELY-1480 > URL: https://issues.jboss.org/browse/ELY-1480 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Affects Versions: 1.2.0.Beta11 > Reporter: Martin Choma > Assignee: Ilia Vassilev > > There are 2 occurences of call to PasswordFactory.getInstance(algorithm) in FileSystemSecurityRealm where algorithm can be null, because algorithm is optional in wildfly-config.xml > {code:xml|title=elytron-1_0_1.xsd} > <xsd:complexType name="credential-type"> > <xsd:simpleContent> > <xsd:extension base="xsd:string"> > <xsd:attribute name="algorithm" type="xsd:string" use="optional"/> > <xsd:attribute name="format" type="xsd:string" use="optional"/> > </xsd:extension> > </xsd:simpleContent> > </xsd:complexType> > <xsd:complexType name="otp-credential-type"> > <xsd:simpleContent> > <xsd:extension base="xsd:string"> > <xsd:attribute name="algorithm" type="xsd:string" use="optional"/> > <xsd:attribute name="hash" type="xsd:string" use="optional"/> > <xsd:attribute name="seed" type="xsd:string" use="optional"/> > <xsd:attribute name="sequence" type="xsd:string" use="optional"/> > </xsd:extension> > </xsd:simpleContent> > </xsd:complexType> > {code} > Algorithm is dereferenced in PasswordFactory.getInstance(algorithm) down in > {code:java|title=java.security.Provider$ServiceKey.java} > private ServiceKey(String type, String algorithm, boolean intern) { > this.type = type; > this.originalAlgorithm = algorithm; > algorithm = algorithm.toUpperCase(ENGLISH); > this.algorithm = intern ? algorithm.intern() : algorithm; > } > {code} > [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847... > [2] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10229) org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus()

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-10229?page=com.atlassian.jira.plugin... ] Scott Marlow edited comment on WFLY-10229 at 4/13/18 10:16 AM: --------------------------------------------------------------- Good point, for me, I didn't realize that WildFly TSR wrapper class was referencing the com.arjuna.ats.jta.TransactionManager instance directly still, which skips using the org.wildfly.transaction.client.ContextTransactionManager instance so I was thinking of that as the "why" as well, but *agreed* that is more of the "*how*". :) This is kind of dangerous that we won't know if an application is directly using com.arjuna.ats.jta.TransactionManager or org.wildfly.transaction.client.ContextTransactionManager, not that applications should directly use a TransactionManager but they might be. Is this a valid concern? was (Author: smarlow): Good point, for me, I didn't realize that WildFly TSR wrapper class was referencing the com.arjuna.ats.jta.TransactionManager instance directly still, which skips using the org.wildfly.transaction.client.ContextTransactionManager instance so I was thinking of that as the "why" as well, but *agreed* that is more of the "*how*. :) This is kind of dangerous that we won't know if an application is directly using com.arjuna.ats.jta.TransactionManager or org.wildfly.transaction.client.ContextTransactionManager, not that applications should directly use a TransactionManager but they might be. Is this a valid concern? > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus() > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10229 > URL: https://issues.jboss.org/browse/WFLY-10229 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Scott Marlow > Assignee: David Lloyd > Fix For: 13.0.0.Beta1 > > > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() is currently using com.arjuna.ats.jta.TransactionManager, instead it should use org.wildfly.transaction.client.ContextTransactionManager.getStatus(). > I'm seeing a case in Hibernate ORM 5.3, where org.wildfly.transaction.client.ContextTransactionManager.getStatus() returns 4 but TransactionSynchronizationRegistryWrapper.getStatus() returns 1. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10229) org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus()

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-10229?page=com.atlassian.jira.plugin... ] Scott Marlow edited comment on WFLY-10229 at 4/13/18 10:15 AM: --------------------------------------------------------------- Good point, for me, I didn't realize that WildFly TSR wrapper class was referencing the com.arjuna.ats.jta.TransactionManager instance directly still, which skips using the org.wildfly.transaction.client.ContextTransactionManager instance so I was thinking of that as the "why" as well, but *agreed* that is more of the "*how*. :) This is kind of dangerous that we won't know if an application is directly using com.arjuna.ats.jta.TransactionManager or org.wildfly.transaction.client.ContextTransactionManager, not that applications should directly use a TransactionManager but they might be. Is this a valid concern? was (Author: smarlow): Good point, for me, I didn't realize that WildFly TSR wrapper class was referencing the com.arjuna.ats.jta.TransactionManager instance directly still, which skips using the org.wildfly.transaction.client.ContextTransactionManager instance so I was thinking of that as the "why" as well. This is kind of dangerous that we won't know if an application is directly using com.arjuna.ats.jta.TransactionManager or org.wildfly.transaction.client.ContextTransactionManager, not that applications should directly use a TransactionManager but they might be. Is this a valid concern? > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus() > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10229 > URL: https://issues.jboss.org/browse/WFLY-10229 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Scott Marlow > Assignee: David Lloyd > Fix For: 13.0.0.Beta1 > > > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() is currently using com.arjuna.ats.jta.TransactionManager, instead it should use org.wildfly.transaction.client.ContextTransactionManager.getStatus(). > I'm seeing a case in Hibernate ORM 5.3, where org.wildfly.transaction.client.ContextTransactionManager.getStatus() returns 4 but TransactionSynchronizationRegistryWrapper.getStatus() returns 1. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2474) Missing Karaf feature for new Kie Camel component

by Jiri Petrlik (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2474?page=com.atlassian.jira.plugi... ] Jiri Petrlik updated DROOLS-2474: --------------------------------- Affects Version/s: 7.7.0.Final > Missing Karaf feature for new Kie Camel component > ------------------------------------------------- > > Key: DROOLS-2474 > URL: https://issues.jboss.org/browse/DROOLS-2474 > Project: Drools > Issue Type: Bug > Components: integration > Affects Versions: 7.7.0.Final > Reporter: Jiri Petrlik > Assignee: Mario Fusco > > There is no Karaf feature for new Kie Camel component [1] in kie-karaf-features xml [2]. > [1] https://github.com/kiegroup/droolsjbpm-integration/tree/master/kie-camel > [2] https://github.com/kiegroup/droolsjbpm-integration/tree/master/kie-osgi/k... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10229) org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus()

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-10229?page=com.atlassian.jira.plugin... ] Scott Marlow commented on WFLY-10229: ------------------------------------- Good point, for me, I didn't realize that WildFly TSR wrapper class was referencing the com.arjuna.ats.jta.TransactionManager instance directly still, which skips using the org.wildfly.transaction.client.ContextTransactionManager instance so I was thinking of that as the "why" as well. This is kind of dangerous that we won't know if an application is directly using com.arjuna.ats.jta.TransactionManager or org.wildfly.transaction.client.ContextTransactionManager, not that applications should directly use a TransactionManager but they might be. Is this a valid concern? > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus() > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10229 > URL: https://issues.jboss.org/browse/WFLY-10229 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Scott Marlow > Assignee: David Lloyd > Fix For: 13.0.0.Beta1 > > > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() is currently using com.arjuna.ats.jta.TransactionManager, instead it should use org.wildfly.transaction.client.ContextTransactionManager.getStatus(). > I'm seeing a case in Hibernate ORM 5.3, where org.wildfly.transaction.client.ContextTransactionManager.getStatus() returns 4 but TransactionSynchronizationRegistryWrapper.getStatus() returns 1. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2474) Missing Karaf feature for new Kie Camel component

by Jiri Petrlik (JIRA)

Jiri Petrlik created DROOLS-2474: ------------------------------------ Summary: Missing Karaf feature for new Kie Camel component Key: DROOLS-2474 URL: https://issues.jboss.org/browse/DROOLS-2474 Project: Drools Issue Type: Bug Components: integration Reporter: Jiri Petrlik Assignee: Mario Fusco There is no Karaf feature for new Kie Camel component [1] in kie-karaf-features xml [2]. [1] https://github.com/kiegroup/droolsjbpm-integration/tree/master/kie-camel [2] https://github.com/kiegroup/droolsjbpm-integration/tree/master/kie-osgi/k... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10229) org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus()

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-10229?page=com.atlassian.jira.plugin... ] David Lloyd commented on WFLY-10229: ------------------------------------ I think the question is _why_ the values differed, not _how_ (the how is already well-understood). Arjuna is reporting the transaction as "rolled back" but WFTC is reporting "marked rollback". > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() should use org.wildfly.transaction.client.ContextTransactionManager.getStatus() > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10229 > URL: https://issues.jboss.org/browse/WFLY-10229 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Scott Marlow > Assignee: David Lloyd > Fix For: 13.0.0.Beta1 > > > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus() is currently using com.arjuna.ats.jta.TransactionManager, instead it should use org.wildfly.transaction.client.ContextTransactionManager.getStatus(). > I'm seeing a case in Hibernate ORM 5.3, where org.wildfly.transaction.client.ContextTransactionManager.getStatus() returns 4 but TransactionSynchronizationRegistryWrapper.getStatus() returns 1. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 April 2018