After typing that above comment, i may have been a bit hasty. Mainly due to the constant blind eye we usually get from Atlassian regarding bugs and nonsensical changes to systems that received no thought from your product managers, then logic is not listened to and blatantly ignored.

I was thinking of a different server, and yes, we do have a JAVA_HOME variable on that server due to fisheye/crucible needing it.

Therefore, your investigation into this issue may have been correct in that the service.bat file may be using that directory. However, this still does not deter from the fact that this is a Standalone version of Confluence and therefore should default to using the built in version of Java. Therefore, I think this is still a bug in the fact that if a customer chooses to not install a service, then at a later point decides to install a service using the service.bat file, it will not be using the built-in version of Java. This should be resolved so that the standalone version of your application is truly standalone and provide options to the users to change these versions if necessary. It shouldn't be the default to use JAVA_HOME when using a standalone version.

I apologize for the hasty reply earlier, but i still do believe that this is a bug since this is a standalone application.

Thanks.

First, I don't think this was a question. It is a Bug in that it is NOT using the built in version of Java that came with the standalone version of Confluence. I do NOT have a Java version installed on the server or a JRE_HOME variable configured for the purpose of inadvertently changing and applications JRE without knowing it. So we rely on every application to explicitly call out a specific Java version.

Therefore, in a standalone installation of Confluence, don't you think it should always use the "standalone" version of Java that came with the standalone version of confluence? That is the way it works for the service.bat for JIRA. I have used the service.bat for JIRA many times in the past and it still successfully uses the built-in version of Java without issue. The reason i was using the service.bat for Confluence is because you changed the way the service was installed and it now uses a giant service ID in the service name instead of the application name that I provide during installation. So, to ensure everything was set up correctly, i used the service.bat file to remove the service, change the service name in the file, then re-add the service using the same file. Well, this resulted in the service attempting to use a JRE version from a directory which does not even exist on my server.

I then looked through the service.bat file and noticed that it is defaulting to that directory as i mentioned in my description. I could solve this myself and re-write your service.bat file, but I don't think it is the responsibility of the customer to be fixing the vendors applications. Therefore, i filled a bug in your system. Then, instead of attempting to reproduce the issue or ask for further clarification, you instead add a cookie cutter comment to the issue, then close it as "Answered".

Your assumption that the service.bat file is using a JRE_HOME variable on our system is incorrect, and this should still be a bug if it is defaulting to a supposed JRE directory which does not even exist. On top of that, since this is a standalone installation, then the entire installation should stand alone without the need for anything else. Therefore, the tools included should also point to the included JRE instead of a fictional directory.

Please re-open this issue. Thanks.

Dear abarylak,

Thanks for submitting the ticket.
When we use service.bat to install the Confluence service, it will use 2 existing environments variable JAVA_HOME or JRE_HOME
If your environment variables JRE_HOME is pointing to C:\Java\jdk1.6.0_45\jre, that means Confluence will use your value

So i suggest you to define JRE_HOME variable by using the built-in C:\Program Files\Atlassian\Confluence\jre

That will help solve your problem.

Thanks,
Minh Tran
Confluence BugMaster
Atlassian