Re: Embedded Tomcat
Eric Holk wrote: I'm working on a project where I would like to run a simple web front end for it. To save the time of implementing my own HTTP server I'd like to embed Tomcat. I've read several documents on how to do this, and I've managed to get Tomcat running inside my program. However, all the examples I've seen show how to load a WAR file and use that as a web application. If it's possible, I'd rather just have a sevlet class inside my program that Tomcat uses rather than having an external web application. You should be able to get away with just a single external file: a web.xml file that mounts the servlet and maps it to a URI pattern. The rest of the webapp code (ie the servlet class you mentioned) would be able to be inside the main jar, because class loader inheritance would cause the servlet class to be visible even if it's not in the WEB-INF/classes folder. If one external file is too many, you might need to do something tricky to set the webapp's mounted instances from code. Maybe via JMX ? Someone else might be able to help here Rick -- Servlet v2.4 container in a single 155KB jar file ? Try Winstone (http://winstone.sourceforge.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems Parsing Request Paramers
Yoav Shapira wrote: Hi, Could it be the referer URL is too long, causing the query string to be ignored or dropped? There's a limit (2048 characters, I think?) on GET requests in some browsers. But actually, you're seeing this on the server, so I'm not sure. Can you try testing with less parameters or an otherwise shorter query string? I've seen this sort of thing too, but I thought it was 255 chars. From RFC2616 section 3.2.1: Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths. Not quite set in stone, but a good general hint to avoid long URLs. Rick -- Servlet v2.4 container in a single 155KB jar file ? Try Winstone (http://winstone.sourceforge.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jasper TCKing
All, Not sure how to go about this, but I wanted to offer my services with TCK compliance testing of tomcat/jasper. I have been granted JSR 152 and 154 TCK karma for my own container (winstone), and I figured since TCK karma is so hard to get, you guys might appreciate having someone else who can share the responsibility for tomcat. Obviously there would be some working out of communication details because of TCK contract restrictions, but that shouldn't be hard. It's in my interest to help with compliance because Jasper is being used within Winstone - I've got it to pass all the JSR154 tests, but the 152 tests were failing in a few places ... I haven't been on this list for a while, so shoot me down if this is a known problem - I ran the JSP TCK over jasper + tomcat 5.5.9, and noticed that there were a few test failures when I ran it (four or so that I counted in the api section). The main reason was that under winstone I noticed the errors, so I tried running it against tomcat, and got the same errors. It's possible they've been excluded and I've misconfigured my test environment, so I well and truly leave open the possibility it's my fault - just wanted to check. Anyway, please let me know if the help is needed. Rick -- Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sourceforge.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jasper TCKing
Yoav, Thank you for the offer. It's certainly welcome. We have TCK grants for these APIs at Apache, and have had them for years. (In fact, the ASF has TCK rights from Sun for virtually every API out there ;)) But as you've noted, it's a time-consuming task, and in general we gladly welcome external help in all areas. Yes - I noticed the Apache Watchdog project heritage. Couldn't help but laugh that Sun are charging for the same tests now (for commercial vendors anyway) ... The main thing I wanted to offer was to help with running it before releases (which I think is part of the contract), and my understanding is that only the individuals within the project that sign their lives away to Sun are allowed access to the TCK, which I would guess isn't everyone on the tomcat-dev team. Would it be possible for you to run the TCK occasionally (as your time permits, of course) on publicly-released Tomcat versions, and post the results either to this mailing list or as a Bugzilla issue for Tomcat? If not, we'll see what we can work out. There are some more private forums to which that information can go, but the public route is preferred, to help our users with their QA and due diligence tasks. OK - no problem. Is it okay to post the results of TCK tests publicly though ? I thought that wasn't allowed by the contract. I guess it should be okay if I just publish the test groups and indexes that fail. The tests that failed were: jsp/api/javax_servlet/jsp/pagecontext: tests 15,28,30 jsp/api/javax_servlet/jsp/tagext/simpletagsupport: test 7 jsp/spec/core_syntax/actions/invoke: test 7 jsp/spec/core_syntax/implicitobjects: test 3 jsp/spec/tagfiles/semantics: tests 1,2,3,4 Note this is 5.5.9, so possibly already fixed. Rick -- Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sourceforge.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: DefaultServlet and getOutputStream() / getWriter()
Steffen, My understanding (and I might be wrong here, so someone please correct me if I am) is that once you've called getWriter(), you can't call getOutputStream() on the same request. The reason is primarily so that you have to use the same char encoding etc on included servlets as in the including servlet. Calling getOutputStream after getWriter results in an exception being thrown in Tomcat, hence the try/catch. Rick Knowles PS And for the record, I thought Remy's response was pretty harsh too. Steffen Heil wrote: Hi That's definitely why I am not interested by code cleanups done by folks who might not know all the small tricks: the risk of breaking stuff is far greater than the gain. Why are you soo hostile? I am just trying to get into the code and if I understand it, I will propably start to contribute something. But I need to start somewhere and I cannot know all the small tricks from beginning. THAT IS WHY I AM ASKING! I did not say remove that shit, nor did I say this is stupid. I just asked why it is done that way. Additionally, every change I suggested (on tomcat-user) was definitly not changing any behaviour, but maybe improving performance. So I need to give that back to the authors. Things that are not self-evident should be documented in code. There is nothing. And again, please see, that this is no allegation. But someone will know it and it is not in the code, so you should accept questions. You told me: ... submit more significant patches ... How should I, if I cannot even get information about easy things? For this particular case, you should look into the API javadocs. That's what I have done for some hours. Returns a ServletOutputStream suitable for writing binary data in the response. The servlet container does not encode the binary data. java.lang.IllegalStateException - if the getWriter method has been called on this response java.io.IOException - if an input or output exception occurred If I believe that javadocs, THERE IS NO REASON to do what the code does, sind getWriter is never called before getOutputStream, so there will never be the IllegalStateException and half of the code is obsolete. That is exactly the reason I am asking. Regards, Steffen -- Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sf.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Request dispatching question
Tomcat devs, I've noticed an interesting behaviour when moving some webapp code from Winstone to Tomcat, and I'd like to get an opinion on whether what it's by design, accidental or I've misinterpreted the spec (equal likelihood of any of the above). The webapp implements access control using a filter and a request wrapper. The filter is mapped to the protected directory, and any request that passes through gets checked for a token. If the token is not found, it dumps the contents of the request into a session object, and forwards to the login servlet. After the login is approved, the token is set, and a client side redirect to the original location is sent with a key added. On this second pass through the filter, the key is used to look up the session object storing the details of the original request. The filter constructs a request wrapper from that session object that makes the new request mimic the original one (eg when getRequestURI is called, it returns what the pre-authentication request's uri was, same for getServletPath, etc) This approach seems to work well with the first servlet, but if that servlet forwards to another servlet, it breaks down. It seems like on a forward, Tomcat sees that the request object it is handling is not the CoyoteRequestFacade and doesn't bother trying to reset the pathInfo, servletPath etc, so forwarding to a JSP seems to fail. It works ok on Winstone, because on a forward it unwraps the request until it hits something that's not a wrapper, resets the pathInfo/servletPath/etc, and passes it into the filter chain. It seems (from the outside) like Tomcat doesn't try more than one unwrap attempt. All of this is without yet looking at Tomcat source, so if I'm making a fool of myself just point me at a file and I'll disappear. My question is this (sorry I took so long to get to it) - what is the correct behaviour here ? Should it unwrap all the way, or only one step ? Is the behaviour I'm seeing expected or is something wrong ? Thanks in advance, Rick Knowles -- Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sf.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: port number at runtime
Having this as a requirement makes an awful lot of assumptions about the architecture of the container, none of which are helpful in the larger scale. For example, what if you have 2 (or 50) http connectors and the same for https ? And then what about ajp13 ? Or mod_caucho's protocol (I think it's called hessian) ? The reason this is not in the servlet api spec is because it would create more problems than it would solve. There are some cases where you just need to know what your deployment environment is going to be ... this is one of them. Rick saugata ghosh wrote: request.getServerPort() -Thanks, but this returns the port number of the current request port. But my problem is, say the request is for http: and I want to redirect to https:/.../somefile.jsp. - then ? Basically what is required is a method that will return the port number set in the conf/server.xml file. -Saugata -- Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sourceforge.net) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding Jasper / JSP compiling
Remy, So now that you have learnt, are you more ineterested in using the TC connectors ? Casually looking at the HTTP code, I can say it is not especially efficient (and really optimizing this part is rather long and painful). If you want to join this project, your servlet API implementation could become an alternative to Catalina (I know the idea floated around on a few occasions in the past). Rémy I've been thinking a lot about this over the last few days about this, and I think the best answer to give is thanks for the offer, but not just yet. Having watched this list for the last month or so now, I can anticipate there would be clashes in working style and priorities that would be more hassle than they were worth for all involved. I know it sounds selfish, but I guess I'm just enjoying having this as a solo project too much to give it up yet. I think the best plan would be to wait until I feel Winstone has reached its end point (in terms of what I can give it), and then just donate it so you guys can replace whatever you want. Thanks again for the offer ... it was very tempting, but knowing the way I work, I'd say not good in the long term. Rick - Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sf.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hypothetical
As for the orininal question: you cannot support scriplets without compiling. I know Kin-Man has entertained the idea of using straight code generation for tags-only pages, but assuming the super-duper-compiler from the JCP shows up, the incentive isn't very big. Rémy Thanks - this is exactly the kind of gotcha I was hoping someone would point out. Much appreciated. Rick - Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sf.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hypothetical
Tomcat dev types, This is not a request for enhancement or change in any way, just seeking an opinion on an idea. Has BCEL ever been considered for use with in a JSP compiler like Jasper ? I'm currently toying with trying to start a new JSP compiler project to go with Winstone (servlet engine), and so started looking at things like XSLTC for ideas. I noticed it was using BCEL, and in doing so avoided the need for more than a JRE. Do any of you know of a JSP compiler already existing that uses this approach ? More importantly do any of you know of a reason why this would be a bad idea ? Any comments would be appreciated. Thanks in advance, Rick Knowles - Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sf.net/) http://winstone.sourceforge.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hypothetical
Yoav, You know Servlet Spec compatibility requires env-entry/resource-ref support and therefore at least a slim JNDI implementation... Yoav Shapira Millennium Research Informatics Thanks for the reply. I've only just (as in this morning) received a reply from the JCP people saying I'd be sent a TCK soon. Until then, I figure it's ok to say it's spec compliant as long as it works with all the apps I've tested, and I tell everyone I haven't run the TCK tests yet. Maybe in another month the JCP people will send me the TCK ... until then though, not much I can do. Interesting though - the spec says: quote from p104 section 13.1 The following additional elements exist in the Web application deployment descriptor to meet the requirements of Web containers that are JSP pages enabled or part of a J2EE application server. They are not required to be supported by containers wishing to support only the servlet specification: jsp-config Syntax for looking up JNDI objects (env-entry, ejb-ref, ejb-local-ref, resource-ref, resource-env-ref) Syntax for specifying the message destination (message-destination, message-destination-ref) Reference to a Web service (service-ref) /quote from p104 section 13.1 I wasn't planning for Winstone to be a full J2EE compliant container, so I took this to mean resource-ref, et al were optional. Did I read it wrong ? Rick Knowles - Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sf.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hypothetical
Yoav, I think you read it correctly, and interpreted it correctly. It's a distinction between the Servlet and JSP specifications. You just have to be careful to mention those sort of things up front, as people might expect those features from a Servlet v2.4 container (because all other servlet containers I know of do support these features, and very few people know the spec by heart). This is a fair point. I'll change the doc to something a little clearer. Or maybe I'll just implement the remaining pieces as components for the full jar set only (ie the non-lite version). Thanks again, Rick - Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sf.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.25 does not honor error-page directive?
What does the rest of the web.xml look like ... could it be an order thing (DTDs impose ordering on the elements) ? Which DTD/XSD did you use ? Rick Knowles Detlef Pleiß wrote: In a freshly unzipped jakarta-tomcat-5.0.25 installation I added error-page error-code404/error-code location/404.html/location /error-page (copied from servlet-2_4-fr-spec.pdf page 153) Just before the closing /web-app in webapps/ROOT/WEB-INF/web.xml I then copied a simple 404.html file to webapps/ROOT. However, when requesting some non existing page like http://127.0.0.1:8080/blub.jsp I get the standard browser 404 error page (in my case MSIE) not my 404.html. Is this a bug? Ciao - thanks - Det. - 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]
Re: Tomcat 5.0.25 does not honor error-page directive?
Sorry - just checked the file. There's only servlet and servlet-mapping elements. My bad Rick Knowles Detlef Pleiß wrote: In a freshly unzipped jakarta-tomcat-5.0.25 installation I added error-page error-code404/error-code location/404.html/location /error-page (copied from servlet-2_4-fr-spec.pdf page 153) Just before the closing /web-app in webapps/ROOT/WEB-INF/web.xml I then copied a simple 404.html file to webapps/ROOT. However, when requesting some non existing page like http://127.0.0.1:8080/blub.jsp I get the standard browser 404 error page (in my case MSIE) not my 404.html. Is this a bug? Ciao - thanks - Det. - 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]
Re: Embedding Jasper / JSP compiling
Dennis, I'm not a tomcat dev, but hopefully I can help anyway - having done what I think it is you're trying to do. I did mine for the Winstone servlet container (http://winstone.sourceforge.net) For Nos 1 and 2, I can't help. But for No 3 it involves setting context attributes: 1) org.apache.catalina.jsp_classpath, and 2) org.apache.catalina.classloader It seems that 1 is the one that does the work. It doesn't actually even seem to call 2 at class load time, but there is code that reads 2, so I set it anyway. By setting 1, you don't actually set the classloader, but you make a new classloader that has the same classpath. If that's not what you want, maybe someone else on the list can help. The only other thing you have to do is mount the JspServlet, which it sounds like you've already done. R Dennis Thrysøe wrote: Hi, I'm currently working on embedding a jasper engine within a servlet container that I'm writing. During this work I have run into the following questions: 1) Is the only advantage to using fork=true, that the javac memory leak issue is avoided? 2) Has the javac memory leak issue been fixed in newer versions of the JDK? 3) Is there any way to have the Java code generated from JSPs compiled using my own classloader? I was thinking, that if I used fork=false, maybe javac would just use the present classloader. Any help with the above questions would be greatly appreciated, since it seems that I'm on a fairly difficult endeavour here. TIA, -dennis - 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]
Re: ajp13 file upload bug
I also had this problem, although I was using my own Multipart Handler class based on Javamail. The upload works correctly using ajp12, but puts jibberish in the logs when ajp13 is substituted in. R - Original Message - From: "Stefan Busse" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 07, 2001 11:47 PM Subject: ajp13 file upload bug here we go... btw our system is Solaris 2.8 on Intel / Apache 1.3.17, compiled with gcc-2.95.2. Tomcat is run by jdk1.3. Maybe the problem is related with assumptions about header-sizes implemented in ajp13 ? Can you post this to the tomcat-dev mailing list? -jh- Stefan Busse wrote: Hi Jason, just stumbled across your post while looking for an answer for my own upload problems. In fact there seems to be an ajp13 bug. I just tried your demo-application because my own (primitive) upload-servlet stopped working when I switched from resin (connected through mod_caucho) to tomcat 3.2.1 (connected through mod_jk). Maybe ajp13 can't handle multipart-contents. There is no error in the logfiles, the servlet just seems to be stuck in a loop, as the browser uploads forever. Hope this helps, or maybe you can forward this to the wizard developing the ajp13-connector... * stefan busse -- To: [EMAIL PROTECTED] Subject: Possible ajp13 bug doing file upload posts From: Jason Hunter [EMAIL PROTECTED] Date: Sun, 07 Jan 2001 19:40:17 -0800 Hi, Here's a bug report in ajp13 from someone using my com.oreilly.servlet package to do file uploads. No real details, but I'm thinking perhaps someone with ajp13 running can test the file upload example? You can download the c.o.s. pkg from http://www.servlets.com/resources/com.oreilly.servlet. I'm happy to provide support. -jh- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some benchmarks
I know some guys at probably the biggest dot com in Japan (fill in the blanks), who tried out servlet engines looking for the elusive "next-generation" engine. They said they tried Weblogic, JRun and another one I can't remember as well as tomcat. they found that with the same code, they were able to serve a maximum of 55 million ad banners of up to 100KB per day with Tomcat (I think v3.0 or 3.1), compared with weblogic and jrun neither of which cracked 45 million (can't remember exact figures, but a significant difference). They also commented that tomcat had less memory leaks and crashed half as often. They were in the process of switching to Catalina when I spoke to them. Moral of the story is well done guys :). R - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]