Use java's native Logger

[jamierocks]

Rather than use, https://github.com/Slowpoke101/FTBLaunch/blob/master/src/main/java/net/ftb/log/Logger.java, you could use Java native Logger. You could access it like Main.LOGGER.

[jikuja]

Yes and no. I was going to open bug report for ideaas More information coming later.

[jikuja]

Using better framework instead of ancient project-specifig code is a nice idea and current implementation has its problems(=memory usage), but...

1. Log entries are stored in memory for later usage. (I don't know logging framework which has support for fetching old log entries.)
   1. Pastebin poster and copy to clipboard features generate their output from saved log entries
   2. When user changes log source or log type via LauncherConsole's dropdown menus LauncherConsole.refreshLogs() reads old log entries from memory and generates new log messages to be shown.
2. StreamLogger.java: We are reading log messages from external process.

Solution for 1.i: We could write combined log(FTBLaunherLog.txt + MinecraftLog.txt) and read contents of that file for pastebin poster and copy to clipboard. What if log files can not be created/written. No logs => support will be difficult. (is that original reason to save log entries into memory instead of relying LogWriters?)

Solution for 1.ii: none? Do not show old messages? Limit console windows backlog size and stored log entries size.

Before wecan use better logging system we need to alter our use cases/existing code:

• for 1.i + write protected installation location: we need really defensive code against stupid users: only give option to change FTB installation location. Nothing else if no rights to write installation directory
• 1.ii Solutions? Do we want to change current features? Do we want to limit backlog size and store raw entries somewhere?

[jamierocks]

When you put it like that, I makes it sound almost counter-productive, what about log4j?—
Sent from Mailbox

On Wed, Sep 17, 2014 at 9:40 PM, jikuja notifications@github.com wrote:

Using better framework instead of ancient project-specifig code is a nice idea and current implementation has its problems(=memory usage), but...

1. Log entries are stored in memory for later usage. (I don't know logging framework which has support for fetching old log entries.)
2. Pastebin poster and copy to clipboard features generate their output from saved log entries
3. When user changes log source or log type via LauncherConsole's dropdown menus LauncherConsole.refreshLogs() reads old log entries from memory and generates new log messages to be shown.
   Solution for 1.i: We could write combined log(FTBLaunherLog.txt + MinecraftLog.txt) and read contents of that file for pastebin poster and copy to clipboard. What if log files can not be created/written. No logs => support will be difficult. (is that original reason to save log entries into memory instead of relying LogWriters?)

Solution for 1.ii: none? Do not show old messages? Limit console windows backlog size and stored log entries size.
Before wecan use better logging system we need to alter our use cases/existing code:

• for 1.i + write protected installation location: we need really defensive code against stupid users: only give option to change FTB installation location. Nothing else if no rights to write installation directory

- 1.ii Solutions? Do we want to change current features? Do we want to limit backlog size and store raw entries somewhere?

Reply to this email directly or view it on GitHub:
#859 (comment)

[jikuja]

Log entries are stored in memory for later usage. (I don't know logging framework which has support for fetching old log entries.)

We need to remove features which rely stored log entries or fix those(1.i and 1.ii). log4j offers nothing which helps with those two tasks. (If it does, please give link)

[jamierocks]

I was only referencing to log4j in case it did have the features. Maybe I should look at other launchers (in Java) to see how they achieve this or what they do instead.—
Sent from Mailbox

On Wed, Sep 17, 2014 at 9:55 PM, jikuja notifications@github.com wrote:

Log entries are stored in memory for later usage. (I don't know logging framework which has support for fetching old log entries.)

We need to remove features which rely stored log entries or fix those(1.i and 1.ii). log4j offers nothing which helps with those two tasks. (If it does, please give link)

Reply to this email directly or view it on GitHub:
#859 (comment)

[jikuja]

One possible solution for 1.i:

• Defensive code: disable launch button if no write access to installation location
• Store messages from launcher to memory and use combined logging
• Use messages stored in memory if faulty installation location detected, otherwise use combined log.

[progwml6]

closing-- java's native logging would reduce the available feature set, and performance