«

I love the concept of dependency injection via ctor. it simplifies life and makes testing easy.
what about logger?
i usually instantiate it in private static logger = Logger.getLogger(myclass);
however this is not dependency injection, should I pass the logger into each ctor? this would look wierd... so what to do about loggers and depedency injection?

thanks

On 1/4/2013 4:00 AM, Tomer wrote:
> I love the concept of dependency injection via ctor. it simplifies
> life and makes testing easy. what about logger? i usually instantiate
> it in private static logger = Logger.getLogger(myclass); however this
> is not dependency injection, should I pass the logger into each ctor?
> this would look wierd... so what to do about loggers and depedency
> injection?


I agree with you on both counts. Ctors are an excellent way of
implementing dependency injection, and static methods aren't.

However loggers are more of an aspect than a dependency. Absent some
other framework (AOP, for example, or some sort of annotation
processing), good old frameworks and libraries solve this problem. Have
a look at Apache logging:

<http://commons.apache.org/logging/>

In article <kc6rjn$fl2$>,
markspace <> wrote:

> On 1/4/2013 4:00 AM, Tomer wrote:
> > I love the concept of dependency injection via ctor. it simplifies
> > life and makes testing easy. what about logger? i usually instantiate
> > it in private static logger = Logger.getLogger(myclass); however this
> > is not dependency injection, should I pass the logger into each ctor?
> > this would look wierd... so what to do about loggers and depedency
> > injection?
>
>
> I agree with you on both counts. Ctors are an excellent way of
> implementing dependency injection, and static methods aren't.
>
> However loggers are more of an aspect than a dependency. Absent some
> other framework (AOP, for example, or some sort of annotation
> processing), good old frameworks and libraries solve this problem. Have
> a look at Apache logging:
>
> <http://commons.apache.org/logging/>

I'd say that Java's own logger (java.util.logging) is worth a look too
if you want modularity. It's easy to plug in custom formatters and
handlers. You map logging paths to handlers during app initialization
so no dependency injection is involved. My biggest peeve about most
loggers is that they don't indent multi-line log entries nicely and
they're sensitive to disk latency. It's not a problem when you plug in
your own parts. You can also do fancy logging to remote archiving
systems (JSON or XML over socket or REST, etc.) with little effort.

http://docs.oracle.com/javase/6/docs...package-summar
y.html
--
I will not see posts from Google because I must filter them as spam

On 1/4/13 7:13 AM, markspace wrote:
> On 1/4/2013 4:00 AM, Tomer wrote:
>> I love the concept of dependency injection via ctor. it simplifies
>> life and makes testing easy. what about logger? i usually instantiate
>> it in private static logger = Logger.getLogger(myclass); however this
>> is not dependency injection, should I pass the logger into each ctor?
>> this would look wierd... so what to do about loggers and depedency
>> injection?
>
>
> I agree with you on both counts. Ctors are an excellent way of
> implementing dependency injection, and static methods aren't.
>
> However loggers are more of an aspect than a dependency. Absent some
> other framework (AOP, for example, or some sort of annotation
> processing), good old frameworks and libraries solve this problem. Have
> a look at Apache logging:
>
> <http://commons.apache.org/logging/>
>
>
Loggers can generally be configured externally to their instances.
Therefor you don't usually need to inject them.

On the other hand, there generally isn't any real requirement that
loggers be static. I have had occasion to create a class which uses a
different logger depending on the context in which that class was created.

public class MySomething {
private final Logger log;

public MySomething() {
this.log = Logger.getLogger(MySomething.class);
}
public MySomething(Logger log) {
this.log = log;
}
}

Daniel Pitts wrote:
> On the other hand, there generally isn't any real requirement that
> loggers be static. I have had occasion to create a class which uses a
> different logger depending on the context in which that class was created.
>
> public class MySomething {
> private final Logger log;
>
> public MySomething() {
> this.log = Logger.getLogger(MySomething.class);
> }
>
> public MySomething(Logger log) {
> this.log = log;
> }
> }

