August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (HAWKULARQE-154) Middleware Provider REST API Automation

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created HAWKULARQE-154: ----------------------------------------- Summary: Middleware Provider REST API Automation Key: HAWKULARQE-154 URL: https://issues.jboss.org/browse/HAWKULARQE-154 Project: Hawkular QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9111) Some tests from manualmode is unable to start with node0 and node1 properties

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-9111?page=com.atlassian.jira.plugin.... ] Richard Janík reopened WFLY-9111: --------------------------------- Still partially present - only Dwm tests are affected, but they still reference only node0, not both as they should. > Some tests from manualmode is unable to start with node0 and node1 properties > ----------------------------------------------------------------------------- > > Key: WFLY-9111 > URL: https://issues.jboss.org/browse/WFLY-9111 > Project: WildFly > Issue Type: Bug > Components: JCA, Test Suite > Reporter: Richard Janík > Assignee: Richard Janík > Fix For: 11.0.0.Beta1 > > > *Description of problem:* > Some tests from manualmode is unable to start with node0 and node1 properties. > It's caused by [these new containers in arquillian.xml|https://github.com/jbossas/jboss-eap7/pull/1935/files#diff...] > These tests are affected by this issue: > {noformat} > org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase > org.jboss.as.test.manualmode.ejb.client.outbound.connection.security.ElytronRemoteOutboundConnectionTestCase > org.jboss.as.test.manualmode.ejb.client.reconnect.EJBClientReconnectionTestCase > org.jboss.as.test.manualmode.jca.connectionlistener.ConnectionListenerTestCase > org.jboss.as.test.manualmode.jca.workmanager.distributed.DwmAlwaysTestCase > org.jboss.as.test.manualmode.jca.workmanager.distributed.DwmNeverTestCase > org.jboss.as.test.manualmode.jca.workmanager.distributed.DwmWatermarkTestCase > org.jboss.as.test.manualmode.layered.LayeredDistributionTestCase > org.jboss.as.test.manualmode.messaging.ha.ReplicatedFailoverTestCase > org.jboss.as.test.manualmode.messaging.ha.SharedStoreFailoverTestCase > org.jboss.as.test.manualmode.security.OutboundLdapConnectionClientCertTestCase > org.jboss.as.test.manualmode.security.OutboundLdapConnectionTestCase > org.jboss.as.test.manualmode.security.SecuredDataSourceTestCase > org.jboss.as.test.manualmode.security.VaultSystemPropertyOnServerStartTestCase > org.jboss.as.test.manualmode.transaction.ObjectStoreTypeTestCase > org.jboss.as.test.manualmode.web.ssl.CertificateRolesLoginModuleTestCase > org.jboss.as.test.manualmode.web.ssl.DatabaseCertLoginModuleTestCase > org.jboss.as.test.manualmode.web.ssl.HTTPSWebConnectorTestCase > org.jboss.as.test.manualmode.weld.extension.BeforeShutdownJNDILookupTestCase > org.jboss.as.test.manualmode.ws.ReloadRequiringChangesTestCase > org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase > {noformat} > *How reproducible:* > Always > *Steps to Reproduce:* > # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Djboss.dist=/home/mkopecky/playground/eap/7.1.0.ER2.2/jboss-eap-7.1 -DtestLogToFile=false -Dts.noSmoke -Dts.manualmode -Dtest=RemoteOutboundConnectionReconnectTestCase > *StackTrace:* > {noformat} > Caused by: java.util.concurrent.TimeoutException: Managed server was not started within [60] s > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:161) > ... 73 more > {noformat} > *Expected results:* > No errors -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1314) Elytron, make scope of SPNEGO authentication configurable

by Martin Choma (JIRA)

