Use log4j2 in webmethods

Hi Waldes, So what did you exactly do to solve the issue? I am also facing the same issue of log file not getting generated. I did read all the comments in this thread but, still the issue doesn’t seem to get resolved for me. Please help! Thanks!

Please note that I used the same files mentioned by you - simplified version. As per my knowledge log file should be generated in the /default directory as you did not mention about any file path in the esb.log4j2.xml file. Please feel free to correct me wherever my understanding is wrong. Thanks in advance!

Hi Senthil,

I tried the options in this thread. but seeing some unexpected results on my side (IS v10.7.0.0).
The log4j log file is getting created as per config but only 1 entry related to MWS is getting logged upon IS restart.
All custom entries are still going to the wrapper.log
Attaching the config and log files (wrapper.conf is untouched, I included log4j path in custom_wrapper.conf as suggested in this thread).
Thank you in adavnce
custom_wrapper.conf (2.1 KB)
log4j2.xml (920 Bytes)
rolling-file.log (97 Bytes)
wrapper.conf (10.2 KB)
wrapper.log (818.7 KB)

Hi,

Just to update, the option with custom_wrapper.conf didn’t work out for me even with SPM and machine restart.
With the use of package class loader, it’s working for me.
package class loader

Is this topic still open? I had a similar challenge for WxConfig and was able to solve it without changes to Tanuki Wrapper. Anybody interested?

1 Like

Christoph, though this is marked as a solved topic, it’ll be valuable if you can compile the resolution for others to have an alternate solution.

KM

2 Likes

Hi Chris, I am interested in the solution found by you, albeit, it got resolved for me by some other method but still would be happy to know any potential alternatives. :slight_smile:

1 Like

I have created a demo package and put it on GitHub. Please check out GitHub - SoftwareAG/webmethods-integrationserver-log4jdemo: Demo for custom logging with Log4J v2 in Integration Server (incl. v10.5+) for details.

1 Like

Christoph, Have you tried with the latest 2.14 jars for log4j2? The Git page does not mention the version of jog4j2 jars used. There seems to be a change in Log4J2 implementation where the logger has to be instantiated using LogManager class rather than LogContext. From what I am seeing there seems to be an internal SAG log4j2 config that is overriding the custom log4j2 properties resulting in the log entries being written to platform.log.

As one of the posters mentioned above it seems using package class loader might have resolved the issue.

The package simply uses the Log4j v2 that comes with IS. It was developed on IS 10.5 works nicely there.

As to the other points you mentioned, I am not sure what you are aiming for. Is there a problem or are those general observations?

Thanks.

Just wanted clarity on what version of log4j2 jars you have used. If these are the ones that came with the SAG install then it will work but when using the ones(2.14) from Apache it still does not work. An observation.

Can you describe what you did and what does not work as expected? I did a quick test with 2.14.1 from the Apache site and it works for me.

BTW: The version used by my IS 10.5 installation is 2.13.1, so not “miles apart” from the latest official release.

Thanks!

Hi Chris,
did you make update in the custom_wrapper.conf? If so could you please attache the same?

No changes were done to custom_wrapper.conf

Hi Senthil,
Please clarify on this. If we are adding new log4j config entry in custom_wrapper.conf. do we need to move the existing predefined entry in wrapper.conf also to custom_wrapper.conf. because I use 10.5 and it has a default entry in wrapper.conf and when I add a new config file entry in custom_wrapper.conf. it’s not getting loaded. I have verified in wrapper.log
wrapper.conf:
wrapper.java.additional.4=-Dlog4j.configurationFile=“/webMethods/webmethods600/profiles/IS_default/configuration/logging/log4j2.properties”
wrapper.java.additional.4.stripquotes=TRUE
custom_wrapper.conf:
wrapper.java.additional.204=-Dlog4j.configuration=“/webMethods/webmethods600/appProperties/Log4j2Demo.xml”
wrapper.java.additional.204.stripquotes=TRUE

I could not see even the log4j2.properties getting loaded in wrapper.log

Thanks in Advance!
Vignesh

Hi Senthil,

Can you please share your initialization service which loads your config file.

Hi Waldes,

Can you please share what was causing the issue. What was the java dependency you are referring here.

Hi,

If I remember right it was the recommendation to remove all custom log4j2.jars from the code as the IS already contains one in its common libs.

When there are multiple (maybe different) versions of a particular jar in the classpath, you might encounter class loading issues.

Regards,
Holger

2 Likes

Hi,

I wanted to share something we found while trying to follow the various instructions in this topic. Everything worked well under 10.5, but on 10.7, the logging would work on our external gateway registration servers, but not on the internal servers. On the internal servers, when starting Integration Server, logging to our own file, and to sag-osgi.log and platform.log would suddenly stop halfway through the boot sequence, and from then on, everything would only go to the wrapper.log file. Even ehcache.log would not write anything.

Last few entries in sag-osgi.log:

2021-12-03 16:01:17,311 INFO  [com.w.p.PortalException                                     ] - No registered exception delegate
2021-12-03 16:01:17,330 INFO  [tas.TaskCompletionHandlerIS                                 ] - Using system/lwq/dbhome directory for completion queue storage
2021-12-03 16:01:17,352 INFO  [tas.TaskCompletionHandlerIS                                 ] - Initialized TaskCompletion Queue

Last entry in ehcache.log:

