james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Logging library in our projects
Date Sat, 31 Dec 2011 15:32:53 GMT
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.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message