On 3/26/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: > "Nathan Bubna" <[EMAIL PROTECTED]> writes: > > [... can't say much about Struts. Even though I've worked on a quite > large Struts app in the last six years, I must say that the experience > was just like all the other Struts experiences before. The fact that > it won out over Turbine is due to the fact that the docs are great and > it fit nicely into the Sun view of the Java world. The framework > itself is, well, well, it could be better... ] > > > >Idea #1 - between what > >http://wiki.apache.org/jakarta-commons/Logging/StaticLog talks about, > >Tomcat's annoying dependence on commons-logging, and the many > >improvements i've made to logging in Velocity 1.5, i am making the > >transition from being a big advocate of using commons-logging in the > >Velocity world to being rather opposed to it. i want to back > >commons-logging use out of VelocityView and GenericTools as soon as we > >are able to depend on Velocity 1.5. > > Ah, that is a new twist to the good old "JCL is evil" scheme. Yes, > I've seen that problem before. The question here is, is VelocityTools > "application code" or "library code". You probably don't want to back > out the references but the static modifiers. > > However, considering the fact that Spring Framework uses > > private static final Log logger = LogFactory.getLog(...) > > all over the place, I don't see that problem going away soon. So I > wouldn't spend too much time thinking about it anyway.
oh, i've already spent far too much time thinking about logging in the last year. :) and really, this static thing can be just as much a catch with log4j as jcl. honestly, while the static issue may carry more theoretic weight, the Tomcat issue and improved practicality of the new LogChute stuff in Velocity are bigger motivators for me personally. > >Idea #4 - So-called "standalone" toolbox support > >(http://issues.apache.org/jira/browse/VELTOOLS-8). The VelocityView > >object above is web-centric, but i agree, it'd be nice to make toolbox > >support for non-j2ee Velocity apps easy. i haven't done any work > >here, but i'm thinking it will probably require some heavy package > >re-organization. it would just be easier to go 2.x and not have to > >worry about being B.C. > > yep. +1 here. > > [...] > > >Question #5 - joda-time (http://joda-time.sourceforge.net/) is great. > >i want to see support for it in DateTool (or a new tool if need be). > >i haven't had time to tackle this myself. has anyone else done this > >yet? anyone want to? i'll probably get to it eventually, but as you > >can see from the above, i already have bitten off a lot to chew. :) > > Uh, yet _another_ wheel re-invention? The problem with all these great > libraries is, that most people either > > a) don't know about them > b) can't use them in their projects because they have to deal with 400kLOC of > existing code > c) are happy with what is in the JDK. > > Personally, I'd like to have stuff like that as an add-on. Best as a > pluggable implementation. If there is one lesson to learn from Spring > Framework then it is that "being flexible" is the way to go. ok, we can just do it as a subclass of DateTool, so if you don't use it, it won't affect you or require anything of you. the whole toolbox thing makes all of our tools intrinsically pluggable. :) so having it as an "add-on" really only saves a few kb for those who don't use it, but makes it a lot tougher for those who want it. and really, the apps we develop for work are seriously date-driven. the DateTool is one of my favorite parts of veltools. since i've been working on a jsp/jstl app for the last few months, i've been really missing it. i'm sick of tags. > Best regards > Henning > > > > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH > [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ > > RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire > Linux, Java, perl, Solaris -- Consulting, Training, Development > > Social behaviour: Bavarians can be extremely egalitarian and folksy. > -- http://en.wikipedia.org/wiki/Bavaria > Most Franconians do not like to be called Bavarians. > -- http://en.wikipedia.org/wiki/Franconia > > --------------------------------------------------------------------- > 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]
