Re: AJP connector maxthreads problem
Thank you David and Wade for this information. I now have an idea what caused it. I have a fairly new programme that uses too many threads, and I can deal with it. However I would like to try the thread dump, but running kill -3 xxx or kill -QUIT xxx on the first Tomcat thread found after running ps ax does nothing. It doesn't kill the thread and nor does it print out the trace. I've experimented using the kill manual but I don't seem to be getting anywhere. I still have a 1.4 JVM unfortunately (as I saw that Jikes couldn't yet be used with 1.5). Am I doing something wrong - how else can I get a thread dump? I have Debian Linux 2.4.24 for what it's worth. Malcolm Warren Wade Chandler wrote: --- David Wall [EMAIL PROTECTED] wrote: 1) We have only a moderately busy site with about 500 new visitors entering from outside every day, so it would have thought it would be fairly difficult for them to use up all the 75 connections at the same time, but I do have some programmes that create their own threads, though in a fairly limited way. In your expert view are 75 jk2 connections sufficient for this kind of moderate use, or is it likely I've some kind of problem I've got to get to the bottom of? I've been through my recent new applications, and there really is nothing that could have created this problem recently. It sure sounds like something is not releasing the threads. In low volume sites, having 75 concurrent requests would be high. It sounds like they are not being properly released when done. 2) I've set connectionTimeout=2, which seems to be what everybody else was setting it to, can I reduce this without any problem? It seems quite long, 20 seconds, why hang on to connections for so long, or is there a lot of overhead in creating them? I believe this value is how long Tomcat will wait to receive the actual HTTP requests after it establishes the connection. So 20 seconds is more than adequate. Making it too low may cause people are slower dial up or the like to get problems. 3) If I want to, can I increase my max connections to 125 without any qualms? - This would appear to be the simplest solution here. That would certainly work, but if you are running out because threads are not being released, it just means you'll run out later than before. Good luck, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Dump a stack trace of the JVM and see where it is locked up in the different threads. If you are able to run a 1.5 VM this would be much easier as you could use jps and jstack to dump all of this externally for your running tomcat process. Anyways, get a stack trace for all of your threads, and you can get a better idea of what is going on. Wade - 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: AJP connector maxthreads problem
P.S. I've found the stack trace in catalina.out. I thought I could pipe it to a file, but never mind. Anyway thankyou for your help, I think I can get to the bottom of it all now. Wade Chandler wrote: --- David Wall [EMAIL PROTECTED] wrote: 1) We have only a moderately busy site with about 500 new visitors entering from outside every day, so it would have thought it would be fairly difficult for them to use up all the 75 connections at the same time, but I do have some programmes that create their own threads, though in a fairly limited way. In your expert view are 75 jk2 connections sufficient for this kind of moderate use, or is it likely I've some kind of problem I've got to get to the bottom of? I've been through my recent new applications, and there really is nothing that could have created this problem recently. It sure sounds like something is not releasing the threads. In low volume sites, having 75 concurrent requests would be high. It sounds like they are not being properly released when done. 2) I've set connectionTimeout=2, which seems to be what everybody else was setting it to, can I reduce this without any problem? It seems quite long, 20 seconds, why hang on to connections for so long, or is there a lot of overhead in creating them? I believe this value is how long Tomcat will wait to receive the actual HTTP requests after it establishes the connection. So 20 seconds is more than adequate. Making it too low may cause people are slower dial up or the like to get problems. 3) If I want to, can I increase my max connections to 125 without any qualms? - This would appear to be the simplest solution here. That would certainly work, but if you are running out because threads are not being released, it just means you'll run out later than before. Good luck, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Dump a stack trace of the JVM and see where it is locked up in the different threads. If you are able to run a 1.5 VM this would be much easier as you could use jps and jstack to dump all of this externally for your running tomcat process. Anyways, get a stack trace for all of your threads, and you can get a better idea of what is going on. Wade - 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]
AJP connector maxthreads problem
I've got Tomcat 4.1.30 and Apache 1.3 on Linux and I've been using the jk2 connector for a year and a half without any problems. Now I've suddenly got Tomcat stopping with the following message: All threads (75) are currently busy, waiting. Increase maxThreads (75) or check the servlet status. Now I've done a lot of homework, googled and searched the jakarta site, but I can't seem to get answers to my specific questions, which if any of you are willing to help me, should be fairly simple to answer. 1) We have only a moderately busy site with about 500 new visitors entering from outside every day, so it would have thought it would be fairly difficult for them to use up all the 75 connections at the same time, but I do have some programmes that create their own threads, though in a fairly limited way. In your expert view are 75 jk2 connections sufficient for this kind of moderate use, or is it likely I've some kind of problem I've got to get to the bottom of? I've been through my recent new applications, and there really is nothing that could have created this problem recently. 2) I've set connectionTimeout=2, which seems to be what everybody else was setting it to, can I reduce this without any problem? It seems quite long, 20 seconds, why hang on to connections for so long, or is there a lot of overhead in creating them? 3) If I want to, can I increase my max connections to 125 without any qualms? - This would appear to be the simplest solution here. Thanks for any help on this. Regards, Malcolm Warren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jsessionid parameter not being accepted
I have done my own url re-writing manually to cater for those browsers who have turned off cookies. i.e. I have manually added ?jsessionid=session id parameter to every url. This worked well in Jrun, but Tomcat is not accepting the jsessionid parameter, and is creating a new session each time. The tomcat session manager is the default one, in fact there is no session manager visibly enabled in server.xml, so everything is default. Has anybody got any ideas what is going on and what I should do? Regards, Malcolm Warren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsessionid parameter not being accepted
I wish it was as easy as you say... I know that I don't have to implement my own url re-writing, but I did, and it was a long time ago! Right now I don't really want to re-write everything - sending the jsessionid as an ordinary parameter worked in Jrun, can't it work in Tomcat? On Thu, 15 Apr 2004 15:25:00 +0200, Ralph Einfeldt [EMAIL PROTECTED] wrote: - You don't have to implement your own url re-writing - The time is long gong when the session id was a parameter, it's now before the ? Just throw away your url rewiting and use rsponse.encodeUrl() instead. -Original Message- From: Malcolm Warren [mailto:[EMAIL PROTECTED] Sent: Thursday, April 15, 2004 3:16 PM To: [EMAIL PROTECTED] Subject: jsessionid parameter not being accepted I have done my own url re-writing manually to cater for those browsers who have turned off cookies. i.e. I have manually added ?jsessionid=session id parameter to every url. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsessionid parameter not being accepted
OK, I think I'll have to re-write, at least that way I eliminate incompatibility across servlet containers. Thanks everyone for your advice. On Thu, 15 Apr 2004 18:46:53 +0400, Veniamin Fichin [EMAIL PROTECTED] wrote: Malcolm Warren wrote: I wish it was as easy as you say... I know that I don't have to implement my own url re-writing, but I did, and it was a long time ago! Right now I don't really want to re-write everything - sending the jsessionid as an ordinary parameter worked in Jrun, can't it work in Tomcat? You may be required to implement custom Manager (see org.apache.catalina.Manager interface), where you'll put your session id generation logic. But if you are not absolutely forced to use that old-fashined url-rewrite style, you should use session mechanism described in Servlet spec. That spec also mentions url-rewrite solution, when a user have switched cookie off, but still it is advisable to use response.encodeURL(String) method. Read description of javax.servlet.http.HttpServletResponse.encodeURL(String) for a more advanced explanation. On Thu, 15 Apr 2004 15:25:00 +0200, Ralph Einfeldt [EMAIL PROTECTED] wrote: - You don't have to implement your own url re-writing - The time is long gong when the session id was a parameter, it's now before the ? Just throw away your url rewiting and use rsponse.encodeUrl() instead. - 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]
Tomcat Security Constraints
Hi, I have been using basic authorization with SSL in Tomcat for some time, quite satisfactorily. However I have found what I feel to be some strange behaviour on the part of Tomcat (I have 4.1.30) in one case. Here's an example: I have a folder, let's say http://www.mysite.com/prot/. I put a security-constraint on this folder in web.xml so that it is protected and requires basic authorization. So far so good. But I have discovered that if you include a document from that protected folder inside a document from an unprotected folder using a jsp:include, then basic authorization is no longer requested by the browser for the protected page. Surely the authorization should be requested in all places and at all times, whereever the request is coming from, even if from an include in an unprotected page? --- This leads on to my second question. I have been trying to solve one small though potentially dangerous problem with Basic Authorization/SSL. If I want to access a protected area of our site from outside the firewall I write an address similar to the following: https://mysslsite.com/pagerequired.jsp. It has happened that I forget to type https:// and type http:// instead. So if a nasty, mean person is listening in, he can see my password unencrypted, right? How can I prevent this? The problem is that the login window with basic authorization pops up before you arrive at the page itself. I thought of FORM authorization, because the .jsp used for the Login form can check the port requested (must be 443) and refuse to request the password if it's wrong. But FORM authorization requires lots of extra programming to give many of the useful extras that BASIC authorization offers included (e.g. remembering your user name and password). Then I thought of including the protected page in an unprotected page that checks if you are in https before doing the include. But since Tomcat has this strange behaviour I mentioned above, after a couple of days of fiddling with this possibility I've had to give that up too. Anybody got any ideas? Thanks for your time, Malcolm Warren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FORM authentication - prevent login from popping up
I'm switching from Basic (with SSL) to Form authentication (also with SSL of course). This has caused a problem with one particular application, which opens a socket on a .jsp page, collects the html code and saves it disk. The html code is then later used by a fax application to send a fax. With Form authentication I am getting a login popping up, which since I have already signed in, should be unnecessary if I provide the right stuff to Tomcat. For Basic authorization, all the application had to do was send an Authorization header and in I went without a login. But with Form authentication I am unable to prevent the new login. I assumed that setting the JSESSIONID and JSESSIONIDSSO cookies would be sufficient, and here is my code. OutputStream out = sock.getOutputStream(); String firstLine = GET + fileName + HTTP/1.1\r\n; String secondLine = Host: + hostName + \r\n; send(out, firstLine); send(out, secondLine); send(out, Set-Cookie: JSESSIONID= + jsessionId + ;JSESSIONIDSSO= + jsessionidSSO + ; Path=/ + \r\n); send(out, \r\n); But unfortunately Tomcat isn't impressed and I get a login page. Can anybody tell me where I'm going wrong? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does Tomcat manage Form-based authentication?
Thank you for your answer. Sorry about the new thread for new topic business - I hadn't understood the thread mechanism. I presume for this topic I'd better continue as we are and I'll get it right next time. I was wondering exactly how the servlet container knows whether the user has already authenticated or not. With BASIC authorization an Authorization header is sent and based on that the programmes know whether to re-present the sign in or not. I'm using an old nuts and bolts programme that actually programmatically sent the Authorization header string for BASIC authorization, and I'd like to continue using this programme, but I have to tell the new FORM version that I've already signed in, and I don't know how. On Thu, 1 Apr 2004 09:10:18 -0600, QM [EMAIL PROTECTED] wrote: On Thu, Apr 01, 2004 at 04:38:49PM +0200, Malcolm Warren wrote: : With BASIC authorization, which I used to use, the browser was sent an : Authorization header. : : This doesn't happen with FORM-based authorization. : I believe Tomcat deals with it all, but how? Anybody know? Not sure I understand your question -- with FORM-based auth: - the container detects an attempt to access a protected resource - container sends requestor to designated form page, which posts to the blackbox j_security_check - success = user is taken to originally-requested page - failure = user is taken designated no-go page Is that the answer to your question? btw, please start new threads for new topics -- replying to an old message plays hell with thread-aware mail readers, even if you change the subject. ;) -QM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Of .war and .jar files - and .jsp class files
That's not quite what I meant, but I shan't want to bother people any more with this question. I can get along with what you told me in another email. Thanks for you time. Malcolm Warren On Thu, 1 Apr 2004 09:06:51 -0600, QM [EMAIL PROTECTED] wrote: : The automatically generated .class files in Tomcat are in the : org.apache.jsp package, but the folders /org/apache/jsp aren't there in : the file system, if you see what I mean. It would have been nice if the : package logic had been followed through. ? I'm not sure I follow. I just checked my own jar of precompiled JSPs and saw the following: org/apache/jsp/index_jsp.class (etc, etc ...) Perhaps I missed this in your original post: do you run Tomcat4 or 5? My knowledge of (Tomcat) precomp is solely from the 5.x series. -QM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does Tomcat manage Form-based authentication?
I've tried including the session id, but it creates a new one. It's calling a url in another application in the same engine. Can't session info be shared across applications? I've allowed single sign-on in server.xml. I don't want to merge them into one application, because I may put one of them in another virtual machine. On Fri, 2 Apr 2004 10:31:59 +0200, Ralph Einfeldt [EMAIL PROTECTED] wrote: That information is stored in the session. So your programm has to include the session id that was created by tomcat in the requests (either as cookie or as query parameter) -Original Message- From: Malcolm Warren [mailto:[EMAIL PROTECTED] Sent: Friday, April 02, 2004 10:12 AM To: Tomcat Users List Subject: Re: How does Tomcat manage Form-based authentication? I'm using an old nuts and bolts programme that actually programmatically sent the Authorization header string for BASIC authorization, and I'd like to continue using this programme, but I have to tell the new FORM version that I've already signed in, and I don't know how. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leak Solution?
I'd be very interested to hear how one can allocate memory without it being de-referenced. It's obviously something to avoid. Can you give a bit of detail? Thanks. On Fri, 2 Apr 2004 10:28:22 -0600, John Thompson [EMAIL PROTECTED] wrote: I've been fighting a similar symptom. I downloaded the eval copy of JProfiler and found the problem pretty quickly. I had some static classes that kept allocating memory that never got de-referenced. John -Original Message- From: LILES, DAVID (CONTRACTOR) [mailto:[EMAIL PROTECTED] Sent: Friday, April 02, 2004 9:50 AM To: [EMAIL PROTECTED] Subject: Memory Leak Solution? I've searched previous postings for a possible solution regarding the memory leak thread that was posted previously but didn't seem to find an answer. I'm running TC5 on IIS5 and have noticed that the memory gradually decreases to the point where the server needs to be rebooted. Does anyone know of a solution for this? Thanks. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Of .war and .jar files - and .jsp class files
Dear QM,
Just a footnote to this problem, if you're interested.
The difference between Tomcat and Jrun on this problem of packing up the
automatcally-generated .class files for .jsps is considerable, and I have
to say that in this case Jrun looks more logical. With Tomcat, as you have
explained, in order to get it to work you have to create all the servlet
mappings.
This wasn't necessary in Jrun, because you simply put a .jar file in place
of the unpacked classes, and the servlet container had no trouble finding
them, because the .jar file was in exactly the same place as the unpacked
.class files.
For some reason there isn't this easy relationship between the location of
the tomcat-generated .class files and the path through the file system.
The automatically generated .class files in Tomcat are in the
org.apache.jsp package, but the folders /org/apache/jsp aren't there in
the file system, if you see what I mean. It would have been nice if the
package logic had been followed through.
Regards,
Malcolm Warren
On Wed, 31 Mar 2004 09:50:41 -0600, QM [EMAIL PROTECTED] wrote:
On Wed, Mar 31, 2004 at 02:55:16PM +0200, Malcolm Warren wrote:
: Now when I transfer everything to my production server I would like to
: eliminate all of the .jsp pages from the application, and all of the
.java
: files, and just send a .jar file containing the .class files in
: /work/Standalone/localhost/$applicationDir.
You can do this.
Sort of.
That's what precompilation is all about.
Please bear with me:
- JSPs get compiled down to servlets, either by you (precompiling) or by
the container (at runtime).
- when the container compiles a JSP for you, it takes care of mapping
the servlet to the context-relative URI that matches the JSP. So
/x/y.jsp is mapped, behind the scenes, to some.package.x.y_jsp.class.
To precompile the JSPs means you must tell Tomcat yourself which
classes map to given URIs. Hence the autogenerated file full of
servlet and servlet-mapping entries I described in my last
message.
- When you precompile, you have can even put the classes into a jar file,
but that jar file must be in {dist}/WEB-INF/lib. That's the only way
Tomcat's classloader will find the jar.
- With the JSPs compiled down to code, and properly mapped in web.xml,
you can remove the JSPs from your app.
See
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/printer/jasper-howto.html#Web%20Application%20Compilation
for more details on the precompilation process (assuming TC5). It
mentions the generated web.xml fragment of which I spoke.
: That way the compilation is already done, and nobody can study my .jsp
: files. In theory I could just create a directory tree somewhere of
: org/apache/jsp/ copy all the automatically generated .class files into
: this directory tree and .jar it all up, and Tomcat should find them
either
: in /WEB-INF/lib or in /work/Standalone/localhost/$applicationDir, but
it
: doesn't.
Close, except that the jar of JSPs must exist in {dist}/WEB-INF/lib.
Tomcat won't load a jar from the context dir itself, aka
.//localhost/$applicationDir. Just not how Tomcat works. ;)
-QM
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
How does Tomcat manage Form-based authentication?
With BASIC authorization, which I used to use, the browser was sent an Authorization header. This doesn't happen with FORM-based authorization. I believe Tomcat deals with it all, but how? Anybody know? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Of .war and .jar files - and .jsp class files
I am changing from Jrun to Tomcat and I have just one problem remaining. Jrun gave an additional security possibility that I am unable to extend to Tomcat. In Jrun you do not need to place your .jsp files, nor the automatically generated .java files on your production server. I could simply .jar up the automatically generated .class files and place the .jar file in the /WEB-INF/jsp folder on the production server. That way I had 3 big advantages: 1) Nobody could look into my .jsp files. 2) Nobody could look into my .java files for my .jsps 3) Compilation on the production server of the .jsps was already done. - Everything was ready in the single .jar file. Now perhaps I am missing something, so please put me right. And I'm just starting now to use ant and I've never bothered with .war files because I don't distribute my programmes, they're just used on our production server. If I create a .war file for the production server then the .war file contains no compiled .jsps, just the original .jsp files - is that right? There seem to me to be obvious advantages to what I was able to do in Jrun - can I do something similar in Tomcat? In general I get many more security features with Tomcat 4.1, than I did with Jrun 3.1, but this particular possibility seems to me to be a good one. I have tried creating .jar files of the Tomcat's /work directory but without any success. Can anybody enlighten me? Thanks for any help. Regards, Malcolm Warren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Of .war and .jar files - and .jsp class files
Thank you very much for your answers, but they haven't quite hit the mark yet. Every .jsp page in Tomcat, as we all know, is compiled in /work/Standalone/localhost/ in an appropriate application folder e.g. _ is the folder in the case of the ROOT application. It's fine by me if this is done when I first access the page in a browser in my test environment. Now when I transfer everything to my production server I would like to eliminate all of the .jsp pages from the application, and all of the .java files, and just send a .jar file containing the .class files in /work/Standalone/localhost/$applicationDir. That way the compilation is already done, and nobody can study my .jsp files. In theory I could just create a directory tree somewhere of org/apache/jsp/ copy all the automatically generated .class files into this directory tree and .jar it all up, and Tomcat should find them either in /WEB-INF/lib or in /work/Standalone/localhost/$applicationDir, but it doesn't. Of course I could be missing the point entirely here, and I shouldn't even by thinking about doing these things, but as I say, in Jrun I could send the automatically generated .jsp .class files to the production environment in a nice .jar file and I had more security because noone could read the original .jsp files, although to be honest there aren't any people in my company who would be interested in reading them, but I feel more secure that way. Any more enlightenment on this would be very helpful. On Wed, 31 Mar 2004 06:00:22 -0600, QM [EMAIL PROTECTED] wrote: On Wed, Mar 31, 2004 at 12:02:40PM +0200, Malcolm Warren wrote: : Jrun gave an additional security possibility that I am unable to extend to : Tomcat. In Jrun you do not need to place your .jsp files, nor the : automatically generated .java files on your production server. I could : simply .jar up the automatically generated .class files and place the .jar : file in the /WEB-INF/jsp folder on the production server. Tomcat does something similar: - As one poster already mentioned, keep all of your jar files in WEB-INF/lib. - make sure the JSPs are mapped to servlet paths in WEB-INF/web.xml. (I'm out on a limb here, but it sounds as if Jrun automagically loads your JSP jar file and creates the mappings for you.) If the latter sounds like a pain in the rear, there are Ant tasks to do the precompilation for you and generate the web.xml snippet. : If I create a .war file for the production server then the .war file : contains no compiled .jsps, just the original .jsp files - is that right? Not true. The war file contains whatever you put in it. JSPs, images, jars, whatever. -QM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Of .war and .jar files - and .jsp class files
Ok, thanks. That looks like what I'm looking for.
Sorry I didn't catch on after your first missive.
On Wed, 31 Mar 2004 09:50:41 -0600, QM [EMAIL PROTECTED] wrote:
On Wed, Mar 31, 2004 at 02:55:16PM +0200, Malcolm Warren wrote:
: Now when I transfer everything to my production server I would like to
: eliminate all of the .jsp pages from the application, and all of the
.java
: files, and just send a .jar file containing the .class files in
: /work/Standalone/localhost/$applicationDir.
You can do this.
Sort of.
That's what precompilation is all about.
Please bear with me:
- JSPs get compiled down to servlets, either by you (precompiling) or by
the container (at runtime).
- when the container compiles a JSP for you, it takes care of mapping
the servlet to the context-relative URI that matches the JSP. So
/x/y.jsp is mapped, behind the scenes, to some.package.x.y_jsp.class.
To precompile the JSPs means you must tell Tomcat yourself which
classes map to given URIs. Hence the autogenerated file full of
servlet and servlet-mapping entries I described in my last
message.
- When you precompile, you have can even put the classes into a jar file,
but that jar file must be in {dist}/WEB-INF/lib. That's the only way
Tomcat's classloader will find the jar.
- With the JSPs compiled down to code, and properly mapped in web.xml,
you can remove the JSPs from your app.
See
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/printer/jasper-howto.html#Web%20Application%20Compilation
for more details on the precompilation process (assuming TC5). It
mentions the generated web.xml fragment of which I spoke.
: That way the compilation is already done, and nobody can study my .jsp
: files. In theory I could just create a directory tree somewhere of
: org/apache/jsp/ copy all the automatically generated .class files into
: this directory tree and .jar it all up, and Tomcat should find them
either
: in /WEB-INF/lib or in /work/Standalone/localhost/$applicationDir, but
it
: doesn't.
Close, except that the jar of JSPs must exist in {dist}/WEB-INF/lib.
Tomcat won't load a jar from the context dir itself, aka
.//localhost/$applicationDir. Just not how Tomcat works. ;)
-QM
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ssi and #exec
I need SSI in Tomcat as I have legacy .shtmls in the Search Engines, but for obvious reasons am alarmed at the possibilities provided by SSI #exec, which can run any system command. It's not an enormous problem for us, because nobody is writing any web pages or programmes on our machine except me, and anyway we're going to chroot Tomcat, but all the same... I only need #include, and I don't think that any of the other commands are a problem, but #exec makes the hairs go up on the back of my neck. Are there any plans to give the possibility of excluding #exec with a simple parameter, like the Apache option includeNoExec? Thanks. Malcolm Warren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CATALINA_BASE in jwsdp
I have a very recent Java Web Services installation and Tomcat 5 is bundled with it. I have a problem that I see has been met with by others using jwsdp, and not solved. I would like to be able to run multiple Tomcat instances. So I have tried to create a new directory for my web applications and I try to start tomcat 5 using the CATALINA_BASE environment variable. Unfortunately jwsdp completely ignores CATALINA_BASE. I see that others have only been able to solve the problem by downloading Tomcat separately, and the problem has gone away. Does anyone know what to do about this? I'd like to stay with Tomcat inside Java Web Services. The script in catalina.sh calls jwsdp. Does anyone know who maintains jwsdp? I've sent an email to Sun, but is there anyone at Jakarta who can be contacted? As far as I know jakarta has nothing to do with it, but you never know. Any help would be appreciated. Regards, Malcolm Warren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CATALINA_BASE in jwsdp
I think I have found something to do with it.
in jwsdp-shared/bin/launcher.xml there is a line as follows:
sysproperty key=catalina.base value=${jwsdp.home}/
This line is surprising to say the least! It seems to be actively ignoring
the CATALINA_BASE variable!
and in fact if I hard-code the value here with my CATALINA_BASE directory
it all starts to work.
Now does anyone know what I should put here so that it picks up the
CATALINA_BASE environment variable?
I tried the following which didn't work:
sysproperty key=catalina.base value=${CATALINA_BASE}/ - doesn't work.
Lastly does anyone know why this happens in the Java web Services
Development Pack unlike the normal Tomcat distribution, which I have read
in several places does not have the same problem? There must be a reason,
which is worrying me
Thanks.
On Fri, 19 Mar 2004 13:55:13 +0100, Malcolm Warren
[EMAIL PROTECTED] wrote:
I have a very recent Java Web Services installation and Tomcat 5 is
bundled with it.
I have a problem that I see has been met with by others using jwsdp, and
not solved.
I would like to be able to run multiple Tomcat instances.
So I have tried to create a new directory for my web applications and I
try to start tomcat 5 using the CATALINA_BASE environment variable.
Unfortunately jwsdp completely ignores CATALINA_BASE. I see that others
have only been able to solve the problem by downloading Tomcat
separately, and the problem has gone away.
Does anyone know what to do about this? I'd like to stay with Tomcat
inside Java Web Services.
The script in catalina.sh calls jwsdp. Does anyone know who maintains
jwsdp? I've sent an email to Sun, but is there anyone at Jakarta who can
be contacted? As far as I know jakarta has nothing to do with it, but
you never know.
Any help would be appreciated.
Regards,
Malcolm Warren
-
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: CATALINA_BASE in jwsdp
Thanks to anyone who read this email. But I've found a hack - or anyway I may just abandon JavaWebServices and go for Tomcat on its own. So don't worry about replying to this problem any more. Malcolm Warren On Fri, 19 Mar 2004 13:55:13 +0100, Malcolm Warren [EMAIL PROTECTED] wrote: I have a very recent Java Web Services installation and Tomcat 5 is bundled with it. I have a problem that I see has been met with by others using jwsdp, and not solved. I would like to be able to run multiple Tomcat instances. So I have tried to create a new directory for my web applications and I try to start tomcat 5 using the CATALINA_BASE environment variable. Unfortunately jwsdp completely ignores CATALINA_BASE. I see that others have only been able to solve the problem by downloading Tomcat separately, and the problem has gone away. Does anyone know what to do about this? I'd like to stay with Tomcat inside Java Web Services. The script in catalina.sh calls jwsdp. Does anyone know who maintains jwsdp? I've sent an email to Sun, but is there anyone at Jakarta who can be contacted? As far as I know jakarta has nothing to do with it, but you never know. Any help would be appreciated. Regards, Malcolm Warren - 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]
