[JBoss JIRA] (WFBUILD-36) Support resolution of ${project.groupId} in the server-provisioning.xml file
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-36?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFBUILD-36:
------------------------------------
Description:
The provisioning plugin allows parameterization of a feature pack's version via {code}${project.version}{code} but parameterizing the groupId via {code}${project.groupId}{code} isn't supported. My guess is something like this for groupId would do the trick:
https://github.com/wildfly/wildfly-build-tools/blob/master/provisioning-m...
This would make it easier to use the same provisioning configs in different branches that have different maven groupIds.
I see the TODO about the project.version thing I linked above, and I understand I'm asking to expand a concept that the TODO indicates is suspect. So I won't be offended if this is rejected.
was:
The provisioning plugin allows parameterization of a feature pack's version via ```${project.version}``` but parameterizing the groupId via ```${project.groupId}``` isn't supported. My guess is something like this for groupId would do the trick:
https://github.com/wildfly/wildfly-build-tools/blob/master/provisioning-m...
This would make it easier to use the same provisioning configs in different branches that have different maven groupIds.
I see the TODO about the project.version thing I linked above, and I understand I'm asking to expand a concept that the TODO indicates is suspect. So I won't be offended if this is rejected.
> Support resolution of ${project.groupId} in the server-provisioning.xml file
> ----------------------------------------------------------------------------
>
> Key: WFBUILD-36
> URL: https://issues.jboss.org/browse/WFBUILD-36
> Project: WildFly Build Tools
> Issue Type: Enhancement
> Reporter: Brian Stansberry
> Assignee: Stuart Douglas
> Priority: Minor
> Fix For: 1.2.9.Final
>
>
> The provisioning plugin allows parameterization of a feature pack's version via {code}${project.version}{code} but parameterizing the groupId via {code}${project.groupId}{code} isn't supported. My guess is something like this for groupId would do the trick:
> https://github.com/wildfly/wildfly-build-tools/blob/master/provisioning-m...
> This would make it easier to use the same provisioning configs in different branches that have different maven groupIds.
> I see the TODO about the project.version thing I linked above, and I understand I'm asking to expand a concept that the TODO indicates is suspect. So I won't be offended if this is rejected.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9810) Enable setting of default cookie version in Undertow
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9810?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved EAP7-909 to WFLY-9810:
-------------------------------------------
Project: WildFly (was: EAP 7 Planning Pilot)
Key: WFLY-9810 (was: EAP7-909)
Issue Type: Feature Request (was: Requirement)
Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 1.2)
Component/s: Web Console
(was: Undertow)
(was: Web Console)
Analysis Document: (was: https://github.com/wildfly/wildfly-proposals/pull/8)
> Enable setting of default cookie version in Undertow
> ----------------------------------------------------
>
> Key: WFLY-9810
> URL: https://issues.jboss.org/browse/WFLY-9810
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Console
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Labels: tp_candidate
>
> Tomcat performs an automatic conversion for incoming cookies from version 0 to version 1, sending back a v1 cookie. We should consider whether Undertow should do this, and if it does provide a way to disable it similar to the org.apache.tomcat.util.http.ServerCookie.VERSION_SWITCH=false system property.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9810) Enable setting of default cookie version in Undertow
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9810?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-9810:
---------------------------------
Component/s: Web (Undertow)
(was: Web Console)
> Enable setting of default cookie version in Undertow
> ----------------------------------------------------
>
> Key: WFLY-9810
> URL: https://issues.jboss.org/browse/WFLY-9810
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Labels: tp_candidate
>
> Tomcat performs an automatic conversion for incoming cookies from version 0 to version 1, sending back a v1 cookie. We should consider whether Undertow should do this, and if it does provide a way to disable it similar to the org.apache.tomcat.util.http.ServerCookie.VERSION_SWITCH=false system property.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3597) Defer sending response to reload op until the ProcessReloadHandler has changed the process state
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3597:
----------------------------------------
Summary: Defer sending response to reload op until the ProcessReloadHandler has changed the process state
Key: WFCORE-3597
URL: https://issues.jboss.org/browse/WFCORE-3597
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Currently the response to the reload op goes out to the client as soon as the op commits, not waiting for the op to complete. It can't wait for the op to complete, because op completion may not occur before the service managing the connection to the client is stopped. But sending the response on commit is too early, as the ProcessReloadHandler hasn't even begun the reload yet. If a client receives that response and immediately begins polling for the server in RUNNING state (i.e. completed reload) there is a race where it's possible the client sees the server as RUNNING *before* the reload has begun, rather than after.
https://github.com/wildfly/wildfly-core/pull/3098 for WFCORE-3594 helps mitigate the chances of this by putting the process in STOPPING state a bit faster. But an ultimate solution requires the ProcessReloadHandler being able to signal when the response should go out. I think this can be done via an OperationContext attachment that the current code that sends the response on commit would attach.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9809) Update jandex to 2.1.0.Final
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-9809:
---------------------------------
Summary: Update jandex to 2.1.0.Final
Key: WFLY-9809
URL: https://issues.jboss.org/browse/WFLY-9809
Project: WildFly
Issue Type: Component Upgrade
Components: Web (Undertow)
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
Fixes heaps of issues. including:
[WFLY-6263][JBEAP-13924][JBEAP-13925][JBEAP-13897] JBEAP-13786
WFLY-7033
JBEAP-10134
WFLY-6263
WFLY-9368
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[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:
----------------------------------
[~pkremens] Are you seeing this failure intermittently or does it always fail for you? I haven't been able to reproduce it locally yet.
> 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, 5 months
[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, ConstantPermissionMapperTestCase start to fail too.
was:
ConstantPermissionMapperTestCase fails on Windows 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, ConstantPermissionMapperTestCase start to fail too.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[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:
-----------------------------
Steps to Reproduce:
{code}
mvn clean test -Dtest=org.wildfly.test.integration.elytron.http.SpnegoMechTestCase,org.wildfly.test.integration.elytron.permissionmappers.ConstantPermissionMapperTestCase -Dsurefire.runOrder=alphabetical
{code}
was:
{code}
mvn clean test -Dtest=org.wildfly.test.integration.elytron.http.SpnegoMechTestCase,org.wildfly.test.integration.elytron.permissionmappers.ConstantPermissionMapperTestCase
{code}
> 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 on Windows when some other test fails before:
> After modifying SpengoMechTestCase to fail during ServerSetup, ConstantPermissionMapperTestCase start to fail too.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9808) Restore support for configuring surefire forkedProcessTimeoutInSeconds, or clean out docs and cruft
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-9808:
--------------------------------------
Summary: Restore support for configuring surefire forkedProcessTimeoutInSeconds, or clean out docs and cruft
Key: WFLY-9808
URL: https://issues.jboss.org/browse/WFLY-9808
Project: WildFly
Issue Type: Task
Components: Test Suite
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The "WildFly Integration Testsuite User Guide" doc includes mention of setting property surefire.forked.process.timeout to control the surefire forkedProcessTimeoutInSeconds setting. And there are a couple places in the poms where this property is set. But nowhere is the property used to configure surefire.
So we should either change the docs to remove this bit of doc and clean out the cruft in our poms, or we should restore the functionality.
I'm sending up a PR to do the latter, as that will align with what's done in the EAP branch. Right now I figure it's simpler to align, e.g. in case someone in QE uses this property. We can always revisit and remove it later if there's no valid use.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months