intercepting/manipulating server.properties settings

[agould]

version: Smartgwtee 2.4 (trial)

I have a requirement to obfuscate DB passwords stored server.properties. Unfortunately, I do not currently have the option of using JNDI to remove the need to store passwords in the file. Is there a way to intercept the loading of this information, or provide some other mechanism to provide the connection information to the Connector? Ideally, I'd love to inject my Spring DataSource bean into it.

Your help/advise is much appreciated.

[Isomorphic]

We basically look for server.properties on the classpath. So an alternative to JNDI would be to dynamically generate a server.properties file on the classpath before the Init servlet runs.

[agould]

Thanks for the response.

The problem with writing the server.properties out is that it's then easily viewable on the file system. Could I instead extend the Init servlet and tweak the properties after the global config is loaded? Something like this:


@SuppressWarnings("serial")
public class Init extends com.isomorphic.base.Init {

@Override
public void init(ServletConfig servletConfig) throws ServletException {

super.init(servletConfig);

Config config = Config.getGlobal();

config.put("sql.SQLServer.driver.password", "password");
}
}

[Isomorphic]

Interesting - we know of no reason why that wouldn't work and in fact the Admin Console does something similar to test out DB configs on the fly. If it's working for you, it would be great if you posted confirmation.

[agould]

It appears to work well. My only concern is the lifecycle of the underlying DB connection pool creation. Is the connection pool created upon the first request for a SmartGWT datasource ?

[Isomorphic]

Only when specifically the first SQLDataSource handles a request. Then connections are created as needed.

[will-gilbert]

This technique works very well!

We have a requirement where a new WAR is posted in our repository with it's MD5 digest by the development team. Our various environments, localhost, DEV, QA, UAT, PROD each contains an external properties file for database configuration and other application configuration. The properties file in PROD is maintained securely by a select group in our IT department. Developers have no access the contents of this file.

New servers can be built out by customizing a properties file and using the same WAR installed from the repository.

By extending the code sample listed above we are able to deploy SmartGWT Power based WARs on many environments without changing the WAR or modifying the classpath contents after deployment.

Would be interesting to have the API to 'com.isomorphic.collections.DataTypeMap' but can pretty much guess that is implements the java collections 'Map' interface.