Data Replication 2
Results 1 to 3 of 3

Thread: Troubleshooting OC4J with the attunityResourceAdapter (JCA)

  1. #1
    Adeeb Mass'ad is offline Support Manager
    Join Date
    Aug 2006
    Jaffa of Nazareth
    Rep Power

    Troubleshooting OC4J with the attunityResourceAdapter (JCA)


    The attunityResourceAdaper uses the log4j package for debugging information. The package should be installed with the Attunity JAR files (see article).

    By default log4j uses the to determine it's logging level and properties. It will automatically try to load this file depending on your CLASSPATH and environment settings.

    Attunity log4j

    Here are the Attunity related log4j properties which can be set in your properties file:
    Attached sample which sets both logging categories to DEBUG level.

    Deploying the

    There are several options to deploying the log4j properties file:
    1. Global Application Level, j2ee/home/applib directory:
    Supported on newer versions of the Oracle Containers for J2EE (OC4J), which means the properties file will be shared among all applications deployed on the Oracle Application Server.
    2. OC4J System Libraries
    For older versions of the OC4J this was used as the shared library, however, in the newer versions it's the where system libraries of the OC4J resides.

    3. Web application level, /WEB-INF/classes

    The log4j should be placed in the /WEB-INF/lib which means it will get initialized for each web application.
    By default the log4j log file will be created at the /j2ee/home sub-directory, unless specified otherwise in the properties file.
    To Find Out more About Attunity Technology:
    Contact Us

  2. #2
    sjcurt01 is offline Junior Member
    Join Date
    Sep 2009
    Rep Power

    Log4j configuration problem

    I've run into a problem using the jca-legacy-adapter connector along with a project that also utilizes log4j. If I include the log4j library in my project and run, log4j will exit with the following exception:

    oracle.classloader.util.AnnotatedLinkageError: duplicate class definition: org/apache/log4j/Logger

    Invalid class: org.apache.log4j.Logger
    Loader: current-workspace-app.web.Application1-Project2-webapp:0.0.0
    Code-Source: /C:/Data/maven/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
    Configuration: <classpath> in C:\Program Files\jdevj2eebase10134\jdev\mywork\Application1\P roject2\public_html

    Dependent class: _index
    Loader: current-workspace-app.web.Application1-Project2-webapp.jsp5138683:0.0.0
    Code-Source: /C:/Program Files/jdevj2eebase10134/jdev/mywork/Application1/Project2/classes/.jsps/
    Configuration: *.jsp in C:\Program Files\jdevj2eebase10134\jdev\mywork\Application1\P roject2\classes\.jsps

    The original class instance was defined in the shared-library jca-legacy-adapter:0.0.0, and current-workspace-app.web.Application1-Project2-webapp.jsp5138683:0.0.0 does import that loader. This may be a search-order problem.

    If I don't include the log4j library in my project, the project will run fine using the log4j classes from the library packaged with the jca-legacy-adapter, but will not compile because log4j is not included in the project. Is there a way to include log4j at compile time but to exclude it at runtime in the JDeveloper project configuration?

  3. #3
    sjcurt01 is offline Junior Member
    Join Date
    Sep 2009
    Rep Power

    Found alternative solution

    To date I have not found a way to specify different classpaths for build vs run time, but with help from a colleague, a solution to my specific situation was stumbled upon. Even though the connector is not a JDev project, the dependent project can reference the log4j jar file that is packaged and loaded with it. That effectively mimics the behavior at runtime, for both standalone as well as embedded oc4j container deployment, in which the web application and associated application code link to the log4j instance loaded by the 3rd party JCA connector's classloader. I did not think this would work assuming that a log4j library loaded by two different classloaders would still appear to be two distinct instances of the library with respect to log4j's static initializers. (That is what I am presuming motivates log4j to throw an exception if it finds another instance of itself in the classloader hierarchy.) Apparently this is not the case, at least for the embedded scenario. I do not have to test this for the standalone container since the Maven build knows not to include a copy of the log4j library jar in the application EAR file via the "provided" scope specification in the build file. The embedded OC4J container now loads the JCA connector, the associated log4 library instance, deploys the application, and allows both to use the log4j classes from the same log4j library file. Not entirely sure of how the connector and web applications classloaders interact, but it works now.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts