"Adam R. B. Jack" wrote:
> 1) I don't know the two communities, but one thing I like about C-L > being in 'user space' is it is clearly a user advocate w/o the > temptations to extend the API. We see (from the recent Gump failures) > how many folks depend upon C-L already, but maybe putting it into a > logging services community would open it up to more folks, including > container writers.
The UGLI interface is intended to be very basic, very simple.
> 2) I know C-L has a hard life, it is trying to sit on top of so much, > but I find it's need/attempt to call/configure logging packages a > problem. I don't know if I am expressing some form of IOC thought > here, but when working on Depot, even C-L falls down. We (as a > library) wanted to plug in to Ant, and we didn't want to force the C-L > to Ant bridge. Basically, we wrote our own > (yet another) logging that was simply a listener pattern, and plugged in an > Ant logger listener, or a commons logging listener, as appropriate. Works > nicely, but I don't want to write that code. I'd like UGLI as a logging > abstraction that all containers can agree upon (Ant as a container, an > application as a container) and have the environment provide it.
When no action is taken by the user to set up a logging context, UGLI will default to NullLogger. Thus, if you want logging the user has to take explicit steps. Otherwise, UGLI will just be silent and will not interfere or hamper your application. Would that approach have worked for you?
> 3) Forgive me, but ... would UGLI (with nose holding) be able to sit > under JDK logging? Surely folks ought be able to just use that. Ugly > or not, the JDK solution is going to be there inside any recent Java > VM. Is that not sufficiently simple?
Eventually, that is one of the intended goals.
-- Ceki G�lc�
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
