polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Discuss; SLF4J in Core
Date Tue, 31 Mar 2015 05:04:04 GMT
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.


On Tue, Mar 31, 2015 at 6:43 AM, James Carman <james@carmanconsulting.com>

> 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 <niclas@hedhman.org> 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
> > 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message