My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 12: Remove e.printStackTrace()
1 person starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  ----
Closed:  May 2007


 
Reported by oliver.lamy@gmail.com, Apr 26, 2007
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
Let me do some checking on this library. This might be an easier sell than you think.
I really did not want to use the commons-logging, but every other framework I use
uses it so I ended up using it myself. 

For sure we need to get that stack trace out of there...and I agree with the warn level.

Apr 27, 2007
#2 extremec...@gmail.com
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
#3 extremec...@gmail.com
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
#4 oliver.lamy@gmail.com
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
#5 extremec...@gmail.com
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
#6 extremec...@gmail.com
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
#7 oliver.lamy@gmail.com
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).


jmesa-12
16.5 KB   Download
May 1, 2007
#8 extremec...@gmail.com
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

Powered by Google Project Hosting