If i might jump in here... I whole-heartedly agree with Don. A couple years ago i would have argued against him on this quite vigorously. But after several more years of working close with both Struts (and VelocityStruts) which use commons-logging and Velocity itself (which takes Don's approach), i can say that Velocity's simple log interface has never caused me the headaches that commons-logging has (which were exacerbated by Tomcat's move to full dependence on commons-logging). I highly recommend you take Don's approach here.
As for actually carrying that out, well ever since i came around to the position on this that i now have, i've been thinking that there still ought to be some "commons" version of what Velocity uses and Struts needs. The catch of course is that the code needs to be rather directly imported into the libraries that will use it and have its package names changed (a static linking of sorts), and i don't know how this would be automated or releases managed or anything of the sort. True, the code needed is not at all difficult or all that time consuming to write, but it seems to me there ought to be a way to develop it communally and share it in a way that can be easily (or better, automatically) internalized. Then we would not only save the work of rewriting it for each project, but also of learning the trivial differences in interfaces and configuration for each library out there. If anyone has ideas for how this might be done, i'd be happy to jump in and contribute Velocity's internal logging facility, as i've put much work into it in the last year or so. And of course, if a similar thing could be done for commons-lang type stuff, the same benefits would apply. Ideas anyone? On 8/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
Commons Logging is a great example of the problems these small third-party dependencies cause host applications :) In this case, yes, we need to log, however, as a library, the only messages the user will care about are those that are from the library as a whole. If the user needs to filter at a package level a library's log messages, that library has problems :) Therefore, all a library needs is a Log interface, a simple default implementation, and a factory to provide that implementation. The library, if it really wants, can provide a commons-logging, jdk logging, and/or log4j implementation, but I think that's really optional. The point is these classes should be in the libraries package system so that they don't conflict with any other application or application server dependencies. At some point, I plan to replace commons-logging in Struts 2 with a simple log framework. I can backport to Struts 1 if desired. Don On 8/21/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > On 8/21/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > > I think we should keep s2's dependencies down to an absolute minimum. > > If you are writing an application, the more you reuse third-party > > libraries the better, however, if you are writing a framework and/or > > library, ideally, you should have none. > > > > The main reason libraries should have as few deps as possible is it > > imposes undue restrictions on the application using the library. For > > example, say Struts 2 started using commons-lang 2.1, but the > > application wanted to move to 3.0. They'd have to wait until Struts 2 > > moved to 3.0, but then all the apps using 2.1 would be forced to upgrade. > > > > IMO, the ideal library has no dependencies, and I include > > commons-logging in the forbidden list. > > > Any library of any consequence needs to log errors and exceptions. We can't > dictate to our users which logging package they use, and we need to provide > for unified logging throughout an application. Given those constraints, how > do you propose that we handle logging if we don't depend on something like > Commons Logging? > > -- > Martin Cooper > > > Don > > > > Paul Benedict wrote: > > > Because Struts does alot of Spring manipulation on URIs, would it make > > sense to add Commons Lang as a dependency? This way we don't have homegrown > > string parsing done everytime. Thoughts for s2 too? > > > > > > > > > --------------------------------- > > > Do you Yahoo!? > > > Next-gen email? Have it all with the all-new Yahoo! Mail Beta. > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
