February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6460) JSON-P 1.1 Support

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-6460?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-6460: ------------------------------------- Analysis document https://github.com/wildfly/wildfly-proposals/pull/21 > JSON-P 1.1 Support > ------------------ > > Key: WFLY-6460 > URL: https://issues.jboss.org/browse/WFLY-6460 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: David Lloyd > Assignee: James Perkins > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9807) ConstantPermissionMapperTestCase influeced by other test fail

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-9807?page=com.atlassian.jira.plugin.... ] Jan Kalina updated WFLY-9807: ----------------------------- Description: ConstantPermissionMapperTestCase fails when some other test fails before: After modifying SpengoMechTestCase to fail during ServerSetup (when I change {{path}} in {{cli.sendLine("/subsystem=elytron/kerberos-security-factory=...}} to filepath which does not exists), ConstantPermissionMapperTestCase start to fail too because of DeploymentException. Reason is, ServerSetup of ConstantPermissionMapperTestCase is not started, so Deployment fails. Edit: the same occurs in opposite case - when ConstantPermissionMapperTestCase setup fails (for example when I change {{withRoleDecoder("groups-to-roles")}} to {{withRoleDecoder("groups-to-roles2")}}), SpengoMechTestCase's SetupTask will not run too, and tests fails on DeploymentException too (resource crated as part of setup task does not exists). {code} mvn clean test -Dtest=org.wildfly.test.integration.elytron.http.SpnegoMechTestCase,org.wildfly.test.integration.elytron.permissionmappers.ConstantPermissionMapperTestCase -Dsurefire.runOrder=alphabetical {code} As the problem is SetupTask is not started in consequences of different test SetupTask behavior (fail), this is probably arquillian or wildfly-arquillian issue. was: ConstantPermissionMapperTestCase fails when some other test fails before: After modifying SpengoMechTestCase to fail during ServerSetup, ConstantPermissionMapperTestCase start to fail too. > ConstantPermissionMapperTestCase influeced by other test fail > ------------------------------------------------------------- > > Key: WFLY-9807 > URL: https://issues.jboss.org/browse/WFLY-9807 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 11.0.0.Final > Reporter: Jan Kalina > Assignee: Jan Kalina > > ConstantPermissionMapperTestCase fails when some other test fails before: > After modifying SpengoMechTestCase to fail during ServerSetup (when I change {{path}} in {{cli.sendLine("/subsystem=elytron/kerberos-security-factory=...}} to filepath which does not exists), ConstantPermissionMapperTestCase start to fail too because of DeploymentException. > Reason is, ServerSetup of ConstantPermissionMapperTestCase is not started, so Deployment fails. > Edit: the same occurs in opposite case - when ConstantPermissionMapperTestCase setup fails (for example when I change {{withRoleDecoder("groups-to-roles")}} to {{withRoleDecoder("groups-to-roles2")}}), SpengoMechTestCase's SetupTask will not run too, and tests fails on DeploymentException too (resource crated as part of setup task does not exists). > {code} > mvn clean test -Dtest=org.wildfly.test.integration.elytron.http.SpnegoMechTestCase,org.wildfly.test.integration.elytron.permissionmappers.ConstantPermissionMapperTestCase -Dsurefire.runOrder=alphabetical > {code} > As the problem is SetupTask is not started in consequences of different test SetupTask behavior (fail), this is probably arquillian or wildfly-arquillian issue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7185) JSON-B 1.0 Support

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-7185?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-7185: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/10872 (was: https://github.com/wildfly/wildfly/pull/10834) > JSON-B 1.0 Support > ------------------ > > Key: WFLY-7185 > URL: https://issues.jboss.org/browse/WFLY-7185 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: David Lloyd > Assignee: James Perkins > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6460) JSON-P 1.1 Support

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-6460?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-6460: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/10872 (was: https://github.com/wildfly/wildfly/pull/10834) > JSON-P 1.1 Support > ------------------ > > Key: WFLY-6460 > URL: https://issues.jboss.org/browse/WFLY-6460 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: David Lloyd > Assignee: James Perkins > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9757) Some jsf integration tests fail if -Dnode != localhost

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-9757?page=com.atlassian.jira.plugin.... ] Farah Juma commented on WFLY-9757: ---------------------------------- Thanks very much, [~pkremens]! I'm able to reproduce it now using your steps. > Some jsf integration tests fail if -Dnode != localhost > ------------------------------------------------------ > > Key: WFLY-9757 > URL: https://issues.jboss.org/browse/WFLY-9757 > Project: WildFly > Issue Type: Bug > Components: JSF, Test Suite > Reporter: Petr Kremensky > Assignee: Farah Juma > Attachments: org.jboss.as.test.integration.jsf.doctype.DoctypeDeclTestCase-output.txt > > > Running the tests keeping a node0 to localhost works fine: > {noformat} > [pkremens@localhost testsuite] (master)$ mvn test -Dts.basic -Dts.noSmoke -Dtest=DoctypeDeclTestCase,DuplicateIDIntegrationTestCase,InjectionToPhaseListenerTest > ... > Running org.jboss.as.test.integration.jsf.doctype.DoctypeDeclTestCase > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.809 sec - in org.jboss.as.test.integration.jsf.doctype.DoctypeDeclTestCase > Running org.jboss.as.test.integration.jsf.duplicateid.DuplicateIDIntegrationTestCase > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.645 sec - in org.jboss.as.test.integration.jsf.duplicateid.DuplicateIDIntegrationTestCase > Running org.jboss.as.test.integration.jsf.phaseListener.injectionTarget.InjectionToPhaseListenerTest > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec - in org.jboss.as.test.integration.jsf.phaseListener.injectionTarget.InjectionToPhaseListenerTest > {noformat} > But once node0 is set, the tests start to fail. > {noformat} > [pkremens@localhost testsuite] (master)$ mvn test -Dts.basic -Dts.noSmoke -Dtest=DoctypeDeclTestCase,DuplicateIDIntegrationTestCase,InjectionToPhaseListenerTest -Dnode0=<IP> > ... > Failed tests: > DoctypeDeclTestCase.testDoctypeDeclDisallowed:93 > DuplicateIDIntegrationTestCase.testDuplicateIDIsNotGenerated:107 expected:<200> but was:<500> > Tests in error: > InjectionToPhaseListenerTest.test:61 » IO java.util.concurrent.ExecutionExcept... > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3603) Upgrade JBoss DMR to 1.5.0.Final

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3603: ---------------------------------------- Summary: Upgrade JBoss DMR to 1.5.0.Final Key: WFCORE-3603 URL: https://issues.jboss.org/browse/WFCORE-3603 Project: WildFly Core Issue Type: Component Upgrade Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Bring in the few 1.5 changes, plus some tweaks for working on JDK 9/10: https://issues.jboss.org/projects/DMR/versions/12336250 https://github.com/jbossas/jboss-dmr/pull/29 This is a minor version upgrade but the changes are quite small. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3602) Upgrade WildFly Elytron Tool to 1.1.0.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-3602: ---------------------------------------- Summary: Upgrade WildFly Elytron Tool to 1.1.0.Final Key: WFCORE-3602 URL: https://issues.jboss.org/browse/WFCORE-3602 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 4.0.0.Beta1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9821) SingletonProvider may be incorrectly initialized with RegistrySingletonProvider

by Martin Kouba (JIRA)

Martin Kouba created WFLY-9821: ---------------------------------- Summary: SingletonProvider may be incorrectly initialized with RegistrySingletonProvider Key: WFLY-9821 URL: https://issues.jboss.org/browse/WFLY-9821 Project: WildFly Issue Type: Bug Components: CDI / Weld Affects Versions: 11.0.0.Final Reporter: Martin Kouba Assignee: Martin Kouba If a non-CDI deployment (contains no beans.xml nor a bean with a bean defining annotation nor a session bean) attempts to access the CDI container using {{CDI.current()}} before {{TCCLSingletonService}} is started (and {{org.jboss.weld.bootstrap.api.SingletonProvider}} initialized with {{ModuleGroupSingletonProvider}}) then {{SingletonProvider}} is incorrectly initialized with the default impl ({{RegistrySingletonProvider}}). As a result, subsequent CDI deployment fail with {{java.lang.RuntimeException: SingletonProvider is already initialized...}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3601) Upgrade Elytron Web to 1.1.0.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-3601: ---------------------------------------- Summary: Upgrade Elytron Web to 1.1.0.Final Key: WFCORE-3601 URL: https://issues.jboss.org/browse/WFCORE-3601 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Blocker Fix For: 4.0.0.Beta1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3600) JSON-P 1.1 is not loaded when ee8.preview.mode property is defined in standalone.xml file, seems that Elytron uses JSON-P stuff too early

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3600?page=com.atlassian.jira.plugi... ] James Perkins moved WFLY-9817 to WFCORE-3600: --------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-3600 (was: WFLY-9817) Component/s: Server (was: Server) > JSON-P 1.1 is not loaded when ee8.preview.mode property is defined in standalone.xml file, seems that Elytron uses JSON-P stuff too early > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3600 > URL: https://issues.jboss.org/browse/WFCORE-3600 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Rostislav Svoboda > Assignee: James Perkins > Priority: Critical > > JSON-P 1.1 is not loaded when ee8.preview.mode property is defined in standalone.xml file. > Early investigation done by James and Stuart indicates that Elytron uses JSON-P stuff too early and it prevents JSON-P 1.1 activation when ee8.preview.mode property is defined in standalone.xml file. > CCing [~jamezp] [~swd847] [~jason.greene] [~kabirkhan] [~brian.stansberry] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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 2018