Re: Introspect whether setCharacterEncoding is present..

Endre Stølsvik wrote:

>See, the problem is that we would like our application to be 2.2
>compliant, but we'd love to use the setCharactherEncoding method if it is
>available (>= 2.3 envs).
>
If an API "level test" is appropriate, it would be a lot cleaner (and 
faster) to test for the existence of a 2.3 class, rather than looking 
for the setCharacterEncoding method via reflection.  You could set a 
Context Attribute (or other flag) based on the following test:

        try {
            Class.forName("javax.servlet.http.HttpServletRequestWrapper");
            // This is Servlet API >= 2.3 --> Set Attribute/Flag TRUE
        } catch(ClassNotFoundException cnfx) {
            // This is Servlet API < 2.3 --> Set Attribute/Flag FALSE
        }

>However, I'm faced with some opposition, where
>some feel that since it isn't specified in the spec, a >2.2 servlet
>container would be smartest if it supplied an actual, complete servlet 2.2
>environment to a 2.2 webapp, and thus either the setCharEnc wouldn't be
>present (which actually wouldn't be problematic), or it would not behave
>(which could be problematic).
>
IANASAL (I Am Not A Servlet API Lawyer), so maybe I am missing some 
compelling reason why a container would provide an authentic 2.2 
environment to a 2.2 Servlet, rather than allowing it to run compatibly 
in a 2.3 environment.  There are only two expectations allowed APIv2.2 
Servlets that aren't valid in a 2.3 container.

The first is that APIv2.2 Servlets CAN rely on the existence of the 
javax.servlet.http.HttpUtils object, while APIv2.3 Servlets SHOULD NOT 
use this class and there may come a time when Servlets MUST NOT use this 
class.

The other possible APIv2.2 Servlet expectation is the availability of 
classes that were present as part of the container implementation; these 
can no longer be "seen" by APIv2.3 apps due to the 2.3 ClassLoader 
rules.  It seems to me that APIv2.2 Servlets with this compatibility 
"problem" would be rife with container dependencies, deserving a little 
"API Darwinism" to weed them out of the code base.

Either way, the v2.3 ClassLoader rules need to be maintained by the 
container, so the "2.2" environment would likely be provided using a set 
of 2.2-compatibility jar files and a corresponding ClassLoader on the 
app Context.

I can imagine a "strict 2.2" mode that ignored the setCharacterEncoding 
method on HttpRequest just for the sake of having one HttpRequest 
implementation.  Why would such a mode have ANY implementation of 
HttpServletRequestWrapper?  Why bother HAVING the Filter Wrapper classes 
if they're non-functional?  Would they ever exists without the Filter 
interfaces existing as well?  I just can't imagine why anyone would 
implement a "2.2 pure" mode with such glaring impurities!

I think the Class.forName() test above should be a sufficient API level 
test, or the Servlet Container is broken.

-- Charles


------------------------ Yahoo! Groups Sponsor --------------------~--> 
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/saFolB/TM
--------------------------------------------------------------------~-> 

Before posting a question, try to find your answer here: 
<http://www.egroups.com/links/advanced-servlets>
Announcements should go to: [email protected]
To Post a message, send it to: [email protected]
To Unsubscribe, send a blank message to: [email protected] 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/advanced-servlets/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/