03.12.21 16:01:08.487 [INFO] | My webMethods Server 10.7.0.0001-0063

After opening a ticket with Software AG, here is what we were told:

I have analyzed the information that you provided.

I found that the main difference between your IS v10.5 master, IS v10.7 proxy, and IS v10.7 master instances is that the effective value of the “log4j.configurationFile” System Property is different. For both the IS v10.5 master and IS v10.7 proxy instances (i.e. the “working” instances), the effective value of this property is pointing to the “log4j2.properties” file. However, with the IS v10.7 master instance (i.e. the “non-working” instance), the effective value of this property is "jar\:file\:/opt2/webmethods/IIS/common/lib/wm-caf-common.jar!/logging_config.xml"

I can see that this property is configured in the IS v10.7 master instance’s custom_wrapper.conf file with the following line:

===
wrapper.java.additional.204=-Dlog4j.configurationFile=“/opt2/webMethods/IIS/profiles/IS_IIS/configuration/logging/log4j2.properties,.tc.custom.log4j2.properties”
===

Unfortunately, this property is being overridden during initialization of the Central User Management utility. This is an intentional change that was made to the CipherUtil class used by MWS/Central User Management. That change happened between v10.5 and v10.7.

Software AG’s suggestion to write the custom code is difficult to do in version 2 of log4j logging facility. In version 1, you could point to your own configuration file using a call to DOMConfigurator.configure. However, in version 2, there is no public function performing this task. The Log4j2 documentation mentions a service, but warns that this is not a publicly exposed service, and that if you use it, your code could break with any updates to log4j2 library.

We also thought of using pub.flow.debugLog in package WmPublic, but that would have logged to the server.log file, which was not ideal.

What we decided to do, until we have a better solution, is to update the file logging_config.xml inside the JAR file /opt2/webMethods/IIS/common/lib/wm-caf-common.jar. We used unzip to extract all the files, made our change in logging_config.xml, and used zip -r to create an updated jar file. We kept a copy of the original jar, as reference, and overwrote the one in IIS/common/lib.

We then restarted Integration server. We now have our logging working, and at the same time, the usual logging in wrapper.log continues as it should so it will not affect Web Methods normal operation.

Until there is a better solution, this is what we will be using.

Maybe in a future version of Web Methods Integration Server and MWS, Software AG will make a change to make the use of log4j2 easier.

Original logging_config.xml file inside wm-caf-common.jar :

<Configuration status="WARN">
  <Appenders>
    <Console name="Console" target="SYSTEM_OUT">
      <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
    </Console>
  </Appenders>
  <Loggers>
    <Root level="info">
      <AppenderRef ref="Console"/>
    </Root>
  </Loggers>
</Configuration>

After our changes :

<Configuration status="WARN">
  <Appenders>
    <Console name="Console" target="SYSTEM_OUT">
      <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
    </Console>
    <!-- MyFile is for writing to file myfile.log with a log rotation of 1 day, gziping the file -->
    <RollingFile name="MyFile" fileName="mylogdir/myfile.log" filePattern="mylogdir/myfile.log.%d{yyyy-MM-dd}.gz">
            <PatternLayout>
                <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %p %c - %msg%n</pattern>
            </PatternLayout>
            <Policies>
                <TimeBasedTriggeringPolicy interval="1" modulate="true" />
            </Policies>
    </RollingFile>
  </Appenders>
  <Loggers>
    <!-- log anything from class Log4j2Tests into the myfile.log file -->
    <Logger name="Log4j2Tests" level="debug" additivity="false">
            <AppenderRef ref="MyFile" />
    </Logger>

    <Root level="info">
      <AppenderRef ref="Console"/>
      <!-- uncomment the following if you also want to log the console messages to myfile.log file -->
      <!--    <AppenderRef ref="MyFile"/>    -->
    </Root>
  </Loggers>
</Configuration>

Hopefully this can be useful to someone else using Integration Server 10.7

Please note that we did not use our own version of log4j2 libraries, we simply used whatever version came with Integration Server 10.7.

2 Likes

This is the same issue that I faced when i tested with 10.7 couple of months ago when I posted my reply above. I suspected this was a product issue but it was not a mission critical issue for us to open a ticket with SAG so I just ignored it. I am glad you did and thanks for sharing the Root cause and the work around for the issue.

Hi @vignesh.govindhan,
Sorry for the delayed response. Have you seen @Christoph_Jahn’s post about using a custom package to configure Log4j2 loggers? If not, please see Jahn’s Sep 23rd comment: https://tech.forums.softwareag.com/t/use-log4j2-in-webmethods/185018/28.
As for your questions here, custom_wrapper.conf is used to add new JVM properties and to overwrite anything previously defined by the wrapper.conf.
If you add a same property with a different value in custom_wrapper.conf, it will overwrite what is defined in the wrapper.conf. If you want to amend your config, then copy over the value of that property from wrapper.conf and then combine it with your value to avoid losing the wrapper.conf value of this property. If you are adding your log4j2 config file then you can bring over the value from wrapper.conf and then add a comma (,) and specify your file. You can find examples of this in this thread.
Also, the -Dlog4j.configurationFile is the system property used by Log4j2. In your example, you were using -Dlog4j.configuration, which is different property and it was only used in Log4j1 as far as I know.

But if you follow Jahn’s https://github.com/SoftwareAG/webmethods-integrationserver-log4jdemo, it will be upgrade prone and easy to maintain.

1 Like