[rfc][icedtea-web] refactored logging
jvanek at redhat.com
Thu Sep 12 03:11:46 PDT 2013
On 09/11/2013 08:24 PM, Jacob Wisor wrote:
> Omair Majid wrote:
>> Hi Jiri,
>> I am mostly interested in this patch as a user (especially if some else
>> has agreed to a full review of this giant patch). But it caught my
>> interest so I have a few questions.
> I have always appreciated when an application transitioned from a custom logging solution or added
> support for a native system logging facility. So, it is fair to say I am interested in this too.
> As Java currently does not provide an abstraction for native system logging facilities my question
> is: Where are you heading with this initiative?
Exactly where you have described - to provide native logging.
>> Can you describe the motivation for logging into syslog? Is this
>> somethings lots of other user programs do?
> I am not sure whether this question can be answered in general. AFAICT, I am observing a shift
> especially in "business" applications transitioning to native system logging facilities. Where
> native system logging facilities may be syslog on Un*x like systems or the "Event Log" service in
To achieve this also on windows will need some advices, as I have no idea how "event log" is working.
However I will be more then happy to implement (or provide api for windows programmer :) )this for
> Windows. It is definitely a good idea and rather indicated for IcedTea-Web in my opinion. Having
> configurable logging options in IcedTea-Web is going to make admin's lives surely easier. But,
> native system logging support is probably going to require a dependency on a third party library
> like Apache's log4j.
> I fear this is the only option if you want to have true native system logging support in
> IcedTea-Web. This is one of these field where Java has fallen behind. I do not how much of a problem
> this is — given J2SE API's current state — to add proper syslog support on Un*x systems in an
> application like IcedTea-Web but adding support for Windows' Event Log service definitely requires
> native bindings to Win32 API (which log4j does provide). In fact, there should be less of a problem
> with the plug-in itself because it is built and compiled for a specific native target system anyway.
> So, adding system dependent code with the help of the preprocessor is easy.
This is still under development. TBH I would like to avoid external library. All I ahve checked till
now had serious drawbacks and were (with all theirs dependences) incredibly big.
For linux logging right now the best appears tcp or native api.
For windows I really have to de-dust my knowledge and dig more./
More information about the distro-pkg-dev