Windows 11 Installation - Error in DB connectivity

I am facing the following when I try to setup openboxes in windows 11

Caused by: java.sql.SQLException: Access denied for user ‘root’@‘localhost’ (using password: YES)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:965)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3933)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3869)

  1. I have installed mysql version 5.7 and tomcat 8.5 (since 7 was not available)
  2. I have copied the war file and started the tomcat. thats when i see this error in logs.
  3. Also openboxes-config.properties is configured properly. I do not see “Unable to load specified config location” for openboxes-config.properties

Also, as a developer what is the openboxes version that I should consider to setup the dev setup. Is java 8 and above supported now in the opensource version. As Java 7 and tomcat 7 is already deprecated.

Hey @Mahesh_Thamilarasu

Thanks for the message, and apologies for the delay in responding.

Caused by: java.sql.SQLException: Access denied for user ‘root’@‘localhost’ (using password: YES)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:965)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3933)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3869)

I suspect this is caused by a common error running Tomcat on a Windows machine. I’m not sure if it’s a bug with Windows, Grails or Tomcat, but the file locations always end up getting mangled when the

Instead of a proper file location

c:\Users\username\.grails\openboxes-config.properties

the application looks for the file here

c:\.grails\openboxes-config.properties

essentially chopping off the USER_HOME or TOMCAT_HOME part of the file location path.

First of all, we need to confirm that this is the problem

Restart Tomcat and paste the first 100-200 lines of your stdout log file (sorry, I’ve forgotten what it’s called on Windows).

I’m looking for a snippet starting with “Using configuration locations …”. If you find it, paste it here to confirm.

Then we need to fix the issue

I think there are three options

  1. Copy your openboxes-config.properties into one of the locations reported in the log file.
  2. Figure out why USER_HOME or TOMCAT_HOME resolves to empty string
  3. Set up your own file location (there’s a configuration property for this, but

I would recommend using option (1) for now since the other two will require some troubleshooting and I’m guessing you just want to see this working.

There are some other posts here that might be helpful. You can also just search in the Search box for “Using configuration locations” to see posts with the same issue.

For option (3) you need to set one of the two command line arguments when starting Tomcat.

-Dopenboxes.config.location=<pathtofile>
-DOPENBOXES_CONFIG_LOCATION=<pathtofile>

In Ubuntu, I would create/edit the setenv.sh and pass this argument in via JAVA_OPTS or CATALINA_OPTS, but I have no idea where or how this would be set in Windows.

For reference, here’s the code in Config.groovy that adds these to our config file location candidates.

// Allow admin to override the config location using command line argument
configLocation = System.properties["${appName}.config.location"]
if (configLocation) {
    grails.config.locations << "file:" + configLocation
}

// Allow admin to override the config location using environment variable
configLocation = System.env["${appName.toString().toUpperCase()}_CONFIG_LOCATION"]
if (configLocation) {
    grails.config.locations << "file:" + configLocation
}

Also, as a developer what is the openboxes version that I should consider to setup the dev setup. Is java 8 and above supported now in the opensource version. As Java 7 and tomcat 7 is already deprecated.

The current codebase is based on Grails 1.3.7 (which only supports Java 7). We’ve been working on a migration of our codebase to Grails 3 (which supports Java 8) for a few years now.

Back in May, we were finally able to dedicate the whole team to this migration work. And as of this week, we are a few bug fixes away from a v0.9.0 release candidate. The code is stable, but there’s a bit more work to do on polishing documentation before we release v0.9.0 to the community.

If you’re interested, you can download a pre-release WAR file from our CI/CD servers. Let me know and I’ll send you the link.