bug #8189
closed
Allow configuration of 'user.home' via the spring environment
Added by Andreas Kohlbecker about 5 years ago.
Updated over 4 years ago.
Description
By now it is only possible to configure the ${user.home} via the system properties. That means the only option to set the user.home variable is via the jvm command argument:
-Duser.home=/home/user/
The ${user.home} is crucial since it determines the location of the .cdmLibrary folder.
In end to end integration test (#8187) this is a big caveat since it requires the tests to be run with the correct -Duser.home argument to. Which would be the source of a lot of errors an confusion.
Therefore I suggest to let CdmUtils use the spring environment to determine the ${user.home} variable, this would be fully compatible with the current implementation but would also allow for more flexibility as it is needed in test contexts.
- Status changed from New to Resolved
- % Done changed from 0 to 50
close issue if the changes are not causing any problems.
- Related to feature request #8187: Use Spring Environment instead of custom code in AbstractWebApplicationConfigurer added
- Status changed from Resolved to In Progress
- Target version changed from Release 5.6 to Release 5.7
now that the changes made for this ticket are no longer causing any problems I will do the next step: turning all sping bean methods into not statically methods.
- Status changed from In Progress to Feedback
- Priority changed from New to Highest
- Severity changed from normal to blocker
The test ConfigFileUtilTest.testGetFolderSeperator does not work anymore on windows systems when running in maven (not tested other environment)
- Assignee changed from Andreas Kohlbecker to Andreas Müller
The test ConfigFileUtilTest.testGetFolderSeperator does not work anymore on windows systems when running in maven
Can you provide me the error message, stacktrace related to this failure?
The Method CdmUtils.getFolderSeperator() is completely redundant since File.separator is extected to provide the same Character. Why are we having an own implementation for somting that java core does for us?
Assert.assertEquals(File.separator, CdmUtils.getFolderSeperator());
Therefore I suggest removing that method as well as the CdmUtils.MUST_EXIST_FILEand the according file in the resources folder.
Andreas Kohlbecker wrote:
The test ConfigFileUtilTest.testGetFolderSeperator does not work anymore on windows systems when running in maven
Can you provide me the error message, stacktrace related to this failure?
Here it is:
Tests run: 3, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 0.13 sec <<< FAILURE!
testGetFolderSeperator(eu.etaxonomy.cdm.config.ConfigFileUtilTest) Time elapsed: 0.06 sec <<< FAILURE!
org.junit.ComparisonFailure: expected:<[\]> but was:<[/]>
at org.junit.Assert.assertEquals(Assert.java:115)
at org.junit.Assert.assertEquals(Assert.java:144)
at eu.etaxonomy.cdm.config.ConfigFileUtilTest.testGetFolderSeperator(ConfigFileUtilTest.java:26)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
- Assignee changed from Andreas Müller to Andreas Kohlbecker
Andreas Kohlbecker wrote:
The Method CdmUtils.getFolderSeperator() is completely redundant since File.separator is extected to provide the same Character. Why are we having an own implementation for somting that java core does for us?
I can't see why it should be redundant. CdmUtils.getFolderSeperator differentiates if the code runs from a jar bundle or if it runs from commandline. In the later case the first case you always need "/" as separator while in the later case it is OS dependendend and therefore the test fails.
Distinguishing this is e.g. important when term loading from csv files to distinguish the position of the csv files in the file system. If compiled to a jar you need another folder separator then reading from the ordinary folder on Windows because on Windows File.separator <> "/".
But I agree that we should maybe rename CdmUtils.getFolderSeperator to make clear that it is only for this specific usecase and it is not a general shortcut to replace File.separator
Therefore I do not agree to remove the method or to remove the MUST_EXIST_FILE (but we may remove if there is a better mechanism for this)
Andreas Kohlbecker wrote:
now that the changes made for this ticket are no longer causing any problems I will do the next step: turning all sping bean methods into not statically methods.
Is this already done?
Andreas Müller wrote:
Andreas Kohlbecker wrote:
now that the changes made for this ticket are no longer causing any problems I will do the next step: turning all sping bean methods into not statically methods.
Is this already done?
Not yet!
- Related to task #8505: ConfigFileUtil: turn all spring bean methods into not statical methods. added
- Status changed from Feedback to Closed
- % Done changed from 50 to 100
all remaining tasks copied to #8505
and closing this ticket
- Related to task #2387: make name and location of ~/.cdmlibrary folder configurable added
Andreas Müller wrote:
The test ConfigFileUtilTest.testGetFolderSeperator does not work anymore on windows systems when running in maven (not tested other environment)
By the way, I set the test to ignore (or completely deleted it, don't remember) as it didn't make any sense to me
- Related to task #8513: CdmUtils: remove MUST_EXIST_FILE and getResourceFolderSeperator() added
Andreas Müller wrote:
Andreas Müller wrote:
The test ConfigFileUtilTest.testGetFolderSeperator does not work anymore on windows systems when running in maven (not tested other environment)
By the way, I set the test to ignore (or completely deleted it, don't remember) as it didn't make any sense to me
I removed this test as well as the getFolderSeperator() method and the MUST_EXIST_FILE, see #8513 for details.
Also available in: Atom
PDF