Conflict between DFC framework and slf4j

waynewcs
waynewcs
edited November 13, 2014 in Documentum #1

I'm trying to integrate an existing Spring-based application with the DFC framework, which is calling out to a Documentum 6.7 server.  Our application uses slf4j for logging and therefore has slf4j.jar and log4j-over-slf4j.jar in its classpath.  Unfortunately, the logging classes these jars expose conflict with what DFC expects in terms of log4j functionality.  Here is the exception we get on start up:

java.lang.NoSuchMethodError: org.apache.log4j.Logger.setResourceBundle(Ljava/util/ResourceBundle;)V

at com.documentum.fc.common.DfLogger.<clinit>(DfLogger.java:604)

at com.documentum.fc.common.impl.logging.LoggingConfigurator.onPreferencesInitialized(LoggingConfigurator.java:178)

at com.documentum.fc.common.DfPreferences.initialize(DfPreferences.java:71)

at com.documentum.fc.common.DfPreferences.getInstance(DfPreferences.java:43)

at com.documentum.fc.client.DfSimpleDbor.getDefaultDbor(DfSimpleDbor.java:78)

at com.documentum.fc.client.DfSimpleDbor.<init>(DfSimpleDbor.java:66)

at com.documentum.fc.client.DfClient$ClientImpl.<init>(DfClient.java:334)

at com.documentum.fc.client.DfClient.<clinit>(DfClient.java:728)

at com.documentum.com.DfClientX.getLocalClient(DfClientX.java:43

Is there a way that we can get DFC to not rely on its own specific version of log4j and simply use slf4j instead?

Tagged:

Comments

  • vincentklock
    vincentklock
    edited November 13, 2014 #2

    I'm affraid not: Documentum customized log4j and, more than just preventing the change of logging framework, the way it has been done imposes the use of log4j 1.2.13 (not any other 1.2.X version, no, there is a static binding with 1.2.13).

    It is done that way at least until DFC 7.1, which I have checked before raising a change request to EMC support on this topic. Unfortunately I have no way to tell if it would be implemented one day or the other

    Now if you want to integrate with slf4j, you can use the log4j bridge but keep in mind that you will need log4j 1.2.13 in your classpath. The best way out to let you take the most out of your favorite recent logging framework is to implement the Documentum layer as a service (or use DFS instead), so that you isolate both parts of your application.

  • waynewcs
    waynewcs
    edited November 13, 2014 #3

    Thanks - I found a version of the bridge that seems to be compatible with log4j 1.2.13.  I guess the trick would be to configure Spring to use that rather than a different one via the gradle or maven build file.  Did you try that by any chance?  Would you know how to do it?

  • Francois Dauberlieu
    Francois Dauberlieu
    edited November 14, 2014 #4

    Well, if you have to modify your code to use DFS as suggested above, why don't you just modify it to use DfLogger nstead of your own logging mechanism?

    This way, whatever version of DFC you have on the machine, your logging will still works and you don;t have to reqwrite most of you DFC calls to use DFS, that would mnost likely shorten a lot the Dev and Testing processes...

    My 2 cents

  • Trejkaz
    Trejkaz
    #5

    Using DfLogger isn't an option for some. Maybe you're integrating Documentum support into a library which already has its own logging framework and which deliberately uses SLF4J so that client code can choose what logging to use for themselves.

    I'm aware of one solution where we edit DfLogger's class file to remove the lines which try to reconfigure log4j, but I'm wondering whether anyone has come up with a better solution than that. It would have been nice to do it at runtime with a custom classloader, but it turns out to be fairly hard to do that without also using a ton of slow reflection.

Categories