Hi Richard, > a) It would be nice to keep the core log4j package as small and > efficient as possible.
Within reason. > b) Allow sandbox classes to be built into independant jars (for > instance, if all I need is core log4j and the smtp appender, then I'd > deploye log4j.jar and log4j-smtp.jar with my app). > > The benefits to this approach would be that log4j.jar would be as small > as possible and you could deploy any old appender you want with your > app, or all of them if that makes you happy. The downside to this > approach is that you could have 10 different little jars to provide your > clients just for logging. > > But, couldn't we modify the build.xml file so that it can build x number > of sandbox classes into one jar file, or even bundled with log4j into > one total jar file, except in cases such as servlets? > > I'm just brainstorming here, it could be utter nonsense :-) I think we need to discover when we have enough class separation in the sandbox and then stop. > Is the sandbox meant for all non-core log4j classes such as appenders? No. The classes that are currently part of the log4j-core release will remain in the log4j release (unless we decide to break them out into sandbox, which I highly doubt). The sandbox is meant for classes or contributions that might not yet be "ready for primetime" as part of the core log4j release. This doesn't mean they don't work or shouldn't be used. It just means that they are allowed to change more dramatically and experimentally than the core log4j classes. -Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
