commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <>
Subject Re: Suggestion for all of Commons
Date Wed, 29 Mar 2006 18:42:47 GMT
On 3/29/06, Frank W. Zammetti <> wrote:
> Hey all,
> I just spent about 20 minutes working through a problem with FileUpload...
> turned out to be my fault entirely, I didn't include Commons IO (FYI, I'm
> not seeing a dependency list on the FileUpload site... maybe I missed it).

You did. See:

This is the standard location for the dependency list for all Commons

The problem is, it was one of those aggrevating problems to track down
> because the stack trace didn't reveal the actual line where the failure
> occured, and catching Exception didn't get triggered.  I wound up catching
> Throwable, and I was then able to figure it out.

The stack trace should have shown a NoClassDefFoundError indicating a class
in Commons IO. I haven't seen a situation where that's not the case, and
that's also been the case for all of the people who've asked about it on the
list, at least that I can recall.

I know that missing dependencies is always a b**ch, and they tend to be
> these annoying problems with no error messages or anything (sure, a
> debugger helps, but that doesn't seem like the best answer to me).  So, I
> have a suggestion that could well go all across Commons, or any other
> project for that matter.
> In Java Web Parts, we've gotten into the habit of putting this in all
> classes:
> /**
> * This static initializer block tries to load all the classes this one
> * depends on (those not from standard Java anyway) and prints an error
> * meesage if any cannot be loaded for any reason.
> */
> static {
>   try {
>     Class.forName("org.apache.commons.logging.Log");
>     Class.forName("org.apache.commons.logging.LogFactory");
>   } catch (ClassNotFoundException e) {
>     System.err.println("CacheControlFilter" +
>       " could not be loaded by classloader because classes it depends" +
>       " on could not be found in the classpath...");
>     e.printStackTrace();
>   }
> }

Aside from the fact that Class.forName is generally not a good idea in a
J2EE environment, I personally have a strong dislike for static
initialisers, so I'm not inclined to do something like this for components I
work on. Other folks may like it, though. ;-)

Martin Cooper

It's just echoing the import list, minus classes found in the SDK (if
> that's missing, you aren't getting *this* far!).  This saves a lot of time
> and headache when you are missing a dependency.  I know that adds
> something additional to maintain in the class, but it seems a fair
> trade-off to me.
> Does anyone see this as being something that might be helpful for Commons?
> If there is a better way to get the same effect I'm all ears too (I could
> see setting a string to the name of the class being checked so that it
> could be output as part of the error message, but I'm talking about a
> whole other way to check for dependencies).
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> AIM: fzammetti
> Yahoo: fzammetti
> MSN:
> Java Web Parts -
> Supplying the wheel, so you don't have to reinvent it!
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message