Feature ITW logging tasks implementation

[Omair Majid]

Hi Jiri,

Some general thoughts and comments below.

* Jiri Vanek <jvanek at redhat.com> [2013-11-01 10:39]:
> Hi all, before to much code is written. I would like to ask you to opinions about suggested approaches:

How about we try and tackle one thing at a time? Does it make sense to
implement one of syslog or file logging first?

>    - file logs are saved at
> {~/.config,$XDG_CONFIG_DIR}/icedtea-web/log without possibility to
> change this location... I think this is correct and I'm not going to
> change it (just going to higlight in ITW settings)

But logs are not configuration. Would $XDG_DATA_DIR be more correct than
$XDG_CONFIG_DIR?

>    - java.stderr, java.stdout are no longer used

What happens to java-side logs, then?

> logging to file(s) approaches:

Is there any guarantee that two processes can write to one file without
stepping on each other's data? If not, then separate processes writing
to separate files is the only option we have (unless you want to use
some form of IPC for logging).

>  - C and java sides are sharing the file and only one part is responsible for writing.

What about when there is no plugin process (that is, there's just
javaws)? Does this mean that the java side has to handle the actual
writing?

>   - this is probably just wrong idea, but there is no danger of conflict during writing into
>     - C part is sending the messages via pipe (new or current one), and java side is logging them
>       - advantage is usage of multithreaded logging on java side
>     - Java part is sending the messages via pipe (new or current one), and C side is logging them
>       - advantage can be in case of syslog(-ng) sytstem logger. The C api is much cleaner
> 
> 
> *System logging:*
> To be honest I got into dead end. Both me and pavel have tried
> several approaches, (abrt, syslog...) but none fit.

I don't know anything about these systems. So I wont comment on this.

> - I would like to log into syslog by default always and everything,
> and so if again somebody came and complain "it donot work", I will
> just tell him "look into well_knonw_location".

"everything" including debug messages? Don't know if so much noise would
be helpful.

>    - multiline loggs must be allowed

Not sure I understand this. What do you mean by multiline? Do you want,
say, an entire exception to be one log record?

>    - logs should be automatically rolled

What do you mean by 'rolled' ?

> As interesting approach of system logging may be just extension to file logging:
> Lets expect that directory /var/log/icedtea-web/ with 777
> permissions on icedtea-web exists (owened by root). Then We can have
> 700 permissions (owned y $USER)  directory $USER here, and log 600
> permissions files (owned y $USER) here in same way as we will do for
> "file logging". Stil the idea of ~.../log/ files should be kept. In
> this case I'm afraid of performance impact :(

This would put 'user' logs in a funny place and without any benefit to
root (root will not be using icedtea-web, will it?). I don't see the
point of it. Perhaps I am missing something?

> *Logging settings"*
> Last item I would like to bring up before first line of code, is setting.
> Right now the settings are
>  - global
>   - debugging on/off  checkbook in itw-settings( or ICEDTEAPLUGIN_DEBUG or -verbose for javaws)
>   - headers on/of itw settings checkbox
> - which are affecting all  underlying outputs:
>   - streams
>   - file (only java implementation right now)
>   - system (nothing implemented)
> 
> I'm thinking about individual settings (verbose and headers) of each stream.
> In ideal world I would like to see:
>   - streams - debug and headers off
>   - file  - debug and headers off, and headers off when debug on
>   - system (nothing implemented) -  debug and headers on
> 
> With possibility to switch each separately to on/of for debug, and
> on/of for headers (so change for checkbox to commbobox in
> itw-settings, but I have no idea how to deal with -verbose and
> ICEDTEA_PLUGIN for this granular settings)
> 
> Anyway. I'm not sure if this is worthy of effort (especially when I
> know that C headers generation are quite time consuming)

I would encourage you to approach this from a user's (and root's) point
of view. Please think about what settings make sense and are useful.
I don't think it's a good idea to get very combination of everything
working. Rather, good default to make life simple for users (and
system admin) would be nice.

For example, I don't think debugging stuff to syslog will be useful at
all. And syslog implementations should be able to add timestamps
automatically.

Thanks,
Omair