RE: how to create log files user level
Hi Vijay,
We have accomplished user level logging using log4j's MDC feature along with a
custom interceptor in Struts 2. The interceptor injects the user name into the
MDC context before any struts actions fire and then removes it from the MDC
context after all actions have fired for a specific web request. This approach
is thread safe and we have had great success with it.
Interceptor:
public class MDCLogInterceptor implements Interceptor {
private static final long serialVersionUID = 1L;
private static final String USER_NAME_KEY = "userName";
public String intercept(ActionInvocation invocation) throws Exception {
try {
String userName = //either get this from the session if
using application authentication or remoteUserId if using tomcat
authentication;
if (!StringUtils.isBlank(userName)){
MDC.put(USER_NAME_KEY, userName);
}
return invocation.invoke();
} finally {
if (MDC.get(USER_NAME_KEY) != null){
MDC.remove(USER_NAME_KEY);
}
}
}
public void destroy() {
// TODO Auto-generated method stub
}
public void init() {
// TODO Auto-generated method stub
}
}
Don't forget to add the interceptor to your interceptor stack in your struts
config. We have it listed first.
Add the MDC value to your log4j config:
The "User[%X{userName}] " is the MDC part that adds the username to the log
files from the value inserted by the interceptor. You can move it to anywhere
in the appender pattern you want.
Thank you,
Bill
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Thursday, June 16, 2016 3:18 AM
To: Tomcat Users List
Subject: Re: how to create log files user level
On 16/06/2016 09:05, Vijay Kumar wrote:
> Hi Andre,
>
> Thanks for the update.
>
> Could you please give me some information whether it's possible or not
> to generate user level log because i have tried using log4j but it failed.
>
> Appreciate your help on this.
Either per user logging or per session logging should be possible. One of
potentially many ways is via a separate Logger for each session/user.
If you give each Logger a unique name based on the user name or session ID
(both of which should be unique) and use a common prefix you should be able to
direct all logs with that prefix to a file. With in the file you then use the
Logger name to identify the source of the log message.
Mark
>
> Thanks,
> Vijay G
>
> On Thu, Jun 16, 2016 at 12:59 PM, André Warnier (tomcat)
>
> wrote:
>
>>
>> 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)
>>>
>>> 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
RE: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server
Hi Chris, Thank you very much for your help. It appears that maxSwallowSize in the configuration has fixed the issue. Your help is greatly appreciated. Thank you, Bill -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, December 3, 2015 9:49 AM To: Tomcat Users List Subject: Re: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server Bill, On 12/3/15 10:27 AM, Bill Wolosek wrote: > We have recently updated the tech stack of a JAX-WS webservice running > on JRE 1.7.0_17/Tomcat7.0.39 to JRE 1.8.0_66/Tomcat 8.0.28. > The web app runs on Windows Server 2012. The web service uses a Metro > implementation for JAX-WS. The clients run on various windows versions > using JRE 7 and the JAX-WS client API built into the JRE. > The webservice is used to upload files from the client machines to the > webservice which saves them in a document management system. The > implementation worked pretty much flawlessly under Java 7/Tomcat 7 but > we have run into a problem with larger payloads (2MB or larger) > running under Java 8/Tomcat 8 server side. The stack trace from the > client is: > > 12/02/2015 14:12:38.699 [AWT-EventQueue-0] ERROR > DocumentImporterMainWindow$SwingAction.importDocument: Unexpected > Problem trying to call the CustomerOrderDMService > javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server > at > com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(Unknown > Source) > at > com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(Unknown > Source) > at > com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(Unknown > Source) > at > com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(Unknown > Source) > at > com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(Unknown > Source) > at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Unknown Source) > at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Unknown Source) > at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Unknown Source) > at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Unknown Source) > at com.sun.xml.internal.ws.client.Stub.process(Unknown Source) > at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(Unknown Source) > at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown > Source) > at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown > Source) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(Unknown Source) > at com.sun.proxy.$Proxy30.importDocument(Unknown Source) > at > com.mycompany.documentimporter.DocumentImporterMainWindow$SwingAction.importDocument(DocumentImporterMainWindow.java:681) > at > com.mycompany.documentimporter.DocumentImporterMainWindow$SwingAction.actionPerformed(DocumentImporterMainWindow.java:612) > at javax.swing.AbstractButton.fireActionPerformed(Unknown Source) > at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source) > at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source) > at javax.swing.DefaultButtonModel.setPressed(Unknown Source) > at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown > Source) > at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Window.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.EventQueue.dispatchEventImpl(Unknown Source) > at java.awt.EventQueue.access$500(Unknown Source) > at java.awt.EventQueue$3.run(Unknown Source) > at java.awt.EventQueue$3.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at > java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown > Source) > at > java.security.ProtectionDomain$Jav
RE: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server
Hi Mark, Your point of assuming Tomcat 7.0.39 = Tomcat 7 and Tomcat 8.0.28 = Tomcat 8 and not taking all other versions in-between into account was a bad on my part. Thanks for clarifying this for me. It appears that maxSwallowSize in the configuration has fixed the issue. I set it to -1 and now the service is working as expected. Now I just need to come up with a good maximum size value. Thank you very much for your help. Thank you, Bill -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, December 3, 2015 11:11 AM To: Tomcat Users List Subject: Re: Tomcat 8 JAX-WS javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server On 03/12/2015 15:27, Bill Wolosek wrote: > We have also tried different combinations of Java and Tomcat: * > Tomcat 7/Java 7 = Works * Tomcat 7/Java 8 = Works * > Tomcat 8/Java 7 = Doesn't Work * Tomcat 8/Java 8 = Doesn't > Work Assuming Tomcat 7 == 7.0.39 and Tomcat 8 == 8.0.28 the above list is somewhat misleading. > This leads us to think that the issue is with Tomcat 8. That conclusion is not supported by the evidence. 7.0.39 is over 2.5 years older than 8.0.28. What is far more likely is that you have been affected by one of the many fixes in that 2.5 year period that has been applied to both 7.0.x and 8.0.x. > Either something was changed in Tomcat 8 and we now need to set some > new timeout/payload settings or Tomcat 8 has a bug related to this > specific problem. See my previous comment. > We have tried setting some of the Tomcat connector settings like > maxPostSize="-1", connectionTimeout="-1", disableUploadTimeout="true", > connectionUploadTimeout="-1", keepAliveTimeout="-1" but none of these > worked and honestly feel like a shot in the dark without knowing what > is going on server side. The 2MB limit should have been a broad hint. The stack trace on the client side could have been clearer but it is telling you that the server has dropped the connection. Those two together plus a review of the changelog should have pointed you towards the maxSwallowSize of the HTTP connector. You could have reduced the amount changelog to review by testing different Tomcat 7.0.x versions which should have pointed you towards 7.0.55 making the 2MB hint more obvious. > We have tried updating the Metro jars server side to the most recent > release (jaxws-ri-2.2.10) as well as running the client using Java 8. > Unfortunately none of these worked. Any help would be greatly > appreciated. maxSwallowSize=-1 is the quick test to see if this is the issue. After that, you need to adjust it as appropriate for your environment since this was added to address CVE-2014-0230. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8 JAX-WS javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server
We have recently updated the tech stack of a JAX-WS webservice running on JRE 1.7.0_17/Tomcat7.0.39 to JRE 1.8.0_66/Tomcat 8.0.28. The web app runs on Windows Server 2012. The web service uses a Metro implementation for JAX-WS. The clients run on various windows versions using JRE 7 and the JAX-WS client API built into the JRE. The webservice is used to upload files from the client machines to the webservice which saves them in a document management system. The implementation worked pretty much flawlessly under Java 7/Tomcat 7 but we have run into a problem with larger payloads (2MB or larger) running under Java 8/Tomcat 8 server side. The stack trace from the client is: 12/02/2015 14:12:38.699 [AWT-EventQueue-0] ERROR DocumentImporterMainWindow$SwingAction.importDocument: Unexpected Problem trying to call the CustomerOrderDMService javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(Unknown Source) at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(Unknown Source) at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(Unknown Source) at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(Unknown Source) at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(Unknown Source) at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Unknown Source) at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Unknown Source) at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Unknown Source) at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Unknown Source) at com.sun.xml.internal.ws.client.Stub.process(Unknown Source) at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(Unknown Source) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(Unknown Source) at com.sun.proxy.$Proxy30.importDocument(Unknown Source) at com.mycompany.documentimporter.DocumentImporterMainWindow$SwingAction.importDocument(DocumentImporterMainWindow.java:681) at com.mycompany.documentimporter.DocumentImporterMainWindow$SwingAction.actionPerformed(DocumentImporterMainWindow.java:612) at javax.swing.AbstractButton.fireActionPerformed(Unknown Source) at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source) at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source) at javax.swing.DefaultButtonModel.setPressed(Unknown Source) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source) at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Window.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.EventQueue.dispatchEventImpl(Unknown Source) at java.awt.EventQueue.access$500(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source) at java.awt.EventQueue$4.run(Unknown Source) at java.awt.EventQueue$4.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) Caused by: java.io.IOException: Error writing to server at
