After a JSP migration, the database is one of the first areas to verify because even a small mismatch in credentials, host names, or connection settings can prevent the application from starting correctly. If your JSP application was moved to a new hosting environment or reconfigured in Plesk, check the database details in the application configuration before you troubleshoot Tomcat, the servlet container, or the code itself.
In a managed hosting setup with Java hosting and My App Server, JSP applications often run in a private JVM with Apache Tomcat and connect to MySQL through application properties, environment values, or a JNDI resource. During migration, the most common issues are not with the database engine itself, but with the connection string, username, password, database name, and allowed host values.
What should be verified first
Start with the basic connection details that your JSP app uses to reach MySQL. If one value changed during the migration, the application may still deploy in Tomcat but fail when it tries to open a database connection.
- Database name - confirm that the application points to the correct schema.
- Database username - check that the account exists in the new hosting configuration.
- Password - verify that the password stored in the app configuration matches the current database password.
- Database host - confirm whether the app should use localhost, 127.0.0.1, or a specific internal hostname.
- Port - make sure the MySQL port is correct, especially if the migration changed the connection target.
- Connection string - review the JDBC URL for syntax, database name, SSL options, and character settings.
In many JSP applications, these values are stored in a properties file, XML config, or directly in the Java code. In a Plesk-based hosting environment, you may also find them in deployment-specific settings or environment variables used by the Tomcat application.
Check the JDBC connection string
The JDBC URL is often the fastest way to identify a migration problem. If the database moved, the JDBC string may still contain the old host name, old schema name, or an unsupported option.
Common items to review in the JDBC URL
- Host value - should match the current database server location used by the hosted app.
- Database name - verify the exact schema name after migration.
- Port number - confirm the MySQL port if a non-default port is used.
- Character encoding - make sure the URL uses the expected encoding, such as UTF-8.
- Timezone or SSL parameters - remove or update values that no longer fit the new environment.
Example of a typical MySQL JDBC URL used by a JSP application:
jdbc:mysql://localhost:3306/exampledb?useUnicode=true&characterEncoding=utf8&useSSL=false
If the application was migrated into a hosting account with My App Server, the database connection may still work with localhost when MySQL is on the same hosted platform. However, do not assume this automatically after a migration. Always test the value that your hosting provider documents for the specific account or service setup.
Confirm that the database user still exists
A common migration issue is a username that was copied into the code but not recreated correctly in the new environment. MySQL users are separate from the database itself, so the schema may exist while the login account does not.
Check the following:
- The database user name is correct and has not been changed.
- The user is assigned to the correct database.
- The user has the required privileges for the JSP application.
- The user password was updated in both MySQL and the application config, if it was changed.
For web applications, the user usually needs at least SELECT, INSERT, UPDATE, DELETE, and sometimes CREATE, ALTER, INDEX, or EXECUTE, depending on the application. If the app uses migrations or automatic schema updates, missing privileges can cause startup failures or runtime errors.
Verify database privileges after migration
Even when the login is correct, the application may still fail if the account does not have enough permissions. This is especially important after moving a JSP app into a new hosting account or restoring it from backup.
Typical permission problems
- The app can connect, but cannot read data.
- The app can read data, but cannot save new records.
- The app connects during startup, but fails on schema initialization.
- Stored procedures or prepared statements fail because specific privileges are missing.
If you use Plesk, review the database user assignment and ensure the credentials in the application match the account that has access to the schema. In a managed hosting setup, privilege changes made in the control panel should be reflected in the app configuration immediately, but cached config files or old deployment packages may still contain outdated values.
Check whether the database password changed
During a migration, passwords are sometimes reset, regenerated, or copied incorrectly. A single wrong character is enough to break the connection.
Review these common password-related issues:
- The password was changed in the control panel, but not in the JSP properties file.
- The password contains special characters that were not escaped correctly in XML or properties syntax.
- The application is still using an old password from a deployed WAR file.
- The deploy process copied a local development password instead of the production value.
If the password includes symbols such as &, <, >, ", or ', check how the value is stored. In XML-based configuration, special characters often need escaping. In Java properties files, the formatting may also affect how the value is read.
Review host name, localhost, and network access
For hosted JSP applications, database access often depends on whether MySQL is local to the same hosting account or accessed remotely. After migration, the app may still try to connect to an old host name, or the host value may need to be adjusted for the new environment.
Questions to ask
- Should the app connect to localhost?
- Should it use 127.0.0.1 instead of localhost?
- Is a specific internal database hostname required?
- Has remote database access been enabled if the database is not local?
In some hosting setups, localhost and 127.0.0.1 behave differently depending on socket and TCP usage. If your JSP app works in one environment but not another, test both values only if this matches the hosting documentation. Do not change host values blindly, because a working app may fail if the JDBC driver expects a specific transport method.
Check the MySQL port and server version compatibility
After migration, it is worth confirming the MySQL port and version compatibility. The application may compile and deploy correctly in Tomcat but still fail when the JDBC driver talks to a different MySQL version or port.
- Confirm the port number in the JDBC string.
- Make sure the JDBC driver version is compatible with the MySQL server version.
- Check whether the app uses legacy driver classes that should be updated.
- Review any warnings related to authentication plugin support.
Older JSP applications sometimes use outdated MySQL Connector/J versions. After migration, a newer MySQL server may reject older connection methods or require a different JDBC driver class. If the application worked before but fails after deployment, review the driver first before making changes in the Tomcat service.
Confirm the database name and schema mapping
During a migration, database names can change slightly, especially if a backup was restored into a different hosting account. The schema might have a prefix, a renamed identifier, or a different case than before.
Check that:
- The JDBC URL points to the correct schema name.
- The application does not use an old development database.
- No extra spaces were introduced when copying the name.
- The schema exists in the current hosting account.
This is particularly important when multiple environments are involved, such as development, staging, and live hosting. A JSP app may deploy successfully in My App Server, but still read from the wrong database if the config file was copied from another environment.
Review configuration files used by the JSP application
After migration, database credentials may be stored in different places depending on how the application was built. Common locations include Java properties files, XML configuration, servlet context parameters, and framework-specific files.
Common files and locations to inspect
- application.properties or similar property files
- web.xml context parameters
- Spring configuration files
- JNDI resource definitions
- Deployment descriptors inside the WAR package
- External config files stored outside the web root
In a hosting platform with Tomcat managed through Plesk, applications may be deployed from a WAR file and read configuration at startup. If the WAR was rebuilt before migration, double-check that the build process did not hardcode the old credentials into the package.
Check Tomcat and My App Server settings
When a JSP application runs on a private JVM in My App Server, database problems are sometimes caused by environment-level settings rather than the credentials themselves. After migration, ensure that the application service is using the expected runtime configuration.
- Confirm that the correct Java version is selected for the app.
- Check that the Tomcat instance was restarted after configuration changes.
- Review environment variables used by the application.
- Make sure the deployed WAR file matches the current database settings.
- Verify whether a JNDI resource needs to be updated in the control panel.
If your app uses a datasource configured in Tomcat, the JDBC credentials may be stored in the server resource definition rather than in the application code. In that case, updating only the JSP properties file will not fix the issue. The datasource definition and the application reference must point to the same values.
Look for common migration errors in the logs
Logs are one of the most useful places to verify database credential problems after migration. A failed login, wrong schema, or invalid JDBC URL usually leaves a clear message in the Tomcat or application log.
Useful error patterns
- Access denied for user - usually points to a wrong username, password, or host.
- Unknown database - the schema name is incorrect or missing.
- Communications link failure - host, port, firewall, or network access issue.
- Cannot create PoolableConnectionFactory - often a datasource or credential problem.
- Public Key Retrieval is not allowed - JDBC driver and MySQL authentication mismatch.
If the application is managed through Plesk, review both the application logs and the Tomcat service logs. This can help you decide whether the issue is in the database credentials, the app configuration, or the runtime environment.
What to check in the control panel
In a hosting control panel, the database details may be visible in multiple places. After a JSP migration, compare the control panel values with the ones stored in the application.
- Database name and user created in Plesk.
- Assigned privileges for the database user.
- Any password reset performed during migration.
- Service status for the Tomcat or Java app server instance.
- Application-level settings that point to the datasource or JDBC connection.
If your hosting platform uses a service control feature for My App Server, restart the service after updating credentials. Some JSP applications only read datasource values at startup, so a restart is necessary before testing the new connection.
Step-by-step checklist after a JSP migration
Use this checklist to verify database credentials in a practical order:
- Open the JSP application configuration and locate the database settings.
- Check the JDBC URL for host, port, database name, and extra parameters.
- Confirm the MySQL username and password in the hosting control panel.
- Verify that the user is assigned to the correct database.
- Review user privileges and ensure they match application needs.
- Check whether the app uses a JNDI datasource instead of hardcoded credentials.
- Inspect logs for access denied, unknown database, or connection errors.
- Confirm the JDBC driver is compatible with the current MySQL server version.
- Restart Tomcat or the My App Server service after any update.
- Test the application again using the live endpoint.
Examples of problems and likely fixes
Example 1: The app connects locally but fails after migration
Likely cause: the database host or schema name in the JDBC URL is still pointing to the old environment.
Fix: update the JDBC string and confirm the user has access to the current database.
Example 2: The app shows access denied errors
Likely cause: wrong password, wrong user, or missing host permission.
Fix: compare the stored password with the control panel value and verify the user assignment.
Example 3: The app starts, but forms cannot save data
Likely cause: insufficient database privileges.
Fix: grant the required write permissions and restart the application service if needed.
Example 4: The connection fails only after rebuilding the WAR
Likely cause: the build packaged outdated credentials into the deployment file.
Fix: move credentials to an external config file or update the build configuration.
Best practices for JSP database credentials during migration
To reduce problems when moving a JSP application between hosting environments, follow a few simple practices:
- Keep database credentials outside the code when possible.
- Use environment-specific config files for live, staging, and testing deployments.
- Document the database user, schema, host, and port used by each application.
- Rotate passwords carefully and update both the control panel and application config.
- Test the connection after every migration step, not only at the end.
- Review Tomcat or My App Server logs immediately after deployment.
For small and medium Java applications hosted in a managed environment, this approach is usually enough to keep JSP, servlet, and WAR deployments stable without needing a complex enterprise Java setup.
FAQ
Should a JSP app use localhost for MySQL after migration?
Only if the hosting environment documents localhost as the correct database host. In some setups, 127.0.0.1 or another internal host value may be required.
Why does the app deploy successfully but still fail to connect to the database?
Deployment and database access are separate. Tomcat can start the app even when the JDBC credentials, schema name, or privileges are wrong.
What is the most common database problem after a JSP migration?
The most common issues are an incorrect password, outdated JDBC URL, wrong schema name, or missing privileges for the database user.
Do I need to restart Tomcat after changing database credentials?
Yes, in many cases. Restarting the Tomcat or My App Server service ensures that updated datasource settings and configuration values are loaded.
Can a WAR file contain old database credentials?
Yes. If credentials were hardcoded or bundled during build time, the WAR may still use old values after migration.
What log message usually means the username or password is wrong?
The message often includes Access denied for user. It can also indicate a host restriction or an incorrect schema reference depending on the full error text.
Conclusion
After a JSP migration, the most important database checks are the JDBC URL, database name, username, password, and privileges. In a hosting environment with Plesk and My App Server, the app may continue to deploy normally while failing only when it reaches MySQL, so it is important to verify both the control panel settings and the application configuration. If you review the credentials, confirm the datasource setup, check the logs, and restart the service after changes, you can usually resolve migration-related database issues quickly and get the JSP application working again.