Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Usage of project.properties file on startup?

    Hi Isomorphic,

    I noticed the reference to a file project.properties during startup:
    Code:
    === 2014-08-27 14:07:17,097 [c-11] INFO  ISCInit - Isomorphic SmartClient/SmartGWT Framework - Initializing
    === 2014-08-27 14:07:17,107 [c-11] INFO  ConfigLoader - Attempting to load framework.properties from CLASSPATH
    === 2014-08-27 14:07:17,362 [c-11] INFO  ConfigLoader - Successfully loaded framework.properties from CLASSPATH at location: jar:file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%207.0/webapps/myapp/WEB-INF/lib/isomorphic_core_rpc.jar!/framework.properties
    [B]=== 2014-08-27 14:07:17,362 [c-11] INFO  ConfigLoader - Attempting to load project.properties from CLASSPATH
    === 2014-08-27 14:07:17,363 [c-11] INFO  ConfigLoader - Unable to locate project.properties in CLASSPATH
    [/B]=== 2014-08-27 14:07:17,372 [c-11] INFO  ConfigLoader - Successfully loaded isc_interfaces.properties from CLASSPATH at location: jar:file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%207.0/webapps/myapp/WEB-INF/lib/isomorphic_core_rpc.jar!/isc_interfaces.properties
    === 2014-08-27 14:07:17,372 [c-11] INFO  ConfigLoader - Attempting to load server.properties from CLASSPATH
    === 2014-08-27 14:07:17,379 [c-11] INFO  ConfigLoader - Successfully loaded server.properties from CLASSPATH at location: file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%207.0/webapps/myapp/WEB-INF/classes/server.properties
    === 2014-08-27 14:07:17,394 [c-11] INFO  Logger - Logging system started.
    === 2014-08-27 14:07:17,399 [c-11] INFO  ISCInit - Auto-detected webRoot - using: C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\myapp
    === 2014-08-27 14:07:17,402 [c-11] INFO  ISCInit - Isomorphic SmartClient/SmartGWT Framework (v9.1p_2014-08-22/EVAL Deployment 2014-08-22) - Initialization Complete
    For what could this file be used?
    Currently, I have a CustomerSettings.java like this:
    Code:
    public class CustomerSettings {
    	public final static long customerTenantId = 0;
    	public final static String customerName = "...";
    	public final static String customerUrl = "...";
    	public final static String customerImage = "...";
    	...
    	...
    	...getters for these...
    The file is used clientside and serverside and modified by many <replaceregexp>-tags inside my ANT-script prior to compilation.
    This works for me, but as I saw the log message I thought if it would be possible to have the same war-file/complied app for all tenants (only different server.properties and project.properties).

    Could you explain what this file is for? Perhaps it can replace my CustomerSettings.java - at least for the serverside.

    Best regards,
    Blama

    #2
    "project.properties" is part of our config hierarchy. We load config from a hierarchy of properties files, with settings in the later files overriding the same settings in the earlier files. The order is: "framework.properties", then "project.properties", then "server.properties". The idea is that "framework.properties" contains factory settings (which is why we hide it in a JAR file); "project.properties" contains overrides and extra settings for a specific project; and "server.properties" contains overrides and extra settings for a specific running instance of a given project.

    In reality, "project.properties" doesn't really give you much of a benefit, unless you really do have multiple instances of a project that each requires its own discrete settings. It's also not really documented, so you would be better using "server.properties", which is documented and is explicitly intended for customer changes and additions. Or just put your own settings into your own .properties file(s), of course

    Both these files, however, are server-side only. The advantage of doing things the way you currently have, with settings as static final properties of an actual Java class, is that the GWT compiler can make them available client-side as well as server-side. So if you can live with the disadvantages of config hard-coded into Java classes, that's not a bad way to do it. This does prevent you, however, from drawing a distinction between config that is appropriate for a client and config that must only be visible to the server (passwords, etc)

    If you need something more dynamic - for example, the ability to add a tenant customer without having to create a special build just for them - you need some way to get the server-side config into the client. A clean SmartClient/SmartGWT way to do this would be to create a PropertiesDataSource that reads information from the global Config instance and returns it as the data of a normal DSResponse (bearing in mind, as mentioned above, that some config absolutely should not be sent to a client). Or, you could use a more general AJAX trick and create a special servlet like our DataSourceLoader.
    Last edited by Isomorphic; 28 Aug 2014, 02:01.

    Comment


      #3
      Hi Isomorphic,

      thank you for the explanation. As I'm not needing a multi-server configuration, I'll stick to the suggested approach (a single server.properties) for startup.

      Regarding the rest I'll look into your suggestions, especially PropertiesDataSource. You are right, I can live with the way it currently is (no sensitive information is copied into the gwtc'd file. My <replaceregexp> targets that file as well as server.properties for some sensitive data), but it would be nice to have just one war + some static files replaced.
      As I already have a servlet that gets me some Database data on application open in browser, I'll look into extending this with file content. My current per-tenant-configuration file is a java-properties file, so this should be easily possible.

      Thanks you & Best regards,
      Blama

      Comment

      Working...
      X