ServiceLoader --> No, Qi4j has better methods for registration of available services and such. So that is not a concern.
It is primarily a matter of get rid of dependencies. With the specific Qi4j interface, I am considering to make it much more "typed", so instead of "warning()" there would be for instance a "entityNotFound(String entityId)" method, which can either be directed to a "warning()" or it could be counting statistics or turn on the 10kV in the developer's chair. And since we have a good AOP model, having many typed methods isn't creating a lot of overhead, as one can easily create a Generic Mixin that handles them all, or just some of them, and stick NoopMixin to terminate all the methods I am not interested in. Loads of opportunities. Stan (if you are listening in), What have you done in the logging compartment of Qi4CS ? Cheers Niclas On Tue, Mar 31, 2015 at 11:18 AM, James Carman <[email protected]> wrote: > You guys know the codebase far better than I do, of course, so I'm > sure it makes perfect sense in that context. From an outsider's > perspective, it just seems silly to put a logging facade over a > logging facade, though. If you already have a service loader (the JDK > already has one) facility and you're cool with using that, then I > suppose that will work. What do you do when there is no logger? Use > a default no-op implementation or something? > > > On Tue, Mar 31, 2015 at 1:04 AM, Niclas Hedhman <[email protected]> > wrote: > > Well, Qi4j prides itself (kind of) to have no dependencies in core. > > Metrics, Serialization, Indexing, Storage and even Migration are > > implemented through the SPI mechanism. The last dependency (ASM) should > > likewise be extracted, so that Android can be supported, and possibly > need > > different code generators for Java 7, 8 and 9. > > > > The pattern that if there is an implementation found through Qi4j's > Service > > mechanism, it is used. For Metrics that is optional, which I think > Logging > > also should be. > > > > As to "controversial" ; Yes, I agree. But I think it is similar in nature > > to "getters", i.e. a deeply held religious belief, that isn't > substantiated > > by reasoning. > > > > For all you ASF buffs, > > In Qi4j, a "getter/setter" is not a "property". When this was raised, it > > was also "controversial", but the model of > > > > Property<String> name(); > > > > is in our opinion "obvious" after the discovery. With "Property", we can > > control whethr mutability "works" in the set() method, it can have tags > and > > other meta information, it can be passed as a "function" to be set and a > > lot more. > > > > I think that after the initial "stigma" and a decent solution found, > > logging will also be non-controversial. > > > > > > Cheers > > Niclas > > > > > > On Tue, Mar 31, 2015 at 6:43 AM, James Carman < > [email protected]> > > wrote: > > > >> I would stick with slf4j since it's designed for this sort of thing, and > >> that's where most folks are these days. > >> > >> On Monday, March 30, 2015, Niclas Hedhman <[email protected]> wrote: > >> > >> > Although codebase is not imported to Apache Zest yet, I am looking at > >> > removing the SLF4J dependency in Core. > >> > > >> > > >> > As the first step, I want to remove the current logging that is in > Core, > >> > simply because it is scattered and primarily in place to support a > couple > >> > of development efforts in the past and not really useful to the user > of > >> > QI4j. > >> > > >> > Second step is to provide a similar extension mechanism for Logging as > >> for > >> > Metrics, and if people plugin a Logging provider, then that will be > used. > >> > > >> > Third step is to migrate the LIbraries and other Extensions to use > this > >> SPI > >> > mechanism. > >> > > >> > Fourth step; Look into "useful" logging from Core, that make sense to > >> > users. > >> > > >> > WDYT? > >> > > >> > > >> > Cheers > >> > -- > >> > Niclas Hedhman, Software Developer > >> > http://www.qi4j.org - New Energy for Java > >> > > >> > > > > > > > > -- > > Niclas Hedhman, Software Developer > > http://www.qi4j.org - New Energy for Java > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java