Martin Choma created ELY-1314: --------------------------------- Summary: Elytron, make scope of SPNEGO authentication configurable Key: ELY-1314 URL: https://issues.jboss.org/browse/ELY-1314 Project: WildFly Elytron Issue Type: Bug Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Blocker Currently Elytron SPNEGO authnetication is tcp connection scoped, whereas legacy SPNEGO for applications is http-session scoped. This different approach can bring these behaviour differences after migration from legacy to Elytron: - if deployment is behind reverse proxy it can lead to user "cross talk" (different http session, but same TCP connection) [1] - more frequent kerberos negotiation cycles - load balancer switches to another node (same http session, but new TCP connection) - new tab in browser (same http session, but new TCP connection) [2] [1] JBEAP-11882 - (7.1) Using a proxy and spnego on the EAP 7 management console leads to user "cross talk" [2] https://superuser.com/questions/1055281/do-web-browsers-use-different-out... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9154) ExceptionEjbClientTestCase fails

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/WFLY-9154?page=com.atlassian.jira.plugin.... ] Jan Martiska moved JBEAP-12457 to WFLY-9154: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9154 (was: JBEAP-12457) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB Test Suite (was: EJB) (was: Test Suite) Affects Version/s: (was: 7.1.0.ER3) > ExceptionEjbClientTestCase fails > -------------------------------- > > Key: WFLY-9154 > URL: https://issues.jboss.org/browse/WFLY-9154 > Project: WildFly > Issue Type: Bug > Components: EJB, Test Suite > Reporter: Jan Martiska > Assignee: Jan Martiska > > {noformat} > Caused by: javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "/ExceptionTestCase/SFSB1", view is interface org.jboss.as.test.integration.ejb.stateful.exception.SFSB1Interface, affinity is None > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3130) Increase timeouts for AbstractCliTestBase#initCLI method

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3130?page=com.atlassian.jira.plugi... ] Marek Kopecký updated WFCORE-3130: ---------------------------------- Issue Type: Task (was: Bug) > Increase timeouts for AbstractCliTestBase#initCLI method > -------------------------------------------------------- > > Key: WFCORE-3130 > URL: https://issues.jboss.org/browse/WFCORE-3130 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Marek Kopecký > Assignee: Marek Kopecký > > Increase timeouts for AbstractCliTestBase#initCLI method -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3130) Increase timeouts for AbstractCliTestBase#initCLI method

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3130?page=com.atlassian.jira.plugi... ] Tomaz Cerar commented on WFCORE-3130: ------------------------------------- why? what is the problem? how does it manifest? > Increase timeouts for AbstractCliTestBase#initCLI method > -------------------------------------------------------- > > Key: WFCORE-3130 > URL: https://issues.jboss.org/browse/WFCORE-3130 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Marek Kopecký > Assignee: Marek Kopecký > > Increase timeouts for AbstractCliTestBase#initCLI method -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3130) Increase timeouts for AbstractCliTestBase#initCLI method

by Marek Kopecký (JIRA)

Marek Kopecký created WFCORE-3130: ------------------------------------- Summary: Increase timeouts for AbstractCliTestBase#initCLI method Key: WFCORE-3130 URL: https://issues.jboss.org/browse/WFCORE-3130 Project: WildFly Core Issue Type: Bug Components: Test Suite Reporter: Marek Kopecký Assignee: Marek Kopecký Increase timeouts for AbstractCliTestBase#initCLI method -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3129) [7.1.z] standalone.bat script does not parse JAVA_OPTS containing '|' symbol properly

by Radovan Stancel (JIRA)

