Content Management and Capture

Content Management and Capture

Come for answers. Stay for best practices. All we’re missing is you.

 View Only

  • 1.  JUL Logging for FileNet Custom Event Action Handler

    Posted Wed August 02, 2023 09:49 AM

    Hey Everyone

    I'm looking to connect with anyone who has successfully converted their custom event action code module to use the new JUL logging capability which replaced Log4j. During development, we're seeing some issues with formatting and multiple lock files per iteration of the event fired so could so with the some help from someone who has it working.

    Thanks in advance, Kenny



    ------------------------------
    Kenny Dick
    ------------------------------


  • 2.  RE: JUL Logging for FileNet Custom Event Action Handler

    Posted 2 days ago

    Kenny did you ever get a resolution to this?



    ------------------------------
    Matthew Clay
    ------------------------------

    Original Message


  • 3.  RE: JUL Logging for FileNet Custom Event Action Handler

    Posted 2 days ago

    Hi Matthew

    I didn't get any joy on this despite exhausting all avenues of support. We tried it but the behaviour was wild and caused issues like hanging the JVM so we scrapped it. Support couldn't help us find root cause. We ended up writing the logs to the WAS System Out and just use filtering to review log activity specific to our handlers. Not ideal but we decided we didn't really need things to be separate like with log4j.

    Regards, Kenny



    ------------------------------
    Kenny Dick
    ------------------------------

    Original Message


  • 4.  RE: JUL Logging for FileNet Custom Event Action Handler

    Posted 2 days ago

    Is the question here about doing your own independent logging to your own log file(s) from your handler or logging into the CPE's own logs?

    If the former, you can do that however you like using JUL or any other logging mechanism (subject to including the supporting jars into your code module if not automatically present) and that won't interfere with or be interfered by the CPE logging.

    If the latter then the correct and only supported way of doing it is using the log and trace methods in the com.filenet.api.engine.HandlerCallContext class (refer to the API documentation). You cannot write to the CPE logs by calling JUL methods directly.



    ------------------------------
    Mike
    ------------------------------

    Original Message


  • 5.  RE: JUL Logging for FileNet Custom Event Action Handler

    Posted 23 hours ago

    We have 9-10 code modules and we have the same problem, multiple lock files and some times the log entry appears in multiple logs as well with JUL logging method,, its not great way but not bad  to fish for right code module logs, but happy to know if there is a better way. we thought of using log4j but there are couple of challenges

    1. a common place where we can upload that log4j libraries so it is visible to all code modules(event handlers), otherwise the libraries have to be bundled with each code module jar
    2. yet have a separate log name generated for each code module and log the information in that file
    3. when these code modules are loaded how the CPE class loader is going to handle is as each code module will have its own same exact set of log4j classes bundled

    Thanks

    Kiran Aithagani



    ------------------------------
    Kiran Aithagani
    ------------------------------

    Original Message


  • 6.  RE: JUL Logging for FileNet Custom Event Action Handler

    Posted 22 hours ago

    There is a separate class loader for each code module, so under standard Java class loading rules that means classes loaded from one code module are isolated from classes loaded from another. Therefore if you place log4j (for example) in two code modules there won't be any "co-operation" between the log4j classes loaded from different code modules, because there is no shared state between them.

    The solutions to this are:

    • place all your handlers in one code module (along with the one copy of log4j).
    • put the commonly used classes (eg: log4j) in a shared library or on the classpath of the application server.
    • use libraries that are provided by the application server or Java runtime (eg: JUL).



    ------------------------------
    Mike
    ------------------------------

    Original Message


Related Content