| Issue 12: | Remove e.printStackTrace() | |
| 1 person starred this issue and may be notified of changes. | Back to list |
BasicCellEditor and DateCellEditor contains e.printStackTrace(). This must be replace with a logger. warn level ? More generally : is-it possible to use slf4j (http://www.slf4j.org/) instead of commons-logging ? Some issues with with commons-logging look : specially this http://www.qos.ch/logging/classloader.jsp. Just let me know and I will provide a patch. -- Olivier
Apr 26, 2007
#1
extremec...@gmail.com
Apr 27, 2007
I think this is worth trying out. My only concern would be in order for other projects to see JMesa logging then they would have to use slf4j. However, considering the creator of log4j is supporting the library, and his new logging framework has support I think it is worth trying it out. That and like I said I really did not want to use commons-logging anyway because I saw those posts talking about how much of a hassle it can be. Do you want to implement it and send me the patch?
Apr 27, 2007
Sorry about this late post, but I was doing some more checking on some popular forums and now I am not convinced that this is a good thing. Plus, it didn't occur to me until after my last post that I would be forcing people to use the slf4j because applications would actually get ClassNotFound exceptions if they did not choose to use slf4j. For some reason I was thinking worse case scenario would be the logging would not work. The interesting thing is technically the slf4j may very well be the right technical choice, but until the larger projects move I cannot see JMesa moving. This would be a lot easier if a project like Spring were to move and then immediately it would be easy to justify. I will have to recant my vote for this change for the time being, however I will be sure to keep tabs on this.
Apr 28, 2007
Can you give me pointers on "ome popular forums" ? Just for my curiosity. ClassNotFound ? No, users just need to jars or use maven (now a pom exists ;-). And have a look : http://www.slf4j.org/manual.html#gradual.
Apr 28, 2007
I am probably making more of this than I should, but I want to make the right decision, and that is not clear cut. I do feel like I was a little forced into a logging framework because all the other projects use commons-logging. That is why I am torn on this and do not want to force anyone else into a logging framework. You presented JMesa with a really good alternative and this is worth talking about. I'm even a little more discouraged after reading this: http://radio.weblogs.com/0122027/2003/08/15.html I went to both Spring and Hibernate's forums and found very little about slf4j. However, even after my last post I searched even more and did more searches about commons-logging problems and then found a ton of hits with people having class loading problems. I'm concerned about the buy-in for slf4j though. If developers have to use slf4j with all the various jars I could see this as being a problem. However, if they could still run commons-logging and the slf4j jars together then that is better. I see that there is that migration jar, but I would not want to force people to use it. If the migration turns out not to work perfectly then the JMesa project gets blamed for having issues. I would even feel better if just to run JMesa the only required jar would be slf4j-api.jar, and then to make logging work then include the proper jar file...slf4j-log4j13.jar, slf4j-jdk14.jar, etc.... Does that make sense? I'm not prepared to force people to use slf4j, so if the impact is just include that one jar and then optionally do other things to make logging work, and ideally bridge the commons-logging with a third jar then I am all for it. Lastly, I would also be willing to try and roll JMesa over and include it as an optional download and find out what other people think. If people really dislike it then I would roll back for the next release. That might actually be our best choice instead of thinking it is all or nothing.
Apr 29, 2007
With the weekend to think about it I like my last suggestion. We should go ahead and roll to the slf4j logging framework and I will put it out as a new download. If all goes well then this is what we will use going forward. The nice thing about doing it now is that it will give people a choice, although my recommendation will be to try the slf4j version. One of the goals of JMesa is to be more agile and have the ability to put out more incremental versions as it makes sense. I am also striving for backwards compatibility. This kind of toes the line because it doesn't really break anything, but requires new jars and possibly changes peoples projects if they choose to completely switch to slf4j. If it just works for people then I will quietly remove the commons-logging version. Would you still be interested in making the necessary changes? If so then I will apply your patch when I get it and put it out there!
Apr 30, 2007
Here. Apply the patch then try mvn eclipse:eclipse. There is trouble with some units in the maven env. The resources loading doesn't work (this.getClass().getResourceAsStream).
May 1, 2007
I applied the patch! It all seems to work great :). I did try running the mvn eclipse:eclipse. That works pretty slick, although I did not check in the classpath change. I need to get used to Maven again. I used to use Maven 1 and only briefly used Maven 2. I really do like the project though. For my current builds I use Ant and a little shell scripting. I did that because I thought it was interesting :). At some point I should change this over to just Ant and/or Maven to package the builds.
Status:
Fixed
|