After a JSP migration, database connectivity is one of the most common places where an application can still fail even when the web layer is deployed correctly. If your JSP pages load but data-driven features return errors, empty results, login failures, or long timeouts, the issue is often related to the database credentials, JDBC configuration, or the way the application reads its connection settings in the new hosting environment.
In a managed hosting setup with Plesk and a private Java runtime or Tomcat instance, it is important to verify not only the username and password, but also the database host, port, schema name, JDBC driver, and any application-specific connection pool settings. A migration can change file locations, environment values, service names, or database access rules, so credentials that worked before may no longer be valid in the new deployment.
What usually changes after a JSP migration
When a JSP application is moved to a new hosting account, new Tomcat instance, or another Java runtime, the database itself may remain the same, but the application may no longer reach it with the same settings. Common changes include:
- Different database host or internal hostname
- New database user name or password
- Updated JDBC URL format
- Different schema or database name
- Changed port number
- Missing JDBC driver in the new Tomcat or application classpath
- Connection limits or permission restrictions at the database level
- Environment variables not copied during deployment
For JSP hosting, these issues often appear after moving a WAR file, switching Java versions, or creating a new app server instance through a hosting control panel. The application may still start normally, but database requests fail at runtime.
Database credentials to check first
The first step is to confirm the exact database values used by the application. Do not rely on memory or old deployment notes. Check the configuration file currently deployed on the server and compare it with the database details in your control panel.
1. Database username
Verify that the JSP application is using the correct database user. In hosted environments, the database user is often created with a prefix tied to the hosting account. After migration, the application may still point to an old username that no longer exists or does not have access to the new database.
Check for:
- Typographical errors
- Old account prefixes
- Case-sensitive mismatches
- Hardcoded values in properties files, XML files, or Java code
2. Database password
Confirm that the password stored in the JSP application matches the current database password. If the password was changed during migration or reset in the control panel, the application must be updated as well.
Important points to review:
- Password updates in the hosting panel
- Encrypted or encoded values in configuration files
- Old secrets stored in build artifacts
- Deployment scripts that may overwrite the current password
3. Database host
The database host is a frequent source of problems after migration. Some applications use localhost, while others use a specific database host name or an internal service name provided by the hosting platform.
Check whether the application should connect through:
- localhost for local database access on the same account or server
- A remote hostname provided in the hosting control panel
- An internal private host name required by the platform
If the application was moved into a private Tomcat instance under My App Server, make sure the JDBC URL still matches the database access method supported in that environment.
4. Database name or schema
It is common for a JSP application to work against a database name that differs slightly after migration. For example, a copied database may have a new prefix, or the application may still point to the old schema name.
Check that the configured database name matches the actual database created in the hosting panel. If the application uses schema-qualified queries, verify the schema name separately.
5. Port number
Most MySQL installations use the default port, but do not assume this automatically after a migration. If your setup uses a custom MySQL port, check that it is reflected correctly in the JDBC connection string.
Typical issues include:
- Missing port in the JDBC URL
- Wrong custom port after service reconfiguration
- Firewall or access policy blocking the chosen port
Where to check the credentials in a JSP application
Database connection details can be stored in different places depending on how the application was built. After migration, review all likely locations instead of checking only one file.
Configuration files
Look for database values in common files such as:
web.xmlcontext.xmlapplication.propertiesdb.propertiesjdbc.properties- Spring or framework-specific configuration files
In many JSP applications, the credentials are not stored in the page files themselves, but in a separate properties file loaded at startup. If the migration changed the deployment path, the application may be reading an old or missing file.
Environment variables
Some applications use environment variables for database access instead of hardcoded values. In a hosting control panel or My App Server setup, make sure these variables are defined in the correct Java service or application context.
Check for variables such as:
- DB_HOST
- DB_NAME
- DB_USER
- DB_PASSWORD
- JDBC_URL
JNDI resources
If the JSP application uses a datasource configured in Tomcat, verify the JNDI resource name and its database settings. A migration can break the link between the application and the datasource if the resource definition was not copied into the new server configuration.
Review:
- Resource name used by the application
- Datasource username and password
- Connection URL
- Driver class name
Hardcoded values in Java classes
Older applications sometimes keep the database credentials inside Java classes. If this is the case, search the codebase for the old host name, user name, or password reference. After migration, a rebuilt WAR may still contain outdated values if the source was not updated before packaging.
JDBC URL checks after migration
The JDBC URL must match the actual database service and driver expectations. Even if the credentials are correct, a wrong URL can still produce authentication or connection errors.
Check the URL format
For MySQL, review whether the application uses a URL similar to the expected format for your environment. Make sure the URL includes the correct host, port, and database name.
Common mistakes include:
- Missing database name at the end of the URL
- Using an IP address when a hostname is required
- Using a hostname that no longer resolves in the new account
- Wrong protocol prefix or unsupported parameters
Check SSL and connection parameters
Some applications include connection flags for SSL, timezone handling, Unicode, or legacy authentication. After migration, these parameters may need to be reviewed, especially if the new database server enforces different defaults.
Useful parameters to inspect include:
- SSL-related options
- Server timezone settings
- Unicode or character set settings
- Legacy authentication flags, if used by older apps
Permissions and access rights
Correct credentials are not enough if the database user does not have the required privileges. After a JSP migration, make sure the user can access the correct database and perform the operations the application needs.
Minimum permissions to verify
For a typical JSP application, the database user usually needs:
- SELECT
- INSERT
- UPDATE
- DELETE
- CREATE or ALTER, if the application manages its own schema changes
If the application uses a migration tool or runs initialization scripts on startup, it may also need permissions for stored procedures, indexes, or table creation.
Host-based access restrictions
Some MySQL accounts are restricted by source host. If the application moved from one environment to another, the database user may still be allowed only from an old host name or IP range. In that case the login may fail even though the username and password are correct.
Check whether the MySQL user is permitted to connect from:
- localhost
- The current hosting account
- The application server host name
- A specific remote address, if applicable
Tomcat and My App Server points to review
If your JSP app runs in a private Tomcat instance managed through My App Server, the migration should include a review of the Java service configuration. The application may start, but its database connection may fail because the service was recreated or the datasource settings were not copied.
Application server restart after changes
After updating credentials or JDBC settings, restart the Java service so the new values are loaded. In many hosted Tomcat setups, changes to configuration files do not take effect until the service is restarted.
Check the deployed WAR and external config
Confirm whether your application reads the database settings from inside the WAR or from an external file. If configuration is external, make sure the file still exists in the correct location after deployment.
Java version and driver compatibility
If the migration included a different Java version, verify that the JDBC driver is still compatible. A driver mismatch may appear as a connection failure, even though the root cause is not the credentials themselves.
Review the following:
- Supported Java version for the app
- MySQL JDBC driver version
- Any deprecated connection options used by the application
Typical error messages and what they mean
Reading the exact error message can help you narrow down whether the issue is a bad credential, a permissions problem, or a connection problem.
Access denied for user
This usually means the username or password is wrong, or the user is not allowed to connect from the current host.
Unknown database
This usually means the database name or schema is incorrect, or the target database was not migrated or created properly.
Communications link failure
This often points to host, port, network, or service availability issues rather than a bad password.
No suitable driver
This means the JDBC driver is missing, outdated, or not loaded in the current Tomcat or Java setup.
Connection refused or timeout
This usually indicates the application cannot reach the database host or port, or the service is not accepting connections.
Step-by-step checklist after a JSP migration
Use this checklist to verify the database connection in order.
- Confirm the current database name in the hosting control panel.
- Confirm the current database user name and password.
- Check the database host and port used by the application.
- Review the JDBC URL for formatting errors.
- Verify the username has access to the target database.
- Confirm the application can read the correct configuration file.
- Check whether the app uses JNDI, environment variables, or hardcoded settings.
- Make sure the MySQL JDBC driver is installed and compatible.
- Restart Tomcat or the private Java service after changes.
- Test the connection with a simple query or health check page.
Practical example of what to compare
If a JSP application worked before migration and now fails, compare the old and new values side by side. A small difference is often enough to break the connection.
- Old user: appuser
- New user: accountprefix_appuser
- Old host: localhost
- New host: mysql-host.example.internal
- Old database: webshop
- New database: accountprefix_webshop
Even if the application code is unchanged, any one of these values can cause login or data access errors after migration.
How to test the connection safely
After updating the credentials, test the database connection before putting the application back into normal use. A basic connection test helps confirm that the issue is resolved without waiting for users to report errors.
You can test by:
- Loading a JSP page that performs a simple SELECT query
- Checking the application logs for datasource errors
- Using a small validation script or health-check endpoint
- Confirming the database session appears in the MySQL process list, if available
In a managed hosting environment, logs are often the fastest way to confirm whether the application is reading the correct credentials and reaching the expected database host.
Common mistakes to avoid
- Updating the password in the control panel but not in the application config
- Leaving an old JDBC URL in a deployed WAR
- Forgetting to copy an external properties file during migration
- Using the wrong database prefix after account migration
- Assuming localhost is still correct in the new setup
- Not restarting Tomcat after changing datasource settings
- Ignoring JDBC driver compatibility after a Java version change
FAQ
Why does my JSP app start but still cannot read data from MySQL?
This usually means the web application is deployed correctly, but the database connection settings are wrong. Check the username, password, host, database name, port, and driver configuration.
Do I need to change credentials if only the Tomcat instance was moved?
Not always, but you should still verify them. A new Tomcat or private Java service may read different config files, use different environment variables, or require a different database host.
What is the most common issue after a JSP migration?
The most common issue is a mismatch between the stored database credentials and the actual database account in the hosting panel. The second most common issue is an outdated JDBC URL.
Should I store database credentials inside the JSP files?
No. It is better to keep them in a dedicated configuration file, environment variable, or datasource definition. That makes migrations and updates easier and reduces the risk of exposing sensitive data.
Can a wrong Java version affect database login?
Yes. A Java version change can affect driver loading or compatibility with the MySQL connector, which may look like a database login problem even when the credentials are correct.
What should I check in Plesk first?
Start with the database user, password, database name, host, and any Java service or Tomcat configuration that stores the JDBC details. Then restart the service and review the logs.
Conclusion
After a JSP migration, database credentials should be checked in a structured way: username, password, host, port, database name, JDBC URL, permissions, and the way the application loads those values. In a hosting environment with Plesk and a managed Java service such as My App Server, the problem is often not the database itself but the configuration copied into Tomcat or the application package.
If you verify the connection details carefully, confirm the datasource configuration, and restart the Java service after changes, most post-migration database issues can be resolved quickly. For JSP hosting, this approach is usually the fastest way to restore login forms, dynamic pages, and database-driven functionality.