Deprecation Warnings in ServletRequestWrapper
http://issues.apache.org/bugzilla/show_bug.cgi?id=33104 Closed ostensibly as the spec claims the container must be compilable under JDK 1.3. I only see this: J2SE 1.3 is the minimum version of the underlying Java platform with which servlet containers must be built. Humor me here. How does "minimum" imply you cant require something stricter? If it did, and 1.4 deprecated code you used, and 1.5 removed it entirely, wouldn't you be stuck? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deprecation Warnings in ServletRequestWrapper
>Second, why require something stricter if we don't have to? >Especially now, in what would be the 18th release of Tomcat 5.5, >thereby causing pain those users who do run on JDK 1.3, just to get >rid of some deprecation warnings that don't make any difference to >anyone except you two apparently? I think your brush is a tad broad here. BillyJoeJimBobServletWriter won't ever get these warnings unless he happens to wrap the Tomcat implementations of HttpServletRequest or HttpServletResponse AND uses the 1.5 JDK. Assuming he fits that category, he might write to Tomcat-user or he might not. If he does, if he had my experience when asking about it, he'll get no response at all. Then he MIGHT search bugzilla, find a bug that was closed due to an apparent spec misread, re open it, and have it reclosed without comment by the Tomcat PMC. Only *then* did I get to this point. Then I got told I'm one of two people who apparently cared about it. What I'm saying here is please don't imply my concern is over-the-top because I happen be the guy who successfully jumped through all of the hurdles put in the way of people like me. Suffice it to say, I happen to think your sampling method to determine the complaint ratio is rather skewed. -Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deprecation Warnings in ServletRequestWrapper
> Second, why require something stricter if we don't have to?
> Especially now, in what would be the 18th release of Tomcat 5.5,
> thereby causing pain those users who do run on JDK 1.3, just to get
> rid of some deprecation warnings that don't make any difference to
> anyone except you two apparently?
>
>And, more to the point, the deprecated methods are still part of the 2.5
>spec :), and so still must be included. What would be possible in TC 6 is
>to do:
> @SuppressWarnings("deprecation")
> public void setStatus(int sc, String sm) { ...
>
>This would at least allow compiling the servlet-api without deprecation
>warnings. Of course, you are free to annotate your own classes anyway you
>want :).
Interesting you point that out, as comments in the bug claims it's being fixed
in TC 6.
If the logic is, "We didn't read the spec right and then we ignored the bug
when it was first reported too, and in the time since we have acquired users
everywhere who are now dependent on our error", there are two options.
1) Fix it, tell the 1.3 JDK people they got lucky to have support this far.
2) Mark the bug WONTFIX, not INVALID. You take your chances with the next JDK.
Because like I said before, as long as these deprecated methods are being used,
Tomcat's javax.servlet.* implementation's days are numbers. The next JDK won't
have these methods. Then it's game over. No compilation under the next JDK. If
the spec hasn't changed, nor your interpretation of it, then it's no left-turn,
no right-turn, whaddyadoo..
So are you guys _REALLY_ sure this is what the spec is saying with regard to
JDK 1.3 support?
-Joe
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
