logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Womack <wom...@adobe.com>
Subject RE: JDJ - log4j vs java.util.logging
Date Thu, 24 Mar 2005 17:43:52 GMT
> I think it is more interesting to open existing solutions (aka backends)
> for
> other frontends and to improve the way to lookup/bind/manage the backend.
> (See also threads discussing classloader issues and dynamic/static
> binding....)
> In my opinion there should be no overwhelming frontend for every case of
> use
> (See also thread discussing "Enterprise Logger") (In German "Eierlegende
> Wollmilchsau" - "all-in-one device suitable for every purpose").
> But there should be one interface for each case of use (i.E. Simple (like
> JCL Log, ugli ULogger), I18N (parts of JSR47), extend (parts of JSR47 with
> log(String sourceClass, String sourceMethod,...)

I agree with this.  You should only have to bite off what you want to chew.
Also, projects that are providing the underlying implementation to the
interfaces (log4j, jul, etc) could only implement interface groups they want
to implement and still be "commons-logging" compatible.  For instance the
current log4j could be used with the "simple" interfaces but not the
enterprise interfaces.  But a future version could then implement the
enterprise interfaces.  Or some industrious soul could provide an
implementation of the enterprise interfaces built on top of the current
log4j, etc.  Give developers options.  That is the name of the game.

> A new project binds people to administrative tasks, will confuse
> developers,
> split communities. As I learned in the last month, there is very much know
> how existing in JCL and log4j. I would wonder if the mentioned technical
> problems are not solvable in the current projects (may cause
> incompatibility
> with former releases).

I think that a coherent migration strategy is needed.  There may be some
backward compatibility issues that cannot be solved, thus v2.0.  If it is
truly better, people will migrate.

> One idea could be to split log4j- (loggers, appenders, and layouts) -
> loggers
> into two parts, one for doing (backend) and one for accessing (frontend),
> the component for accessing then can be used by wrappers or extended with
> special (existing?) interfaces.

I think we have talked about this before.  I'd want to see a proposal.  But
I think the real issue is that people want to have an "agnostic" set of
interfaces they can use for development and make the decision about the
underlying logging implementation later at deployment.  Just splitting log4j
does not provide this.


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

View raw message