james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <e...@apache.org>
Subject Re: Logging library in our projects
Date Sun, 01 Jan 2012 09:22:53 GMT
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.


On 31/12/11 16:32, Stefano Bagnara wrote:
> 2011/12/31 Eric Charles<eric@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

View raw message