On May 13, 2009, at 5:39 PM, Vincent Massol wrote:

>
> On May 13, 2009, at 5:30 PM, Sergiu Dumitriu wrote:
>
>> Vincent Massol wrote:
>>> Hi,
>>>
>>> I wanted to see if we could move our LogEnabled lifecycle phase to a
>>> Logging component. I think it's not going to work since this means
>>> injecting a LoggingFactory/LoggingManager component and you need to
>>> call getLogger(this.getClass()) to get access to the Logger which is
>>> awkward.
>>>
>>> What I propose:
>>>
>>> 1) Use SLF4J (drop the slf4j-log4j jar in our WEB-INF/lib so that
>>> SLF4J uses log4j by default)
>>> 2) Drop the JCL/JUL/LOG4j SLF4J legacy jars in our WEB-INF/lib too
>>> and exclude the JCL/JUL/LOG4J jars from our poms so that all third
>>> party logs go to our logging system
>>> 3) Non component code should use a SLF4J's LoggerFactory directly
>>>
>>> 4a) Keep LogEnabled and AbstractLogEnabled for our components
>>> or
>>> 4b) Automatically inject a Logger and a ComponentManager when there
>>> are fields with these types in a component class.
>>>
>>> I like 4b) for its simplicity but I'm worried by the "magical"  
>>> aspect
>>> of it.

Note that if we wanted to remove the magical aspect of it we could  
simply add a @LogEnabled and @Composable annotations and the class  
fields would only be injected if those annotations are found. But  
maybe it's not even necessary.

-Vincent

>> But... Why do we need 4 at all?
>
> You mean use a static and don't do IOC?
>
> I don't like it it has all the problems of static.
>
> -Vincent

_______________________________________________
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to