[Swift-devel] Re: coaster service log4j.properties

Mihael Hategan hategan at mcs.anl.gov
Sat Dec 18 00:17:35 CST 2010


Whatever goes to coaster.log is governed by the log4j.properties in
provider-coaster/resources and that is stuck into the coaster jar file
at compile time (so modifications to that require recompilation).

The rlog stuff, that's the coaster service forwarding some specific log
messages to the client. It does not currently forward all log4j
messages, but some select messages distinct from what goes to log4j.
They are forwarded as INFO level (given that that's just a sample thing
for now), so you won't see anything else than INFO from the rlog
package. Given that the actual calls to log4j are done on the client
side, the swift log4j.properties would decide the level there.

I think in the long run we would probably want to have all log4j stuff
forwarded, at least in the case in which the service is deployed
automatically, but that's not there now. I think it should also be done
seamlessly, such that log messages appear to come from the original
classes rather than RemoteLogHandler.

Mihael

On Fri, 2010-12-17 at 19:56 -0600, Allan Espinosa wrote:
> I'm bumping this thread to swift-devel.  I'm starting to need (at a
> higher priority) the timing information in the persistent logs.
> 
> -Allan
> 
> 2010/10/21 Allan Espinosa <aespinosa at cs.uchicago.edu>:
> > Hi,
> >
> > I set my
> >
> > log4j.logger.org.globus.cog.abstraction.coaster.rlog=DEBUG
> >
> >
> > but the persistent coaster-service still seems to be in INFO mode.
> > Does bin/coaster-service still look at etc/log4j.properties ? Or do i
> > need to specify the log4j.properties file in the bin/coaster-service
> > script itself as a java flag?
> >
> > Thanks.
> > -Allan
> 
> 
> 





More information about the Swift-devel mailing list