> > JUL was probably never designed to be a front end but rather as the > Yup. JUL is neither open to be a front end, neither is the backend open for other ways to use it without a wrapper.
> > Maybe we should consider an independent project acting as a facade for > > the existing alogging APIs. Comments? > > I'd prefer a fixed Jakarta commons-logging over a brand new project. I > see a dead-end in the current JCL 1.x tree, and a new JCL 2.0 that is a > combined > effort from logging services, Jakarta, Tomcat, and other interested > parties. > It'll probably break backwards compatibility, but it will work. 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,...) 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). 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. Boris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
