Thanks. The rest below, as preferred on this mailing list.
Thanks,
Vijay G
On Thu, Jun 16, 2016 at 12:40 PM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:
On 16.06.2016 08:50, Vijay Kumar wrote:
Hi Team,
We have a requirement to create a log either at User level or at User
session level.
Please provide your inputs on this.
User level means a separate log to be created for that User and the same
should be used always for writing the log.
or
There will be one log file and within that log there should be a context
information to identify the user which we will do but want to know which
approach we have to use
Session level means, is it possible to turn the logger mode to INFO for a
particular session and the log to be written in one of the file at
server/client side?
Our application is built with Struts 1.2.
Webserver used is Tomcat.
Currently using Tomcat JULI Logging.
Tomcat version ?
On 16.06.2016 09:18, Vijay Kumar wrote:
> We are using Tomcat 7.0.33 and 7.0.62
>
> 7.0.33 when Customer is on Java 1.7
> 7.0.62 when our customer is on 1.8
>
> But we can upgrade to 8 if required to achieve the logging support
I don't think that there is anything "standard" that will allow to create user-specific
logfiles.
What you want is more an application-level thing, so it would have to be resolved at the
application level.
You can create your own logger and do what you want. Any application module can call
getRemoteUser(), and use the result to insert it in all the log messages that it issues.
Of course this will only work in code running within an application, and only when there
is an authenticated user.
To avoid a lot of overhead (also at the system administration level), I would recommend to
keep using the standard logfiles, and just insert a user-id "marker" in the log messages
of interest. This standard logfile can then be filtered a-posteriori by an external
log-processing utility, which can then generate any individual files that you want. That
is likely to be a lot simpler to do than generating user-specific logfiles at the Tomcat
level, and also would have a lot less impact on performance.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
