Being without dfc.properties

If you ever tried to implement some kind of integration between j2ee application and Documentum, you probably know that putting DFC libraries into j2ee environment is always a pain in ass because DFC follows neither best practices nor common sense:

To resolve second problem I invented following class:

/**
 * @author Andrey B. Panfilov <andrew@panfilov.tel>
 */
public class DfcPropertiesLoader {

    private final Map<String, Object> _properties;

    public DfcPropertiesLoader(Map<String, Object> properties) {
        _properties = properties;
    }

    public final void load() {
        Properties filtered = getKnownProperties(_properties);
        if (filtered == null || filtered.isEmpty()) {
            return;
        }
        DfPreferences.getInstance().loadProperties(filtered, false);
    }

    private Properties getKnownProperties(Map<String, Object> properties) {
        Properties filtered = new Properties();
        for (Field field : DfPreferences.class.getDeclaredFields()) {
            Preference preference = field.getAnnotation(Preference.class);
            if (preference == null) {
                continue;
            }
            String preferenceName;
            try {
                preferenceName = toString(field.get(null));
            } catch (IllegalAccessException e) {
                continue;
            }
            if (!properties.containsKey(preferenceName)) {
                continue;
            }
            Object value = properties.get(preferenceName);
            if (value == null) {
                continue;
            }
            if (preference.repeating()) {
                filtered.put(preferenceName, toArray(value));
            } else {
                if (value instanceof List || value.getClass().isArray()) {
                    continue;
                }
                filtered.put(preferenceName, toString(value));
            }
        }
        return filtered;
    }

    private String[] toArray(Object object) {
        if (object instanceof List) {
            List list = (List) object;
            String[] result = new String[list.size()];
            for (int i = 0, n = result.length; i < n; i++) {
                result[i] = toString(list.get(i));
            }
            return result;
        }
        if (!object.getClass().isArray()) {
            return new String[] {toString(object) };
        }
        String[] result = new String[Array.getLength(object)];
        for (int i = 0, n = result.length; i < n; i++) {
            result[i] = toString(Array.get(object, i));
        }
        return result;
    }

    private String toString(Object object) {
        if (object instanceof String) {
            return (String) object;
        }
        return object.toString();
    }

}

which allows to build DFC preferences from any context without using dfc.properties file, for example, below is a configuration for Spring:

<bean id="dfcPropertiesLoader" class="DfcPropertiesLoader" init-method="load">
    <constructor-arg name="properties">
        <map>
            <entry key="dfc.docbroker.host" value="docu70dev02"/>
            <entry key="dfc.docbroker.port" value="1489"/>
            <entry key="dfc.bof.registry.repository" value="ssc_dev"/>
            <entry key="dfc.bof.registry.username" value="dm_bof_registry"/>
            <entry key="dfc.bof.registry.password" value="dm_bof_registry"/>
        </map>
    </constructor-arg>
</bean>

7 thoughts on “Being without dfc.properties

  1. Really cool way of doing this. Will try that in my next project… This probably solves the problem that we have to deliver dfc.properties on each server instance and are not able to package it into the application.

    Thanks,
    Jens

    Like

  2. DFC has always been garbage code. It was made as a Java wrapper for the existing iAPI and you can see traces of it when you decompile it. Case in point: IdfCollection… it’s a remnant of the api era where you needed to iterate through the results on the command line so the results were stored on the server instead of the client. Somehow DFC never found the need of changing this over the years and we still see developers leaving collections open throughout their applications. When they decided to rewrite the dmcl api in Java, I thought they would fix some of these archaic things but unfortunately they did not.

    Like

  3. Pingback: Classloader leak because of DFC | Documentum in a (nuts)HELL
  4. Pingback: Q & A. VIII. | Documentum in a (nuts)HELL
  5. Hi, how to set dynamic values like dfc.data.dir? The value cannot be set via external property because DFC tells me “4545 [main] WARN com.documentum.fc.common.DfPreferences – [DFC_PREFERENCE_NOT_DYNAMIC] Persistent change for preference “dfc.data.dir” will not take effect until the next restart

    Any idea how to fix that?
    Thanks
    Jens

    Like

  6. Pingback: Being without dfc.properties. Part II | Documentum in a (nuts)HELL
  7. Pingback: Why you should stay clear of REST | Pro Documentum

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s