Good. Then should't the Commons Logging API documentation example be like
this:
public class MyComponent {
protected static Log log = LogFactory.getLog("my.component");
. . .
instead of like this
public class MyComponent {
protected Log log = LogFactory.getLog("my.component");
. . .
The first way is how Struts uses it and how I've always used Log4J's
Category. I don't want a seperate Log instance for every instance of my
classes. However if a Log implementation instance maintains state in an
unsychronized way then I would need a seperate Log instance for each
instance of my classes.
What worries me is that the API documentation does not guarantee this type
of thread-safety. I haven't investigated any of the other implementations
to see if they are thread-safe, but would feel good if the Commons API
required it (and examples implied it).
> -----Original Message-----
> From: Scott Sanders [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 11, 2002 1:48 PM
> To: Jakarta Commons Users List
> Subject: RE: [Logging] Thread safety guaruntee of Log classes?
>
>
> > I guessed that. However one should program to the API
> > contract. One benefit of using the Commons Logging API
> > wrapper layer was to allow switching implementations. If you
> > are assuming thread safety as Struts seems to be, then
> > switching to a non-thread safe implementation would break
> > your application.
> >
> > So, is the contract of Log supposed to guarantee
> > thread-safety? Despite what Struts assumes I'll assume no
> > until I hear otherwise.
> >
>
> No, commons-logging makes no guarantee of thread safety. It was not
> intended to do so.
>
> The assumption that Struts makes, IMO, is a safe one. Using a logging
> API that is not thread safe will break more than Struts :)
>
> Scott
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
