You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Eric Charles <er...@apache.org> on 2011/12/30 20:48:08 UTC
Logging library in our projects
Hi,
I noticed:
- https://issues.apache.org/jira/browse/JAMES-1149 (Replace
commons-logging with jcl-over-slf4j)
- and recent https://issues.apache.org/jira/browse/PROTOCOLS-76 (Remove
dependency on slf4j)
I commented on the PROTOCOLS-76 about the incompatible types which makes
the integration of our different project more complicated (incompatible
logger types in constructor,...).
One option is to standardize for all project to one of the following:
1.- slf4j
2.- java.util.Logger
3.- commons-logging
4.- Our own implementation
5.- ...
I don't have any strong preference for any, but the trend I see in some
(not all) other projects is slf4j.
If we go this way, this will give us probably less work to integrate
server-trunk with protocols-trunk.
...or let each project decide, which will be hell.
WDYT?
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Dhrubo <dh...@gmail.com>.
+1
On Sat, Dec 31, 2011 at 1:11 PM, Young Gu <hy...@gmail.com> wrote:
> > 2.- the uniformisation between all projects.
>
> +1
>
> slf4j is a good candidate, no the dependency nightmare.
>
> Please be free to contact with me for any question or suggestion.
> Thanks & Best Regards .
> ------------------------------**------------------------------**----------------
>
> Young Gu | Software Engineer | http://www.infor.com
>
> On 12/31/2011 03:35 PM, Eric Charles wrote:
>
>> Hello Norman,
>>
>> Yes, I can understand this.
>>
>> So, how are we gonna create a POP3Protocol(**ProtocolHandlerChain,
>> ProtocolConfiguration, Logger) from server which uses slf4j?
>>
>> We need to give as third parameter a org.apache.james.protocols.**
>> api.Logger.
>>
>> An adapter between org.slf4j.Logger and org.apache.james.protocols.**api.Logger
>> could do the job, even if find this a bit overhead.
>>
>> When integrating server and protocols trunk a few days before, I thus
>> though to these 2 options:
>> 1.- the adapter.
>> 2.- the uniformisation between all projects.
>>
>> but didn't know where to go..., this is the reason for this thread :)
>> Maybe you have a third option in mind such as having two completely
>> separated logging mechanism when running protocols in server?
>>
>> Thx,
>>
>> Eric
>>
>>
>> On 30/12/11 21:25, Norman Maurer wrote:
>>
>>> Hi Eric,
>>>
>>> I pulled out the slf4j dependency in protocols as its really sexy to
>>> have zero dependencies in the API. We even only used the Logger interface
>>> which made it even more clear to me that we should use our own logger
>>> interface.
>>>
>>> Our implementations and so consumer of the API will still use slf4j.
>>>
>>> We did the same in jSPF.
>>>
>>> Hope it helps,
>>> Norman
>>>
>>> Von meinem iPhone gesendet
>>>
>>> Am 30.12.2011 um 20:48 schrieb Eric Charles<er...@apache.org>:
>>>
>>> Hi,
>>>>
>>>> I noticed:
>>>>
>>>> - https://issues.apache.org/**jira/browse/JAMES-1149<https://issues.apache.org/jira/browse/JAMES-1149>(Replace commons-logging with jcl-over-slf4j)
>>>> - and recent https://issues.apache.org/**jira/browse/PROTOCOLS-76<https://issues.apache.org/jira/browse/PROTOCOLS-76>(Remove dependency on slf4j)
>>>>
>>>> I commented on the PROTOCOLS-76 about the incompatible types which
>>>> makes the integration of our different project more complicated
>>>> (incompatible logger types in constructor,...).
>>>>
>>>> One option is to standardize for all project to one of the following:
>>>> 1.- slf4j
>>>> 2.- java.util.Logger
>>>> 3.- commons-logging
>>>> 4.- Our own implementation
>>>> 5.- ...
>>>>
>>>> I don't have any strong preference for any, but the trend I see in some
>>>> (not all) other projects is slf4j.
>>>> If we go this way, this will give us probably less work to integrate
>>>> server-trunk with protocols-trunk.
>>>>
>>>> ...or let each project decide, which will be hell.
>>>>
>>>> WDYT?
>>>> --
>>>> eric | http://about.echarles.net | @echarles
>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.**apache.org<se...@james.apache.org>
>>>> For additional commands, e-mail: server-dev-help@james.apache.**org<se...@james.apache.org>
>>>>
>>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.**apache.org<se...@james.apache.org>
>>> For additional commands, e-mail: server-dev-help@james.apache.**org<se...@james.apache.org>
>>>
>>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.**apache.org<se...@james.apache.org>
> For additional commands, e-mail: server-dev-help@james.apache.**org<se...@james.apache.org>
>
>
--
Kind Regards... Dhrubo
<http://www.linkedin.com/in/dhrubo>
Re: Logging library in our projects
Posted by Young Gu <hy...@gmail.com>.
> 2.- the uniformisation between all projects.
+1
slf4j is a good candidate, no the dependency nightmare.
Please be free to contact with me for any question or suggestion.
Thanks & Best Regards .
----------------------------------------------------------------------------
Young Gu | Software Engineer | http://www.infor.com
On 12/31/2011 03:35 PM, Eric Charles wrote:
> Hello Norman,
>
> Yes, I can understand this.
>
> So, how are we gonna create a POP3Protocol(ProtocolHandlerChain,
> ProtocolConfiguration, Logger) from server which uses slf4j?
>
> We need to give as third parameter a
> org.apache.james.protocols.api.Logger.
>
> An adapter between org.slf4j.Logger and
> org.apache.james.protocols.api.Logger could do the job, even if find
> this a bit overhead.
>
> When integrating server and protocols trunk a few days before, I thus
> though to these 2 options:
> 1.- the adapter.
> 2.- the uniformisation between all projects.
>
> but didn't know where to go..., this is the reason for this thread :)
> Maybe you have a third option in mind such as having two completely
> separated logging mechanism when running protocols in server?
>
> Thx,
>
> Eric
>
>
> On 30/12/11 21:25, Norman Maurer wrote:
>> Hi Eric,
>>
>> I pulled out the slf4j dependency in protocols as its really sexy to
>> have zero dependencies in the API. We even only used the Logger
>> interface which made it even more clear to me that we should use our
>> own logger interface.
>>
>> Our implementations and so consumer of the API will still use slf4j.
>>
>> We did the same in jSPF.
>>
>> Hope it helps,
>> Norman
>>
>> Von meinem iPhone gesendet
>>
>> Am 30.12.2011 um 20:48 schrieb Eric Charles<er...@apache.org>:
>>
>>> Hi,
>>>
>>> I noticed:
>>>
>>> - https://issues.apache.org/jira/browse/JAMES-1149 (Replace
>>> commons-logging with jcl-over-slf4j)
>>> - and recent https://issues.apache.org/jira/browse/PROTOCOLS-76
>>> (Remove dependency on slf4j)
>>>
>>> I commented on the PROTOCOLS-76 about the incompatible types which
>>> makes the integration of our different project more complicated
>>> (incompatible logger types in constructor,...).
>>>
>>> One option is to standardize for all project to one of the following:
>>> 1.- slf4j
>>> 2.- java.util.Logger
>>> 3.- commons-logging
>>> 4.- Our own implementation
>>> 5.- ...
>>>
>>> I don't have any strong preference for any, but the trend I see in
>>> some (not all) other projects is slf4j.
>>> If we go this way, this will give us probably less work to integrate
>>> server-trunk with protocols-trunk.
>>>
>>> ...or let each project decide, which will be hell.
>>>
>>> WDYT?
>>> --
>>> eric | http://about.echarles.net | @echarles
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Stefano Bagnara <ap...@bago.org>.
2012/1/1 Eric Charles <er...@apache.org>:
> Hi Stefano,
>
> I agree with your arguments as with mine :)
> I think there is not only one valid answer to this.
So True!
> If there was one, everybody would do that way.
Not so sure about this ;-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Eric Charles <er...@apache.org>.
Hi Stefano,
I agree with your arguments as with mine :)
I think there is not only one valid answer to this. If there was one,
everybody would do that way.
Eric
On 31/12/11 16:32, Stefano Bagnara wrote:
> 2011/12/31 Eric Charles<er...@apache.org>:
>> Hi,
>>
>> As said, I am more in favor of uniformisation across projects, but I'm also
>> fine with an adapter.
>
> (I'm not trying to push my idea, but instead trying to explain you my
> thinking, as we talked about this a bunch of times in the past years)
>
> Logging is a very peculiar "aspect" and while in the past 10 years
> everything moved to dependency injection and separation of concerns,
> logging did not.
>
> You can't bring this uniformisation to every user's projects. Most of
> our users use only one of our products. Most jspf users only use jspf
> from Apache James. Most mime4j users only use mime4j from Apache James
> and so on.
> So uniformisation doesn't give anything to them and instead they would
> have the same issue that you now try to solve with our use case (as
> James Server instead uses all of them).
>
> Correct me if I'm wrong, but let's say someone wants to take james 2.3
> branch and make a 2.x release just adding an updated smtp component
> based on our new protocols libraries: the slf4j dependency would add
> pain for them as there is no way to bridge slf4j to avalon (while the
> opposite is really easy).
>
>> I'm seeing the current 'server' projects more like components/librairies
>> like the other libraries, thus tend to apply the same rules to them.
>
> I'm not aware of downstream users for the single modules of server
> product and I don't see a clear use case for that, so maybe it doesn't
> worth using the same adapter approach there.
> Furthermore most of the server components already have many
> dependencies on other components, so they are not really usable
> without inheriting many other stuff. This is not the same thing as
> jspf, mime4j, protocols so I don't think we should treat them as the
> same thing.
>
> If/when we'll identify some james server component that can be
> promoted to a generic library then we'll have to deal with the removal
> of many dependencies and in that case we will also deal with the
> logging aspect.
>
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Stefano Bagnara <ap...@bago.org>.
2011/12/31 Eric Charles <er...@apache.org>:
> Hi,
>
> As said, I am more in favor of uniformisation across projects, but I'm also
> fine with an adapter.
(I'm not trying to push my idea, but instead trying to explain you my
thinking, as we talked about this a bunch of times in the past years)
Logging is a very peculiar "aspect" and while in the past 10 years
everything moved to dependency injection and separation of concerns,
logging did not.
You can't bring this uniformisation to every user's projects. Most of
our users use only one of our products. Most jspf users only use jspf
from Apache James. Most mime4j users only use mime4j from Apache James
and so on.
So uniformisation doesn't give anything to them and instead they would
have the same issue that you now try to solve with our use case (as
James Server instead uses all of them).
Correct me if I'm wrong, but let's say someone wants to take james 2.3
branch and make a 2.x release just adding an updated smtp component
based on our new protocols libraries: the slf4j dependency would add
pain for them as there is no way to bridge slf4j to avalon (while the
opposite is really easy).
> I'm seeing the current 'server' projects more like components/librairies
> like the other libraries, thus tend to apply the same rules to them.
I'm not aware of downstream users for the single modules of server
product and I don't see a clear use case for that, so maybe it doesn't
worth using the same adapter approach there.
Furthermore most of the server components already have many
dependencies on other components, so they are not really usable
without inheriting many other stuff. This is not the same thing as
jspf, mime4j, protocols so I don't think we should treat them as the
same thing.
If/when we'll identify some james server component that can be
promoted to a generic library then we'll have to deal with the removal
of many dependencies and in that case we will also deal with the
logging aspect.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Eric Charles <er...@apache.org>.
Hi,
As said, I am more in favor of uniformisation across projects, but I'm
also fine with an adapter.
I'm seeing the current 'server' projects more like components/librairies
like the other libraries, thus tend to apply the same rules to them.
Thx,
Eric
On 31/12/11 15:23, Norman Maurer wrote:
> Hi Stefano,
>
> I would even put the slf4j adapter into the api package. Then make it optional as you said. This will also work with osgi.
>
> Bye,
> Norman
>
>
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Norman Maurer <no...@apache.org>.
Hi Stefano,
I would even put the slf4j adapter into the api package. Then make it optional as you said. This will also work with osgi.
Bye,
Norman
--
Norman Maurer
Am Samstag, 31. Dezember 2011 um 15:03 schrieb Stefano Bagnara:
> 2011/12/31 Eric Charles <eric@apache.org (mailto:eric@apache.org)>:
> > Hello Norman,
> >
> > Yes, I can understand this.
> >
> > So, how are we gonna create a POP3Protocol(ProtocolHandlerChain,
> > ProtocolConfiguration, Logger) from server which uses slf4j?
> >
> > We need to give as third parameter a org.apache.james.protocols.api.Logger.
> >
> > An adapter between org.slf4j.Logger and
> > org.apache.james.protocols.api.Logger could do the job, even if find this a
> > bit overhead.
> >
> > When integrating server and protocols trunk a few days before, I thus though
> > to these 2 options:
> > 1.- the adapter.
> > 2.- the uniformisation between all projects.
> >
> > but didn't know where to go..., this is the reason for this thread :)
> > Maybe you have a third option in mind such as having two completely
> > separated logging mechanism when running protocols in server?
> >
>
>
> IMO we should go with #1 (using a private Logger interface and then
> use an adapter to slf4j).
>
> I also think that an slf4j adapter could be provided direclty in the
> protocols project and used as an optional dependency (so you don't
> have to write the adapter in every project).
> The "right" approach would be to have a protocols module with the
> slf4j adapter, but IMO a module for a single class is too much, so
> maybe we can simply put the adapter in the netty module or in the api
> module and then declare the slf4j dependency as optional, so that
> users of the library will decide if they want to use the slf4j logger
> or instead provide their own implementation.
>
> I'm not sure if this plays well with OSGi.
>
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org (mailto:server-dev-unsubscribe@james.apache.org)
> For additional commands, e-mail: server-dev-help@james.apache.org (mailto:server-dev-help@james.apache.org)
>
>
Re: Logging library in our projects
Posted by Norman Maurer <no...@googlemail.com>.
Like I said, optional dependency works quite well with osgi. We did the same in netty.
Bye
Norman
Sent from my iPhone. Excuse any typos....
Am 31.12.2011 um 15:52 schrieb Stefano Bagnara <ap...@bago.org>:
> 2011/12/31 Eric Charles <er...@apache.org>:
>> On 31/12/11 15:03, Stefano Bagnara wrote:
>>>>
>>>> but didn't know where to go..., this is the reason for this thread :)
>>>> Maybe you have a third option in mind such as having two completely
>>>> separated logging mechanism when running protocols in server?
>>>
>>>
>>> IMO we should go with #1 (using a private Logger interface and then
>>> use an adapter to slf4j).
>>>
>>
>> Hi Stefano,
>> I am more in favor of #2 to keep things simple.
>> For which reason do you prefer #1?
>
> Because as a user or a library I prefer to write an adapter (5
> minutes) instead of being forced to use a given logging toolkit.
>
> History clearly shown us that choosing a logging framework is never a
> good idea: just count how many products moved from one logger to
> another in the last 10 years. I bet 90% had to do that! So if a couple
> of interfaces allow us to encapsulate logging I think it is much
> better.
>
> Also, encapsulating it for a library gives one more opportunity as it
> allows the library user to intercept/monitor/alter the log calls.
> The best thing would be to name the specific logger interface
> something like "Monitor" (and not Logger) and use domain specific
> calls that will be converted to log calls only by the wrapper.
>
> We did this in mime4j and it worked fine (it even allowed us to
> introduce new features using the "monitor" in a special way to deal
> with strict/lenient parsing)!
>
> So, IMO, the "best practice" is that libraries should not provide
> logging at all. Logging is needed by applications (and not libraries)
> because the application user is an human and can't interface
> differently, instead library users are applications (or other
> libraries) so they can communicate much better than using a log file.
>
>>> I also think that an slf4j adapter could be provided direclty in the
>>> protocols project and used as an optional dependency (so you don't
>>> have to write the adapter in every project).
>>> The "right" approach would be to have a protocols module with the
>>> slf4j adapter, but IMO a module for a single class is too much, so
>>> maybe we can simply put the adapter in the netty module or in the api
>>> module and then declare the slf4j dependency as optional, so that
>>> users of the library will decide if they want to use the slf4j logger
>>> or instead provide their own implementation.
>>>
>>
>> Yes, it would be crazy to ask to all our library users to reimplement that
>> adapter.
>>
>> To open the discussion more, I already saw (don't remember which ones) needs
>> for a "james-common" that could be useful to all our projects. Some logging,
>> streaming,... classes could perfectly fit there.
>
> I don't like the james-common solution as it would be one more
> dependency anyway and it doesn't make sense if it can be reduced by
> just adding 2 classes in each library.
> All of this PITA could have been skipped if only java.util.Logging
> provided an interface or commons-logging provided also an interface
> for the logger factory, but this never happened and I guess it won't
> happen anymore, so we are forced to do that.
>
>>> I'm not sure if this plays well with OSGi.
>>>
>>
>> No idea... but I don't see why it couldn't
>
> I have limited experience with OSGi but I remember optional
> dependencies created me some issue, but maybe this is because I was
> not skilled enough to deal with that... so I hope someone else
> (Norman) will answer this doubt.
>
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Norman Maurer <no...@googlemail.com>.
Hi there,
I will review the Monitor usage in mime4j and then come back to you..
Have fun,
Norman
Von meinem iPad gesendet
Am 31.12.2011 um 18:10 schrieb Stefano Bagnara <ap...@bago.org>:
> 2011/12/31 Norman Maurer <no...@apache.org>:
>> Hi Stefano,
>>
>> to be honest I like the "monitor" idea but its a bit hard to implement in a useful way in the ProtocolSession. This is because users will write their own ProtocolHandler implementation and want to log different things there. How would you fulfill the need of that with a "monitor" ?
>
> monitor.error()
> monitor.warn()
> monitor.debug()
>
> ;-)
>
> You can also give an option to the monitor to throw an exception to
> tell the monitored object that you didn't like what it told you. (but
> this would need addind at least some message identifier to avoid text
> pattern matching).
> I don't think we need this, but never analyzed the code with this idea in mind.
>
> Stefano
>
> PS: have to go preparing for year end party!!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Stefano Bagnara <ap...@bago.org>.
2011/12/31 Norman Maurer <no...@apache.org>:
> Hi Stefano,
>
> to be honest I like the "monitor" idea but its a bit hard to implement in a useful way in the ProtocolSession. This is because users will write their own ProtocolHandler implementation and want to log different things there. How would you fulfill the need of that with a "monitor" ?
monitor.error()
monitor.warn()
monitor.debug()
;-)
You can also give an option to the monitor to throw an exception to
tell the monitored object that you didn't like what it told you. (but
this would need addind at least some message identifier to avoid text
pattern matching).
I don't think we need this, but never analyzed the code with this idea in mind.
Stefano
PS: have to go preparing for year end party!!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Norman Maurer <no...@apache.org>.
Hi Stefano,
to be honest I like the "monitor" idea but its a bit hard to implement in a useful way in the ProtocolSession. This is because users will write their own ProtocolHandler implementation and want to log different things there. How would you fulfill the need of that with a "monitor" ?
Thanks,
Norman
--
Norman Maurer
Am Samstag, 31. Dezember 2011 um 17:47 schrieb Stefano Bagnara:
> 2011/12/31 Eric Charles <eric@apache.org (mailto:eric@apache.org)>:
> > A Logger is a logger.
>
>
> I agree, but then I would say that most times we abuse "loggers" :-)
>
> > For monitoring purposes, I would not generalize the Logger to be a Monitor.
> > But this is way beyond our discussion on the logging libraries :)
> >
>
>
> Apple vs Oranges or better Aspects vs Pattern. Why can't you implement
> the Logging aspect of a given actor using a Monitor pattern?
> I find that if you use a monitor instead of plain "local logging" you
> also think better to the meaning of what you want to log and to the
> target of the log (user? developer? bug hunter?).
> Also a monitor can help during unit tests, instead "standard logging"
> doesn't help at all.
>
> > mmh, for me everything is a library and a library needs logging.
>
> I don't agree.
> A book is a sorted collection of pages but if you take a bunch of
> random pages and add a number to it you can do something that looks
> like a book but I wouldn't call "a book".
>
> So a library is a very specific subset of a "bunch of classes".
> We could also create 2 distinct worlds of libraries: libraries using
> IO and libraries not using IO.
>
> > An application is just a composition of libraries.
>
> An application is another subset of a "bunch of classes", using IO,
> and providing a "main" function. You don't need composition to create
> an application, instead you need a "main" to do that!
> I can't really call every application "a library".
> Every subset needs special consideration, so I'm not ready to find a
> "one fit them all" solution.
>
> (I'm not saying that mine explanation of words is better than your,
> just explaining how I used words, when I used them)
>
> > If I follow your reasoning, nor protocols nor server would need logging?
>
> In my language, server is an application and needs logging. protocols
> is a library and should better use monitoring instead of logging. If
> server wants to log something happening in protocols then can simply
> monitor the procotols and log monitored things.
>
> > Also, logging can be configured with appenders to log in database, jms
> > queues... and even in mails (for error level for example) :)
> >
>
>
> Sure, but it is not really easy to add "monitorability" ta library
> that makes use of logging.
> Instead is easy to add "logging" to a library that use a monitor pattern.
>
> So if we use a monitor like pattern (a dependency inject Logger
> interface , despite the name, is an implementation of a monitor) we
> allow users to define what to do.
>
> I love the approach of pico-container loggin (unfortunately I guess it
> is a dead project). I find this page really influenced my thought:
> http://svn.codehaus.org/picocontainer/java/2.x/trunk/logging/src/site/content/monitor-pattern.html
>
> > > I don't like the james-common solution as it would be one more
> > > dependency anyway and it doesn't make sense if it can be reduced by
> > > just adding 2 classes in each library.
> > >
> >
> >
> > 2 classes for logging, 3 more classes for something else, that could save us
> > some code and maintenance, but yes, it also needs a release, that's not
> > piece-of-cake...
> >
>
>
> You would end up with a "catch-all" module where you put everything
> that is used by at least 2 modules.
> After few years using this approach you will have a 2MB catch-all
> library and your protocol library will depend on "james-catchall", a
> 2MB jar from which we only use 2 logging classes.
>
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org (mailto:server-dev-unsubscribe@james.apache.org)
> For additional commands, e-mail: server-dev-help@james.apache.org (mailto:server-dev-help@james.apache.org)
>
>
Re: Logging library in our projects
Posted by Eric Charles <er...@apache.org>.
Hi,
I started the integration of protocols trunk in server (still 55 errors
and downcounting).
This gives funny adaptation like this (in ImapChannelUpstreamHandler)
private Logger getLogger(Channel channel) {
return new Slf4jLoggerAdapter(new ProtocolSessionLogger("" +
channel.getId(), new ProtocolLoggerAdapter(logger)));
}
fyi,
Eric
On 02/01/12 09:09, Eric Charles wrote:
> On 02/01/12 08:56, Eric Charles wrote:
>> As Norman, I will look to the Monitor usage in mime4j and we could try
>> to go that way with a Slf4jLoggerAdapter provided in protocols-api (btw,
>> this will have as consequence to re-add the dependency to slf4j in
>> protocols-api's pom).
>>
>
> btw, already done by Norman with optional slf4j dependency.
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Eric Charles <er...@apache.org>.
On 02/01/12 08:56, Eric Charles wrote:
> As Norman, I will look to the Monitor usage in mime4j and we could try
> to go that way with a Slf4jLoggerAdapter provided in protocols-api (btw,
> this will have as consequence to re-add the dependency to slf4j in
> protocols-api's pom).
>
btw, already done by Norman with optional slf4j dependency.
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Eric Charles <er...@apache.org>.
Thx for the discussion Stefano.
(see my comments in line).
As Norman, I will look to the Monitor usage in mime4j and we could try
to go that way with a Slf4jLoggerAdapter provided in protocols-api (btw,
this will have as consequence to re-add the dependency to slf4j in
protocols-api's pom).
Eric
On 02/01/12 01:10, Stefano Bagnara wrote:
> 2012/1/1 Eric Charles<er...@apache.org>:
>> "Better Java Development with AspectJ" (I think the ppt is no more online)
>> from PARC clearly points the logging as a perfect candidate to aspect
>> programming.
>
> I saw logging always as a case in AOP books, but I never really saw a
> real project using AOP for logging, so I can't tell if it works fine
> or not. IMO most logging happens inside methods and not
> before/after/around so I don't expect AOP to solve the logging
> problem, but I'd be happy to learn I'm wrong here.
>
Same here.
>> A bunch of classes that can be reused in one than one use case.
>> Why distinguish IO vs non-IO ?
>
> I'm used to do this. IO is a "dependency", and an "hard" one for a library.
> Maybe this has something to do with my studies in functional programming.
>
So true.
>> So an application is a library with a class with a main :) (just kidding)
>
> An apple is a fruit.
> A banana is a yellow fruit.
> A yellow apple is a yellow fruit.
> So a yellow apple is a banana.... not sure ;-)
>
I don't know, but I like to eat apple, banana and oranges, although
oranges are not yellow :)
> Happy new year!
All the best!
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Stefano Bagnara <ap...@bago.org>.
2012/1/1 Eric Charles <er...@apache.org>:
> "Better Java Development with AspectJ" (I think the ppt is no more online)
> from PARC clearly points the logging as a perfect candidate to aspect
> programming.
I saw logging always as a case in AOP books, but I never really saw a
real project using AOP for logging, so I can't tell if it works fine
or not. IMO most logging happens inside methods and not
before/after/around so I don't expect AOP to solve the logging
problem, but I'd be happy to learn I'm wrong here.
> A bunch of classes that can be reused in one than one use case.
> Why distinguish IO vs non-IO ?
I'm used to do this. IO is a "dependency", and an "hard" one for a library.
Maybe this has something to do with my studies in functional programming.
> So an application is a library with a class with a main :) (just kidding)
An apple is a fruit.
A banana is a yellow fruit.
A yellow apple is a yellow fruit.
So a yellow apple is a banana.... not sure ;-)
Happy new year!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Eric Charles <er...@apache.org>.
On 31/12/11 17:47, Stefano Bagnara wrote:
> 2011/12/31 Eric Charles<er...@apache.org>:
>> A Logger is a logger.
>
> I agree, but then I would say that most times we abuse "loggers" :-)
>
sometimes we abuse, and often we are quite happy to have them.
How many times don't we ask our users to raise the debug level from info
to debug :)
>> For monitoring purposes, I would not generalize the Logger to be a Monitor.
>> But this is way beyond our discussion on the logging libraries :)
>
> Apple vs Oranges or better Aspects vs Pattern. Why can't you implement
> the Logging aspect of a given actor using a Monitor pattern?
> I find that if you use a monitor instead of plain "local logging" you
> also think better to the meaning of what you want to log and to the
> target of the log (user? developer? bug hunter?).
> Also a monitor can help during unit tests, instead "standard logging"
> doesn't help at all.
>
We can indeed extend the discussion and see how we could better
architecture/design our logging functions.
"Better Java Development with AspectJ" (I think the ppt is no more
online) from PARC clearly points the logging as a perfect candidate to
aspect programming.
I didn't remind the Monitor pattern, so I took back my books and found
in the "Pattern oriented software architecture" a Monitor Object pattern
to "synchronize method execution".
So to design such an architecture we could also take into consideration
aspect programing, and be sure that a Monitor will not be confusing with
the 'object monitor' responsible to manage the locks. btw Monitor is
also used in JMX world, and in that way it could have more sense.
>> mmh, for me everything is a library and a library needs logging.
>
> I don't agree.
> A book is a sorted collection of pages but if you take a bunch of
> random pages and add a number to it you can do something that looks
> like a book but I wouldn't call "a book".
>
> So a library is a very specific subset of a "bunch of classes".
> We could also create 2 distinct worlds of libraries: libraries using
> IO and libraries not using IO.
>
A bunch of classes that can be reused in one than one use case.
Why distinguish IO vs non-IO ?
>> An application is just a composition of libraries.
>
> An application is another subset of a "bunch of classes", using IO,
> and providing a "main" function. You don't need composition to create
> an application, instead you need a "main" to do that!
> I can't really call every application "a library".
> Every subset needs special consideration, so I'm not ready to find a
> "one fit them all" solution.
>
> (I'm not saying that mine explanation of words is better than your,
> just explaining how I used words, when I used them)
>
So an application is a library with a class with a main :) (just kidding)
>> If I follow your reasoning, nor protocols nor server would need logging?
>
> In my language, server is an application and needs logging. protocols
> is a library and should better use monitoring instead of logging. If
> server wants to log something happening in protocols then can simply
> monitor the procotols and log monitored things.
>
>> Also, logging can be configured with appenders to log in database, jms
>> queues... and even in mails (for error level for example) :)
>
> Sure, but it is not really easy to add "monitorability" ta library
> that makes use of logging.
> Instead is easy to add "logging" to a library that use a monitor pattern.
>
> So if we use a monitor like pattern (a dependency inject Logger
> interface , despite the name, is an implementation of a monitor) we
> allow users to define what to do.
>
> I love the approach of pico-container loggin (unfortunately I guess it
> is a dead project). I find this page really influenced my thought:
> http://svn.codehaus.org/picocontainer/java/2.x/trunk/logging/src/site/content/monitor-pattern.html
>
Seems like pico container has/had much to give.
>>> I don't like the james-common solution as it would be one more
>>> dependency anyway and it doesn't make sense if it can be reduced by
>>> just adding 2 classes in each library.
>>
>> 2 classes for logging, 3 more classes for something else, that could save us
>> some code and maintenance, but yes, it also needs a release, that's not
>> piece-of-cake...
>
> You would end up with a "catch-all" module where you put everything
> that is used by at least 2 modules.
> After few years using this approach you will have a 2MB catch-all
> library and your protocol library will depend on "james-catchall", a
> 2MB jar from which we only use 2 logging classes.
>
I don't push for james-common atm, but what could be there is just what
developers decide to put. Good or bad design/content is applicable for
any library, not only a potential james-common.
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Stefano Bagnara <ap...@bago.org>.
2011/12/31 Eric Charles <er...@apache.org>:
> A Logger is a logger.
I agree, but then I would say that most times we abuse "loggers" :-)
> For monitoring purposes, I would not generalize the Logger to be a Monitor.
> But this is way beyond our discussion on the logging libraries :)
Apple vs Oranges or better Aspects vs Pattern. Why can't you implement
the Logging aspect of a given actor using a Monitor pattern?
I find that if you use a monitor instead of plain "local logging" you
also think better to the meaning of what you want to log and to the
target of the log (user? developer? bug hunter?).
Also a monitor can help during unit tests, instead "standard logging"
doesn't help at all.
> mmh, for me everything is a library and a library needs logging.
I don't agree.
A book is a sorted collection of pages but if you take a bunch of
random pages and add a number to it you can do something that looks
like a book but I wouldn't call "a book".
So a library is a very specific subset of a "bunch of classes".
We could also create 2 distinct worlds of libraries: libraries using
IO and libraries not using IO.
> An application is just a composition of libraries.
An application is another subset of a "bunch of classes", using IO,
and providing a "main" function. You don't need composition to create
an application, instead you need a "main" to do that!
I can't really call every application "a library".
Every subset needs special consideration, so I'm not ready to find a
"one fit them all" solution.
(I'm not saying that mine explanation of words is better than your,
just explaining how I used words, when I used them)
> If I follow your reasoning, nor protocols nor server would need logging?
In my language, server is an application and needs logging. protocols
is a library and should better use monitoring instead of logging. If
server wants to log something happening in protocols then can simply
monitor the procotols and log monitored things.
> Also, logging can be configured with appenders to log in database, jms
> queues... and even in mails (for error level for example) :)
Sure, but it is not really easy to add "monitorability" ta library
that makes use of logging.
Instead is easy to add "logging" to a library that use a monitor pattern.
So if we use a monitor like pattern (a dependency inject Logger
interface , despite the name, is an implementation of a monitor) we
allow users to define what to do.
I love the approach of pico-container loggin (unfortunately I guess it
is a dead project). I find this page really influenced my thought:
http://svn.codehaus.org/picocontainer/java/2.x/trunk/logging/src/site/content/monitor-pattern.html
>> I don't like the james-common solution as it would be one more
>> dependency anyway and it doesn't make sense if it can be reduced by
>> just adding 2 classes in each library.
>
> 2 classes for logging, 3 more classes for something else, that could save us
> some code and maintenance, but yes, it also needs a release, that's not
> piece-of-cake...
You would end up with a "catch-all" module where you put everything
that is used by at least 2 modules.
After few years using this approach you will have a 2MB catch-all
library and your protocol library will depend on "james-catchall", a
2MB jar from which we only use 2 logging classes.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Eric Charles <er...@apache.org>.
Hi Stefano, Comments inline.
Eric
On 31/12/11 15:52, Stefano Bagnara wrote:
> 2011/12/31 Eric Charles<er...@apache.org>:
>> On 31/12/11 15:03, Stefano Bagnara wrote:
>>>>
>>>> but didn't know where to go..., this is the reason for this thread :)
>>>> Maybe you have a third option in mind such as having two completely
>>>> separated logging mechanism when running protocols in server?
>>>
>>>
>>> IMO we should go with #1 (using a private Logger interface and then
>>> use an adapter to slf4j).
>>>
>>
>> Hi Stefano,
>> I am more in favor of #2 to keep things simple.
>> For which reason do you prefer #1?
>
> Because as a user or a library I prefer to write an adapter (5
> minutes) instead of being forced to use a given logging toolkit.
>
> History clearly shown us that choosing a logging framework is never a
> good idea: just count how many products moved from one logger to
> another in the last 10 years. I bet 90% had to do that! So if a couple
> of interfaces allow us to encapsulate logging I think it is much
> better.
>
Makes sense.
> Also, encapsulating it for a library gives one more opportunity as it
> allows the library user to intercept/monitor/alter the log calls.
> The best thing would be to name the specific logger interface
> something like "Monitor" (and not Logger) and use domain specific
> calls that will be converted to log calls only by the wrapper.
>
> We did this in mime4j and it worked fine (it even allowed us to
> introduce new features using the "monitor" in a special way to deal
> with strict/lenient parsing)!
>
A Logger is a logger.
For monitoring purposes, I would not generalize the Logger to be a
Monitor. But this is way beyond our discussion on the logging libraries :)
> So, IMO, the "best practice" is that libraries should not provide
> logging at all. Logging is needed by applications (and not libraries)
> because the application user is an human and can't interface
> differently, instead library users are applications (or other
> libraries) so they can communicate much better than using a log file.
>
mmh, for me everything is a library and a library needs logging. An
application is just a composition of libraries.
If I follow your reasoning, nor protocols nor server would need logging?
Also, logging can be configured with appenders to log in database, jms
queues... and even in mails (for error level for example) :)
>>> I also think that an slf4j adapter could be provided direclty in the
>>> protocols project and used as an optional dependency (so you don't
>>> have to write the adapter in every project).
>>> The "right" approach would be to have a protocols module with the
>>> slf4j adapter, but IMO a module for a single class is too much, so
>>> maybe we can simply put the adapter in the netty module or in the api
>>> module and then declare the slf4j dependency as optional, so that
>>> users of the library will decide if they want to use the slf4j logger
>>> or instead provide their own implementation.
>>>
>>
>> Yes, it would be crazy to ask to all our library users to reimplement that
>> adapter.
>>
>> To open the discussion more, I already saw (don't remember which ones) needs
>> for a "james-common" that could be useful to all our projects. Some logging,
>> streaming,... classes could perfectly fit there.
>
> I don't like the james-common solution as it would be one more
> dependency anyway and it doesn't make sense if it can be reduced by
> just adding 2 classes in each library.
2 classes for logging, 3 more classes for something else, that could
save us some code and maintenance, but yes, it also needs a release,
that's not piece-of-cake...
> All of this PITA could have been skipped if only java.util.Logging
> provided an interface or commons-logging provided also an interface
> for the logger factory, but this never happened and I guess it won't
> happen anymore, so we are forced to do that.
>
:/
>>> I'm not sure if this plays well with OSGi.
>>>
>>
>> No idea... but I don't see why it couldn't
>
> I have limited experience with OSGi but I remember optional
> dependencies created me some issue, but maybe this is because I was
> not skilled enough to deal with that... so I hope someone else
> (Norman) will answer this doubt.
>
That may be the price to pay for flexibility.
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Stefano Bagnara <ap...@bago.org>.
2011/12/31 Eric Charles <er...@apache.org>:
> On 31/12/11 15:03, Stefano Bagnara wrote:
>>>
>>> but didn't know where to go..., this is the reason for this thread :)
>>> Maybe you have a third option in mind such as having two completely
>>> separated logging mechanism when running protocols in server?
>>
>>
>> IMO we should go with #1 (using a private Logger interface and then
>> use an adapter to slf4j).
>>
>
> Hi Stefano,
> I am more in favor of #2 to keep things simple.
> For which reason do you prefer #1?
Because as a user or a library I prefer to write an adapter (5
minutes) instead of being forced to use a given logging toolkit.
History clearly shown us that choosing a logging framework is never a
good idea: just count how many products moved from one logger to
another in the last 10 years. I bet 90% had to do that! So if a couple
of interfaces allow us to encapsulate logging I think it is much
better.
Also, encapsulating it for a library gives one more opportunity as it
allows the library user to intercept/monitor/alter the log calls.
The best thing would be to name the specific logger interface
something like "Monitor" (and not Logger) and use domain specific
calls that will be converted to log calls only by the wrapper.
We did this in mime4j and it worked fine (it even allowed us to
introduce new features using the "monitor" in a special way to deal
with strict/lenient parsing)!
So, IMO, the "best practice" is that libraries should not provide
logging at all. Logging is needed by applications (and not libraries)
because the application user is an human and can't interface
differently, instead library users are applications (or other
libraries) so they can communicate much better than using a log file.
>> I also think that an slf4j adapter could be provided direclty in the
>> protocols project and used as an optional dependency (so you don't
>> have to write the adapter in every project).
>> The "right" approach would be to have a protocols module with the
>> slf4j adapter, but IMO a module for a single class is too much, so
>> maybe we can simply put the adapter in the netty module or in the api
>> module and then declare the slf4j dependency as optional, so that
>> users of the library will decide if they want to use the slf4j logger
>> or instead provide their own implementation.
>>
>
> Yes, it would be crazy to ask to all our library users to reimplement that
> adapter.
>
> To open the discussion more, I already saw (don't remember which ones) needs
> for a "james-common" that could be useful to all our projects. Some logging,
> streaming,... classes could perfectly fit there.
I don't like the james-common solution as it would be one more
dependency anyway and it doesn't make sense if it can be reduced by
just adding 2 classes in each library.
All of this PITA could have been skipped if only java.util.Logging
provided an interface or commons-logging provided also an interface
for the logger factory, but this never happened and I guess it won't
happen anymore, so we are forced to do that.
>> I'm not sure if this plays well with OSGi.
>>
>
> No idea... but I don't see why it couldn't
I have limited experience with OSGi but I remember optional
dependencies created me some issue, but maybe this is because I was
not skilled enough to deal with that... so I hope someone else
(Norman) will answer this doubt.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Eric Charles <er...@apache.org>.
On 31/12/11 15:03, Stefano Bagnara wrote:
>> but didn't know where to go..., this is the reason for this thread :)
>> Maybe you have a third option in mind such as having two completely
>> separated logging mechanism when running protocols in server?
>
> IMO we should go with #1 (using a private Logger interface and then
> use an adapter to slf4j).
>
Hi Stefano,
I am more in favor of #2 to keep things simple.
For which reason do you prefer #1?
> I also think that an slf4j adapter could be provided direclty in the
> protocols project and used as an optional dependency (so you don't
> have to write the adapter in every project).
> The "right" approach would be to have a protocols module with the
> slf4j adapter, but IMO a module for a single class is too much, so
> maybe we can simply put the adapter in the netty module or in the api
> module and then declare the slf4j dependency as optional, so that
> users of the library will decide if they want to use the slf4j logger
> or instead provide their own implementation.
>
Yes, it would be crazy to ask to all our library users to reimplement
that adapter.
To open the discussion more, I already saw (don't remember which ones)
needs for a "james-common" that could be useful to all our projects.
Some logging, streaming,... classes could perfectly fit there.
> I'm not sure if this plays well with OSGi.
>
No idea... but I don't see why it couldn't
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Stefano Bagnara <ap...@bago.org>.
2011/12/31 Eric Charles <er...@apache.org>:
> Hello Norman,
>
> Yes, I can understand this.
>
> So, how are we gonna create a POP3Protocol(ProtocolHandlerChain,
> ProtocolConfiguration, Logger) from server which uses slf4j?
>
> We need to give as third parameter a org.apache.james.protocols.api.Logger.
>
> An adapter between org.slf4j.Logger and
> org.apache.james.protocols.api.Logger could do the job, even if find this a
> bit overhead.
>
> When integrating server and protocols trunk a few days before, I thus though
> to these 2 options:
> 1.- the adapter.
> 2.- the uniformisation between all projects.
>
> but didn't know where to go..., this is the reason for this thread :)
> Maybe you have a third option in mind such as having two completely
> separated logging mechanism when running protocols in server?
IMO we should go with #1 (using a private Logger interface and then
use an adapter to slf4j).
I also think that an slf4j adapter could be provided direclty in the
protocols project and used as an optional dependency (so you don't
have to write the adapter in every project).
The "right" approach would be to have a protocols module with the
slf4j adapter, but IMO a module for a single class is too much, so
maybe we can simply put the adapter in the netty module or in the api
module and then declare the slf4j dependency as optional, so that
users of the library will decide if they want to use the slf4j logger
or instead provide their own implementation.
I'm not sure if this plays well with OSGi.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Eric Charles <er...@apache.org>.
Hello Norman,
Yes, I can understand this.
So, how are we gonna create a POP3Protocol(ProtocolHandlerChain,
ProtocolConfiguration, Logger) from server which uses slf4j?
We need to give as third parameter a org.apache.james.protocols.api.Logger.
An adapter between org.slf4j.Logger and
org.apache.james.protocols.api.Logger could do the job, even if find
this a bit overhead.
When integrating server and protocols trunk a few days before, I thus
though to these 2 options:
1.- the adapter.
2.- the uniformisation between all projects.
but didn't know where to go..., this is the reason for this thread :)
Maybe you have a third option in mind such as having two completely
separated logging mechanism when running protocols in server?
Thx,
Eric
On 30/12/11 21:25, Norman Maurer wrote:
> Hi Eric,
>
> I pulled out the slf4j dependency in protocols as its really sexy to have zero dependencies in the API. We even only used the Logger interface which made it even more clear to me that we should use our own logger interface.
>
> Our implementations and so consumer of the API will still use slf4j.
>
> We did the same in jSPF.
>
> Hope it helps,
> Norman
>
> Von meinem iPhone gesendet
>
> Am 30.12.2011 um 20:48 schrieb Eric Charles<er...@apache.org>:
>
>> Hi,
>>
>> I noticed:
>>
>> - https://issues.apache.org/jira/browse/JAMES-1149 (Replace commons-logging with jcl-over-slf4j)
>> - and recent https://issues.apache.org/jira/browse/PROTOCOLS-76 (Remove dependency on slf4j)
>>
>> I commented on the PROTOCOLS-76 about the incompatible types which makes the integration of our different project more complicated (incompatible logger types in constructor,...).
>>
>> One option is to standardize for all project to one of the following:
>> 1.- slf4j
>> 2.- java.util.Logger
>> 3.- commons-logging
>> 4.- Our own implementation
>> 5.- ...
>>
>> I don't have any strong preference for any, but the trend I see in some (not all) other projects is slf4j.
>> If we go this way, this will give us probably less work to integrate server-trunk with protocols-trunk.
>>
>> ...or let each project decide, which will be hell.
>>
>> WDYT?
>> --
>> eric | http://about.echarles.net | @echarles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging library in our projects
Posted by Norman Maurer <no...@googlemail.com>.
Hi Eric,
I pulled out the slf4j dependency in protocols as its really sexy to have zero dependencies in the API. We even only used the Logger interface which made it even more clear to me that we should use our own logger interface.
Our implementations and so consumer of the API will still use slf4j.
We did the same in jSPF.
Hope it helps,
Norman
Von meinem iPhone gesendet
Am 30.12.2011 um 20:48 schrieb Eric Charles <er...@apache.org>:
> Hi,
>
> I noticed:
>
> - https://issues.apache.org/jira/browse/JAMES-1149 (Replace commons-logging with jcl-over-slf4j)
> - and recent https://issues.apache.org/jira/browse/PROTOCOLS-76 (Remove dependency on slf4j)
>
> I commented on the PROTOCOLS-76 about the incompatible types which makes the integration of our different project more complicated (incompatible logger types in constructor,...).
>
> One option is to standardize for all project to one of the following:
> 1.- slf4j
> 2.- java.util.Logger
> 3.- commons-logging
> 4.- Our own implementation
> 5.- ...
>
> I don't have any strong preference for any, but the trend I see in some (not all) other projects is slf4j.
> If we go this way, this will give us probably less work to integrate server-trunk with protocols-trunk.
>
> ...or let each project decide, which will be hell.
>
> WDYT?
> --
> eric | http://about.echarles.net | @echarles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org