added configuration options to configure log file folder location and pid file name and it's location

[Jermolinski]

No description provided.

[Sami32]

Typo: DEFAULT
DEFAILT_LOG_FOLDER_LINUX="/var/log/UMS/";

[Sami32]

Why having set DEFAILT ? typo ?

[Jermolinski]

=> TYPO?
yes, corrected it.

[Nadahar]

@Jermolinski Thank you for your contribution.

UMS has some challenges that you're probably not aware of, which complicate things slightly. There are a number of plugins for UMS that for historical reasons do pretty much what they want. Any changes in the existing API risks breaking those, and this has been a constant source of frustration when we try to evolve UMS. I've tried to make the log file path configurable in the past, but it didn't go down well with the plugin authors that claim that they have to be able to find the location from installers and scripts without actually launching UMS, and thus it must follow predictable rules. There has also been an attempt to enable plugins to be compatible with both UMS as the "anchestor project" PMS, which prevents altering the API. I won't go into what I think of this, it suffices to say that I disagree with the philosopy.

That said, the log file path is already configurable, it's just not very well documented, and anyone who alters it can expect plugins to break. If you look inside the JAR, you will find two files logback.xml and logback.headless.xml. These files can be extracted and placed in your profile folder, in which case they will be used instead of those in the JAR.

By editing these you can create the logfile anywhere you want, and you can also do other things like create multiple logfiles with different filtering, define rollover etc.

DefaultLogFilePath in UMS is simply applied to the variable logFilePath in those files, and doesn't have to be used.

I'm not sure if changing the default log file path will be accepted anymore now than in the past.

When it comes to the PID file, I've been meaning to rewrite the whole logic for a long time because there are several "side effects" with how it works today. I think you changes looks like they would be an improvement to the current implementation, even though my "plan" was to move away from using a PID file completely. There are too many things that can go wrong with a PID file taking permissions and location into account. Because UMS binds to sockets, running multiple instances of UMS only makes sense if they are run under different profiles (so that the port assignments can be different). That doesn't work properly either though, because not all the ports are currently configurable (something else I'm working on). Linux users have a general understanding of the PID file concept, but the Linux users is a very small part of our user base. Windows and OS X users generally doesn't understand what a PID file are, and many have no idea how filesystem permissions work or how to manage them, so it's a constant source of problems.

The implementation is also flawed in my opinion in that it works just the opposite of what is "normal". The fact that UMS find the PID file during launch doesn't prevent it from launching, it simply means that it kills the previous instance - causing abrupt termination of any renderer configuration and potentially corrupting the configuration file and the database. While it means that a orphaned PID file will never prevent UMS from launching (saving us all the support threads on that topic), it's very disruptive as I see it and can cause corruption that can be hard to debug/figurte out.