Util.applicationPath based on ProtectionDomain returns unintended context-/app-location
Hello everyone, I'm new to BaseX. Just evaluating if it fits in my current project. Looks great. My project uses maven, BaseX 6.3.2 is added as a dependency according to your documentation. Here comes the problem: The resolution of the Prop.HOME-Directory (thus the location of the props-file ".basex") doesn't fit the intended behavior (as far as I got the intention), when using (Netbeans and) maven for build and run. And it should not work as intended when placing the basex-jars in a lib-directory as well. AFAIK, it's supposed to be a directory relative to the path in which the application got executed (if props ".basex" are found there, otherwise the users home directory). (If however the current path should be the intended one, then I'd say it's not very intuitive or practical) Using (Netbeans and) maven for build and run, causes the relative path to result in the maven-repository-location of the xbase-jar. (e.g. "{repository-root}/.m2/...") That's definitely no place for a props-file, so it will always result in the user-home-directory. I don't want to pollute the users home directory however (besides we plan to make the app portable), that's why I was wondering if you could detect the relative path in another way. Here's the details of what's currently happening: The creation of the Database: Class<?> c = Class.forName(DRIVER); Database db = (Database) c.newInstance(); causes several initializations to happen. Among others, there's the static initializer of Prop (line 38), which calls Util.applicationPath() to calculate the HOME directory. The method body of applicationPath starts with final String path = Util.class.getProtectionDomain(). getCodeSource().getLocation().getPath(); which returns the location of the jar in the maven repository, which is not the application path (and could result in a completely unintended path when using custom-classloaders). Suggestion: Could you just calculate the working directory like this: final String path = new File(".").getPath(); or final String path = new File(".").getAbsolutePath(); This would IMHO result in a more intuitive location for the working- (or config-)directory. I'd suggest to put that into a new method, say Util.workingPath() (or Util.configPath()), to prevent trouble with code, that actually needs to receive the jar-file-location (if such code exists at all). To stay compatible with the old resolution strategy, you could just add this line of code on top of the old resolution, thus provide a third location for props. I'd contribute this patch by myself, if you'd agree. Future needs for my application are dynamic configuration of port-ranges and stuff, that's why I'd also love to have the opportunity to configure BaseX completely by the use of the API, without having to deal with config-files for "third-party-libs". BaseX looks great and I'd love to use it for my project if it proves to be adequate. Great work! Greetings, -- Thomas
Hi Thomas, thanks for your thorugh feedback. Yes, finding the optimal location for the property files has been a popular topic for discussion: – The main location for the props has always been the user home directory, as it turned out to cause the least problems for most users and use cases. – The "application path" (the terminology refers to the "BaseX Application") was added just recently to simplify portable installations of BaseX and to support the upcoming Windows installer. I understand pretty well that you would benefit from a third solution, which uses the working directory for the property files, and I think this solution shouldn't cause any unwanted side effects. The working directory can also be requested via System.getProperty("user.dir"). Feel free to provide us with a patch that works out for you, Christian On Wed, Nov 17, 2010 at 1:37 PM, Thomas <basex@macrominds.de> wrote:
Hello everyone,
I'm new to BaseX. Just evaluating if it fits in my current project. Looks great. My project uses maven, BaseX 6.3.2 is added as a dependency according to your documentation.
Here comes the problem:
The resolution of the Prop.HOME-Directory (thus the location of the props-file ".basex") doesn't fit the intended behavior (as far as I got the intention), when using (Netbeans and) maven for build and run. And it should not work as intended when placing the basex-jars in a lib-directory as well.
AFAIK, it's supposed to be a directory relative to the path in which the application got executed (if props ".basex" are found there, otherwise the users home directory). (If however the current path should be the intended one, then I'd say it's not very intuitive or practical)
Using (Netbeans and) maven for build and run, causes the relative path to result in the maven-repository-location of the xbase-jar. (e.g. "{repository-root}/.m2/...")
That's definitely no place for a props-file, so it will always result in the user-home-directory.
I don't want to pollute the users home directory however (besides we plan to make the app portable), that's why I was wondering if you could detect the relative path in another way.
Here's the details of what's currently happening:
The creation of the Database: Class<?> c = Class.forName(DRIVER); Database db = (Database) c.newInstance();
causes several initializations to happen. Among others, there's the static initializer of Prop (line 38), which calls Util.applicationPath() to calculate the HOME directory.
The method body of applicationPath starts with final String path = Util.class.getProtectionDomain(). getCodeSource().getLocation().getPath();
which returns the location of the jar in the maven repository, which is not the application path (and could result in a completely unintended path when using custom-classloaders).
Suggestion: Could you just calculate the working directory like this:
final String path = new File(".").getPath(); or final String path = new File(".").getAbsolutePath();
This would IMHO result in a more intuitive location for the working- (or config-)directory.
I'd suggest to put that into a new method, say Util.workingPath() (or Util.configPath()), to prevent trouble with code, that actually needs to receive the jar-file-location (if such code exists at all).
To stay compatible with the old resolution strategy, you could just add this line of code on top of the old resolution, thus provide a third location for props.
I'd contribute this patch by myself, if you'd agree.
Future needs for my application are dynamic configuration of port-ranges and stuff, that's why I'd also love to have the opportunity to configure BaseX completely by the use of the API, without having to deal with config-files for "third-party-libs".
BaseX looks great and I'd love to use it for my project if it proves to be adequate. Great work!
Greetings,
-- Thomas
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Hi Christian, great. Thanks. I'll provide the patch asap. Greetings, -- Thomas On 18.11.2010 01:25, Christian Grün wrote:
Hi Thomas,
thanks for your thorugh feedback. Yes, finding the optimal location for the property files has been a popular topic for discussion:
– The main location for the props has always been the user home directory, as it turned out to cause the least problems for most users and use cases.
– The "application path" (the terminology refers to the "BaseX Application") was added just recently to simplify portable installations of BaseX and to support the upcoming Windows installer.
I understand pretty well that you would benefit from a third solution, which uses the working directory for the property files, and I think this solution shouldn't cause any unwanted side effects.
The working directory can also be requested via System.getProperty("user.dir"). Feel free to provide us with a patch that works out for you,
Christian
On Wed, Nov 17, 2010 at 1:37 PM, Thomas <basex@macrominds.de> wrote:
Hello everyone,
I'm new to BaseX. Just evaluating if it fits in my current project. Looks great. My project uses maven, BaseX 6.3.2 is added as a dependency according to your documentation.
Here comes the problem:
The resolution of the Prop.HOME-Directory (thus the location of the props-file ".basex") doesn't fit the intended behavior (as far as I got the intention), when using (Netbeans and) maven for build and run. And it should not work as intended when placing the basex-jars in a lib-directory as well.
AFAIK, it's supposed to be a directory relative to the path in which the application got executed (if props ".basex" are found there, otherwise the users home directory). (If however the current path should be the intended one, then I'd say it's not very intuitive or practical)
Using (Netbeans and) maven for build and run, causes the relative path to result in the maven-repository-location of the xbase-jar. (e.g. "{repository-root}/.m2/...")
That's definitely no place for a props-file, so it will always result in the user-home-directory.
I don't want to pollute the users home directory however (besides we plan to make the app portable), that's why I was wondering if you could detect the relative path in another way.
Here's the details of what's currently happening:
The creation of the Database: Class<?> c = Class.forName(DRIVER); Database db = (Database) c.newInstance();
causes several initializations to happen. Among others, there's the static initializer of Prop (line 38), which calls Util.applicationPath() to calculate the HOME directory.
The method body of applicationPath starts with final String path = Util.class.getProtectionDomain(). getCodeSource().getLocation().getPath();
which returns the location of the jar in the maven repository, which is not the application path (and could result in a completely unintended path when using custom-classloaders).
Suggestion: Could you just calculate the working directory like this:
final String path = new File(".").getPath(); or final String path = new File(".").getAbsolutePath();
This would IMHO result in a more intuitive location for the working- (or config-)directory.
I'd suggest to put that into a new method, say Util.workingPath() (or Util.configPath()), to prevent trouble with code, that actually needs to receive the jar-file-location (if such code exists at all).
To stay compatible with the old resolution strategy, you could just add this line of code on top of the old resolution, thus provide a third location for props.
I'd contribute this patch by myself, if you'd agree.
Future needs for my application are dynamic configuration of port-ranges and stuff, that's why I'd also love to have the opportunity to configure BaseX completely by the use of the API, without having to deal with config-files for "third-party-libs".
BaseX looks great and I'd love to use it for my project if it proves to be adequate. Great work!
Greetings,
-- Thomas
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Hi Christian, am I supposed to send the .diff to you or do you want me to send it to the list? -- Thomas On 18.11.2010 01:25, Christian Grün wrote:
Hi Thomas,
thanks for your thorugh feedback. Yes, finding the optimal location for the property files has been a popular topic for discussion:
– The main location for the props has always been the user home directory, as it turned out to cause the least problems for most users and use cases.
– The "application path" (the terminology refers to the "BaseX Application") was added just recently to simplify portable installations of BaseX and to support the upcoming Windows installer.
I understand pretty well that you would benefit from a third solution, which uses the working directory for the property files, and I think this solution shouldn't cause any unwanted side effects.
The working directory can also be requested via System.getProperty("user.dir"). Feel free to provide us with a patch that works out for you,
Christian
On Wed, Nov 17, 2010 at 1:37 PM, Thomas <basex@macrominds.de> wrote:
Hello everyone,
I'm new to BaseX. Just evaluating if it fits in my current project. Looks great. My project uses maven, BaseX 6.3.2 is added as a dependency according to your documentation.
Here comes the problem:
The resolution of the Prop.HOME-Directory (thus the location of the props-file ".basex") doesn't fit the intended behavior (as far as I got the intention), when using (Netbeans and) maven for build and run. And it should not work as intended when placing the basex-jars in a lib-directory as well.
AFAIK, it's supposed to be a directory relative to the path in which the application got executed (if props ".basex" are found there, otherwise the users home directory). (If however the current path should be the intended one, then I'd say it's not very intuitive or practical)
Using (Netbeans and) maven for build and run, causes the relative path to result in the maven-repository-location of the xbase-jar. (e.g. "{repository-root}/.m2/...")
That's definitely no place for a props-file, so it will always result in the user-home-directory.
I don't want to pollute the users home directory however (besides we plan to make the app portable), that's why I was wondering if you could detect the relative path in another way.
Here's the details of what's currently happening:
The creation of the Database: Class<?> c = Class.forName(DRIVER); Database db = (Database) c.newInstance();
causes several initializations to happen. Among others, there's the static initializer of Prop (line 38), which calls Util.applicationPath() to calculate the HOME directory.
The method body of applicationPath starts with final String path = Util.class.getProtectionDomain(). getCodeSource().getLocation().getPath();
which returns the location of the jar in the maven repository, which is not the application path (and could result in a completely unintended path when using custom-classloaders).
Suggestion: Could you just calculate the working directory like this:
final String path = new File(".").getPath(); or final String path = new File(".").getAbsolutePath();
This would IMHO result in a more intuitive location for the working- (or config-)directory.
I'd suggest to put that into a new method, say Util.workingPath() (or Util.configPath()), to prevent trouble with code, that actually needs to receive the jar-file-location (if such code exists at all).
To stay compatible with the old resolution strategy, you could just add this line of code on top of the old resolution, thus provide a third location for props.
I'd contribute this patch by myself, if you'd agree.
Future needs for my application are dynamic configuration of port-ranges and stuff, that's why I'd also love to have the opportunity to configure BaseX completely by the use of the API, without having to deal with config-files for "third-party-libs".
BaseX looks great and I'd love to use it for my project if it proves to be adequate. Great work!
Greetings,
-- Thomas
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
participants (2)
-
Christian Grün -
Thomas