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