If I have a class hierarchy (for when despite Josh Bloch's recommendation to "prefer composition
to inheritance" I go the other way) I will often put in the parent class:

private final Logger logger = Logger.getLogger(getClass().getName());

This despite the violation of "Don't call an overrideable method during construction."



--
Lew

On 1/4/13 11:36 AM, Lew wrote:
> Daniel Pitts wrote:
>> On the other hand, there generally isn't any real requirement that
>> loggers be static. I have had occasion to create a class which uses a
>> different logger depending on the context in which that class was created.
>>
>> public class MySomething {
>> private final Logger log;
>>
>> public MySomething() {
>> this.log = Logger.getLogger(MySomething.class);
>> }
>>
>> public MySomething(Logger log) {
>> this.log = log;
>> }
>> }
>
> If I have a class hierarchy (for when despite Josh Bloch's recommendation to "prefer composition
> to inheritance" I go the other way) I will often put in the parent class:
>
> private final Logger logger = Logger.getLogger(getClass().getName());
>
> This despite the violation of "Don't call an overrideable method during construction."
>
>
>
getClass() is not overrideable.

On 1/4/2013 7:00 AM, Tomer wrote:
> I love the concept of dependency injection via ctor. it simplifies life and makes testing easy.
> what about logger?
> i usually instantiate it in private static logger = Logger.getLogger(myclass);
> however this is not dependency injection, should I pass the logger into each ctor? this would look wierd... so what to do about loggers and depedency injection?

If you do not use a logger hierarchy, then DI'ing loggers would be easy.

But you typical do so DI is difficult.

Arne

On 1/4/2013 12:18 PM, Kevin McMurtrie wrote:
> In article <kc6rjn$fl2$>,
> markspace <> wrote:
>> Absent some
>> other framework (AOP, for example, or some sort of annotation
>> processing), good old frameworks and libraries solve this problem. Have
>> a look at Apache logging:
>>
>> <http://commons.apache.org/logging/>
>
> I'd say that Java's own logger (java.util.logging) is worth a look too
> if you want modularity. It's easy to plug in custom formatters and
> handlers.

log4j has more than jul.

But if jul has sufficient, then it is obviously fine.

> My biggest peeve about most
> loggers is that they don't indent multi-line log entries nicely

I would recommend avoiding multi-line entries completely.

Arne

On 1/4/2013 1:31 PM, Daniel Pitts wrote:
> On 1/4/13 7:13 AM, markspace wrote:
>> Absent some
>> other framework (AOP, for example, or some sort of annotation
>> processing), good old frameworks and libraries solve this problem. Have
>> a look at Apache logging:
>>
>> <http://commons.apache.org/logging/>
>>
> Loggers can generally be configured externally to their instances.
> Therefor you don't usually need to inject them.
>
> On the other hand, there generally isn't any real requirement that
> loggers be static.

Typically non static logger refs will point to same
logger object.

Arne

On 01/05/2013 12:33 AM, Wayne wrote:
> On 1/4/2013 10:27 PM, Arne Vajhøj wrote:
>> On 1/4/2013 12:18 PM, Kevin McMurtrie wrote:
>>> In article <kc6rjn$fl2$>,
>>> markspace <> wrote:
>>>> Absent some
>>>> other framework (AOP, for example, or some sort of annotation
>>>> processing), good old frameworks and libraries solve this problem. Have
>>>> a look at Apache logging:
>>>>
>>>> <http://commons.apache.org/logging/>
>>>
>>> I'd say that Java's own logger (java.util.logging) is worth a look too
>>> if you want modularity. It's easy to plug in custom formatters and
>>> handlers.
>>
>> log4j has more than jul.
>>
>> But if jul has sufficient, then it is obviously fine.
>>
>>> My biggest peeve about most
>>> loggers is that they don't indent multi-line log entries nicely
>>
>> I would recommend avoiding multi-line entries completely.
>>
>> Arne
>>
>
> Arne is right. Permitting multi-line log entries is a security
> hazard. (It is safe to format log entries with multiple lines; but
> you need to sanitize user data (e.g., strip CR/LF) before including
> such data in your log messages.)
>
Errr, having multiline log entries is not a security hazard, not even
remotely. Splunk certainly doesn't think so - that toolset has extensive
configuration capabilities for handling multiline entries.

What *is* a hazard is if external input to a log entry, that might be
maliciously seeded with linefeeds, is not sanitized/conditioned. Which
is what you said. This is actually a CERT secure coding guideline. Point
being, if you are controlling log entry input, and *you* want a
linefeed, fill your boots. It's not insecure. Just don't let accidental
or malicious ones be supplied across a trust boundary.

I do agree with Arne that multiline should be avoided. Mainly because
it's a PITA. Not everyone is using Splunk.

AHS