I want to use log4j2 in webMethods project and i have write some code. it’s a beta version.
you can configure log4j2.xml file in the Log4j2 package home page.
----20151118 added shutdown service.
Log4j2.zip (999 KB)
I want to use log4j2 in webMethods project and i have write some code. it’s a beta version.
you can configure log4j2.xml file in the Log4j2 package home page.
----20151118 added shutdown service.
Log4j2.zip (999 KB)
Thanks for your time and efforts. I will check this and let you know if I have any questions.
Can you please attach the code sample at the below location with some instruction guide. It will help the forum members:
http://techcommunity.softwareag.com/ecosystem/communities/public/webmethods/contents/codesamples/
Hi,
this doesn’t seem working on 10.x versions.
I tried couple of combinations but none seem to work so far with out interfering with IS’ logging framework.
has any one else encountered the same issue
Hi Chakradhar,
please provide some details what exactly you have tried and what was the outcome.
As per the age of the thread you might have missed out the change in the directory structure in wM 9.6, where the IS not working under IntegrationServer directly but uses IntegrationServer/instances/default nowadays to support multiple instances being created from installation directory, while in previous versions this always required different installation directories.
Regards,
Holger
Hi Chakradhar, I am facing the same issue with 10.5. did you get any resolution? please share if you resolved it
much appriciated
Hi Sridhar,
I’m assuming your Log4j2 config file is not getting loaded in 10.5. Unlike prior versions, webMethods Integration Server 10.5 comes with Log4j2 and is used for Integration Server’s logging as well. As part of it’s Logj42 use, IntegrationServer configures <sag dir>/profiles/IS_<instance>/configuration/logging/lo4j2.properties
as the Log4j2 configuration file by adding the following two lines in the <profile_dir>/configuration/wrapper.conf
file:
wrapper.java.additional.4=-Dlog4j.configurationFile="<sag dir>\profiles\IS_default/configuration/logging/log4j2.properties"
wrapper.java.additional.4.stripquotes=TRUE
Because such an entry already presents on the Integration Server, the log4j2.xml from your custom application may not be loading. You can fix it by adding your Logj42 configuration file to the above parameter as shown below:
-Dlog4j.configurationFile="<sag dir>\profiles\IS_default/configuration/logging/log4j2.properties,packages/<your-logging-pkg>/config/Log4j2.xml"
Here, I’m using relative path i.e. “packages/…” because the current working directory of any Integration Server is <sag dir>/IntegrationServer/instances/<instance_name>
and typically the configuration stays in custom packages so I’m showing that as sample. If you have it in another folder, please specify the path to that file. Also, if you have multiple Log4j2 configuraiton files, you can add them to the same parameter using ,
(comma) as the separator.
We don’t recommend changing wrapper.conf
so what we recommend here is to move the whole entry to custom_wrapper.conf
to the next available 3xx entry e.g. 304, 305 and etc. Here, I’m choosing 304 because that’s my next available 3xx entry on 10.5.
wrapper.java.additional.304="<sag dir>\profiles\IS_default/configuration/logging/log4j2.properties,packages/<your-logging-pkg>/config/Log4j2.xml"
wrapper.java.additional.304.stripquotes=TRUE
Please let us know how it works out.
Thanks,
-Senthil
Hi Senthil, I have tried what you suggested and it does not work for me. Please can you kindly take a look below and let me know what’s wrong? I need help.
#encoding=UTF-8
wrapper.app.parameter.2=4
wrapper.app.parameter.5=-service
wrapper.app.parameter.6=sagis105_1.default
wrapper.java.additional.100=-server
wrapper.java.additional.101=-Dorg.apache.xml.dtm.DTMManager=org.apache.xml.dtm.ref.DTMManagerDefault
wrapper.java.additional.102=-Djavax.xml.xpath.XPathFactory:Oracle Java Technologies | Oracle
wrapper.java.additional.103=-Dcom.webMethods.sc.auditing.Use80TableFormat=true
wrapper.java.additional.104=-Dsun.lang.ClassLoader.allowArraySyntax=true
wrapper.java.additional.201=-DWM_HOME=C:\SoftwareAG
wrapper.java.additional.202=-Dwatt.server.prepend.classes=C:\SoftwareAG\common\lib\wm-converters.jar
wrapper.java.additional.203=-Dwatt.server.append.classes=
wrapper.java.additional.204=-Dlog4j.configuration=“C:\SoftwareAG\IntegrationServer\instances\default\log4j.properties,esb.log4j2.xml”
wrapper.java.additional.204.stripquotes=TRUE
wrapper.java.additional.301=-Dorg.tanukisoftware.wrapper.WrapperStartStopApp.passthroughMode=START
wrapper.java.additional.302=-Djava.awt.headless=true
wrapper.java.additional.303=-DLog4jContextSelector=org.apache.logging.log4j.core.selector.BasicContextSelector
wrapper.java.classpath.3=C:\SoftwareAG\common\lib\wm-converters.jar
wrapper.java.initmemory=256
wrapper.java.library.path.11=C:\SoftwareAG\IntegrationServer\instances\default\lib
wrapper.java.library.path.12=C:\SoftwareAG\IntegrationServer\instances\default\support\win32
wrapper.java.library.path.13=C:\SoftwareAG\common\bin
wrapper.java.library.path.append_system_path=TRUE
wrapper.java.maxmemory=1024
wrapper.jvm_exit.timeout=300
wrapper.on_exit.42=RESTART
wrapper.ping.timeout=300
wrapper.restart.reload_configuration=TRUE
wrapper.shutdown.timeout=300
wrapper.single_invocation=TRUE
wrapper.working.dir=C:\SoftwareAG\IntegrationServer\instances\default
<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
<Appenders>
<File name="File" FileName="logs\esb.log">
<PatternLayout>
<pattern>
[%-5level] %d{yyyy-MM-dd HH:mm:ss.SSS} %msg%n
</pattern>
</PatternLayout>
</File>
</Appenders>
<Loggers>
<Logger name="MyLogger" level="debug" additivity="false">
<AppenderRef ref="File"/>
</Logger>
</Loggers>
</Configuration>
Here is my custom java service (just the part that calls the Logger) that I run from inside the webMethods runtime, and it’s a custom java code in one of my wM IS packages, as follows:
Logger logger = LogManager.getLogger("MyLogger");
try {
if(logger.isEnabled(level)) {
// remove variable substitutions from the inputs and trim to max length
message = removeVarSubstitutions(message, 1999);
/* append to logger */
logger.log(level, message, callingServiceName);
Question: what is wrong with the custom_wrapper.conf, and how can I call the Logger named “MyLogger” as defined in my Log4j2 configuration file (esb.log4j2.xml) from the java service above?
Results: every time my java service logs any messages, it goes to the wrapper.log located under the directory \profiles\IS_default/logs, instead of using the Logger “MyLogger” configuration as shown in the configuration file (esb.log4j2.xml) listed above.
So the Logger configuration is not working and by default it goes to the webMethods Integration Server console file (aka wrapper.log)
Btw, I am running webMethods Integration v10.5 on Windows Server 2012 and using MS SQL database.
Please advise.
Thanks in advance.
Hi Waldes,
Looks like your esb.log4j2.xml is not loaded.
Evtl. you need to specify the full path to the esb.log4j2.xml as it is already done for the internal log4j.properties file.
Regards,
Holger
Hi Holder, yes I changed the custom_wrapper.conf file located under C:\SoftwareAG\profiles\IS_default\configuration and added the full path, as you can see below, but the issue is still the same.
New: I modified the following line in custom_wrapper.conf: (here is the original entry from the custom_wrapper.conf file shipped with the webMethods Integration Server:
wrapper.java.additional.204=-Dlog4j.configuration=“C:\SoftwareAG\IntegrationServer\instances\default\log4j.properties,C:\SoftwareAG\IntegrationServer\instances\default\config\esb.log4j2.xml”
wrapper.java.additional.204.stripquotes=TRUE
Notes:
Question: I wonder what could be wrong? Is the issue with the custom_wrapper.conf file configuration (see above), or is my java service the way the Logger is instantiated (the Logger name is “MyLogger”) and maybe the way the method is invoked inside my java service?
Please advise.
Hi Waldes,
Your custom wrapper entry appears to be fine. While we are on this subject, I want to mention that you could use relative file reference to identify your config file. In each IS, the top level IS folder is the working directory. In your case, it is C:\SoftwareAG\IntegrationServer\instances\default
. You could also just specify it as config\esb.log4j2.xml.
After making this change, you need to restart the Integration Server. Did you restart? If you did, maybe then the esb.log4j2.xml has some issues. Can you please share that file?
Thanks,
-Senthil
Hi Waldes,
I just realized that you have already shared all the details in your initial post. Let me go through it and let you know.
Thanks,
-Senthil
Hi Sentil, yes I already tried the relative path (config\esb.log4j2.xml) in the custom_wrapper.conf and also the absolute path (as per my previous post).
Additionally, yes I shutdown the webMethods IS every time and then change the custom_wrapper.conf file and after that I startup the server using the script “startup.bat” located under c:/sag dir/profiles/IS_default/bin.
Also keep in mind that I am running the webMethods IS on a Windows machine, as indicated in previous post.
Current results: my java service and the call to the Logger (in this case is “MyLogger” as you can see in previous posts my java service source code) are actually going to the webMethods Integration Server default wrapper.log (located under c:/sag dir/profiles/IS_default/logs), instead of using what is configured in my custom Log4j2 configuration file (config\esb.log4j2.xml).
I look froward to hearing from you.
Thanks in advance.
Hi Waldes,
Thanks. I also tried with your config file and after starting up my IS, it created the esb.log file in the \logs folder because that’s what we specified in the configuration file.
Then I tried to log a message using my own code and it worked. As I didn’t have all the code you are using, I didn’t try that but I don’t think the code is the problem but if you share the full logic of that service, we can try to see if anything can attribute from there.
As for using the relative path, if your esb.log2.xml exists under C:\SoftwareAG\IntegrationServer\instances\default\config
folder, then using config\esb.log4j2.xml should work.
As a next step, please try to enable Log4j2’s logger to help troubleshoot why it’s not working. In order to do that, edit your esb.log4j2.xml and replace the line <Configuration>
with <Configuration status="trace" name="esb">
. Then restart the IS. As the IS starts up, you can see the log messages in c:/sag dir/profiles/IS_default/logs/wrapper.log and search for your file esb.log4j2.xml to see if there is any clue.
Thanks,
-Senthil
Senthil, in order to save time and to avoid impacting you with more work, please can you share here the following files from your webMethods installation:
I would like to compare on my end and verify if there’s anything you have that I don’t have in my webMethods instance, ok?
I want to make sure I can reproduce your results on my end as well.
Thanks in advance,
Waldes
custom_wrapper.conf (2.3 KB) wrapper.conf (10.2 KB)
Hi Waldes,
Please find my wrapper and custom_wrapper.conf files attached. Also note that my config files have another customer’s log4j2 config file as well from sometime back. I don’t think having that or not having that changes the result.
Given below is the code I have in a java service named logMessage:
IDataMap pipe = new IDataMap(pipeline);
String loggerName = pipe.getAsString("loggerName");
String logMessage = pipe.getAsString("logMessage");
try
{
Logger logger = LogManager.getLogger(loggerName);
logger.fatal(logMessage);
logger.error(logMessage);
logger.warn(logMessage);
logger.info(logMessage);
logger.debug(logMessage);
logger.trace(logMessage);
} catch( Throwable t) {
throw new ServiceException(t);
}
The following imports are needed to use this code:
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import com.softwareag.util.IDataMap;
Hope this helps.
logging.java (1.4 KB)
Hi Waldes,
I just realized, I only had one IS java service on that folder so sharing that java file (logging.java) as well.
Senthil, no matter what I do any messages written using the Lo4j2 only go to the wrapper.log and not to the custom esb.log declared in the Log4j2 configuration (xml) file.
One observation: even if I delete the esb.log file, when the webMethods Integration Server is restarted, a new esb.log file is created with zero bytes (empty file), which indicates that the configuration seems to be having some effect, but for some reason the logger “MyLogger” is not completely activated or the configuration is somewhat overwritten or canceled by the server, and any message written to the logs via my java services goes to the wrapper.log as mentioned above.
I hope you can take another look in the details below (modified to simplify my configuration a bit) and let me know what you think? What could be causing this? Please, advise.
I made some minor adjustments to simplify the configuration and I moved the Log4J2 xml configuration file to be located under the wM IS package, in order to match your configuration, instead of putting under the /instances/default/config main directory - this was the biggest change compared to before.
I also needed to update my custom_wrapper.conf file to reflect this, and I decided to also simplify my Log4J2 xml configuration file, as you can see below:
1. Here is my custom_wrapper.conf updated, but only the lines relevant to this topic - please note the entries starting with “wrapper.java.additional.205” which match your configuration, as follows:
wrapper.java.additional.204=-Dlog4j.configuration=file:///C:\SoftwareAG\IntegrationServer\instances\default\log4j.properties
wrapper.java.additional.205=-Dlog4j.configurationFile=“C:\SoftwareAG\profiles\IS_default/configuration/logging/log4j2.properties,packages/MyISPackage/config/esb.log4j2.xml”
wrapper.java.additional.205.stripquotes=TRUE
2. Here is my modified and simplified Log4j2 file (esb.log4j2.xml)
<?xml version="1.0" encoding="UTF-8"?><Configuration status="DEBUG">
<Appenders>
<File name="LogToFile" FileName="esb_new.log">
<PatternLayout>
<Pattern>[%-5level] %d{yyyy-MM-dd HH:mm:ss.SSS} %msg%n</Pattern>
</PatternLayout>
</File>
</Appenders>
<Loggers>
<Logger name="MyLogger" level="error" additivity="false">
<AppenderRef ref="LogToFile"/>
</Logger>
</Loggers>
</Configuration>
3. Here is my java service now in a new simplified version:
package POC.LMLogging;
import com.wm.data.*;
import com.wm.util.Values;
import com.wm.app.b2b.server.Service;
import com.wm.app.b2b.server.ServiceException;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
public final class logMessage_SVC
{
/**
* The primary method for the Java service
*
* @param pipeline
* The IData pipeline
* @throws ServiceException
*/
public static final void logMessage(IData pipeline) throws ServiceException {
// pipeline
IDataCursor pipelineCursor = pipeline.getCursor();
String logMessage = IDataUtil.getString( pipelineCursor, "logMessage" );
pipelineCursor.destroy();
String loggerName = "MyLogger";
// pipeline
try
{
Logger logger = LogManager.getLogger(loggerName);
logger.fatal(logMessage);
logger.error(logMessage);
logger.warn(logMessage);
logger.info(logMessage);
logger.debug(logMessage);
logger.trace(logMessage);
} catch( Throwable t) {
throw new ServiceException(t);
}
}
// --- <<IS-BEGIN-SHARED-SOURCE-AREA>> ---
// --- <<IS-END-SHARED-SOURCE-AREA>> ---
final static logMessage_SVC _instance = new logMessage_SVC();
static logMessage_SVC _newInstance() { return new logMessage_SVC(); }
static logMessage_SVC _cast(Object o) { return (logMessage_SVC)o; }
}
Hi Wales,
Do you see esb.log getting created? I still think your config file is not loading. Can you please share zip of your wrapper.log file? Please try to restart the server and then pull the log after IS startup completes that way, the log will be clean for this purpose.
Hi @Senthil, yes it worked as you suggested. My webMethods Integration Server installation had another java dependancy that was impacting the class loader, and once I installed a new IS instance from scratch, it all worked as expected. The issue has been resolved. Thanks for your help and guidance in this topic.
Hi Waldes,
That’s great news! Thanks so much for updating us.