Hello, Did you open the logs tab in LogMX before your JBoss application? For Socket Appenders, LogMX should be started first so that somebody opens the TCP port and listens to it, otherwise the logging may never happen. Also, I'm a bit confused why you tried to add the Log4j JARs in LogMX: if you ar...

Hello, To be honest, I had never heard of an SSH session opened using a physical RSA token, until today. So I looked it up. According to https://www.ssh.com/manuals/clientserver-product/52/Clientserver-securid.html (Tectia, pretty famous), such 2FA is implemented using the SSH Authentication method ...

OK great, added to our backlog. We will post a message in this thread when the feature will be available.

Hello, There is no such feature for now in LogMX, but it's a good idea. Maybe we can add an optional suffix to specify an individual log entry field: for example %e{message}, or %e{timestamp} (and of course we would keep the possibility to use just %e to output the complete log entry). What do you t...

I did test on macOS, but only to reply at your first post to check how the HTTP server is behaving on macOS Mojave (I didn't use your Parser because I didn't have it back then, so I used a Parser I already had). But I just tried with your Parser and your JAR, and I reproduced the issue. I still thin...

I tried to open the same URL (http-server://127.0.0.1:8080/logmx), with your Parser "GlogJSONParser.GlogJSONParser", with your library "json-20141113.jar", and with your LogMX config file ("logmx.properties" from your health-report), and it worked fine, even with all the HTTP headers you specified i...

Hello, Looking at your Health Report, it seems that if you don't see any log entry, it's because the Log Parser you wrote (GlogJSONParser.GlogJSONParser) failed: it cannot find the class org.json.JSONArray (I guess it's the JSON library you'd like to use in order to parse the json log entry). If you...

Hello, I just tried on macOS Mojave (same URL, with curl), and it worked fine. Here are a couple of things you can try: In the terminal, type: lsof -nP -iTCP:8080 You should see the LogMX process listening on the port 8080. If not, you may encounter some OS network config issue (firewall, network in...

Wow, I was not aware of this weird Layout offered by Logback :shock: . It's basically a Layout that tries (but clearly fails) to mimic the Log4j XML Layout. I personally think it's wrong that Logback provides this. If at least it had the same format, why not, but since it's not the same format, I wo...

Hello, These logs look like they were actually produced by Log4j, not Logback (see https://howtodoinjava.com/log4j/how-to-create-logs-in-xml-format-using-log4j). But even then, this new line character right before the timestamp prevents LogMX from recognizing this Log4j syntax (and as you said, the ...

Hello, I would actually consider a 60 MB log file rather small. There is no file size limitation. But there are 2 cases: You want to load all the log events in memory to see them in the graphical user interface. You want to monitor only the end of a log file being updated in real-time (and maybe get...

LogMX v7.8.0 has been released: If LogMX runs out of memory when loading multiple log files, it now doesn't try to load the remaining log files anymore The "Open file" dialog received a few improvements for local files: it now provides 2 new file filters (for "*.log" files, and for compressed files)...

Hello, If you are talking about upgrading from the application itself, yes, sorry it is a known bug (see https://logmx.com/download#v7.6.0T), you need to upgrade it manually. Here is how to do it: https://logmx.com/forum/viewtopic.php?f=3&t=19&p=46#p46 Please let me know if you have any question. Xa...

Hello, Unless I missed something, I think this use case is already covered by the URL bar in the main window toolbar: you can paste there any complex LogMX URL and it will load it, the matter the LogManager (FTP, SFTP, SFTP-DIR, SMB, ...). If you're note sure about the syntax to use for the URL, you...

Hello, Thanks, that's a good idea, I like it :) I guess if LogMX listens to a local/loopback interface, there shouldn't be any firewall issue. I also wonder if there could be any performance hit when the port is already used by another process (could be LogMX or other). If it takes a short timeout (...