February 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-614) Review and document usage of UMB

by Filip Brychta (Jira)

Filip Brychta created SWSQE-614: ----------------------------------- Summary: Review and document usage of UMB Key: SWSQE-614 URL: https://issues.jboss.org/browse/SWSQE-614 Project: Kiali QE Issue Type: Sub-task Reporter: Filip Brychta Assignee: Michael Foley We need to document how we use UMB. * jenkins master configuration * jobs which are consuming msgs * which msgs are consumed * which msgs are sent to UMS -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11689) Update the "Getting Started Guide" doc for WF 16

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11689?page=com.atlassian.jira.plugin... ] Brian Stansberry reopened WFLY-11689: ------------------------------------- Assignee: James Perkins (was: Brian Stansberry) Reopening as the version is controllable via the source -- the first commit in https://github.com/wildfly/wildfly/pull/12092 is actually the fix for this. > Update the "Getting Started Guide" doc for WF 16 > ------------------------------------------------ > > Key: WFLY-11689 > URL: https://issues.jboss.org/browse/WFLY-11689 > Project: WildFly > Issue Type: Task > Components: Documentation > Reporter: Brian Stansberry > Assignee: James Perkins > Priority: Blocker > Fix For: 16.0.0.CR1 > > > The "Getting Started Guide"[1] is release specific. This task is to update it for 16 before we release. > My expectation here is that this is mostly just changing a few places that say "15" to "16". > The "Requirements" section should not recommend using the latest update available; it should recommend the latest *LTS* available. > [1] http://docs.wildfly.org/15/Getting_Started_Guide.html -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-267) Present write your first test case with new UI automation

by Jeeva Kandasamy (Jira)

