I didn't see the JIRA, so I'm copying the dev list. It was removed because the semantic was unclear. Users were expecting to pass in an absolute file and then have the AS write back to that file. We're not going to support writing outside the configuration/ dir and never intended to. I agree though that completely eliminating this was not the best solution, as there's a good use case for it. Besides the testing issue, some folks don't like the AS overwriting the config file in the first place, so passing in a config file in a non-writable location is a workaround solution for them. My thoughts on this were to allow an --initial-server-config (for standalone) and --initial-domain-config and --initial-host-config (for domain). They would allow absolute paths. Their names and documentation would indicate their contents are read when the process is first started and thereafter are ignored. On 2/13/12 4:28 AM, Ondřej Žižka wrote: > I've created a jira for this task, > let's discuss there. > > Thx, > Ondra > > > Ondřej Žižka píše v Po 13. 02. 2012 v 11:15 +0100: >> Hi Brian, >> >> what was the reason to restrict AS config in sys prop to a relative path? >> >> In the testsuite, we would make use of absolute paths. >> The reason is that we reuse the configs from docs/examples, and they >> change quite often, so having them in resources would be hardly >> maintainable. >> However, docs/examples is not guaranteed to be always in the same >> place: E.g. for EAP, or for RPM-based installation of EAP it might end >> up in /var/docs or such. >> >> I would like to pass some property from maven to the tests, but that >> results in absolute path. >> >> Thanks, >> Ondra >

I didn't see the JIRA, so I'm copying the dev list. It was removed because the semantic was unclear. Users were expecting to pass in an absolute file and then have the AS write back to that file. We're not going to support writing outside the configuration/ dir and never intended to. I agree though that completely eliminating this was not the best solution, as there's a good use case for it. Besides the testing issue, some folks don't like the AS overwriting the config file in the first place, so passing in a config file in a non-writable location is a workaround solution for them. My thoughts on this were to allow an --initial-server-config (for standalone) and --initial-domain-config and --initial-host-config (for domain). They would allow absolute paths. Their names and documentation would indicate their contents are read when the process is first started and thereafter are ignored. On 2/13/12 4:28 AM, Ondřej Žižka wrote: > I've created a jira for this task, > let's discuss there. > > Thx, > Ondra > > > Ondřej Žižka píše v Po 13. 02. 2012 v 11:15 +0100: >> Hi Brian, >> >> what was the reason to restrict AS config in sys prop to a relative path? >> >> In the testsuite, we would make use of absolute paths. >> The reason is that we reuse the configs from docs/examples, and they >> change quite often, so having them in resources would be hardly >> maintainable. >> However, docs/examples is not guaranteed to be always in the same >> place: E.g. for EAP, or for RPM-based installation of EAP it might end >> up in /var/docs or such. >> >> I would like to pass some property from maven to the tests, but that >> results in absolute path. >> >> Thanks, >> Ondra >