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
Re: Alternative to NSI
I've worked with both Setup Factory and InstallShield in the past and I liked Setup Factory a lot. But as far as I know, it is Windows only. Last I heard, both InstallShield and Wise were planning Java versions of their installers that were supposed to be cross-platform. Wouldn't that make some sense for a product like Tomcat that is cross-platform itself? Just my $.02 Klaus Sonnenleiter At 10:13 AM 7/15/01 +0100, you wrote: hi all, talking about alternatives, there is a program called DemoSheild from InstallShield which is free and can be used to make msi install scripts. There is another program called 'Setup Factory 5.0' which has some very advanced features like regisrty editing, inf. file editing, setting run-time env. variables and stuff,, just saying, i have got the setup factory program, if u would like me to make an example copy of it. Thanx in advance, Hiten Pandya [EMAIL PROTECTED] -- From: Remy Maucherat Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Alternative to NSI Date: Sat, 14 Jul 2001 22:54:36 -0700 (PDT) MIME-Version: 1.0 Received: from [64.208.42.41] by hotmail.com (3.2) with ESMTP id MHotMailBD1A7B2200CA4004311F40D02A290A770; Sat, 14 Jul 2001 22:54:42 -0700 Received: (qmail 95669 invoked by uid 500); 15 Jul 2001 05:54:27 - Received: (qmail 95657 invoked from network); 15 Jul 2001 05:54:27 - From tomcat-dev-return-24471-h_pandya5 Sat, 14 Jul 2001 22:56:07 -0700 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Delivered-To: mailing list [EMAIL PROTECTED] X-Authentication-Warning: kali.betaversion.org: nobody set sender to [EMAIL PROTECTED] using -f Message-ID: <[EMAIL PROTECTED]> References: In-Reply-To: User-Agent: IMP/PHP IMAP webmail program 2.2.2 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Quoting Daniel Ritchey : > Microsoft has its own installation mechanism built in to Win2000 & WinXP > and > offers a download to add it Win9x. Its the same thing that the binary > release of Apache for windows is packaged in. > > Just thought I would throw that out there, I don't know if it has any > advantages over NSI. Ok, but how do you build the MSI ? I know InstallShield can generate that, but that costs (lots of) cash ... There are a few advanced features missing in NSI, but more or less gets the job done. It is also very simple to use. I had a tweaked version of the script, but unfortunately my main HD died on me a few moments ago. The tweaks weren't too complex so I should be able to put them back in quickly. What would I do without IMAP (thanks Pier ;-)) and CVS ? (since of course I never back up anything) :-) Remy Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
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 ).
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 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
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
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
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 > >
%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
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
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