Radovan Stancel created WFCORE-3129: --------------------------------------- Summary: [7.1.z] standalone.bat script does not parse JAVA_OPTS containing '|' symbol properly Key: WFCORE-3129 URL: https://issues.jboss.org/browse/WFCORE-3129 Project: WildFly Core Issue Type: Bug Components: Scripts Affects Versions: 3.0.0.Beta30 Reporter: Radovan Stancel Assignee: Radovan Stancel ====================== Scenario-1) ============ With the following line of JAVA_OPTS in "standalone.bat.conf" file set "JAVA_OPTS=%JAVA_OPTS% -Dhttp.nonProxyHosts=localhost|127.0.0.1|10.10.10.*" {code} Error while starting EAP 6.1.1 C:\jboss-eap-6.1.1\bin>standalone.bat Calling "C:\jboss-eap-6.1.1\bin\standalone.conf.bat" Setting JAVA property to "C:\JDKs\jdk1.7.0_67\bin\java" '127.0.0.1' is not recognized as an internal or external command, operable program or batch file. {code} Scenario-2) ============ In Windows "^" sign is the escape character so we tried altering the JAVA_OPTS as following in the "standalone.bat.conf" file: set "JAVA_OPTS=%JAVA_OPTS% -Dhttp.nonProxyHosts=localhost^|127.0.0.1^|10.10.10.*" Now EAP 6.1.1 server starts but still we see the following messages in windows console: {code} C:\jboss-eap-6.1.1\bin>standalone.bat Calling "C:\jboss-eap-6.1.1\bin\standalone.conf.bat" Setting JAVA property to "C:\JDKs\jdk1.7.0_67\bin\java" '127.0.0.1' is not recognized as an internal or external command, operable program or batch file. '127.0.0.1' is not recognized as an internal or external command, operable program or batch file. '127.0.0.1' is not recognized as an internal or external command, operable program or batch file. '127.0.0.1' is not recognized as an internal or external command, operable program or batch file. '127.0.0.1' is not recognized as an internal or external command, operable program or batch file. '127.0.0.1' is not recognized as an internal or external command, operable program or batch file. '127.0.0.1' is not recognized as an internal or external command, operable program or batch file. {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9126) Deployment fails when application domain names referrencing one Elytron domain are different in Undertow and EJB subsystems

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9126?page=com.atlassian.jira.plugin.... ] Ondrej Lukas commented on WFLY-9126: ------------------------------------ [~swd847] reproducer app is attached in original Jira - JBEAP-12328. > Deployment fails when application domain names referrencing one Elytron domain are different in Undertow and EJB subsystems > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9126 > URL: https://issues.jboss.org/browse/WFLY-9126 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow) > Reporter: Josef Cacek > Assignee: Stuart Douglas > Priority: Critical > > The WAR deployment fails when it contains EJBs and Servlets with security domains mapped under different names (application-security-domain). The underlying Elytron domain is the same for both subsystems. > EJB subsystem tries to search also for the domain name which is used in {{jboss-web.xml}} and this lookup fails. > Sample configuration: > {code:xml|title=jboss-ejb3.xml} > <jboss:ejb-jar> > <assembly-descriptor><s:security> > <ejb-name>*</ejb-name> > <s:security-domain>seccontext-whoami</s:security-domain> > </s:security></assembly-descriptor> > </jboss:ejb-jar> > {code} > {code:xml|title=jboss-web.xml} > <jboss-web> > <security-domain>seccontext-web</security-domain> > </jboss-web> > {code} > {code:title=application-security-domain-mapping.cli} > /subsystem=ejb3/application-security-domain=seccontext-whoami:add( \ > security-domain=ApplicationDomain) > /subsystem=undertow/application-security-domain=seccontext-web:add( \ > http-authentication-factory=application-http-authentication) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9126) Deployment fails when application domain names referrencing one Elytron domain are different in Undertow and EJB subsystems

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9126?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-9126: -------------------------------------- Looks like the reproducer app is missing? > Deployment fails when application domain names referrencing one Elytron domain are different in Undertow and EJB subsystems > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9126 > URL: https://issues.jboss.org/browse/WFLY-9126 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow) > Reporter: Josef Cacek > Assignee: Stuart Douglas > Priority: Critical > > The WAR deployment fails when it contains EJBs and Servlets with security domains mapped under different names (application-security-domain). The underlying Elytron domain is the same for both subsystems. > EJB subsystem tries to search also for the domain name which is used in {{jboss-web.xml}} and this lookup fails. > Sample configuration: > {code:xml|title=jboss-ejb3.xml} > <jboss:ejb-jar> > <assembly-descriptor><s:security> > <ejb-name>*</ejb-name> > <s:security-domain>seccontext-whoami</s:security-domain> > </s:security></assembly-descriptor> > </jboss:ejb-jar> > {code} > {code:xml|title=jboss-web.xml} > <jboss-web> > <security-domain>seccontext-web</security-domain> > </jboss-web> > {code} > {code:title=application-security-domain-mapping.cli} > /subsystem=ejb3/application-security-domain=seccontext-whoami:add( \ > security-domain=ApplicationDomain) > /subsystem=undertow/application-security-domain=seccontext-web:add( \ > http-authentication-factory=application-http-authentication) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2017