jVose

was having the same problem, errors when a previously working site that used spring 1.2.8 was updated to 2.0. The site would not start in tomcat.
The site was using WebWork 2.2 with Hibernate and Spring, and created and edited in Eclipse 3.2 with MyEclipse plugin, then launched into Tomcat 5.5. Tomcat spit out errors for each of the extensions where the ant-Implementation-URL parameters wrapped to two lines, and refused to start the context.
I tried to add the commons-attributes-*-2.2.jar files and the qdox-1.6.jar files to the local ant lib directory in Eclipse. This didn't work for me, but with Eclipse-MyEclipse I'm not sure if there was a separate lib directory where it would of worked?
I then tried the approach of extracting the jar, editing the manifest file so that the "ant-Implementation-URL" lines in the commons-attributes-compiler.jar manifest file were on the same line, but when I rejarred the file, the jar tool split the lines again, and Tomcat spit out the same error.
I finally got the errors to go away by getting rid of the original manifest file. Simply extracting the "commons-attributes-compiler.jar" file into an empty directory:
jar xf commons-attributes-compiler.jar
Deleting the original jar file, then re-jaring the files without explicitly specifying the manifest file (no -m option):
jar cf commons-attributes-compiler.jar *
The jar tool just created a new default manifest file, without the extensions specified. I might of broken something else, but for my configuration this has worked on three simple spring sites

Moving to OT > Soft Dev

rodlaurens,
I'm sorry to say I have no idea what is going on here. For such a randomly obscure bug I would have to assume your problem actually lies elsewhere... maybe even something silly (like a corrupted JAR, or bad Tomcat install?)

Was there ever a fix for this... It's a real pain to have to swap out the files all the time :)

awamser,
There is a huge thread about this in the Interface21 forums. Some folks incorrectly identified the problem as the line wraps in the MANIFEST file, but as quite a few folks that re-created the JAR, simply getting rid of the line-wraps didn't change anything (also the "bad" manifest has been in play since the early 2.0 and most recent releases).

In each case the errors ended up being caused by something else on the build path or in the app server. I don't remember the details exactly though.