Re: Suggestion for all of Commons
It did, but because of the way the code around it was structured it got masked in the stack trace and wasn't obvious right away. It looks like what happened is that the method that made use of FileUpload was called reflectively, and because I was catching TargetInvocationException, the NoClassDefFoundError got "converted" to TargetInvocationException. Frank Dakota Jack wrote: Out of curiosity, didn't this throw a NoClassDefFoundError? If not, that indicates a coding choice someone might want to change.. On 3/29/06, Frank W. Zammetti <[EMAIL PROTECTED]> 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). 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. 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(); } } 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 http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Suggestion for all of Commons
Out of curiosity, didn't this throw a NoClassDefFoundError? If not, that indicates a coding choice someone might want to change.. On 3/29/06, Frank W. Zammetti <[EMAIL PROTECTED]> 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). > > 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. > > 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(); > } > } > > 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 > http://www.omnytex.com > AIM: fzammetti > Yahoo: fzammetti > MSN: [EMAIL PROTECTED] > Java Web Parts - > http://javawebparts.sourceforge.net > Supplying the wheel, so you don't have to reinvent it! > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [all] Suggestion for all of Commons
On 29/03/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > On 3/29/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > On 3/29/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > > On 3/29/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > > Or maybe we should simply advertise the dependencies pages better? > > > > > > Dependencies should be listed on the download page. The mind set of > > > someone wanting to to use a component is and I know this from having > > > done it a dozen or so times: +1 > > > > I've come to believe that dependencies should be included in the > > distribution. Also that we shouldn't bother with binary and source > > distributions anymore; be like tapestry/hivemind (I think they're the > > ones) and have just the one dist file. -1 if that is the only archive type made available > Urk. No thanks. If I download a couple of Commons components, and they share > a couple of dependencies, and the bundled versions of those dependencies are > different, what should I, as a user, do? I think that would just cause more > confusion within the user base. +1 > As for having just a single distribution, I'm not in favour of that either. > The vast majority of users don't give a dickey bird about the source, and it > just bulks up the distribution, and therefore the size of the end user's > distribution as well. I doubt our users will thank us for increasing the > size of their own applications, potentially increasing their bandwidth usage > for customers to download their products. +1 Seems to me the binary download should be the minimum needed to run the component; the source download should not include any jars that are in the binary download. Depending on the component, potentially put the javadoc in a separate jar. > -- > Martin Cooper > > > > 1. Find the component's site. > > > 2. Find the download link on the site. > > > 3. See want they want to download (src/bin, tar/zip) > > > 4. Unpack > > > 5. Find the jar and add it to their project. > > > > > > Step #3 is where we have the most cranial activity available to us and > > > we should take advantage of that. Any other step and the end user is > > > just going through the motions trying to get their work done with as > > > little effort as possible. > > > > Agreed. > > > > Hen > > > > - > > 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]
Re: [all] Suggestion for all of Commons
On 30/03/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > On 3/29/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > On 3/29/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > > On 3/29/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > On 3/29/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > > > > On 3/29/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > > > > Or maybe we should simply advertise the dependencies pages better? > > > > > > > > > > Dependencies should be listed on the download page. The mind set of > > > > > someone wanting to to use a component is and I know this from having > > > > > done it a dozen or so times: > > > > > > > > I've come to believe that dependencies should be included in the > > > > distribution. Also that we shouldn't bother with binary and source > > > > distributions anymore; be like tapestry/hivemind (I think they're the > > > > ones) and have just the one dist file. > > > > > > I'm almost cool with that. I'd be happy with a full download > > > (binary.jar, sources, docs, etc) and just the raw binary.jar > > > > > > 85% of the time downloading the binary distrobution is just an extra > > > step to get to what I want: the binary.jar > > > > Yeah, +1. > > > > I tend to go to ibiblio to get downloads half the time now; sad :) > > Definitely valuable to be able to download just the jar, especially > > for Commons things. > > If you don't like ibiblio, you can of course always use > http://www.apache.org/dist/java-repository/ > > Bundling dependencies is a last century waste of bandwidth, IMHO. I > agree though that making it clear what they are is important. Might > we worth a maven ticket to get them moved up in the default nav . I > vaguely remember this being discussed before either here or on > maven-user. > +1 Why not include it in the Download section of the navigation - e.g: Download * Releases (mirrored) * Nightly snapshots + Dependencies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > On 3/29/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > On 3/29/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > On 3/29/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > > > On 3/29/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > > > Or maybe we should simply advertise the dependencies pages better? > > > > > > > > Dependencies should be listed on the download page. The mind set of > > > > someone wanting to to use a component is and I know this from having > > > > done it a dozen or so times: > > > > > > I've come to believe that dependencies should be included in the > > > distribution. Also that we shouldn't bother with binary and source > > > distributions anymore; be like tapestry/hivemind (I think they're the > > > ones) and have just the one dist file. > > > > I'm almost cool with that. I'd be happy with a full download > > (binary.jar, sources, docs, etc) and just the raw binary.jar > > > > 85% of the time downloading the binary distrobution is just an extra > > step to get to what I want: the binary.jar > > Yeah, +1. > > I tend to go to ibiblio to get downloads half the time now; sad :) > Definitely valuable to be able to download just the jar, especially > for Commons things. If you don't like ibiblio, you can of course always use http://www.apache.org/dist/java-repository/ Bundling dependencies is a last century waste of bandwidth, IMHO. I agree though that making it clear what they are is important. Might we worth a maven ticket to get them moved up in the default nav . I vaguely remember this being discussed before either here or on maven-user. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > On 3/29/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > > > > Well, in any case, making the dependency list more visible addresses the > > concern, so that's cool, I hope others agree and pick up on it. Sandy's > > point about it being on the download page is a good one too, I'd be more > > than satisfied either way. Thanks! > > > > > OK, I did this [1]. A small step. > > -Rahul > > [1] http://jakarta.apache.org/commons/sandbox/scxml/ The one thing I wish we could do on that page (well the dependencies one linked from it) is a nice link to ibiblio (or the asf repository) to download the jar there. Oh, and the m2 snippet that someone else mentioned, but the ibiblio link would be nice too. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Well, in any case, making the dependency list more visible addresses the > concern, so that's cool, I hope others agree and pick up on it. Sandy's > point about it being on the download page is a good one too, I'd be more > than satisfied either way. Thanks! > OK, I did this [1]. A small step. -Rahul [1] http://jakarta.apache.org/commons/sandbox/scxml/ > > Frank > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > On 3/29/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > On 3/29/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > Or maybe we should simply advertise the dependencies pages better? > > > > Dependencies should be listed on the download page. The mind set of > > someone wanting to to use a component is and I know this from having > > done it a dozen or so times: > > I've come to believe that dependencies should be included in the > distribution. Also that we shouldn't bother with binary and source > distributions anymore; be like tapestry/hivemind (I think they're the > ones) and have just the one dist file. Urk. No thanks. If I download a couple of Commons components, and they share a couple of dependencies, and the bundled versions of those dependencies are different, what should I, as a user, do? I think that would just cause more confusion within the user base. As for having just a single distribution, I'm not in favour of that either. The vast majority of users don't give a dickey bird about the source, and it just bulks up the distribution, and therefore the size of the end user's distribution as well. I doubt our users will thank us for increasing the size of their own applications, potentially increasing their bandwidth usage for customers to download their products. -- Martin Cooper > 1. Find the component's site. > > 2. Find the download link on the site. > > 3. See want they want to download (src/bin, tar/zip) > > 4. Unpack > > 5. Find the jar and add it to their project. > > > > Step #3 is where we have the most cranial activity available to us and > > we should take advantage of that. Any other step and the end user is > > just going through the motions trying to get their work done with as > > little effort as possible. > > Agreed. > > Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [fileupload] Suggestion for all of Commons
On 3/29/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > > Frank W. Zammetti wrote: > > 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). > > We've seen a few fileupload/io issues come through. I think maybe I > should have stuck to my guns on not adding an [io] dependency to > [fileupload]... ;-) And I, on the other hand, am quite happy that, as about the only developer who ever works on FileUpload, I got to do what I felt was right, rather than having an opposing view imposed on me. ;-) -- Martin Cooper Stephen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [all] Suggestion for all of Commons
On 3/29/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > On 3/29/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > On 3/29/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > > On 3/29/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > > Or maybe we should simply advertise the dependencies pages better? > > > > > > Dependencies should be listed on the download page. The mind set of > > > someone wanting to to use a component is and I know this from having > > > done it a dozen or so times: > > > > I've come to believe that dependencies should be included in the > > distribution. Also that we shouldn't bother with binary and source > > distributions anymore; be like tapestry/hivemind (I think they're the > > ones) and have just the one dist file. > > I'm almost cool with that. I'd be happy with a full download > (binary.jar, sources, docs, etc) and just the raw binary.jar > > 85% of the time downloading the binary distrobution is just an extra > step to get to what I want: the binary.jar Yeah, +1. I tend to go to ibiblio to get downloads half the time now; sad :) Definitely valuable to be able to download just the jar, especially for Commons things. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > On 3/29/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > On 3/29/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > Or maybe we should simply advertise the dependencies pages better? > > > > Dependencies should be listed on the download page. The mind set of > > someone wanting to to use a component is and I know this from having > > done it a dozen or so times: > > I've come to believe that dependencies should be included in the > distribution. Also that we shouldn't bother with binary and source > distributions anymore; be like tapestry/hivemind (I think they're the > ones) and have just the one dist file. I'm almost cool with that. I'd be happy with a full download (binary.jar, sources, docs, etc) and just the raw binary.jar 85% of the time downloading the binary distrobution is just an extra step to get to what I want: the binary.jar > > 1. Find the component's site. > > 2. Find the download link on the site. > > 3. See want they want to download (src/bin, tar/zip) > > 4. Unpack > > 5. Find the jar and add it to their project. > > > > Step #3 is where we have the most cranial activity available to us and > > we should take advantage of that. Any other step and the end user is > > just going through the motions trying to get their work done with as > > little effort as possible. > > Agreed. > > Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] Suggestion for all of Commons
On Wed, March 29, 2006 4:36 pm, Stephen Colebourne said: > Frank W. Zammetti wrote: >> 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). > > We've seen a few fileupload/io issues come through. I think maybe I > should have stuck to my guns on not adding an [io] dependency to > [fileupload]... ;-) We came to the same conclusion as Henri when it comes to dependencies with Java Web Parts, that's why things like Commons Lang is included. We actually took it a bit further and put those classes in our package structure, but that was to avoid even having to have more JARs floating around, i.e., you include javawebparts-core.jar all the time, then just include the JARs you are interested in beyond that... the only external depenendency we left was JCL, just to hopefully avoid any classloader issues that might arise. IO doesn't at all strike me as an unreasonable dependency, so don't fret it too much :) I think simply making sure it is well-known is enough, and that just means prominently on the web site (whether on the download page, front page, or whatever, but it should be very hard to miss). > Stephen Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] Suggestion for all of Commons
Frank W. Zammetti wrote: 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). We've seen a few fileupload/io issues come through. I think maybe I should have stuck to my guns on not adding an [io] dependency to [fileupload]... ;-) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > On 3/29/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > Or maybe we should simply advertise the dependencies pages better? > > Dependencies should be listed on the download page. The mind set of > someone wanting to to use a component is and I know this from having > done it a dozen or so times: I've come to believe that dependencies should be included in the distribution. Also that we shouldn't bother with binary and source distributions anymore; be like tapestry/hivemind (I think they're the ones) and have just the one dist file. > 1. Find the component's site. > 2. Find the download link on the site. > 3. See want they want to download (src/bin, tar/zip) > 4. Unpack > 5. Find the jar and add it to their project. > > Step #3 is where we have the most cranial activity available to us and > we should take advantage of that. Any other step and the end user is > just going through the motions trying to get their work done with as > little effort as possible. Agreed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
Sandy McArthur wrote: > On 3/29/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > Or maybe we should simply advertise the dependencies pages better? > > Dependencies should be listed on the download page. The mind set of > someone wanting to to use a component is and I know this from having > done it a dozen or so times: > > 1. Find the component's site. > 2. Find the download link on the site. > 3. See want they want to download (src/bin, tar/zip) > 4. Unpack > 5. Find the jar and add it to their project. > > Step #3 is where we have the most cranial activity available to us and > we should take advantage of that. Any other step and the end user is > just going through the motions trying to get their work done with as > little effort as possible. With the advent of maven (and the maven ant tasks to a lesser extent) and its central repository, I have found I almost never need to go through that exercise any more. A bit of doc something like... To include commons-xxx as dependency for your maven 2.x project (and transitively, commons-xxx's dependencies) use the following in your pom.xml: org.apache.commons commons-xxx 1.0 compile To include commons-xxx as a dependency for your maven 1.x project use the following in your project.xml: org.apache.commons commons-xxx 1.0 org.apache.commons commons-xxx-dependency0 2.5 org.apache.commons commons-xxx-dependency1 3.0 (and a similar example using the maven ant tasks) ...would be quite useful to have on a download page, and could probably be generated via the maven 1.x or 2.x dependency plugin. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On Wed, March 29, 2006 3:08 pm, Rahul Akolkar said: >> > Aside from the fact that Class.forName is generally not a good idea in >> a >> > J2EE environment >> >> I hadn't heard that. Why is that? >> > > > * Many more classloaders in J2EE environments > * Atleast need to use the three argument version using the TCCL, even > that isn't a given Hehe, based on my experience with Websphere and the Classloaders From Hell that it is, I should have known that :) Good point about the 3-argument version... I don't want the checked classes to be initialized, so throwing false in there is fine (even though the specified classloader would be equivalent). >> Fair enough, I just wanted to make the suggestion. I'm interested >> though, >> why don't you like static initializers? Just curious ;) >> > > > * Libraries may be in shared environments where some initializations > may not work well > * Users have numerous classloader delegation models, loading classes > via static code can get tricky But if the intent is just to test if a given class is available for use by the loading class, aren't these points, if not irrelevant, than at least minimized? I totally see your point if we were talking about static initialization of members or actually loading/intializing a class (i.e., JDBC driver or similar). I'm not so sure I see the problem in the case of a simple "is class X available to me" check. Well, in any case, making the dependency list more visible addresses the concern, so that's cool, I hope others agree and pick up on it. Sandy's point about it being on the download page is a good one too, I'd be more than satisfied either way. Thanks! > -Rahul Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: 1. Find the component's site. 2. Find the download link on the site. 3. See want they want to download (src/bin, tar/zip) 4. Unpack 5. Find the jar and add it to their project. Step #3 is where we have the most cranial activity available to us and we should take advantage of that. Any other step and the end user is just going through the motions trying to get their work done with as little effort as possible. -- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > On Wed, March 29, 2006 1:42 pm, Martin Cooper said: > > You did. See: > > > > http://jakarta.apache.org/commons/fileupload/dependencies.html > > > > This is the standard location for the dependency list for all Commons > > components. > > Yep, was pointed out to me. As I mentioned in the other thread, I'd > personally like to see that not buried beneath a "branch" like it is... I > for one didn't know that was the standard location for Commons, I can't > imagine I'm the only one that didn't know that. OK, I will put the link in a more obvious place for one of the sandbox components [scxml]. If others like it, it might become a popular trend. > > > Aside from the fact that Class.forName is generally not a good idea in a > > J2EE environment > > I hadn't heard that. Why is that? > * Many more classloaders in J2EE environments * Atleast need to use the three argument version using the TCCL, even that isn't a given > > , I personally have a strong dislike for static > > initialisers, so I'm not inclined to do something like this for components > > I > > work on. > > Fair enough, I just wanted to make the suggestion. I'm interested though, > why don't you like static initializers? Just curious ;) > * Libraries may be in shared environments where some initializations may not work well * Users have numerous classloader delegation models, loading classes via static code can get tricky -Rahul > > Martin Cooper > > Frank > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On Wed, March 29, 2006 1:42 pm, Martin Cooper said: > You did. See: > > http://jakarta.apache.org/commons/fileupload/dependencies.html > > This is the standard location for the dependency list for all Commons > components. Yep, was pointed out to me. As I mentioned in the other thread, I'd personally like to see that not buried beneath a "branch" like it is... I for one didn't know that was the standard location for Commons, I can't imagine I'm the only one that didn't know that. > 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. It didn't... I think its because the method that uses FileUpload was called from a piece of code that was reflectively creating its class and calling it, so I was catching InvocationTargetException there, and that's what was showing up in the logs... that's what I was seeing in the logs, and the first line of the trace was the code inside the catch block, not any code in the class using FileUpload. It was a bit confusing for a few minutes. > Aside from the fact that Class.forName is generally not a good idea in a > J2EE environment I hadn't heard that. Why is that? > , I personally have a strong dislike for static > initialisers, so I'm not inclined to do something like this for components > I > work on. Fair enough, I just wanted to make the suggestion. I'm interested though, why don't you like static initializers? Just curious ;) > Martin Cooper Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On Wed, March 29, 2006 1:33 pm, Rahul Akolkar said: > Please prefix with [all], yup, its a bit tricky ;-) Sorry, forgot :) > Its here: > > http://jakarta.apache.org/commons/fileupload/dependencies.html Hmm, weird... I go to: http://jakarta.apache.org/commons/fileupload/ And I don't see a link to it... ah, I see... have to expand the Project Info "branch" first. Yes, I would suggest that being more front and center, i.e., visible right away. I know I'm the only person that has ever been burned by missing dependencies, it would be much better if that info was right there right away with no digging. > > > Or maybe we should simply advertise the dependencies pages better? Certainly that would suffice. I think the code telling you when a dependency is missing is a little friendlier, but certainly it isn't necessary, as long as the information is quick and easy to find. > -Rahul Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Suggestion for all of Commons
On 3/29/06, Frank W. Zammetti <[EMAIL PROTECTED]> 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: http://jakarta.apache.org/commons/fileupload/dependencies.html This is the standard location for the dependency list for all Commons components. 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 > http://www.omnytex.com > AIM: fzammetti > Yahoo: fzammetti > MSN: [EMAIL PROTECTED] > Java Web Parts - > http://javawebparts.sourceforge.net > Supplying the wheel, so you don't have to reinvent it! > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [all] Suggestion for all of Commons
Please prefix with [all], yup, its a bit tricky ;-) On 3/29/06, Frank W. Zammetti <[EMAIL PROTECTED]> 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). > Its here: http://jakarta.apache.org/commons/fileupload/dependencies.html Or maybe we should simply advertise the dependencies pages better? -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Suggestion for all of Commons
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). 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. 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(); } } 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 http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]