NX Contractor - silly "working directory" question

[BillLeighton]

regarding the instructions "Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory." Um, where would the "current working directory" be? If I am creating or reading this file form a class in a package called "suncertify.client", would that be the directory? Sun seems very specific on where things should be locared for submission, like help files, etc. Or would it be the "root" of the runme.jar?

[Andrew Monkhouse]

Hi Bill
Take a look at System.getProperty("user.dir") - this should be your current working directory.
Your current working directory is the directory you are in when you start your application. This may not be the same directory as where the application resides.
For example, if I run:

cd /tmp
java -jar /home/andrewm/scjd/dist/client.jar

Then my current working directory is /tmp
To put that into Microsoft format:

C:
cd \temp
java -jar z:\scjd\dist\client.jar

Then my current working directory is c:\temp
Having the properties file in the current working directory instead of being with the jar file could be quite logical - it means that parameters that are stored per client can be accomodated.
For example, if you stored the size and placement of the window in the properties file, then the next time the user runs your application they will get the same screen placement they had last time - which is a nice feature. But you would not want that stored in a common properties file, otherwise you could get some other user's prefered screen size and placement.
Regards, Andrew

[BillLeighton]

Thanks, Andrew!

[Philippe Maquet]

Hi Andrew,

Your current working directory is the directory you are in when you start your application. This may not be the same directory as where the application resides.

That's why I don't like System.getProperty("user.dir") to store a property file. The first time I used it, I couldn't find the file produced. As I used SUN One Studio as an editor and ran my app from it, I finally found my property file in C:\Program Files\s1studio_jdk\s1studio\bin . I found that so silly, that I now save it in the same directory as my executable jar.
If you loose the last placement of a window, it's no disaster. But what if the server looses the port it must listen to, or the fine-tuning settings of its Data class ?
By using the application installation directory, you make the application responsible for finding where to save/retrieve its properties. By using user.dir, you delegate that responsability to the user. And as the latter is typically less consistent and reliable that your code ...

Having the properties file in the current working directory instead of being with the jar file could be quite logical - it means that parameters that are stored per client can be accomodated.
For example, if you stored the size and placement of the window in the properties file, then the next time the user runs your application they will get the same screen placement they had last time - which is a nice feature. But you would not want that stored in a common properties file, otherwise you could get some other user's prefered screen size and placement.

Normally, clients will run on different machines, right ? So I don't see the issue there.
Regards,
Phil.

[Andrew Monkhouse]

Hi Philippe
I get the distinct impression that you try and save your users from the problems that they can cause themselves
Unfortunately we do have to follow the specs, even if we disagree with them. In this case, Bill mentioned the requirement:

Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory.

So we cannot store it in the same location as the jar file, because the jar file may not be in the current working directory.
I do agree with the problems you mentioned though - in real life I would probably have two configuration files. One with the jar file to contain system wide parameters, and one in the user directory (or even better, use Preferences for the user Preferences).

Andrew: Having the properties file in the current working directory instead of being with the jar file could be quite logical - it means that parameters that are stored per client can be accomodated.
For example, if you stored the size and placement of the window in the properties file, then the next time the user runs your application they will get the same screen placement they had last time - which is a nice feature. But you would not want that stored in a common properties file, otherwise you could get some other user's prefered screen size and placement.
Philippe: Normally, clients will run on different machines, right ? So I don't see the issue there.

My comment was that if two clients are running on different machines, but using the same properties file in a common location, then one would overwrite the other.
If you are only storing generic information (server name & port) then this might not be a problem since they are probably the same for both users (not necessarily though: what if one user wants to have a "test" configuration).
But if you are storing information such as window size, and I store my preferred window size of 1152x864 (yes that is my current screen size / window size) in the common location, and you try and start the application in a system that is configured for 1024x786, what happens? On some systems it might ignore your request as being unreasonable. On others it might decide to use the specified size and just have all the controls displayed off screen.
Regards, Andrew

[Jay Bromley]

Hello all,
Not to beat a dead horse, but I've read most of the threads on where to put suncertify.properties and I still am not even close to being sure about what I should do. The part of the assignment that I can't figure out is the following:

Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory.

This requirement seems so utterly ridiculous that I'm thinking I must be interpreting it wrong. I'm very much a command-line Unix type of guy, so strictly implementing this means I'll end up with suncertify.properties files littered throughout my filesystem. What's worse, If I start from one directory, make some settings and then later start from a different directory (completely likely given the way I, and I think most people, work) I lose the previous settings because suncertify.properties won't be in the current directory. What a pain! This requirement is a must, so I'm afraid to do it any other way, like putting the file in the same directory with the app jar.
OK, so I could create the properties file in the current directory and then copy it to somewhere in the application. Then, when the app is launched from a different directory I could copy the app's version to the new current directory. The only problem is that I then have to come up with some sort of conflict resolution for when different users set different settings. Aaargh! It's all seemingly so simple and yet so maddening...
In the real world, some type of application launch script could solve the problem, but for the SCJD I'm lost on this one. How have others out there gotten around this?
Tnanks for any tips,
Jay
[ December 19, 2003: Message edited by: Jay Bromley ]

