[JBoss JIRA] (WFCORE-3267) Authorization identity forwarding not exposed to configuration
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3267?page=com.atlassian.jira.plugi... ]
Jason Greene updated WFCORE-3267:
---------------------------------
Fix Version/s: 3.0.2.Final
> Authorization identity forwarding not exposed to configuration
> --------------------------------------------------------------
>
> Key: WFCORE-3267
> URL: https://issues.jboss.org/browse/WFCORE-3267
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jason Greene
> Assignee: Jason Greene
> Priority: Blocker
> Fix For: 3.0.2.Final
>
>
> As part of EAP7-284, Elytron was designed for and contains implementation to support trusted use of identities between peers in addition to credential forwarding. Cases in which one would prefer this approach include:
> * Scenarios where the user has requirements to not send passwords over the wire. Notably credential forwarding requires TLS and/or secure networks
> * Setups where an authentication type that does not support credential forwarding are used (credential forwarding is limited to Plain, Form, and OAuth, all other mechanisms, including the out of the box Digest auth of EAP are not)
> * Environments where its desired to limit which systems are allowed to receive requests which are propagated
> Due to an oversight this capability was not properly wired to the server configuration (nor a config method on the Elytron API).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3267) Authorization identity forwarding not exposed to configuration
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3267?page=com.atlassian.jira.plugi... ]
Jason Greene moved JBEAP-13091 to WFCORE-3267:
----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3267 (was: JBEAP-13091)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: (was: 7.1.0.CR1)
> Authorization identity forwarding not exposed to configuration
> --------------------------------------------------------------
>
> Key: WFCORE-3267
> URL: https://issues.jboss.org/browse/WFCORE-3267
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jason Greene
> Assignee: Jason Greene
> Priority: Blocker
>
> As part of EAP7-284, Elytron was designed for and contains implementation to support trusted use of identities between peers in addition to credential forwarding. Cases in which one would prefer this approach include:
> * Scenarios where the user has requirements to not send passwords over the wire. Notably credential forwarding requires TLS and/or secure networks
> * Setups where an authentication type that does not support credential forwarding are used (credential forwarding is limited to Plain, Form, and OAuth, all other mechanisms, including the out of the box Digest auth of EAP are not)
> * Environments where its desired to limit which systems are allowed to receive requests which are propagated
> Due to an oversight this capability was not properly wired to the server configuration (nor a config method on the Elytron API).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3266) Simple permission mapper can't represent wildcards or spaces
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3266?page=com.atlassian.jira.plugi... ]
Jason Greene updated WFCORE-3266:
---------------------------------
Security: (was: Red Hat Internal)
> Simple permission mapper can't represent wildcards or spaces
> ------------------------------------------------------------
>
> Key: WFCORE-3266
> URL: https://issues.jboss.org/browse/WFCORE-3266
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jason Greene
> Assignee: Jason Greene
> Priority: Blocker
>
> The inability of the simple-permission-mapper to handle wildcards forces the user to utilize complex logical permission mapper chains to achieve common use cases. This makes simple changes, such as adding an additional permission to a user unnecessarily complex. In addition to construction complexity, modifications performed by non-experts are likely to lead to unintended behavior, including accidentally granting permissions to a user that should not have them.
> This is readily apparent by even our default configuration requiring the use of 3 permission mappers to handle the basic case of denying anonymous users and allowing everyone else.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9325) Reduce on-disk size and copying in the test suite
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9325?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9325:
----------------------------------------
Disabling standalone_xml_history needs to be configurable, as it's useful data when debugging problems. IIRC we already have some sort of switch that drives cleanup on CI so perhaps it could be repurposed.
> Reduce on-disk size and copying in the test suite
> -------------------------------------------------
>
> Key: WFLY-9325
> URL: https://issues.jboss.org/browse/WFLY-9325
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System, Test Suite
> Reporter: David Lloyd
> Assignee: Tomaz Cerar
>
> The test suite takes up large amounts of disk space (over 2.7GB) during build. This causes overhead for copying and bogs down test runs and CI. Find ways to mitigate this.
> First approach is to use Maven refs instead of fixed JARs in the build process:
> {code:diff}
> diff --git a/pom.xml b/pom.xml
> index fb2b68c..5805471 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -252,8 +252,8 @@
> <linkXRef>false</linkXRef>
>
> <server.output.dir.prefix>wildfly</server.output.dir.prefix>
> - <wildfly.build.output.dir>dist/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> - <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
> + <wildfly.build.output.dir>build/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> + <wildfly.web.build.output.dir>servlet-build/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
>
> <!--
> See ChildFirstClassLoaderBuilder in model-test for the explanation of the org.jboss.model.test.cache.root and org.jboss.model.test.classpath.cache properties.
> {code}
> This saves a bit of space but copied images are still taking upwards of 55MB each, and there are very many copies; consider this example from {{testsuite/integration/iiop/target}}:
> {noformat}
> 30M jbossas
> 55M jbossas-iiop-client
> 55M jbossas-iiop-server
> 55M jbossas-iiop-ssl-client
> 55M jbossas-iiop-ssl-legacy-server
> 55M jbossas-iiop-ssl-server
> {noformat}
> Within a typical copy (after the above patch), about half of the data is in {{bin}} and half is in {{standalone}}. In {{bin}}, the dominating files are:
> * {{2.2M wildfly-elytron-tool.jar}}
> * {{7.2M client/jboss-cli-client.jar}}
> * {{17M client/jboss-client.jar}}
> In {{standalone}}, the dominator is:
> * {{25M data/activemq}} (mostly journal files but also the {{bindings}} file)
> Together these four areas cover 51.4MB of the 55MB in each IIOP server copy.
> In other areas, big users include {{standalone_xml_history}}, which can be as large as 67MB. Disabling the across the board could help.
> We're also making over 50 copies of the {{docs}} directory at 2.3M per instance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9325) Reduce on-disk size and copying in the test suite
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9325?page=com.atlassian.jira.plugin.... ]
David Lloyd updated WFLY-9325:
------------------------------
Description:
The test suite takes up large amounts of disk space (over 2.7GB) during build. This causes overhead for copying and bogs down test runs and CI. Find ways to mitigate this.
First approach is to use Maven refs instead of fixed JARs in the build process:
{code:diff}
diff --git a/pom.xml b/pom.xml
index fb2b68c..5805471 100644
--- a/pom.xml
+++ b/pom.xml
@@ -252,8 +252,8 @@
<linkXRef>false</linkXRef>
<server.output.dir.prefix>wildfly</server.output.dir.prefix>
- <wildfly.build.output.dir>dist/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
- <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
+ <wildfly.build.output.dir>build/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
+ <wildfly.web.build.output.dir>servlet-build/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
<!--
See ChildFirstClassLoaderBuilder in model-test for the explanation of the org.jboss.model.test.cache.root and org.jboss.model.test.classpath.cache properties.
{code}
This saves a bit of space but copied images are still taking upwards of 55MB each, and there are very many copies; consider this example from {{testsuite/integration/iiop/target}}:
{noformat}
30M jbossas
55M jbossas-iiop-client
55M jbossas-iiop-server
55M jbossas-iiop-ssl-client
55M jbossas-iiop-ssl-legacy-server
55M jbossas-iiop-ssl-server
{noformat}
Within a typical copy (after the above patch), about half of the data is in {{bin}} and half is in {{standalone}}. In {{bin}}, the dominating files are:
* {{2.2M wildfly-elytron-tool.jar}}
* {{7.2M client/jboss-cli-client.jar}}
* {{17M client/jboss-client.jar}}
In {{standalone}}, the dominator is:
* {{25M data/activemq}} (mostly journal files but also the {{bindings}} file)
Together these four areas cover 51.4MB of the 55MB in each IIOP server copy.
In other areas, big users include {{standalone_xml_history}}, which can be as large as 67MB. Disabling the across the board could help.
We're also making over 50 copies of the {{docs}} directory at 2.3M per instance.
was:
The test suite takes up large amounts of disk space (over 2.7GB) during build. This causes overhead for copying and bogs down test runs and CI. Find ways to mitigate this.
First approach is to use Maven refs instead of fixed JARs in the build process:
{code:diff}
diff --git a/pom.xml b/pom.xml
index fb2b68c..5805471 100644
--- a/pom.xml
+++ b/pom.xml
@@ -252,8 +252,8 @@
<linkXRef>false</linkXRef>
<server.output.dir.prefix>wildfly</server.output.dir.prefix>
- <wildfly.build.output.dir>dist/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
- <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
+ <wildfly.build.output.dir>build/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
+ <wildfly.web.build.output.dir>servlet-build/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
<!--
See ChildFirstClassLoaderBuilder in model-test for the explanation of the org.jboss.model.test.cache.root and org.jboss.model.test.classpath.cache properties.
{code}
This saves a bit of space but copied images are still taking upwards of 55MB each, and there are very many copies; consider this example from {{testsuite/integration/iiop/target}}:
{noformat}
30M jbossas
55M jbossas-iiop-client
55M jbossas-iiop-server
55M jbossas-iiop-ssl-client
55M jbossas-iiop-ssl-legacy-server
55M jbossas-iiop-ssl-server
{noformat}
Within a typical copy (after the above patch), about half of the data is in {{bin}} and half is in {{standalone}}. In {{bin}}, the dominating files are:
* {{2.2M wildfly-elytron-tool.jar}}
* {{7.2M client/jboss-cli-client.jar}}
* {{17M client/jboss-client.jar}}
In {{standalone}}, the dominators is:
* {{25M data/activemq}} (mostly journal files but also the {{bindings}} file)
Together these four areas cover 51.4MB of the 55MB in each IIOP server copy.
In other areas, big users include {{standalone_xml_history}}, which can be as large as 67MB. Disabling the across the board could help.
We're also making over 50 copies of the {{docs}} directory at 2.3M per instance.
> Reduce on-disk size and copying in the test suite
> -------------------------------------------------
>
> Key: WFLY-9325
> URL: https://issues.jboss.org/browse/WFLY-9325
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System, Test Suite
> Reporter: David Lloyd
> Assignee: Tomaz Cerar
>
> The test suite takes up large amounts of disk space (over 2.7GB) during build. This causes overhead for copying and bogs down test runs and CI. Find ways to mitigate this.
> First approach is to use Maven refs instead of fixed JARs in the build process:
> {code:diff}
> diff --git a/pom.xml b/pom.xml
> index fb2b68c..5805471 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -252,8 +252,8 @@
> <linkXRef>false</linkXRef>
>
> <server.output.dir.prefix>wildfly</server.output.dir.prefix>
> - <wildfly.build.output.dir>dist/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> - <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
> + <wildfly.build.output.dir>build/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> + <wildfly.web.build.output.dir>servlet-build/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
>
> <!--
> See ChildFirstClassLoaderBuilder in model-test for the explanation of the org.jboss.model.test.cache.root and org.jboss.model.test.classpath.cache properties.
> {code}
> This saves a bit of space but copied images are still taking upwards of 55MB each, and there are very many copies; consider this example from {{testsuite/integration/iiop/target}}:
> {noformat}
> 30M jbossas
> 55M jbossas-iiop-client
> 55M jbossas-iiop-server
> 55M jbossas-iiop-ssl-client
> 55M jbossas-iiop-ssl-legacy-server
> 55M jbossas-iiop-ssl-server
> {noformat}
> Within a typical copy (after the above patch), about half of the data is in {{bin}} and half is in {{standalone}}. In {{bin}}, the dominating files are:
> * {{2.2M wildfly-elytron-tool.jar}}
> * {{7.2M client/jboss-cli-client.jar}}
> * {{17M client/jboss-client.jar}}
> In {{standalone}}, the dominator is:
> * {{25M data/activemq}} (mostly journal files but also the {{bindings}} file)
> Together these four areas cover 51.4MB of the 55MB in each IIOP server copy.
> In other areas, big users include {{standalone_xml_history}}, which can be as large as 67MB. Disabling the across the board could help.
> We're also making over 50 copies of the {{docs}} directory at 2.3M per instance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos commented on WFCORE-3210:
-----------------------------------------------
Hi,
I would just like to give some quick feedback on this issue.
I have now quickly tried to setup a simple module:
e.g modules/company/logrj1appenders/main/module.xml
This module, configuration is completely trivial and clen.
It references to our apenders jar, and it has module dependency org.apache.log4j module.
Then I plugged in the custom appender on the subsytem logging and configured all the properties.
And yes, It seems to be working nicely.
So one appender at least looks like it will just work with the subsytem logging nicely.
I have to test the rest of them when i come back.
:)
But the subsytem logging from wildfly looks pretty great.
This feature of supporting log4j1 appenders natively is fantastic.
It would be great if this gets extended in the future to kind of support each of the maing loging libraries like log4j2 etc...
Because then a person is completely free to chose the appender technology that he wishes to write an appender in, and trivially integrate it into the wildfly subsytem logging.
I cannot believe that the solution was this simple :).
But I am quite happy with this first test result.
Many many thanks for the help.
Kindest regards.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9325) Reduce on-disk size and copying in the test suite
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9325?page=com.atlassian.jira.plugin.... ]
David Lloyd updated WFLY-9325:
------------------------------
Description:
The test suite takes up large amounts of disk space (over 2.7GB) during build. This causes overhead for copying and bogs down test runs and CI. Find ways to mitigate this.
First approach is to use Maven refs instead of fixed JARs in the build process:
{code:diff}
diff --git a/pom.xml b/pom.xml
index fb2b68c..5805471 100644
--- a/pom.xml
+++ b/pom.xml
@@ -252,8 +252,8 @@
<linkXRef>false</linkXRef>
<server.output.dir.prefix>wildfly</server.output.dir.prefix>
- <wildfly.build.output.dir>dist/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
- <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
+ <wildfly.build.output.dir>build/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
+ <wildfly.web.build.output.dir>servlet-build/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
<!--
See ChildFirstClassLoaderBuilder in model-test for the explanation of the org.jboss.model.test.cache.root and org.jboss.model.test.classpath.cache properties.
{code}
This saves a bit of space but copied images are still taking upwards of 55MB each, and there are very many copies; consider this example from {{testsuite/integration/iiop/target}}:
{noformat}
30M jbossas
55M jbossas-iiop-client
55M jbossas-iiop-server
55M jbossas-iiop-ssl-client
55M jbossas-iiop-ssl-legacy-server
55M jbossas-iiop-ssl-server
{noformat}
Within a typical copy (after the above patch), about half of the data is in {{bin}} and half is in {{standalone}}. In {{bin}}, the dominating files are:
* {{2.2M wildfly-elytron-tool.jar}}
* {{7.2M client/jboss-cli-client.jar}}
* {{17M client/jboss-client.jar}}
In {{standalone}}, the dominators is:
* {{25M data/activemq}} (mostly journal files but also the {{bindings}} file)
Together these four areas cover 51.4MB of the 55MB in each IIOP server copy.
In other areas, big users include {{standalone_xml_history}}, which can be as large as 67MB. Disabling the across the board could help.
We're also making over 50 copies of the {{docs}} directory at 2.3M per instance.
was:
The test suite takes up large amounts of disk space (over 2.7GB) during build. This causes overhead for copying and bogs down test runs and CI. Find ways to mitigate this.
First approach is to use Maven refs instead of fixed JARs in the build process:
{code:diff}
diff --git a/pom.xml b/pom.xml
index fb2b68c..5805471 100644
--- a/pom.xml
+++ b/pom.xml
@@ -252,8 +252,8 @@
<linkXRef>false</linkXRef>
<server.output.dir.prefix>wildfly</server.output.dir.prefix>
- <wildfly.build.output.dir>dist/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
- <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
+ <wildfly.build.output.dir>build/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
+ <wildfly.web.build.output.dir>servlet-build/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
<!--
See ChildFirstClassLoaderBuilder in model-test for the explanation of the org.jboss.model.test.cache.root and org.jboss.model.test.classpath.cache properties.
{code}
This saves a bit of space but copied images are still taking upwards of 55MB each, and there are very many copies; consider this example from {{testsuite/integration/iiop/target}}:
{noformat}
30M jbossas
55M jbossas-iiop-client
55M jbossas-iiop-server
55M jbossas-iiop-ssl-client
55M jbossas-iiop-ssl-legacy-server
55M jbossas-iiop-ssl-server
{noformat}
Within a typical copy (after the above patch), about half of the data is in {{bin}} and half is in {{standalone}}. In {{bin}}, the dominating files are:
* {{2.2M wildfly-elytron-tool.jar}}
* {{7.2M client/jboss-cli-client.jar}}
* {{17M client/jboss-client.jar}}
In {{standalone}}, the dominators is:
* {{25M data/activemq}} (mostly journal files but also the {{bindings}} file)
Together these four areas cover 51.4MB of the 55MB in each IIOP server copy.
In other areas, big users include {{standalone_xml_history}}, which can be as large as 67MB. Disabling the across the board could help.
We're also making over 50 copies of the {{docs}} directory at 2.3M per instance.
> Reduce on-disk size and copying in the test suite
> -------------------------------------------------
>
> Key: WFLY-9325
> URL: https://issues.jboss.org/browse/WFLY-9325
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System, Test Suite
> Reporter: David Lloyd
> Assignee: Tomaz Cerar
>
> The test suite takes up large amounts of disk space (over 2.7GB) during build. This causes overhead for copying and bogs down test runs and CI. Find ways to mitigate this.
> First approach is to use Maven refs instead of fixed JARs in the build process:
> {code:diff}
> diff --git a/pom.xml b/pom.xml
> index fb2b68c..5805471 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -252,8 +252,8 @@
> <linkXRef>false</linkXRef>
>
> <server.output.dir.prefix>wildfly</server.output.dir.prefix>
> - <wildfly.build.output.dir>dist/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> - <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
> + <wildfly.build.output.dir>build/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> + <wildfly.web.build.output.dir>servlet-build/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
>
> <!--
> See ChildFirstClassLoaderBuilder in model-test for the explanation of the org.jboss.model.test.cache.root and org.jboss.model.test.classpath.cache properties.
> {code}
> This saves a bit of space but copied images are still taking upwards of 55MB each, and there are very many copies; consider this example from {{testsuite/integration/iiop/target}}:
> {noformat}
> 30M jbossas
> 55M jbossas-iiop-client
> 55M jbossas-iiop-server
> 55M jbossas-iiop-ssl-client
> 55M jbossas-iiop-ssl-legacy-server
> 55M jbossas-iiop-ssl-server
> {noformat}
> Within a typical copy (after the above patch), about half of the data is in {{bin}} and half is in {{standalone}}. In {{bin}}, the dominating files are:
> * {{2.2M wildfly-elytron-tool.jar}}
> * {{7.2M client/jboss-cli-client.jar}}
> * {{17M client/jboss-client.jar}}
> In {{standalone}}, the dominators is:
> * {{25M data/activemq}} (mostly journal files but also the {{bindings}} file)
> Together these four areas cover 51.4MB of the 55MB in each IIOP server copy.
> In other areas, big users include {{standalone_xml_history}}, which can be as large as 67MB. Disabling the across the board could help.
> We're also making over 50 copies of the {{docs}} directory at 2.3M per instance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9325) Reduce on-disk size and copying in the test suite
by David Lloyd (JIRA)
David Lloyd created WFLY-9325:
---------------------------------
Summary: Reduce on-disk size and copying in the test suite
Key: WFLY-9325
URL: https://issues.jboss.org/browse/WFLY-9325
Project: WildFly
Issue Type: Enhancement
Components: Build System, Test Suite
Reporter: David Lloyd
Assignee: Tomaz Cerar
The test suite takes up large amounts of disk space (over 2.7GB) during build. This causes overhead for copying and bogs down test runs and CI. Find ways to mitigate this.
First approach is to use Maven refs instead of fixed JARs in the build process:
{code:diff}
diff --git a/pom.xml b/pom.xml
index fb2b68c..5805471 100644
--- a/pom.xml
+++ b/pom.xml
@@ -252,8 +252,8 @@
<linkXRef>false</linkXRef>
<server.output.dir.prefix>wildfly</server.output.dir.prefix>
- <wildfly.build.output.dir>dist/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
- <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
+ <wildfly.build.output.dir>build/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
+ <wildfly.web.build.output.dir>servlet-build/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
<!--
See ChildFirstClassLoaderBuilder in model-test for the explanation of the org.jboss.model.test.cache.root and org.jboss.model.test.classpath.cache properties.
{code}
This saves a bit of space but copied images are still taking upwards of 55MB each, and there are very many copies; consider this example from {{testsuite/integration/iiop/target}}:
{noformat}
30M jbossas
55M jbossas-iiop-client
55M jbossas-iiop-server
55M jbossas-iiop-ssl-client
55M jbossas-iiop-ssl-legacy-server
55M jbossas-iiop-ssl-server
{noformat}
Within a typical copy (after the above patch), about half of the data is in {{bin}} and half is in {{standalone}}. In {{bin}}, the dominating files are:
* {{2.2M wildfly-elytron-tool.jar}}
* {{7.2M client/jboss-cli-client.jar}}
* {{17M client/jboss-client.jar}}
In {{standalone}}, the dominators is:
* {{25M data/activemq}} (mostly journal files but also the {{bindings}} file)
Together these four areas cover 51.4MB of the 55MB in each IIOP server copy.
In other areas, big users include {{standalone_xml_history}}, which can be as large as 67MB. Disabling the across the board could help.
We're also making over 50 copies of the {{docs}} directory at 2.3M per instance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-6882) A client is not able to invoke EJB's deployed as "HASingleton deployment"
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink updated WFLY-6882:
-----------------------------------
Priority: Blocker (was: Major)
> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
> Key: WFLY-6882
> URL: https://issues.jboss.org/browse/WFLY-6882
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Paul Ferraro
> Priority: Blocker
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3259) ModelTestUtils isn't confirming the transformed boot ops work on the legacy slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3259?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3259:
------------------------------------------
Note I have no idea if those failures indicate some problems in the transformers, or just are test issues.
> ModelTestUtils isn't confirming the transformed boot ops work on the legacy slave
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-3259
> URL: https://issues.jboss.org/browse/WFCORE-3259
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> In checkFailedTransformedBootOperations:
> {code}
> if (config.isTransformComposite()) {
> //Transform and execute the composite
> TransformedOperation transformedComposite = mainServices.transformOperation(modelVersion, legacyComposite);
> if (transformedComposite.rejectOperation(successResult())) {
> Assert.fail(transformedComposite.getFailureDescription());
> }
> mainServices.executeOperation(modelVersion, transformedComposite);
> }
> {code}
> The outcome of that "mainServices.executeOperation" is ignored, so if the transformation isn't actually producing good ops, we don't know that.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months