Hi,
I have successfully written my AutoConfigParser that extends your Log4jPatternLogFileParser!
However, when viewing log entries written with a Log4J pattern like "%d{dd MMM yyyy HH:mm:ss,SSS} [%t] %-5p %c [%x] - %m%n" the NestedContext value from the log record is ignored by LogMX. I know, there is no column up to know that can contain "extra info" like the one presented in ParsedEntry. And this kind of info is said to be ignored by the viewer anyway. So, do I have a chance to display the contents of my "[%x]" NDC info? I had the idea of extending the "message" part, but unfortenately "addEntry()" is protected final(!). Therefore I CANNOT MODIFY the message field used by Log4jPatternLogFileParser for this purpose.
ANY IDEAS?
--Klaus
Log4jPatternLogFileParser seems to ignore Log4j NDN/MDC...
Moderator: admin
[ this post refers to post viewtopic.php?t=58 ]
Hello
The solution is to use the obfuscated class "aH" to set the "%x" Log4j Tag settings like you can do with a Log4j parser you would create using LogMX GUI (switch on the flag "Include in Message" for this "%x" tag):
Xavier
Hello
The solution is to use the obfuscated class "aH" to set the "%x" Log4j Tag settings like you can do with a Log4j parser you would create using LogMX GUI (switch on the flag "Include in Message" for this "%x" tag):
Code: Select all
import java.util.ArrayList;
import java.util.List;
import com.lightysoft.logmx.mgr.parsers.Log4jPatternLogFileParser;
public class TestParser extends Log4jPatternLogFileParser {
public TestParser() {
super(getL4jPatternToUse());
}
private static fS getL4jPatternToUse() {
String pattern = "%d{dd MMM yyyy HH:mm:ss,SSS} [%t] %-5p %c [%x] - %m%n";
// If you use 'System.getProperty("my.pattern")', you will get the value of
// line "my.pattern=..." in file "config/parsers.properties" of your LogMX directory
// String pattern = System.getProperty("my.pattern");
// This List actually configure log4j tags like you can see in the L4j Parser
// creation dialog (options like "may contain spaces", "include in message")
List<aH> log4jTagsSettings = new ArrayList<aH>();
aH ndcSettings = new aH();
// ndcSettings.a = true; // Flag "May Contain Spaces" (by default: true)
// ndcSettings.b = true; // Flag "Match Minimum Chars" (by default: true)
ndcSettings.c = true; // Flag "Include in Message" (by default: false)
log4jTagsSettings.add(new aH()); // settings for tag "%d"
log4jTagsSettings.add(new aH()); // settings for tag "%t"
log4jTagsSettings.add(new aH()); // settings for tag "%p"
log4jTagsSettings.add(new aH()); // settings for tag "%c"
log4jTagsSettings.add(ndcSettings); // settings for tag "%x"
log4jTagsSettings.add(new aH()); // settings for tag "%m"
// Return the Log4jPattern
return new fS(pattern, log4jTagsSettings, true);
}
public String getParserName() {
return "Test parser";
}
public String getSupportedFileType() {
return "test";
}
}
Access to obfuscated classes not possible LogMX-1.2.6_pro!?
Hi Xavier,
with the free eval version 1.2.6 everything works fine now! Thanks a lot.
But today I bought 1 license for LogMX-1.2.6_pro and using this version my nice Log4J AutoConfigParser does not run The logmx.jar files are different between professional and eval version and that means that my very flexible solution for Log4J will NOT work after buying a license, due to NoSuchMethod error etc.
That's a pitty because I thought I will get MORE from LogMX when switching to the professional version. In my case, I will get less! So, I'm quite disappointed if this is your company's policy...
Reading your previous postings I remember you pointing me to 1.2.6 free eval version, but I did not guessed these kind of consequences...
--Klaus
with the free eval version 1.2.6 everything works fine now! Thanks a lot.
But today I bought 1 license for LogMX-1.2.6_pro and using this version my nice Log4J AutoConfigParser does not run The logmx.jar files are different between professional and eval version and that means that my very flexible solution for Log4J will NOT work after buying a license, due to NoSuchMethod error etc.
That's a pitty because I thought I will get MORE from LogMX when switching to the professional version. In my case, I will get less! So, I'm quite disappointed if this is your company's policy...
Reading your previous postings I remember you pointing me to 1.2.6 free eval version, but I did not guessed these kind of consequences...
--Klaus
Hello Klaus,
Sorry for the inconvenience.
Thank you for purchasing LogMX, I can reassure you, you will get more with this version (see http://www.logmx.com/p_download.php) our company's policy is of course to match users need the best we can.
Producing two different obfuscations for eval and pro JARs is not something really expected: the pro version contains more classes than the eval version, so the obfuscation tool we use may rename classes in a slighty different way... In your case, the eval class "fS" is named "fU" in pro version (class "aH" has the same name).
If you want to use the same class for both versions, please let me know, we will try to find something user-friendly enough. We could also add a new feature in the next release to allow this use of our API with some security checks (like checking that LogMX GUI was started to prevent use of our JAR like a simple library).
Please let me know if you have any other question or problem.
Xavier
Sorry for the inconvenience.
Thank you for purchasing LogMX, I can reassure you, you will get more with this version (see http://www.logmx.com/p_download.php) our company's policy is of course to match users need the best we can.
Producing two different obfuscations for eval and pro JARs is not something really expected: the pro version contains more classes than the eval version, so the obfuscation tool we use may rename classes in a slighty different way... In your case, the eval class "fS" is named "fU" in pro version (class "aH" has the same name).
If you want to use the same class for both versions, please let me know, we will try to find something user-friendly enough. We could also add a new feature in the next release to allow this use of our API with some security checks (like checking that LogMX GUI was started to prevent use of our JAR like a simple library).
Please let me know if you have any other question or problem.
Xavier
Using Log4JPatternParser in LogMX professional version
Hi Xavier,
thanks again for your help!
I have no problem of producing two different versions of my AutoConfigParser, one for LogMX eval and one for LogMX pro. Now, using the new classnames with LogMX pro everything works fine, even with NDC, just as expected!
-Klaus
thanks again for your help!
I have no problem of producing two different versions of my AutoConfigParser, one for LogMX eval and one for LogMX pro. Now, using the new classnames with LogMX pro everything works fine, even with NDC, just as expected!
-Klaus