Re: Tomcat & JDK for PDA arm processor
(Forgive a shameless plug, but seems it might be relevant to this thread) I just thought I'd mention Winstone (winstone.sourceforge.net) for this application too - there have been some people running it successfully on J2ME CDC 1.0 PP 1.0. It also lets you cut out some parts of the spec you don't want (eg JSP, JNDI, servlet reloading, SSL, clustering) by deleting packages from the jarfile. Latest version is v0.8.1, but the CVS version is stable too. Thanks, Rick Costin Manolache wrote: Not sure Jetty is fit for embedded use either. http://khttp.objectweb.org/ - or something similar, capable of running in CVM or even KVM - could be a viable solution for java on low end devices. The real problem is not the size of tomcat itself - but the number of JVM classes it uses and all the layers and features that need to be loaded. What people fail to understand very often is that flash has very different characteristics from a hard drive, and a 200MHz processor and 32MB ( or even 400MHz/64MB ) are slightly different from a 2G Hz/ 1 G RAM or even a low end - 1GHz/256M :-) Costin On 4/23/06, Preston L. Bannister <[EMAIL PROTECTED]> wrote: How small does it need to be? If you really need a full HTTP + servlets configuration then it might be easier to use one of the smaller Jetty configurations ( http://jetty.mortbay.org/ ). Do you really need servlets (i.e. is this webapp meant to run anywhere)? Dropping the standard servlet interface will slim things down. Do you really need the ability to handle heavy traffic? Both Tomcat and Jetty put extra effort into handling large numbers of connections with high throughput - which translates to bigger code and data. If you don't need this ability, then a simpler HTTP server could be a better bet. -- Servlet v2.4 container in a single 160KB jar file ? Try Winstone (http://winstone.sourceforge.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat & JDK for PDA arm processor
Costin, If it's the java util collection classes you mean, they were included from 1.2 and higher weren't they ? For the XML parser crimson was needed, because it was a 1.3 compliant JDK. Agreed about them not being in the spec, but things like basic/form auth are in the spec and they can be removed. Basically the goal was making it so only core components were required (or anything that was too difficult to abstract). (actually it was a guy called Petr Andre who managed to get it running in the CDC environment, not me but we emailed to discuss getting around some of the incompatibilities). Rick Costin Manolache wrote: Looks interesting, pretty good footprint. One correction - none of the features you mention are part of the Servlet spec actually, at least AFAIK. My understanding is that JNDI is required only if running in a J2EE env, and reloading, JSP, SSL, clustering are not required. How did you get it to run in CDC - don't you need the collection classes from JDK1.4 ? Costin On 4/24/06, Rick Knowles <[EMAIL PROTECTED]> wrote: (Forgive a shameless plug, but seems it might be relevant to this thread) I just thought I'd mention Winstone (winstone.sourceforge.net) for this application too - there have been some people running it successfully on J2ME CDC 1.0 PP 1.0. It also lets you cut out some parts of the spec you don't want (eg JSP, JNDI, servlet reloading, SSL, clustering) by deleting packages from the jarfile. Latest version is v0.8.1, but the CVS version is stable too. Thanks, Rick Costin Manolache wrote: Not sure Jetty is fit for embedded use either. http://khttp.objectweb.org/ - or something similar, capable of running in CVM or even KVM - could be a viable solution for java on low end devices. The real problem is not the size of tomcat itself - but the number of JVM classes it uses and all the layers and features that need to be loaded. What people fail to understand very often is that flash has very different characteristics from a hard drive, and a 200MHz processor and 32MB ( or even 400MHz/64MB ) are slightly different from a 2G Hz/ 1 G RAM or even a low end - 1GHz/256M :-) Costin On 4/23/06, Preston L. Bannister <[EMAIL PROTECTED]> wrote: How small does it need to be? If you really need a full HTTP + servlets configuration then it might be easier to use one of the smaller Jetty configurations ( http://jetty.mortbay.org/ ). Do you really need servlets (i.e. is this webapp meant to run anywhere)? Dropping the standard servlet interface will slim things down. Do you really need the ability to handle heavy traffic? Both Tomcat and Jetty put extra effort into handling large numbers of connections with high throughput - which translates to bigger code and data. If you don't need this ability, then a simpler HTTP server could be a better bet. -- Servlet v2.4 container in a single 160KB jar file ? Try Winstone (http://winstone.sourceforge.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Servlet v2.4 container in a single 160KB jar file ? Try Winstone (http://winstone.sourceforge.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS Issue
The point you're missing is likely that Tomcat as a project has standardized on subversion. Try: http://www.apache.org/dev/version-control.html#anon-svn for help. Rick animesh saxena wrote: Hi, I am trying to download Webapp module for intergating apache web server with tomcat. setenv CVSROOT :pserver:[EMAIL PROTECTED]:/home/cvspublic cvs login CVS password: cvs [login aborted]: connect to [apache.org]:2401 failed: Connection refused As per the apache site I am entering the password as anoncvs but still it is failing to login. Am I missing something? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_proxy_ajp and mod_unique_id
If this is on the wrong list, please redirect me: I wasn't sure exactly where the responsibility for mod_proxy_ajp lies. Until now I've been using mod_jk + mod_unique_id to pass an apache generated unique request id, so that my webapp's and apache's log data can be correlated. After switching to mod_proxy_ajp, the unique_id is no longer passed over the ajp wire to tomcat. This is understandable, since the request attribute concept in the AJP13 protocol isn't something that would exist across all mod_proxy flavours (http for example). There doesn't seem to be any name=value parameter for this purpose on the ProxyPass directive. Is support for this deprecated, or is there some way to pass the mod_unique_id to tomcat that I don't know about ? Thanks for any help in advance, Rick -- Servlet v2.4 container in a single 160KB jar file ? Try Winstone (http://winstone.sourceforge.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mod_jk] Documentation (offtopic)
Filip Hanik - Dev Lists wrote: yes, mod_proxy is probably a better choice, since it is HTTP, if you wanna use mod_jk the end point has to support the AJP protocol, I don't know that any other than jserv and tomcat are doing that right now. Actually I think you'll find it's in a little wider use than that. Winstone (see below) supports mod_jk AJP13, and a quick google showed that there's even a Perl module that acts as a listener. Sorry for the offtopic, I just thought I'd mention it so you know there are others using it. Rick -- Servlet v2.4 container in a single 160KB jar file ? Try Winstone (http://winstone.sourceforge.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: no possibility to cancel a post request with tomcat?
Christian, Unfortunately due to request pipelining (the norm in HTTP/1.1), any attempt to send an error message or abort just results in the container having to silently consume the body of the upload anyway. The next request in the pipeline after a medium size upload could even conceivably be in the same TCP packet, so the container has to consume every request to make sure it correctly locates the start of the next request. It isn't worth even trying to handle - it's a necessary evil, the flipside of the taken-for-granted speed boosts that request pipelining brings. Rick Christian Kindler wrote: Hi all, there seems to be no possibility to immediately cancel a (multipart) post request (for example if the content-length exceeds a certain limit). Whatever I do in a servlet's doPost method (throwing an exception, closing the request's stream, interrupting the current thread), the client continues sending the data to the server. So there is nothing I can do to prevent users from sending huge amount if data to the server and producing a lot of traffic. All I want to do is to cancel a request immediately. I don't care if the client get's a reasonable error message or if the connection remains or not. Is there any way to achieve this or is it a general problem of the HTTP protocol? I hope it's o.k. that I ask this question here, on the users list unfortunately nobody could help or explain the reasons for this behavior. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
