> On Tue, Oct 11, 2011 at 2:20 PM, Neil Bartlett <njbartl...@gmail.com>
wrote:
>
>> With DS and bnd annotations, I find the boilerplate for binding to the
log service is quite minimal, i.e.:
>> @Reference(type = '?')
>> protected void setLogService(LogService log) {
>> this.log = log;
>> }
>> However, the annoying boilerplate comes when you simply try to invoke
the service:
>> log.log(LogService.LOG_ERROR, "blah blah");
>
>
>> i.e., why do I have to type the word "log" FIVE times to output *ONE*
log message??
I've stared at this for a while and I still see only four?
1. The identifier of the log instance
2. The name of its log(,) method
3. The name of the service interface which the log instance provides
4. Part of the name of a "constant" exported by that class.
1. is basically due to the fact that in OSGi we always invoke a method of
a service instance. 2. reflects a design decision to have one "log"
method with a severity level parameter rather than one method per severity
level. The same decision also results in 3 and/or 4 ... 3. is there
because the designers followed the general Java practice of using "public
static final" fields to define constants, one of those Java language
features about which the kindest thing you can say is that they are
familiar to C programmers. 4. is clearly pleonastic; no ambiguity with
other "ERROR" declarations is possible, but it may be there because Java
kindly provides the possibility to introduce such ambiguity by means of
the "static import" misfeature. By writing "static import
org.osgi.service.log.LogService.*;" you can eliminate 3. but at the same
time justify 4.
> Thats clearly a design flaw. The log4j way is much cleaner:
> log.error("blah");
The only advantage I see to the OSGi way is that the severity level
doesn't have to be a constant. However I suspect that there are very few
use cases where this advantage outweighs the additional verbosity.
Chris
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
