> 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. -Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
