xmlValidation is Broken (and Undocumented) in TC 5.5.12

[Bob Bronson <rb...@yahoo.com>]

Hi All,

Just a word of warning...apparently the sloppy Tomcat programmers did 
not thoroughly test TC 5.5.12.

The <Host> element has an attribute, "xmlValidation". In the default 
server.xml that's distributed with TC this value is set to false. If 
you set it to "true" you will see a boatload of very nice, completely 
unfriendly stack traces. Thank you, lazy Tomcat developers. I set this 
attribute to "true" on my own web app, hoping to validate my simple 
web.xml, and I received the same stack trace.

It's bad enough that this feature was not tested before TC 5.5.12 was 
released, but why couldn't the TC programmers give nice, easy to read 
error messages instead of an ugly stack trace? Lazy programmers with no 
regard for user friendly messages, that's why.

Oh BTW, if you are wondering what the "xmlValidation" attribute is for 
don't bother looking at the TC documentation 
(http://tomcat.apache.org/tomcat-5.5-doc/config/host.html). It seems 
the Tomcat programmers did bother to update the documentation. It still 
the same crappy, incomplete documentation we've been living with for so 
many years.

Personally, I am getting really sick of the sloppiness of the Tomcat 
programmers. It's not just this 'xmlValidation' issue but several 
others over the past years. Additionally, I'm fed up with their snotty, 
arrogant attitudes.

When someone criticizes the poor state of an open sores project (as I 
am doing now), the typical response from the open sores programmer is 
to shift responsibility to the user -- the user is often told to dig 
through the change logs or browse the forum archives or even to fix the 
bug/documentation themselves instead of "useless complaining". What an 
unprofessional, lazy attitude from programmers! The open sores 
programmers try to cast *their* laziness as the user's laziness for 
"not digging deeply enough" to resolve their own problem, or even 
fixing the problem themselves by going into the source code.

Yes, yes, I know Tomcat is "not for me". You're right. Good bye Tomcat, 
hello Jetty. I dobt Jetty could be worse.


--
Bob Bronson 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: xmlValidation is Broken (and Undocumented) in TC 5.5.12

[Mark Thomas <ma...@apache.org>]

Bob Bronson wrote:
> Hi All,
> 
> Just a word of warning...apparently the sloppy Tomcat programmers did 
> not thoroughly test TC 5.5.12.

Tomcat isn't perfect but it looks like the validation errors you are 
seeing are caused by a spec problem. See 
http://issues.apache.org/bugzilla/show_bug.cgi?id=31125 for more info.

> The <Host> element has an attribute, "xmlValidation". In the default 
> server.xml that's distributed with TC this value is set to false. If you 
> set it to "true" you will see a boatload of very nice, completely 
> unfriendly stack traces. Thank you, lazy Tomcat developers. I set this 
> attribute to "true" on my own web app, hoping to validate my simple 
> web.xml, and I received the same stack trace.
 >
> It's bad enough that this feature was not tested before TC 5.5.12 was 
> released, but why couldn't the TC programmers give nice, easy to read 
> error messages instead of an ugly stack trace? Lazy programmers with no 
> regard for user friendly messages, that's why.

Patches to improve error messages or any other part of Tomcat are 
always welcome.

> Oh BTW, if you are wondering what the "xmlValidation" attribute is for 
> don't bother looking at the TC documentation 
> (http://tomcat.apache.org/tomcat-5.5-doc/config/host.html). It seems the 
> Tomcat programmers did bother to update the documentation. It still the 
> same crappy, incomplete documentation we've been living with for so many 
> years.

Yep, some of the attributes are missing from the docs and yes this 
makes things more difficult than they need to be. As people point out 
the errors they will get fixed. They will get fixed faster if someone 
provides a patch.

> Personally, I am getting really sick of the sloppiness of the Tomcat 
> programmers. It's not just this 'xmlValidation' issue but several others 
> over the past years. Additionally, I'm fed up with their snotty, 
> arrogant attitudes.
> 
> When someone criticizes the poor state of an open sores project (as I am 
> doing now), the typical response from the open sores programmer is to 
> shift responsibility to the user -- the user is often told to dig 
> through the change logs or browse the forum archives or even to fix the 
> bug/documentation themselves instead of "useless complaining". What an 
> unprofessional, lazy attitude from programmers! The open sores 
> programmers try to cast *their* laziness as the user's laziness for "not 
> digging deeply enough" to resolve their own problem, or even fixing the 
> problem themselves by going into the source code.

The supplier-customer relationship is very different in open source 
projects. In fact, it just doesn't exist. There is no them and us. We 
are all users, we are all developers, we all provide support to the 
other members of our community. Everyone is welcome to contribute. 
Contributions can take many forms: Some people write code; some answer 
user questions on this list. However we contribute, we are all part of 
the one community and we all have a part to play to make Tomcat even 
better than it is today.

Criticism is fine and is welcomed when it is constructive. Criticism 
with a patch to fix the problem is even better ;)

> Yes, yes, I know Tomcat is "not for me". You're right. Good bye Tomcat, 
> hello Jetty. I dobt Jetty could be worse.

I sincerely hope that you are able to find the product that is right 
for you. Good luck with both your current and future projects.

Mark

> -- 
> Bob Bronson
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org