[JBoss JIRA] (WFLY-9807) ConstantPermissionMapperTestCase influeced by other test fail
by Jan Kalina (JIRA)
Jan Kalina created WFLY-9807:
--------------------------------
Summary: 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, 2 months
[JBoss JIRA] (WFLY-9781) Support Forwarded HTTP Extension - RFC 7239
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-9781?page=com.atlassian.jira.plugin.... ]
Jan Stourac commented on WFLY-9781:
-----------------------------------
Created MR with integration tests for this issue - https://github.com/wildfly/wildfly/pull/10860.
> Support Forwarded HTTP Extension - RFC 7239
> -------------------------------------------
>
> Key: WFLY-9781
> URL: https://issues.jboss.org/browse/WFLY-9781
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Labels: tp_candidate
>
> "X-Forwarded-For, X-Forwarded-By, and X-Forwarded-Proto" headers are non-standards headers and implementations might vary in different environments.
> RFC-7239 standardizes a header field called "Forwarded" and provides the syntax and semantics for disclosing such information. I see that now a days most of the vendors supporting this including routes in "Openshift container platform" but due to lack of support in Undertow limiting us to relay on X-Forwarded-For* headers.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9806) Clean up use of jboss.as.release.version
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9806?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-9806:
-----------------------------------
Description:
Our poms have a 'jboss.as.release.version' property that is used for two distinct purposes:
1) In the root pom it drives the value of the JBossAS-Release-Version property in our MANIFEST.mf files.
2) In many places throughout the poms its value is appended to the value of the server.output.dir.prefix property to produce the names of various output dirs used in the build.
This is a bit messy, and is made messier because in the EAP variant of the poms, nearly all[1] of the type 2) uses have been converted to a different property, named 'jboss.eap.release.version'. EAP then changes the value of this to a short form version (e.g. "7.1") rather than the full maven GAV version. However, this property name is not appropriate for upstream. The effect of this is it's unnecessarily difficult to go from a WF tag to an EAP branch.
To clean this up I propose to do the following:
A) Replace all the type 2) uses of jboss.as.release.version in the poms with a new property, "server.output.dir.version". This better describes the purpose of the property and has a name that is agnostic between WildFly and EAP.
B) Examine some uses of "jboss.eap.release.version" in EAP that are not present in WF and if appropriate port them to WF, but using "server.output.dir.version".
C) Either drop jboss.as.release.version for the type 1) manifest use, and directly use "project.version" (which is the only value ever provided for this), or better comment the declaration of jboss.as.release.version so its sole intended use is clear. (Probably for now I'll do the latter to avoid risk of unintended side effects.)
[1] "Nearly all" because there's still this, which I think should be corrected to use the same version string as the others:
{code}
<wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
{code}
was:
Our poms have a 'jboss.as.release.version' property that is used for two distinct purposes:
1) In the root pom it drives the value of the JBossAS-Release-Version property in our MANIFEST.mf files.
2) In many places throughout the poms its value is appended to the value of the server.output.dir.prefix property to produce the names of various output dirs used in the build.
This is a bit messy, and is made messier because in the EAP variant of the poms, nearly all[1] of the type 2) uses have been converted to a different property, named 'jboss.eap.release.version'. This name is not appropriate for upstream. The effect of this is it's unnecessarily difficult to go from a WF tag to an EAP branch.
To clean this up I propose to do the following:
A) Replace all the type 2) uses of jboss.as.release.version in the poms with a new property, "server.output.dir.version". This better describes the purpose of the property and has a name that is agnostic between WildFly and EAP.
B) Examine some uses of "jboss.eap.release.version" in EAP that are not present in WF and if appropriate port them to WF, but using "server.output.dir.version".
C) Either drop jboss.as.release.version for the type 1) manifest use, and directly use "project.version" (which is the only value ever provided for this), or better comment the declaration of jboss.as.release.version so its sole intended use is clear. (Probably for now I'll do the latter to avoid risk of unintended side effects.)
[1] "Nearly all" because
> Clean up use of jboss.as.release.version
> ----------------------------------------
>
> Key: WFLY-9806
> URL: https://issues.jboss.org/browse/WFLY-9806
> Project: WildFly
> Issue Type: Task
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Our poms have a 'jboss.as.release.version' property that is used for two distinct purposes:
> 1) In the root pom it drives the value of the JBossAS-Release-Version property in our MANIFEST.mf files.
> 2) In many places throughout the poms its value is appended to the value of the server.output.dir.prefix property to produce the names of various output dirs used in the build.
> This is a bit messy, and is made messier because in the EAP variant of the poms, nearly all[1] of the type 2) uses have been converted to a different property, named 'jboss.eap.release.version'. EAP then changes the value of this to a short form version (e.g. "7.1") rather than the full maven GAV version. However, this property name is not appropriate for upstream. The effect of this is it's unnecessarily difficult to go from a WF tag to an EAP branch.
> To clean this up I propose to do the following:
> A) Replace all the type 2) uses of jboss.as.release.version in the poms with a new property, "server.output.dir.version". This better describes the purpose of the property and has a name that is agnostic between WildFly and EAP.
> B) Examine some uses of "jboss.eap.release.version" in EAP that are not present in WF and if appropriate port them to WF, but using "server.output.dir.version".
> C) Either drop jboss.as.release.version for the type 1) manifest use, and directly use "project.version" (which is the only value ever provided for this), or better comment the declaration of jboss.as.release.version so its sole intended use is clear. (Probably for now I'll do the latter to avoid risk of unintended side effects.)
> [1] "Nearly all" because there's still this, which I think should be corrected to use the same version string as the others:
> {code}
> <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9806) Clean up use of jboss.as.release.version
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-9806:
--------------------------------------
Summary: Clean up use of jboss.as.release.version
Key: WFLY-9806
URL: https://issues.jboss.org/browse/WFLY-9806
Project: WildFly
Issue Type: Task
Components: Build System
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Our poms have a 'jboss.as.release.version' property that is used for two distinct purposes:
1) In the root pom it drives the value of the JBossAS-Release-Version property in our MANIFEST.mf files.
2) In many places throughout the poms its value is appended to the value of the server.output.dir.prefix property to produce the names of various output dirs used in the build.
This is a bit messy, and is made messier because in the EAP variant of the poms, nearly all[1] of the type 2) uses have been converted to a different property, named 'jboss.eap.release.version'. This name is not appropriate for upstream. The effect of this is it's unnecessarily difficult to go from a WF tag to an EAP branch.
To clean this up I propose to do the following:
A) Replace all the type 2) uses of jboss.as.release.version in the poms with a new property, "server.output.dir.version". This better describes the purpose of the property and has a name that is agnostic between WildFly and EAP.
B) Examine some uses of "jboss.eap.release.version" in EAP that are not present in WF and if appropriate port them to WF, but using "server.output.dir.version".
C) Either drop jboss.as.release.version for the type 1) manifest use, and directly use "project.version" (which is the only value ever provided for this), or better comment the declaration of jboss.as.release.version so its sole intended use is clear. (Probably for now I'll do the latter to avoid risk of unintended side effects.)
[1] "Nearly all" because
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFBUILD-34) Use the same groupId:artifactId[:type[:classifier[:version]]] format everywhere
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-34?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFBUILD-34:
--------------------------------------
This seems to resolved in https://github.com/wildfly/wildfly-build-tools/commit/11d4ee32c607f249433.... The build tool will attempt to first check for the version number as the 3 parameter of the coordinates.
> Use the same groupId:artifactId[:type[:classifier[:version]]] format everywhere
> -------------------------------------------------------------------------------
>
> Key: WFBUILD-34
> URL: https://issues.jboss.org/browse/WFBUILD-34
> Project: WildFly Build Tools
> Issue Type: Enhancement
> Reporter: Peter Palaga
> Assignee: Stuart Douglas
> Fix For: 1.2.8.Final
>
>
> This both a usability issue and a feature request.
> On the usability side, the artifact formats in module.xml files vs. in feature-pack-build.xml files are not the same:
> * `{{groupId:artifactId\[:version\[:classifier]]}}` in module.xml files
> * `{{groupId:artifactId\[:type\[:classifier]]}}` in feature-pack-build.xml files
> The missing feature is the impossibility to define type/extension in module.xml files and the impossibility to had code version in feature-pack-build.xml files
> The current proposal is to use the same {{groupId:artifactId\[:type\[:classifier\[:version]]]}} format in both kinds of files.
> The proposal is backwards incompatible for module.xml files. But given that the support for hardcoded versions in module.xml files was added just 11 days ago, this will probably impact just a few users.
> I am not sure what artifact format is used by JBoss modules. Maybe `{{groupId:artifactId\[:version\[:classifier]]}}` is taken from there?
> WDYT [~swd847]?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months