[ https://issues.jboss.org/browse/SWSQE-267?page=com.atlassian.jira.plugin.... ] Jeeva Kandasamy commented on SWSQE-267: --------------------------------------- [~mmahoney] I guess we gave a demo. This tick is not valid now. > Present write your first test case with new UI automation > --------------------------------------------------------- > > Key: SWSQE-267 > URL: https://issues.jboss.org/browse/SWSQE-267 > Project: Kiali QE > Issue Type: QE Task > Reporter: Jeeva Kandasamy > Assignee: Jeeva Kandasamy > Priority: Major > > Recently we changed UI automation majorly. It needs to be present to the team how to write test case with this framework. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-267) Present write your first test case with new UI automation

by Jeeva Kandasamy (Jira)

[ https://issues.jboss.org/browse/SWSQE-267?page=com.atlassian.jira.plugin.... ] Jeeva Kandasamy closed SWSQE-267. --------------------------------- Resolution: Done > Present write your first test case with new UI automation > --------------------------------------------------------- > > Key: SWSQE-267 > URL: https://issues.jboss.org/browse/SWSQE-267 > Project: Kiali QE > Issue Type: QE Task > Reporter: Jeeva Kandasamy > Assignee: Jeeva Kandasamy > Priority: Major > > Recently we changed UI automation majorly. It needs to be present to the team how to write test case with this framework. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-191) Add Sekuli into Zalenium

by Jeeva Kandasamy (Jira)

[ https://issues.jboss.org/browse/SWSQE-191?page=com.atlassian.jira.plugin.... ] Jeeva Kandasamy commented on SWSQE-191: --------------------------------------- [~mmahoney] we can close this issue now. I am not working on this and we do not have a requirement at this moment. > Add Sekuli into Zalenium > ------------------------ > > Key: SWSQE-191 > URL: https://issues.jboss.org/browse/SWSQE-191 > Project: Kiali QE > Issue Type: QE Task > Reporter: Jeeva Kandasamy > Assignee: Jeeva Kandasamy > Priority: Major > > https://github.com/jkandasa/sekuli -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11750) Allow cluster to use DNS addresses instead of IP addresses

by Tomasz Adamski (Jira)

[ https://issues.jboss.org/browse/WFLY-11750?page=com.atlassian.jira.plugin... ] Tomasz Adamski updated WFLY-11750: ---------------------------------- Description: We would need a configuration that would allow for the cluster to use DNS addresses instead of IP addresses. The reason is that OpenShift guarantees the node identity under DNS address and not under IP address. Sample scenario that may currently fail when application are deployed in OpenShift: A (application) B (clustered application) 1. A calls transactional invocation on B 2. as a result of discovery process A obtains a cluster topology from B and uses one of obtained IP addresses for the connection 3. as the invocation is transactional the object-store records are written in A's persistent object store; those records are based on the data obtained from the cluster => subordinate node is identified by the IP address from point two 4. B node fails 5. OpenShift restarts node B on another IP address 6. A attempts recovery and persistently fails OTOH OpenShift guarantees node identity under DNS address. As a result, at point 5 node is guaranteed to restart on established DNS address so if the cluster used this address instead of physical addresses the scenario above will finish with A being able to recover the transaction. was: We would need a configuration that would allow for the cluster to use DNS addresses instead of IP addresses. The reason is that OpenShift guarantees the node identity under DNS address and not under IP address. Sample scenario that may currently fails when application are deployed in OpenShift: A (application) B (clustered application) 1. A calls transactional invocation on B 2. as a result of discovery process A obtains a cluster topology from B and uses one of obtained IP addresses for the connection 3. as the invocation is transactional the object-store records are written in A's persistent object store; those records are based on the data obtained from the cluster => subordinate node is identified by the IP address from point two 4. B node fails 5. OpenShift restarts node B on another IP address 6. A attempts recovery and persistently fails OTOH OpenShift guarantees node identity under DNS address. As a result, at point 5 node is guaranteed to restart on established DNS address so if the cluster used this address instead of physical addresses the scenario above will finish with A being able to recover the transaction. > Allow cluster to use DNS addresses instead of IP addresses > ---------------------------------------------------------- > > Key: WFLY-11750 > URL: https://issues.jboss.org/browse/WFLY-11750 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 16.0.0.Beta1 > Reporter: Tomasz Adamski > Assignee: Paul Ferraro > Priority: Major > > We would need a configuration that would allow for the cluster to use DNS addresses instead of IP addresses. The reason is that OpenShift guarantees the node identity under DNS address and not under IP address. > Sample scenario that may currently fail when application are deployed in OpenShift: > A (application) > B (clustered application) > 1. A calls transactional invocation on B > 2. as a result of discovery process A obtains a cluster topology from B and uses one of obtained IP addresses for the connection > 3. as the invocation is transactional the object-store records are written in A's persistent object store; those records are based on the data obtained from the cluster => subordinate node is identified by the IP address from point two > 4. B node fails > 5. OpenShift restarts node B on another IP address > 6. A attempts recovery and persistently fails > OTOH OpenShift guarantees node identity under DNS address. As a result, at point 5 node is guaranteed to restart on established DNS address so if the cluster used this address instead of physical addresses the scenario above will finish with A being able to recover the transaction. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11749) Upgrade Hibernate ORM from 5.3.7 to 5.3.8

by Gail Badner (Jira)

[ https://issues.jboss.org/browse/WFLY-11749?page=com.atlassian.jira.plugin... ] Gail Badner updated WFLY-11749: ------------------------------- Description: In addition to upgrading Hibernate ORM, this also upgrades ByteBuddy from 1.8.17 to 1.9.4. > Upgrade Hibernate ORM from 5.3.7 to 5.3.8 > ----------------------------------------- > > Key: WFLY-11749 > URL: https://issues.jboss.org/browse/WFLY-11749 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Reporter: Gail Badner > Assignee: Gail Badner > Priority: Major > Fix For: 16.0.0.CR1 > > > In addition to upgrading Hibernate ORM, this also upgrades ByteBuddy from 1.8.17 to 1.9.4. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11750) Allow cluster to use DNS addresses instead of IP addresses

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-11750: ------------------------------------- Summary: Allow cluster to use DNS addresses instead of IP addresses Key: WFLY-11750 URL: https://issues.jboss.org/browse/WFLY-11750 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 16.0.0.Beta1 Reporter: Tomasz Adamski Assignee: Paul Ferraro We would need a configuration that would allow for the cluster to use DNS addresses instead of IP addresses. The reason is that OpenShift guarantees the node identity under DNS address and not under IP address. Sample scenario that may currently fails when application are deployed in OpenShift: A (application) B (clustered application) 1. A calls transactional invocation on B 2. as a result of discovery process A obtains a cluster topology from B and uses one of obtained IP addresses for the connection 3. as the invocation is transactional the object-store records are written in A's persistent object store; those records are based on the data obtained from the cluster => subordinate node is identified by the IP address from point two 4. B node fails 5. OpenShift restarts node B on another IP address 6. A attempts recovery and persistently fails OTOH OpenShift guarantees node identity under DNS address. As a result, at point 5 node is guaranteed to restart on established DNS address so if the cluster used this address instead of physical addresses the scenario above will finish with A being able to recover the transaction. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11604) Non-anonymous principal is not propagated from EJB context to CDI bean

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ] Farah Juma commented on WFLY-11604: ----------------------------------- {quote} This does however leave the question once WildFly Elytron is activated regarding why the EJBContext does not report the run as principal when the call reaches the second bean, I suspect this may have been a decision during implementation as these run as scenarios were discussed quite heavily but it is purely an EJB container issue and not a CDI issue. {quote} For JBEAP-9744, we updated {{EJBContext.getCallerPrincipal()}} so that when called from an unsecured bean, an anonymous principal is returned. This was done to match PicketBox behaviour for the Remoting -> EJB case. For the EJB -> EJB case here with Elytron enabled (i.e., {{CallerWithIdentity -> BeanWithPrincipalFromEJBContext}}), notice that {{BeanWithPrincipalFromEJBContext}} is an unsecured bean. So when {{EJBContext.getCallerPrincipal}} is called, the 'anonymous' principal is currently being returned. However, if any security metadata is added to this bean, then the 'non-anonymous' principal will be returned. Since the 'non-anonymous' principal is returned for the legacy case, I think we should get an issue created to see if there is a way to fix this for the Elytron case without breaking the fix for JBEAP-9744. > Non-anonymous principal is not propagated from EJB context to CDI bean > ---------------------------------------------------------------------- > > Key: WFLY-11604 > URL: https://issues.jboss.org/browse/WFLY-11604 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Security > Affects Versions: 14.0.1.Final, 15.0.1.Final > Reporter: Nikoleta Žiaková > Assignee: Darran Lofthouse > Priority: Critical > > This is a follow-up on WFLY-11587 which only dealt with being able to inject the principal. > However, during testing I have tried a scenario when the caller principal was not anonymous (run-as-principal setting in jboss-ejb3.xml). See the test case in this [commit|https://github.com/nziakova/wildfly/commit/9ae586ad0159e6399f65103...]. > The principal is not propagated from the EJB context. The result is that injected principal in the CDI bean is always anonymous, although {{ctx.getCallerPrincipal()}} in the EJB returns correct principal. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11689) Update the "Getting Started Guide" doc for WF 16

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11689?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved WFLY-11689. ------------------------------------- Resolution: Rejected The main point here is invalid. These release numbers are controlled by a wildflyVersion var that is set when the docs are built. > Update the "Getting Started Guide" doc for WF 16 > ------------------------------------------------ > > Key: WFLY-11689 > URL: https://issues.jboss.org/browse/WFLY-11689 > Project: WildFly > Issue Type: Task > Components: Documentation > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 16.0.0.CR1 > > > The "Getting Started Guide"[1] is release specific. This task is to update it for 16 before we release. > My expectation here is that this is mostly just changing a few places that say "15" to "16". > The "Requirements" section should not recommend using the latest update available; it should recommend the latest *LTS* available. > [1] http://docs.wildfly.org/15/Getting_Started_Guide.html -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 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 February 2019