powered by Jive Software

Spark.properties file in wrong location?

I’ve been trying to install Spark 2.5.8 on a Windows Vista Enterprise (32-bit) machine.

The issue I’m having is that both the EXE and MSI installer place the spark.properties file in C:\Users\default\Spark and not C:\Users%username%\Spark. This causes the properties file to the shared amoung everyone who logs into that machine… which as you could image is not the behavior I’m looking for.

Has anyone else ran into this issue, or know how to solve it?




I need to know how to fix this issue. I haven’t been able to figure it out from the source code… this is pretty much breaking my company’s implementation of Spark as our internal chat client.

It’s a little discouraging to see more than one thread about this, some years old, with no resolution.

The spark installer does not create the properties file. It is created at the launch of spark. This issue will need to be addressed with a later build of spark if that ever happens.

Yes, I’ve tracked down the problem… never fails that just when I give up and post about it, I find the solution. When I’m 100%, I will post how to change the Spark preferences location here.

To make this work, you’ll have to be creating your own custom build. I have the folder being created in the user’s Application Data folder.

Edit src\java\org\jivesoftware\Spark.java ln 42

private static final String USER_SPARK_HOME = System.getProperties().getProperty("user.home") + "/" getUserConf();

Change to:

private static final String USER_SPARK_HOME = System.getProperties().getProperty("user.home") + "/" + "Application Data" + "/" + getUserConf();

This is now working in my company. Hope it helps you out.

For the record, this information should have been a LOT easier to get.


that’s a nice change, but an existing installation will have to have a migration mechanism to move the properties from the old to the new location.


In my company, that’s fine… we’re just rolling out a branded version of Spark to use here.

If I had to migrate the properties, I’d probably use group policy to run a script at login to move the preferences if they already exist. For us though, our branded Spark has been heavilly modified, and users can’t modify their preferences from what we’ve set for them anyway.

I’m not convinced that this community is motivated enough to look in to actually making those changes beyond that though.

As you might have noticed, the Spark client is moving again, at least on the level of the SVN. If your “modified” Spark client has also bug fixes that might be of general use for the project, it would be most appreciated to have them in the community forum. I am sure that cstux (who is currently managing the trunk) will look into it an commit those changes. He is doing this for the bug fixes we are doing for our company client.