Problems Compiling mod_webapp and APR on Solaris
Has anybody successfully compiled mod_webapp and/or the APR library on Solaris? I was able to compile everything without any trouble on a RedHat 7.1 system. But when I tried the same version of the sources (tonight's CVS) on Solaris, it failed miserably (some output below). The errors seem to be related to the APR library and I've tried to use a more recent one which compiles without problems, but it creates conflicts when compiling the mod_webapp module (it requires a different number of parameters and I remember from a discussion here that it was considered safer to stay with the older library). TIA -- snip - Compiling sources in /home/klaus/jakarta-tomcat-connectors/webapp/apr... make[1]: Entering directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr' Making all in strings make[2]: Entering directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings' make[3]: Entering directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings' /bin/sh /home/klaus/jakarta-tomcat-connectors/webapp/apr/libtool --silent --mode =compile gcc-DHAVE_CONFIG_H -DSOLARIS2=7 -D_POSIX_PTHREAD_SEMANTICS -D_REENT RANT -I../include -I../include/arch/unix -c apr_cpystrn.c touch apr_cpystrn.lo In file included from apr_cpystrn.c:55: ../include/apr.h:187: #error Can not determine the proper size for apr_int64_t ../include/apr.h:242: #error Can not determine the proper size for ssize_t ../include/apr.h:245: #error Can not determine the proper size for size_t ../include/apr.h:254: #error Can not determine the proper size for apr_int64_t make[3]: *** [apr_cpystrn.lo] Error 1 make[3]: Leaving directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr' make: *** [apr-all] Error 2 Compiling sources in /home/klaus/jakarta-tomcat-connectors/webapp/apr... make[1]: Entering directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr' Making all in strings make[2]: Entering directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings' make[3]: Entering directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings' /bin/sh /home/klaus/jakarta-tomcat-connectors/webapp/apr/libtool --silent --mode=compile gcc-DHAVE_CONFIG_H -DSOLARIS2=7 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I../include -I../include/arch/unix -c apr_cpystrn.c touch apr_cpystrn.lo In file included from apr_cpystrn.c:64: /usr/include/string.h:43: warning: conflicting types for built-in function `memcpy' /usr/include/string.h:45: warning: conflicting types for built-in function `strcpy' /usr/include/string.h:51: warning: conflicting types for built-in function `memcmp' /usr/include/string.h:52: warning: conflicting types for built-in function `strcmp' apr_cpystrn.c:84: conflicting types for `apr_cpystrn' ../include/apr_strings.h:203: previous declaration of `apr_cpystrn' apr_cpystrn.c:126: conflicting types for `apr_tokenize_to_argv' ../include/apr_strings.h:224: previous declaration of `apr_tokenize_to_argv' apr_cpystrn.c:235: conflicting types for `apr_collapse_spaces' ../include/apr_strings.h:212: previous declaration of `apr_collapse_spaces' make[3]: *** [apr_cpystrn.lo] Error 1 make[3]: Leaving directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr' make: *** [apr-all] Error 2
Re: mod_webapp
At 04:43 PM 7/18/01 +0100, you wrote: jean-frederic clere at [EMAIL PROTECTED] wrote: Nope... The official _stable_ WARP code is distributed with Tomcat 4.0, and resides in that CVS... The one you download from jakarta-tomcat-connectors is the working copy... As soon as I tag a stable version, that gets copied over into the official repository... So we will need to explain this in the README.txt. If the idea is to have the developement version in jakarta-tomcat-connectors and the maintenance mode one in Tomcat 4.0 that is great! (Otherwise it is confusing...). Hmm... Ok... If will change apjava.m4, so that if you don't specify --with-jdk, you won't compile java (remove the compile task, and remove all dependancies) sometimes in the future... Now it's not a priority (the priority is to have that piece of shit to pass the watchdog tests, soo). Maybe next week. The CVS I have does not compile because apr_socket_create()... It misses the inherit parameter! APR has added it to the apr_socket_create(). Should I fix it or just tell we need a tagged APR (like APACHE_2_0_20). I have an old pre-sms version of APR I'm using, and it seems it's working on most platforms as-is... I might ask the APR guys to tag it with MOD_WEBAPP_1_0, or redistribute it in a nice tarball... Pier, I just ran into that problem myself: I think you can't get the older version of APR anymore (or rather: I wasn't able to find it). I was able to get everything to compile by just adding the parameter in the function call. However, didn't get around to test it yet. Klaus Pier
%3F Problem
This may be a bit obscure, but I'm trying to get Tomcat to respond to a request that arrives with an encoded URL in the form [URL]%3F[Parameters]. It looks like "http://myhost:myport/mycontext/servlet/myservlet%3Fx=y" If I do the equivalent with an Apache http server (for verifying that I'm trying the right thing), I get the error message indicating that Apache was looking for the correct URL followed by a question mark and the name-value pairs of the parameter list. In Tomcat, however, the %3F does not get replaced and the error message indicates that Tomcat is looking for a servlet class called "myservlet%3Fx=y" which does not exist on my system. It looks like somebody must have attempted to fix this since the b3 version does a correct replacement if the %3F shows up right behind the end of the context (/mycontext/servlet%3F). I would volunteer to attempt a fix, if someone could point me to the right files - I looked at StandardWrapper and StandardClassLoader, and I can get the class loaded by cutting the name before the %, but then I lose the parameter list. Any hints? TIA
Re: %3F Problem
Oops, I guess I should have mentioned that I'm using the 4.0 version. Do you happen to know where the RequestImpl or equivalent class is in catalina? (I checked org.apache.catalina.core.* without success). At 05:09 PM 4/13/01 +0200, you wrote: I find out some problem with this. Encoding som other characters then ISO Latin 1 from %xx URL fromat. With URL encoding deals: in tomcat: org.apache.tomcat.core.RequestImpl.handleParameters(); ... this use some methods from the same class but the same thinh does: in servlet spec: javax.servlet.http.HttpUtils.parseQueryString() I thing is better to use one implementation of parsing URL. (I posted the code in "Support for different Charsets" tread) Hi Jan Fnukal e-mail: [EMAIL PROTECTED] tel: +420-5-4142 5628 EfCon a.s. Jaselska 25 611 57 Brno Czech Republic www.efcon.cz - Original Message ----- From: Klaus Sonnenleiter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 13, 2001 4:40 PM Subject: %3F Problem This may be a bit obscure, but I'm trying to get Tomcat to respond to a request that arrives with an encoded URL in the form [URL]%3F[Parameters]. It looks like "http://myhost:myport/mycontext/servlet/myservlet%3Fx=y" If I do the equivalent with an Apache http server (for verifying that I'm trying the right thing), I get the error message indicating that Apache was looking for the correct URL followed by a question mark and the name-value pairs of the parameter list. In Tomcat, however, the %3F does not get replaced and the error message indicates that Tomcat is looking for a servlet class called "myservlet%3Fx=y" which does not exist on my system. It looks like somebody must have attempted to fix this since the b3 version does a correct replacement if the %3F shows up right behind the end of the context (/mycontext/servlet%3F). I would volunteer to attempt a fix, if someone could point me to the right files - I looked at StandardWrapper and StandardClassLoader, and I can get the class loaded by cutting the name before the %, but then I lose the parameter list. Any hints? TIA
Re: %3F Problem
Craig, I looked at HttpRequestImpl. Would it be safe to manipulate the URI in a call to setRequestURI before it sets the instance variable requestURI? It seems like this gets called the moment a request is made - this way, the encoded characters could be transformed to their unencoded equivalents before the parameter list is parsed and the classloader gets called. Klaus At 09:34 AM 4/13/01 -0700, you wrote: On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote: Oops, I guess I should have mentioned that I'm using the 4.0 version. Do you happen to know where the RequestImpl or equivalent class is in catalina? (I checked org.apache.catalina.core.* without success). The base class is org.apache.catalina.connector.HttpRequestBase. The 1.1 connector subclasses this as org.apache.catalina.connector.http.HttpRequestImpl. Craig
Re: %3F Problem
Craig, since I'm not really familiar with what the standard says, I can't comment on that. But I can only tell you what I observed in other HTTP servers and it appears that most convert a %3F into a question mark some time before sending the request to the classloader or to the filter that looks for the file. My current problem is actually limited to a specific area and I think taking a calculated risk and deviating slightly from the standard (if that's what it is), would not be the worst of all options. However, I would be interested in finding out what exactly the desired behavior for the final version of Tomcat 4.0 is. Speaking of which, is there a target release date yet? Klaus Sonnenleiter At 10:47 AM 4/13/01 -0700, you wrote: On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote: Craig, I looked at HttpRequestImpl. Would it be safe to manipulate the URI in a call to setRequestURI before it sets the instance variable requestURI? It seems like this gets called the moment a request is made - this way, the encoded characters could be transformed to their unencoded equivalents before the parameter list is parsed and the classloader gets called. Klaus The key thing to remember is a spec requirement that request.getRequestURI() must return the original request URI *without* decoding. The values returned by request.getServletPath() and request.getPathInfo(), on the other hand, are decoded first. Therefore, if you manipulate the request URI value in setRequestURI(), we'd need to make sure that we save an unmanipulated version somewhere as well. The deeper issue, though, is the portability of what you are proposing (across servlet containers) would be. As I understand it, you would like the %3f character to be interpreted as a "?" character so that the stuff after it is understood as part of the query string. That seems (to me) a questionable practice -- the reason you would use a %3f encoding in the first place is so that you could treat a question mark as a regular data character, instead of being a significant delimiter. If you decode first and then find that the "?" is significant, how would you ever include a question mark as part of the data value for a query string parameter (for example)? NOTE: There also needs to be a little more work in this area with respect to path parameters (;xxx stuff, which is how the session id is transmitted). This is being discussed in the expert group, and will probably require some minor changes in this area of Tomcat 4. Craig At 09:34 AM 4/13/01 -0700, you wrote: On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote: Oops, I guess I should have mentioned that I'm using the 4.0 version. Do you happen to know where the RequestImpl or equivalent class is in catalina? (I checked org.apache.catalina.core.* without success). The base class is org.apache.catalina.connector.HttpRequestBase. The 1.1 connector subclasses this as org.apache.catalina.connector.http.HttpRequestImpl. Craig
Re: %3F Problem
Remy, Craig, Yes, you're right. I read the specs and apparently the TC way of doing things is precisely the way it's written in the standard. However, that still doesn't fix my problem except if I want to carry along my hacked version forever. Here's what I'm trying to achieve: I currently have Tomcat proxy requests to underlying applications. When proxying applets however, I'm running into trouble since I need to pass parameters to the proxy from the URI which in this case is embedded in an APPLET tag and gets cut at the question mark by the browser unless it's escaped. A properly behaving Tomcat will not be able to find the right servlet. So, is there any way to intercept the first call to the URI parser, determine whether this is one of my previously encoded URIs and replace the escaped character if it is? Klaus At 10:55 AM 4/13/01 -0700, you wrote: On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote: Craig, I looked at HttpRequestImpl. Would it be safe to manipulate the URI in a call to setRequestURI before it sets the instance variable requestURI? It seems like this gets called the moment a request is made - this way, the encoded characters could be transformed to their unencoded equivalents before the parameter list is parsed and the classloader gets called. Klaus The key thing to remember is a spec requirement that request.getRequestURI() must return the original request URI *without* decoding. The values returned by request.getServletPath() and request.getPathInfo(), on the other hand, are decoded first. Therefore, if you manipulate the request URI value in setRequestURI(), we'd need to make sure that we save an unmanipulated version somewhere as well. The deeper issue, though, is the portability of what you are proposing (across servlet containers) would be. As I understand it, you would like the %3f character to be interpreted as a "?" character so that the stuff after it is understood as part of the query string. That seems (to me) a questionable practice -- the reason you would use a %3f encoding in the first place is so that you could treat a question mark as a regular data character, instead of being a significant delimiter. If you decode first and then find that the "?" is significant, how would you ever include a question mark as part of the data value for a query string parameter (for example)? NOTE: There also needs to be a little more work in this area with respect to path parameters (;xxx stuff, which is how the session id is transmitted). This is being discussed in the expert group, and will probably require some minor changes in this area of Tomcat 4. '?' shouldn't be encoded in the first place as it's a reserved character (just like you should never encode '/' in the path). If it's encoded, I don't think it should be interpreted as the delimiter for the query section of the URL. So IMO the current TC behavior is the right one. The RFC for URIs is http://www.ietf.org/rfc/rfc2396.txt Remy
Re: %3F Problem
So, is there any way to intercept the first call to the URI parser, determine whether this is one of my previously encoded URIs and replace the escaped character if it is? Never mind, I just answered that for myself (must have been half asleep when I asked g).
Embedded and Classpath
When I instantiate Catalina's Embedded class from within my application, shouldn't it automatically inherit my application's classpath? I've tried mapping a servlet that is part of my application's package to a URL pattern and it fails with an IllegalArgumentException saying "servlet mapping specifies an unknown servlet name [name_of_servlet]". My goal is to allow access to a servlet that is part of a package which for numerous reasons cannot live within the webapps directory tree. Is there any way to do this? I'm using 4.0 b1 TIA Klaus Sonnenleiter
