I think I may have miscommunicated the scenario. When I said, "...code to dynamically toggle inbound or outbound logging...", I meant that an administrator will enable or disable logging manually, through a GUI. The term "dynamic" may have been misleading, what I really meant was "at runtime". But yes, if we had code enabled/disabled logging in response to certain kinds of web service requests, you're right, that scenario would be thread unsafe and result in ambiguous behavior. I understand your suggestion about subclassing the CXF logging interceptors, which is similar to Ron's suggestion. This is the route I am going to take.
Thanks, - Aaron -----Original Message----- From: Daniel Kulp [mailto:[email protected]] Sent: Wednesday, May 16, 2012 9:46 PM To: [email protected] Cc: Pieper, Aaron Subject: Re: Independently toggling inbound/outbound logging in CXF Honestly, neither approach (or your original) is something I'd consider a good solution. (sorry) It's not a thread safe solution. If you have two requests coming in, one that should log and one that shouldn't, the behavior is relatively unpredictable. They may or may not log as expected. Your best option really is to subclass the CXF logging interceptors and override the handleMessage call. If the message should log, call super.handleMessage. If not, return. Don't mess with the global loggers. Dan On Wednesday, May 16, 2012 06:20:08 PM Pieper, Aaron wrote: > Our web application currently uses Log4j and CXF 2.4.2, and has some > code to dynamically toggling inbound or outbound logging. This means > that while our web application is running, administrators can > temporarily enable inbound SOAP message logging, and then turn it back > off when they're done. The underlying code looks like this: > > public void setInboundLogging(boolean b) { > LogFactory.getLog(LoggingInInterceptor.class).setLevel(b ? > Level.INFO > > : Level.ERROR); > > } > > public void setOutboundLogging(boolean b) { > LogFactory.getLog(LoggingOutInterceptor.class).setLevel(b ? > Level.INFO > > : Level.ERROR); > > } > > This worked in CXF 2.4.2, but breaks in CXF 2.5.3. This is because CXF > 2.5.3 uses a more complex implementation of the logging interceptor > classes. Now, the LoggingInInterceptor and LoggingOutInterceptor > classes both use the > "org.apache.cxf.services.MyImplService.MyServiceImplPort.MyService" > logger, whereas before they both had separate loggers based on their > class name. Because the in and out interceptors share the same logger > in CXF 2.5.3, I can't think of a way to control them independently anymore. > > I see two workarounds, one would be to implement our own in-house > logging interceptors which behave like the ones in CXF 2.4.2. Another > might be to create an in-house patch of CXF 2.5.3 which has an extra > "logName" on these interceptors... > > <bean id="loggingInInterceptor" > class="org.apache.cxf.interceptor.LoggingInInterceptor"> > <property name="logName" > value="org.apache.cxf.interceptor.LoggingInInterceptor"/> > </bean> > > Are there any other more intelligent ways to approach this problem? > Also, should I submit an improvement request to CXF's issue tracker > describing this use case? > > Thanks, > > - Aaron -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
