HTTP "listener" Log Manager
Moderator: admin
HTTP "listener" Log Manager
Hi - TCP isn't natively supported in the browser (outside of the Flash Player). We deploy our game clients to the browser and need to receive logs in realtime directly from a game client to LogMX. We use TCP for this when using Flash games or any game deployed to mobile. But with Unity or any other non-Flash browser games TCP is not an option.
So, I think we can solve this by adding a HTTP log manager that is able to receive log entry additions. The log manager would I guess have to spin up a light weight web server for receiving these additions.
Does something like this exist? If not, it seems like it would be a useful addition to your log manager list as it would work for any browser-based app.
So, I think we can solve this by adding a HTTP log manager that is able to receive log entry additions. The log manager would I guess have to spin up a light weight web server for receiving these additions.
Does something like this exist? If not, it seems like it would be a useful addition to your log manager list as it would work for any browser-based app.
Re: HTTP "listener" Log Manager
Hello,
Good idea. But I guess the way to implement this HTTP listener depends on your needs: raw HTTP GETs/POSTs, REST API style with JSON log entries in the body, log entries put inside the HTTP request URL, ... So depending on this, you may want to use: the basic JDK HTTP features, or a richer framework like Jetty, NanoHttpd, or Apache HTTP Components. All these solutions seem easily feasible in a LogMX Log Manager.
I would be curious to know, in your case, what your needs are. Maybe we can find a set of features that would cover most of people's needs.
Also, if you have purchased a Premium license, we can build a Log Manager that will perfectly fit your needs (Log Manager built just for you).
Xavier
Good idea. But I guess the way to implement this HTTP listener depends on your needs: raw HTTP GETs/POSTs, REST API style with JSON log entries in the body, log entries put inside the HTTP request URL, ... So depending on this, you may want to use: the basic JDK HTTP features, or a richer framework like Jetty, NanoHttpd, or Apache HTTP Components. All these solutions seem easily feasible in a LogMX Log Manager.
I would be curious to know, in your case, what your needs are. Maybe we can find a set of features that would cover most of people's needs.
Also, if you have purchased a Premium license, we can build a Log Manager that will perfectly fit your needs (Log Manager built just for you).
Xavier
Re: HTTP "listener" Log Manager
Hi Xavier, thanks for the response!
Let me explain the need. I think most of the log managers read logs from some external source. Like a local file, or a file found at some FTP, SCP, or HTTP location. But in our case we develop game clients. These clients can run locally during dev, on a mobile device, or in the desktop browser. The biggest use of logging for us is during development and to be read by a developer. We prefer to receive logs in realtime as the app is used. This allows us to us to use the app, navigate through it, and view-and-interpret logs in realtime using LogMX.
We've been doing this successfully for a few years now with LogMX using a custom TCP log manager what we wrote. LogMX listens over TCP on a port. Our client connects to that port and sends logs to it one entry at a time as the application logs it.
Why this won't work for us going forward is because the Flash Player is dying. So TCP support in the browser dies with it. That leaves us with either WebSocket or HTTP. HTTP is more flexible.
We do have a premium 50 seat license (High 5 Games). I would certainly like to hear what you could do for us. Email is jobe dot makar at high5games.com. Just message me here that you've emailed me so I can be sure it wasn't filtered out.
Let me explain the need. I think most of the log managers read logs from some external source. Like a local file, or a file found at some FTP, SCP, or HTTP location. But in our case we develop game clients. These clients can run locally during dev, on a mobile device, or in the desktop browser. The biggest use of logging for us is during development and to be read by a developer. We prefer to receive logs in realtime as the app is used. This allows us to us to use the app, navigate through it, and view-and-interpret logs in realtime using LogMX.
We've been doing this successfully for a few years now with LogMX using a custom TCP log manager what we wrote. LogMX listens over TCP on a port. Our client connects to that port and sends logs to it one entry at a time as the application logs it.
Why this won't work for us going forward is because the Flash Player is dying. So TCP support in the browser dies with it. That leaves us with either WebSocket or HTTP. HTTP is more flexible.
We do have a premium 50 seat license (High 5 Games). I would certainly like to hear what you could do for us. Email is jobe dot makar at high5games.com. Just message me here that you've emailed me so I can be sure it wasn't filtered out.
Re: HTTP "listener" Log Manager
Hello,
I just sent you an e-mail to get more details about the Manager to implement for you![Smile :)](./images/smilies/icon_e_smile.gif)
Xavier
I just sent you an e-mail to get more details about the Manager to implement for you
![Smile :)](./images/smilies/icon_e_smile.gif)
Xavier
Re: HTTP "listener" Log Manager
Note to anyone else reading this. Xavier did a great job on this and it meets our need perfectly!
Re: HTTP "listener" Log Manager
Xavier - I've been using this successfully locally. But now that I'm logging from the browser to LogMX, I have run into this security restriction:
Failed to load http://localhost:8080/logmx: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:51849' is therefore not allowed access.
I think I mentioned via email that we might run into that. Could that header be enabled?
Failed to load http://localhost:8080/logmx: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:51849' is therefore not allowed access.
I think I mentioned via email that we might run into that. Could that header be enabled?
Re: HTTP "listener" Log Manager
Hello,
Sorry my bad, I forgot about that. My initial idea was to use the config file "<LogMX_Dir>/config/managers.properties" to list the headers you want the HTTP server to return, so that you don't need our help to add/update/remove headers. Since this file can be used for other Manager settings, I suggest the prefix "http.server.header". Here is an example:
Can I send you a patch for LogMX v6.1.1? If you're using an older version (and don't want to -or cannot- update right now), please let me know which one you're using so that I can provide you with the proper patch (the modification will be easy and fast, just a business day, and then of course it will be also included in the next releases)
Xavier
Sorry my bad, I forgot about that. My initial idea was to use the config file "<LogMX_Dir>/config/managers.properties" to list the headers you want the HTTP server to return, so that you don't need our help to add/update/remove headers. Since this file can be used for other Manager settings, I suggest the prefix "http.server.header". Here is an example:
Code: Select all
http.server.header.Access-Control-Allow-Origin = *
http.server.header.Content-Type = text/plain
http.server.header.X-My-Custom-Header = my value
Xavier
Re: HTTP "listener" Log Manager
Thanks Xavier, that sounds fine. I'm using v6.0.301. However, I don't mind updating to the latest stable either.
Re: HTTP "listener" Log Manager
I just sent you an e-mail containing a link for the patch to apply (cannot post this Pro version here
)
![Wink :wink:](./images/smilies/icon_e_wink.gif)
Re: HTTP "listener" Log Manager
Strange - I did not receive it. I checked the spam folders too. I'll email you directly.
Re: HTTP "listener" Log Manager
Mail re-sent. I replaced the base URL of our website with XXXXX, I guess your mail server doesn't like URLs ending with ".jar" (which could make sense!)