[Philippe Maquet]

Hi Jay,

Not to beat a dead horse, but I've read most of the threads on where to put suncertify.properties and I still am not even close to being sure about what I should do.

It's quite rare that a so old post comes back into life, but you did well in this case IMO. In the meantime, I changed my mind in comparison with what I wrote in July.
I still think you're 100% right in all you wrote just above, but Andrew convinced me that the instructions are clear : current directory cannot be interpreted otherwise than by System.getProperty("user.dir"), even though it's not the more user-friendly solution.
You may use your choices.txt file to explain why you think it's a shame the instructions are what they are (BTW, it would prove that you were aware of a possible issue), but as it's a "must" instruction, I wouldn't take any risk in that area.
Before Andrew convinced me, I wrote this method as a standard way of getting the "executable file" path :

    /**
     * Returns the execution path (.class path name) of a given class.
     *
     * The returned path name includes a trailing <code>File.separator</code>.
     *
     * Special cases:
     * <ul>
     * <li>If the class was executed from a <b>jar file</b>, the path returned is the jar file path.</li>
     * <li>If any exception is thrown during the process, <code>System.getProperty("user.dir")</code> is returned instead
     * (best effort).
     * </ul>
     *
     * @param aClass  the class whose execution path has to be returned
     * @return the execution path name of a the given class
     */
    public static String getExecutionPathOf(Class aClass) {
        String pathOfClass;
        try {
            String className = aClass.getName(); // full class name includes package name
            String pureClassName = className.substring(className.lastIndexOf(
                '.') + 1);
            URL url = aClass.getResource(pureClassName + ".class");
            pathOfClass = new File( (new URI("file://" + url)).getPath()).
                getParent();
            int posExclamationMark = pathOfClass.indexOf('!');
            if (posExclamationMark != -1) { // class is in a jar file
                pathOfClass = pathOfClass.substring(0,
                    pathOfClass.lastIndexOf(File.separator, posExclamationMark)
                    + 1);
            }
            else {
                pathOfClass += File.separator;
            }
        }
        //catch (java.net.URISyntaxException e) {
        catch (Exception e) {
            pathOfClass = System.getProperty("user.dir") + File.separator;
        }
        return pathOfClass;
    }

But I don't use it anymore to locate the suncertify.properties file, though I found another use for it : the default path for the DB file.
Cheers,
Phil.
[ December 19, 2003: Message edited by: Philippe Maquet ]

[Andrew Monkhouse]

Hi Jay,

OK, so I could create the properties file in the current directory and then copy it to somewhere in the application. Then, when the app is launched from a different directory I could copy the app's version to the new current directory. The only problem is that I then have to come up with some sort of conflict resolution for when different users set different settings. Aaargh! It's all seemingly so simple and yet so maddening...

Similar solutions have been discussed a few times - it does seem to have some nice points (although a little beyond the requirements of the assignment).
I think the basic concept for a propogating properties file was:

if we are in the same directory as the jar file {
    do normal processing
} else {
    if we do not currently have a properties file in the current working directory {
        if there is a properties file with the jar file {
            copy it locally and use it
        } else {
            start with defaults
        }
    } else {
        use the local "customised" properties file
    }
}
when we have finished making configuration changes {
    if there is no properties file with the jar file {
        copy the local properties file to the directory with the jar file
        (note the local properties file is still stored in the cwd)
    }
}

This makes some things easy - you can have the IP address and Port number in the properties file which is stored with the jar file. And if someone starts the application from a brand new working directory, then they will automagically get the correct IP/Port as a default.
This does not solve the conflict resolution issue you mentioned. But I think we should not look at that issue. The instructions tell us that configurable items must be stored in the properties file in the current working directory, and loading potential updates of IP/Port from another file in a different directory (ignoring the current settings) would (IMHO) be a contradiction to those instructions.
It also does not solve the problem of having configuration files littered all over your system. Unfortunately getting around this would contradict the instructions. It would be better if the assignment allowed us to use java.util.prefs.Preferences - that way we could still have per user configuration, without the worry of which directory the user started in. But the instructions are explicit that we should be using a properties file .
Regards, Andrew

[Jay Bromley]

Hello,
First off, sorry about posting basically the same rant in a similar new thread, I was so worked up I wrote before checking this thread...
Thanks Phillippe and Andrew, I think I'm more at peace with this now. I was thinking of something roughly along the lines you mentioned, Andrew, but I wasn't sure how far down the rathole I should go.
I'm still a little bit weird about this requirement, because it's definitely not good design. I know the bit about users who don't know why they want something and bad implementation requirements, but in the real world I'd try to explain to the user why this is a very bad thing and why it doesn't matter to the end user. I can understand mandating the database interface, for example, but this just makes no sense to me, and even less in that it fosters less than optimal designs.
Anyway, thanks for the help. I think I've seen the murky light.
Thanks and regards,
Jay