Non-obsolete way of running Tomcat as a Windows Service?
The documentation for tomcat5.exe and tomcat5w.exe in 5.5 starts with: quote NOTICE This section of the documentation applies to procrun 1.0, and is now obsolete. /quote Now, it seems to work perfectly well, but I'm always wary about running things which are claimed to be obsolete. Is there a preferred way of running Tomcat as a Wndows service? The Windows installer isn't a good option for us (as far as I can tell), as we need a customised version of Tomcat to be installed as part of another installation process. Jon Skeet Clearswift monitors, controls and protects all its messaging traffic in compliance with its corporate email policy using Clearswift products. Find out more about Clearswift, its solutions and services at http://www.clearswift.com This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient, you must not copy, distribute or take any action in reliance on it. Unless expressly stated, opinions in this message are those of the individual sender and not of Clearswift. If you have received this communication in error, please notify Clearswift by emailing [EMAIL PROTECTED] quoting the sender and delete the message and any attached documents. Clearswift accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Clearswift domain. This footnote confirms that this email message has been swept by MIMEsweeper for Content Security threats, including computer viruses. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What does this mean?
Found this in my JK2 logs (Windows events): Emerg: [jk_isapi_plugin.c (426)]: HttpFilterProc [/cc200x/meta-inf/services/javax.xml.parsers.documentbuilderfactory] points to the web-inf or meta-inf directory. Somebody try to hack into the site!!! What does this mean? I believe it means that someone has requested a URL of http://servername/cc200x/meta-inf/services/javax.xml.parsers.documentbui lderfactory which the connector won't allow, because no-one should be trying to directly read from anything under the meta-inf or web-inf directories. Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What does this mean?
That's what I figured... However, the only one accesing the system at the moment is myself. It must be one of my servlets that places such a request. Why is there a meta-inf directory anyway? It is not reflected in the file system.? Consider a war file - that's likely to have a meta-inf directory. Now, exactly why your servlet is requesting that URL is a different matter... and worth tracing. Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IIS 5.1 and Tomcat 4
The module that could not be found, it seems like IIS is talking about isapi_redirect.dll. I don't know really how it all works with these isapi filters, but the file should be downloadable from a browser, so you should try pointing your browser to http://locahost/jakarta/isapi_redirect.dll and make sure you can download the file. If that does not work you have access problems. The IIS user can't reach the file. I think we are close to a solution now. Well done - that was indeed the problem! (I still can't download isapi_redirect.dll because I haven't given read access to the directory) but you pointed me in the right direction - I was pointing /jakarta at the tomcat directory rather than the directory underneath it. I've changed that, and it's all working fine now :) I think the reason I didn't check before was that clearly it *was* finding the module at some stage, otherwise I wouldn't have had an isapi.log file - but presumably it needs it in two different ways. Anyway, thank you ever so much - you're a star :) Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IIS 5.1 and Tomcat 4
snip log It seems like /mobilizer/mobilizer/ finds its way through, but the path /localhost/mobilizer/mobilizer doesn't. Is that correct? What is the path starting with /localhost, is this really your intention? There shouldn't be any path starting with /localhost. I'm visiting the URL http://localhost/mobilizer/mobilizer but the localhost part is the servername, not the path. This appears to be consistent with the log I get when I use the name of the computer rather than localhost, eg: [Tue Sep 23 10:40:11 2003] [jk_uri_worker_map.c (351)]: Into jk_uri_worker_map_t::map_uri_to_worker [Tue Sep 23 10:40:11 2003] [jk_uri_worker_map.c (368)]: Attempting to map URI '/treebeard/mobilizer/mobilizer/' [Tue Sep 23 10:40:11 2003] [jk_uri_worker_map.c (456)]: jk_uri_worker_map_t::map_uri_to_worker, done without a match My guess is that it's something IIS is doing for the sake of virtual hosting, but I wouldn't like to say for sure. The /mobilizer/mobilizer path is the correct one - but I don't know why it's then not getting any further than it is doing. Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IIS 5.1 and Tomcat 4
That explains the localhost part.
It worries me a bit though - I don't like the idea of paths having to
*not* start with the machine name, just in case things get confused :(
Then I would try with a network
sniffer (or whatever they are called)
to find out if IIS tries to contact tomcat at 8009. If you don't have
one, I suggest Ethereal at
www.ethereal.com/
I've got a port monitor which just shows connections - and it shows no
sign of IIS trying to contact Tomcat. I'll try with Ethereal as well.
BTW: Do you get a strange stacktrace at startup (MBean
something...)?
Nope.
Do the tomcat shutdown take a long time?
No - although to be fair I'm not using the normal NT service manager -
we have our own one which calls
org.apache.catalina.startup.Bootstrap.main (new string[]{stop})
basically.
It *did* give a stack trace before, but I've patched ChannelSocket to
stop that from misbehaving.
If so, you can try removing the connector at 8009 and instead use the
8081 one at port 8009.
The org.apache.coyote.tomcat4.CoyoteConnector is a new one used with
jk2, but I can't imagine that it won't work with jk as well, since the
protocol is the
same (ajp13).
That's what I was wondering - but I've tried just changing worker port
to 8081, and that doesn't seem to have made any difference.
Also you can add these rules to uriworkermap.properties, just
to see if
anything changes in the log file:
/localhost/mobilizer/mobilizer/*=$(default.worker)
/mobilizer/mobilizer/*=$(default.worker)
Well, now /localhost/mobilizer/mobilizer matches, but that's the only
real difference. The end of the log looks like this:
[Tue Sep 23 12:11:03 2003] [jk_isapi_plugin.c (555)]: HttpFilterProc
started
[Tue Sep 23 12:11:03 2003] [jk_isapi_plugin.c (600)]: In HttpFilterProc
Virtual Host redirection of /localhost/mobilizer/mobilizer/
[Tue Sep 23 12:11:03 2003] [jk_uri_worker_map.c (351)]: Into
jk_uri_worker_map_t::map_uri_to_worker
[Tue Sep 23 12:11:03 2003] [jk_uri_worker_map.c (368)]: Attempting to
map URI '/localhost/mobilizer/mobilizer/'
[Tue Sep 23 12:11:03 2003] [jk_uri_worker_map.c (391)]:
jk_uri_worker_map_t::map_uri_to_worker, Found a context match ajp13 -
/localhost/mobilizer/mobilizer/
[Tue Sep 23 12:11:03 2003] [jk_isapi_plugin.c (617)]: HttpFilterProc
[/mobilizer/mobilizer/] is a servlet url - should redirect to ajp13
[Tue Sep 23 12:11:03 2003] [jk_isapi_plugin.c (639)]: HttpFilterProc
check if [/mobilizer/mobilizer/] is points to the web-inf directory
I'll have a look with Ethereal now and see if that gives any more clues.
I'm sure we'll find something really silly in the end - it's just
finding it that's the problem :(
Thanks for helping,
Jon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: IIS 5.1 and Tomcat 4
I've got a port monitor which just shows connections - and it shows no sign of IIS trying to contact Tomcat. I'll try with Ethereal as well. snip Darn - Ethereal won't (as far as I can see) let me capture network activity within my own system (ie the loopback, effectively). Any ideas what will? (I've tried various sniffers in the past, and none of them have particularly appealed - I'd welcome recommendations.) Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IIS 5.1 and Tomcat 4
[Replying to two posts from Mats at once] (About not being able to sniff local packets) Correct, but can't you use a browser on another machine? Yes, but that wouldn't help - it's the IIS-Tomcat communication which is at issue here (I thought, anyway) and that would still be local. I don't have easy access to another machine to test all this with IIS on one box and Tomcat on another - although it's the next step if I can't get anywhere soon. What do you get in the browser when trying to connect? The specified module could not be found. Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IIS 5.1 and Tomcat 4
Please excuse my butting in mid-thread as I may have missed something. I've spent more time than I'd like getting IIS and Tomcat working in the past but unfortunately don't remember all the details. One thing I do notice from earlier thread is that you seem to be calling the host localhost. See below. Perhaps you should change it to machine name? It *should* be fine like that (as IIS and Tomcat are on the same machine) - I've used it before with Tomcat 3.2.3 and IIS with localhost. I'll certainly give it a whirl though. sfx: typing and clicking Nope. No luck. I've tried 127.0.0.1 and 192.168.0.8 (my IP address), and the results are the same. I don't have DNS running at home (where I am now) but I could try that tomorrow if you think it would be worth it - I'd have thought it should work with numeric addresses though. I've also tried changing the host to 128.0.0.1 - and I *still* don't see anything with Ethereal, which really *does* suggest that IIS isn't trying to connect. (I can see connection attempts with telnet to 128.0.0.1.) Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IIS 5.1 and Tomcat 4
I'm trying to get IIS 5.1 and Tomcat 4 to play nicely together. snip Did this question not get answered because: a) I didn't provide enough information b) Few people on the list have hooked IIS up to Tomcat c) A more interesting question (OutOfMemoryError) came in soon afterwards ? If you can spare a minute and know about hooking IIS and Tomcat together, I'd be grateful if you'd have a look - I don't think I can make much more headway on my own. Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IIS 5.1 and Tomcat 4
(Thanks for replying, btw :) I think you must have this row in your workers.properties: worker.list=ajp13 I'm afraid I already have that - I must have been a bit overenthusiastic when snipping my file down to a manageable file for mailing list purposes. o isapi_redirect.dll from http://apache.oregonstate.edu/jakarta/tomcat-3/bin/win32/i386/ (That's the only place I could find it, and it took a while to find... should I be worried that it's in the Tomcat 3 directory?) Go here instead. Seems better. http://www.apache.org/dist/jakarta/tomcat-connectors/ Sounds promising, but unfortunately it's empty as far as I can see. (Or rather, there are directories for coyote, jk, jk2 and webapp, but they're all empty.) o Registry entries in Jakarta Isapi Redirector\1.0 (which I think are okay) They are, you have the green up Good. One thing less to worry about :) snip server.xml has: !-- Define a Coyote/JK2 AJP 1.3 Connector on port 8081 -- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8081 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=0 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ !-- Define an AJP 1.3 Connector on port 8009 -- Connector className=org.apache.ajp.tomcat4.Ajp13Connector port=8009 minProcessors=5 maxProcessors=75 acceptCount=10 debug=0/ I was slightly unsure about this - given that I want the first one (note the non-default port, by the way) do I actually need the second? Should I just be able to change teh port in workers.properties? workers.properties in your configuration tells IIS that your worker (=tomcat) will listen at port 8009) while the Connector declaration in server.xml tells tomcat that it sould start the AJP13 Connector on port 8009. So, you need both. Sorry - I wasn't clear. What I meant was, can I get rid of the Ajp13Connector part of server.xml, and just use the JkCoyote connector? Or can I get rid of the JkCoyote connector and just use the Ajp13Connector? I can't see why I'd need both, but I'd appreciate any advice on which is better, etc. Any clues as to what I'm missing? IIS does listen on your requests and the dll is registered ok, but for some reason it can't map the request to a worker (= a running tomcat instance). I think it is because you miss the worker.list as I described it above. How I wish that were the case. One thing I'm *not* doing is specifying workers.tomcat_home or workers.java_home - as I'm starting Tomcat up separately, I don't think I need those. Is that right? I use jk2. Some people say it is not as stable as jk, but I have not encountered any problems with it yet. My reason is that the old jk does not support MBeans, don't ask what it is more precisely, but my tomcat will generate a (harmless) stacktrace at the beginning telling me this. Later when I shut my tomcat down, the shutdown process takes a long time, probably waiting to shut down the jk module in tomcat, which does not support being shut down like a MBean or something. Have you the same experience with jk? I haven't seen anything like that, although I needed to patch JK's ChannelSocket class in order to get it to shut down cleanly. (It's fine now though.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IIS 5.1 and Tomcat 4
Just checking this, my log definitely shows it's found the ajp13 stuff: [Mon Sep 22 16:22:03 2003] [jk_worker.c (82)]: Into wc_open [Mon Sep 22 16:22:03 2003] [jk_worker.c (207)]: Into build_worker_map, creating 1 workers [Mon Sep 22 16:22:03 2003] [jk_worker.c (213)]: build_worker_map, creating worker ajp13 [Mon Sep 22 16:22:03 2003] [jk_worker.c (138)]: Into wc_create_worker [Mon Sep 22 16:22:03 2003] [jk_worker.c (152)]: wc_create_worker, about to create instance ajp13 of ajp13 [Mon Sep 22 16:22:03 2003] [jk_ajp13_worker.c (922)]: Into ajp13_worker_factory [Mon Sep 22 16:22:03 2003] [jk_worker.c (161)]: wc_create_worker, about to validate and init ajp13 [Mon Sep 22 16:22:03 2003] [jk_ajp13_worker.c (443)]: Into jk_worker_t::validate [Mon Sep 22 16:22:03 2003] [jk_ajp13_worker.c (456)]: In jk_worker_t::validate for worker ajp13 contact is localhost:8009 [Mon Sep 22 16:22:03 2003] [jk_ajp13_worker.c (482)]: Into jk_worker_t::init [Mon Sep 22 16:22:03 2003] [jk_worker.c (177)]: wc_create_worker, done [Mon Sep 22 16:22:03 2003] [jk_worker.c (223)]: build_worker_map, removing old ajp13 worker [Mon Sep 22 16:22:03 2003] [jk_worker.c (235)]: build_worker_map, done [Mon Sep 22 16:22:03 2003] [jk_worker.c (102)]: wc_open, done (I assume the removing old ajp13 worker is okay?) Looking with a TCP viewer, my Tomcat installation is definitely listening on port 8009, but there's no sign of IIS trying to connect to it, which at least suggests that the problem's somewhere there rather than in server.xml. There doesn't seem to be much I could have done wrong - I'm rather confused :( Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IIS 5.1 and Tomcat 4
I'm trying to get IIS 5.1 and Tomcat 4 to play nicely together. So far I've not got very far. I've got: o isapi_redirect.dll from http://apache.oregonstate.edu/jakarta/tomcat-3/bin/win32/i386/ (That's the only place I could find it, and it took a while to find... should I be worried that it's in the Tomcat 3 directory?) o Registry entries in Jakarta Isapi Redirector\1.0 (which I think are okay) workers.properties and uriworkermap.properties which I think are okay. Only useful bits in them are: [workers.properties] worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 worker.ajp13.lbfactor=1 [uriworkermap.properties] default.worker=ajp13 /mobilizer/*=$(default.worker) server.xml has: !-- Define a Coyote/JK2 AJP 1.3 Connector on port 8081 -- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8081 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=0 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ !-- Define an AJP 1.3 Connector on port 8009 -- Connector className=org.apache.ajp.tomcat4.Ajp13Connector port=8009 minProcessors=5 maxProcessors=75 acceptCount=10 debug=0/ I was slightly unsure about this - given that I want the first one (note the non-default port, by the way) do I actually need the second? Should I just be able to change teh port in workers.properties? The servlets work fine from the HTTP connector. IIS has a jakarta virtual directory with execute script permission, the ISAPI filter is up (green arrow), but I get: The specified module could not be found. on my web browser. The catalina log has: 2003-09-19 14:02:42 Ajp13Connector[8009] Opening server socket on all host IP addresses 2003-09-19 14:02:42 Ajp13Connector[8009] Starting background thread 2003-09-19 14:02:42 Ajp13Processor[8009][0] Starting background thread 2003-09-19 14:02:42 Ajp13Processor[8009][1] Starting background thread 2003-09-19 14:02:42 Ajp13Processor[8009][2] Starting background thread 2003-09-19 14:02:42 Ajp13Processor[8009][3] Starting background thread 2003-09-19 14:02:43 Ajp13Processor[8009][4] Starting background thread The localhost log doesn't seem to mention anything in particular. The isapi log has lines such as: [Fri Sep 19 14:04:40 2003] [jk_isapi_plugin.c (626)]: HttpFilterProc started [Fri Sep 19 14:04:40 2003] [jk_isapi_plugin.c (672)]: In HttpFilterProc Virtual Host redirection of /localhost/mobilizer/mobilizer [Fri Sep 19 14:04:40 2003] [jk_uri_worker_map.c (351)]: Into jk_uri_worker_map_t::map_uri_to_worker [Fri Sep 19 14:04:40 2003] [jk_uri_worker_map.c (368)]: Attempting to map URI '/localhost/mobilizer/mobilizer' [Fri Sep 19 14:04:40 2003] [jk_uri_worker_map.c (456)]: jk_uri_worker_map_t::map_uri_to_worker, done without a match [Fri Sep 19 14:04:40 2003] [jk_isapi_plugin.c (678)]: In HttpFilterProc test Default redirection of /mobilizer/mobilizer [Fri Sep 19 14:04:40 2003] [jk_uri_worker_map.c (351)]: Into jk_uri_worker_map_t::map_uri_to_worker [Fri Sep 19 14:04:40 2003] [jk_uri_worker_map.c (368)]: Attempting to map URI '/mobilizer/mobilizer' [Fri Sep 19 14:04:40 2003] [jk_uri_worker_map.c (391)]: jk_uri_worker_map_t::map_uri_to_worker, Found a context match ajp13 - /mobilizer/ [Fri Sep 19 14:04:40 2003] [jk_isapi_plugin.c (688)]: HttpFilterProc [/mobilizer/mobilizer] is a servlet url - should redirect to ajp13 [Fri Sep 19 14:04:40 2003] [jk_isapi_plugin.c (737)]: HttpFilterProc check if [/mobilizer/mobilizer] is points to the web-inf directory [Fri Sep 19 14:19:23 2003] [jk_isapi_plugin.c (626)]: HttpFilterProc started [Fri Sep 19 14:19:23 2003] [jk_isapi_plugin.c (672)]: In HttpFilterProc Virtual Host redirection of /localhost/mobilizer/mobilizer/ [Fri Sep 19 14:19:23 2003] [jk_uri_worker_map.c (351)]: Into jk_uri_worker_map_t::map_uri_to_worker [Fri Sep 19 14:19:23 2003] [jk_uri_worker_map.c (368)]: Attempting to map URI '/localhost/mobilizer/mobilizer/' [Fri Sep 19 14:19:23 2003] [jk_uri_worker_map.c (456)]: jk_uri_worker_map_t::map_uri_to_worker, done without a match [Fri Sep 19 14:19:23 2003] [jk_isapi_plugin.c (678)]: In HttpFilterProc test Default redirection of /mobilizer/mobilizer/ [Fri Sep 19 14:19:23 2003] [jk_uri_worker_map.c (351)]: Into jk_uri_worker_map_t::map_uri_to_worker [Fri Sep 19 14:19:23 2003] [jk_uri_worker_map.c (368)]: Attempting to map URI '/mobilizer/mobilizer/' [Fri Sep 19 14:19:23 2003] [jk_uri_worker_map.c (391)]: jk_uri_worker_map_t::map_uri_to_worker, Found a context match ajp13 - /mobilizer/ [Fri Sep 19 14:19:23 2003] [jk_isapi_plugin.c (688)]: HttpFilterProc [/mobilizer/mobilizer/] is a servlet url - should redirect to ajp13 [Fri Sep 19 14:19:23 2003] [jk_isapi_plugin.c (737)]: HttpFilterProc check if [/mobilizer/mobilizer/] is points to the web-inf directory Any clues as to what I'm
Where does tomcat-jk2.jar come from?
I'm still on the trail of bug 17193, and I'd quite like to see if I can fix it myself. Unfortunately, I've run into a problem at the very first hurdle - finding the source! Catalina has tomcat-jk2.jar in the server/lib directory, but where does this come from in the first place? The source doesn't seem to be in the main 4.1.27 source archive. Any offers? Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Running Tomcat 4.1.27 without Jasper (or a JDK)?
Actually, removing Jasper from 3.3.1(a) is about the same as for 4.1.x: You just comment out the JspInterceptor element in server.xml, and voila: you've got a JSP-less Servlet-Container. I tried that at the time - I can't remember which version, I'm afraid - and if I didn't have Jasper present, it barfed. I didn't have *any* references to JSPs left in the configuration, *anywhere*. Very strange. Never mind though - seems to be fine with 4.1. Ok, to be helpful, for 4.1.x, you need to comment out all references to JspServlet in $CATALINA_HOME/conf/web.xml (including the servlet-mapping). Then you have a JSP-less Servlet-Container. Cheers, Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Interesting (?) classloader problem
As observant readers will have noticed, I'm migrating a webapp or two from Tomcat 3.2.3 to Tomcat 4.1. Now, our apps have a very specific version of Xerces that they currently need to use (although I'm hoping this requirement will go away). I believe the version is Xerces-J 1.4.4 (at least according to the SourceSafe history). Now, that sounds considerably out of whack with what Tomcat ships with, and my guess is that Tomcat may well not be able to work properly with the version we need. (I would just try it, but there's always a good chance that there'll be something hiding away which doesn't get tested.) I can stick the version of xerces.jar in my webapp's lib directory, but according to the documentation, everything in org.apache.xerces (and the org.xml.sax and org.w3c.dom) packages gets delegated to the parent classloader, which obviously wouldn't help me as I'd pick up the newer version of Xerces instead of the one I need. There's also another wrinkle which means I need to load xerces.jar *before* any of the other jar files in webapps/lib. I can't remember where exactly this requirement comes from, but I suspect it's due to some other library we use having its own version of xerces (or maybe just the XML API) built in. I can clearly modify the WebappClassLoader source to get rid of the delegation for org.apache.xerces: what would be the downside of this? Why does the documentation even say you can override common/lib/xerces.jar by putting xerces.jar into webapps/lib, when it's going to delegate everything anyway? The business about loading xerces.jar first is slightly thorny - I suspect the best solution may be to just find out which other jar file contains the other/wrong classes and take them out, but I'd be interested to hear any other solutions. Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Interesting (?) classloader problem
There is a typo in the documentation - you can not override the Xerces parser used. Aha. That at least explains my confusion :) You can replace the one in /common/endorsed and see if it works - I don't recall which version tomcat requires. Have you tried your app with the version that tomcat supplies? I haven't yet, to be honest - hopefully I'll be able to use that in the end, but the guy whose code is most likely to use internal xerces/xalan interfaces is on holiday this week... you can't guarantee the order in which jars are loaded within the same classloader, but if you can replace the version in /common/endorsed, then it won't matter what xml classes any web-inf jars include. Fortunately, I've found that isn't a problem any more. I'm not sure when it was, but it seems to be okay now. I checked which classes were duplicated, and they only seem to be the standard interfaces/base classes, not the implementations. I wish I could find the bug report for what was wrong before... If you modify the WebappClassLoader class, you will have to maintain it for each tomcat upgrade. Indeed. We very rarely upgrade though, to be honest, so that shouldn't be a problem - and hopefully I'll be able to get rid of it soon and we can use the standard xerces when my colleague comes back. I just wanted something to get up and running to start with. Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can't stop tomcat with shutdown.bat - bug 17193
I'm running into a problem when I try to run shutdown.bat (or use the stop parameter directly). I get an exception in the main Tomcat process: java.net.BindException: Cannot assign requested address: connect snip I've had a look in Bugzilla, and this seems to be bug 17193. The process is hanging around, although Tomcat itself has stopped listening for requests on port 8080. This isn't too bad, as our own service start/stop code quits the VM after 5 seconds, but it's not generally nice. Is there a good workaround for this (use a different version of JK etc) which is particularly recommended? Does anyone familiar with the code in this area know whether it's worth me even looking at it to try to fix it myself? Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can't stop tomcat with shutdown.bat - bug 17193
I think a jk2 release (v1.2.5 I believe) is very close, and has this bug fixed. That's excellent news. When it's released, will I be able to just dump a new tomcat-jk2.jar in server/lib, and everything should spring to life, or is there more to it than that? Check the recent jk2 release thread on tomcat-dev archives for more information. Do you know the name of the thread? I'm not getting very far with the searches I'm doing at the moment, unfortunately :( Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can't stop tomcat with shutdown.bat - bug 17193
The release that Yoav is referencing is a new mod_jk, which is an Apache DSO module, not a JAR file. So yes, I guess you will be able to sub in the new DSO as soon as you can build one or find a binary, but don't confuse it with a JAR file. In that case I can't see how it's going to help - I'm not running under apache, I'm running a standalone Tomcat, which can't shut itself down... Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Running Tomcat 4.1.27 without Jasper (or a JDK)?
I'm trying to run Tomcat 4.1 (currently 4.1.27) without needing a full JDK. I don't need any JSP stuff whatsoever, just servlets. Does anyone know of a page explaining how to remove Jasper from Tomcat, or fancy explaining it here? I couldn't find anything in the archive (with only a couple of searches, admittedly). Thanks, Jon Skeet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Running Tomcat 4.1.27 without Jasper (or a JDK)?
I don't think you need to do anything. But you probaly want to do this: - remove $CATALINA/common/lib/jasper-compiler.jar - in $CATALINA/conf/web.xml - comment out boht jasper/jsp references If you don't use precompiled jsp's - remove $CATALINA/common/lib/jasper-runtime.jar You might not need $CATALINA/common/lib/ant.jar either. (I don't know if anything other than jasper depends on it) [ On second thought, you might need to edit setclasspath.bat (or sh) to remove the javac check. ] I'll certainly need to do the last bit, and I'll also (for the sake of completeness) remove the reference to tools.jar on the classpath. Great. I know I tried to do this with Tomcat 3.3, and I couldn't for the life of me get it to not require the Jasper jar files on the system... Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Running Tomcat 4.1.27 without Jasper (or a JDK)?
Just out of curiosity: I'm wondering why you want to do that? The overhead of the JDK over JRE isn't that big and disk space isn't usually a problem. We distribute the JRE in our installation. I know these days you're allowed to distribute tools.jar (and javac.exe?) but the JRE we distribute (which would be inconvenient to change) doesn't allow this. There's also the fact that getting rid of JSPs gets rid of a fair amount of the *possibility* of security problems, which is never a bad thing :) Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Autodeploy to false, but still happening?
I should state that I'm pretty new to Tomcat 4, but have used Tomcat 3 for quite a while. In order to prevent the examples web-app from loading (which required the invoker servlet, which I've commented out completely for the moment), I thought I could just set the Host autoDeploy attribute to false, and get rid of the examples Context entry from server.xml. However, it looks like even with autoDeploy false, subdirectories of webapps are automatically added. I'm sure I'm just missing something - anyone care to enlighten me? (Tomcat 4.1.27 if it matters.) Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Autodeploy to false, but still happening?
There's liveDeploy too (periodic deployment), in addition to autoDeploy. Aha! Great, thanks very much. The attributes have been changed in Tomcat 5, BTW (refer to the docs). That shouldn't bother me for a while - we're only getting round to moving to Tomcat 4 now; it'll be years before we get to Tomcat 5! Having managed to disable all of that, I'd really *like* to be able to use context XML files and *only* context XML files, i.e. part of autoDeploy but not the rest. I'm assuming I can't do that, which is fine - it would be nice, but it's no biggie. If I decide later on that it would be sufficiently nice, I can always patch the source. Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Autodeploy to false, but still happening?
Having managed to disable all of that, I'd really *like* to be able to use context XML files and *only* context XML files, i.e. part of autoDeploy but not the rest. I'm assuming I can't do that, which is fine - it would be nice, but it's no biggie. If I decide later on that it would be sufficiently nice, I can always patch the source. Note: I've just tried setting deployXML to true with autoDeploy and liveDeploy both false - it doesn't work. I suspect deployXML is used as a negative parameter rather than a positive one, which is fair enough. As I said before, no biggie (although if I've missed something, I'd be glad to hear about it). Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Call for Votes: comp.lang.java.{server-side,servlet}
Greetings!
This message is being posted here (and to other places where
servlets are discussed) because there is a Call For Votes (CFV) on
the news.announce.newgroups Usenet newsgroup concerning the proposal
of two new Java newsgroups:
comp.lang.java.servlet
comp.lang.java.server-side
If you are not interested in Usenet or feel you wouldn't use the new
groups, please ignore this message and accept my apologies for wasting
your time.
The subject line of the Call For Votes is:
CFV: comp.lang.java.{server-side, servlet}.
The article itself contains all the details of how to vote.
Any further discussion of the proposal should be carried out on the
news.groups newsgroup.
[Note - I myself am about to go on holiday for a week, but as soon as
I come back I'll be happy to answer any questions that might arise.]
Thanks for your time,
Jon Skeet [EMAIL PROTECTED]
Servlet newsgroup discussion on news.groups
Title: Servlet newsgroup discussion on news.groups Greetings! This message is being posted here (and to other places where servlets are discussed) because there is a Request For Discussion (RFD) on the news.groups Usenet newsgroup concerning the proposal of two new Java newsgroups: comp.lang.java.servlet comp.lang.java.server-side If you are not interested in Usenet or feel you wouldn't use the new groups, please ignore this message and accept my apologies for wasting your time. If you wish to view the proposal and comment on it, however, I would be very happy to hear your views. The subject line of the RFD is: 2nd RFD: comp.lang.java.server-side and comp.lang.java.servlet and the article ID is: [EMAIL PROTECTED] Discussion of the RFD should be carried out on news.groups, but if you don't wish to post there yourself I'd be happy to post on your behalf if you wish to mail me at [EMAIL PROTECTED] If your news-server doesn't carry news.groups, a copy of the RFD has also been posted on comp.lang.java.programmer, comp.lang.java.databases, and comp.lang.java.corba - or I'd be happy to mail you a copy. If you wish to read news.groups on the web, http://groups.google.com provides an updating archive of posts, although it's usually a couple of days behind. NOTE: Due to the large number of mailing lists and discussion boards this message has been posted to, I won't be able to participate in any discussion on the list/board itself. Furthermore, it would be counter-productive to have several small discussions, one in each area. Please use news.groups instead. I apologise if you feel this request is poor netiquette - I'm usually a great fan of read where you write myself, but I hope you'll see this as a slightly unusual case. The feelings of the Java community are very important on this matter - and when it comes to the vote, the new groups will only pass if there is sufficient support. I'll post another message here when the Call For Votes (CFV) takes place, so you don't need to read news.groups in the meantime if you don't want to. Thanks for reading, Jon Skeet - [EMAIL PROTECTED]
Re: context-param: illegal char
apparently is an illegal character. but how do i solve this problem? i've thought of url_encoding this, but that's an ugly sollution. anybody got a better idea? No, you need to *xml* encode it - use amp; instead of . Jon
RE: How do you compile ?
How do I compile this servlet so it should know what where that function is? I think you'd be better off learning Java first, *then* going into servlets - trying to learn both at once may well be much trickier than learning one at a time. Jon
RE: How do you compile ?
I basically want to know if a servlet is using a function in another package how do you compile that servlet? What tags do I include or how do I reference the package when I compile. And what I've said, and what I'll repeat, is that you should learn Java *first*. If you knew Java, you'd know the answer to this question. This is not the best place to discuss general Java matters. You can't expect to write even half-decent servlets without learning the language first. Fumbling about, trying to guess the syntax from other servlets, is going to take you *far* longer than reading a good tutorial on Java. Jon
Re: preloaded feture
May I know that is't tomcat have the feture that preload a servlet each time I start the tomcat? For example, every time I start the tomcat, it will automatically load a servlet (this servlet will read a properties file, and set these properties to to ServletContext). If so, how to configure? Below is the sample servlet. Many thanks!! Set the load-on-startup parameter in web.xml for that particular servlet to be a positive integer. Jon
Re: Application Path
Hello All,
I have a question regarding application path in Tomcat. I have
loaded and application named "myapp" under 'webapps' of Tomcat. Now, is it
possible to know the full path of my application "myapp"?[i.e upto and including
the folder 'myapp']
Within a request, use something like the following:
String requestURL = HttpUtils.getRequestURL (req).toString();
String path = req.getPathInfo();
if (path==null)
servletURL=requestURL;
else
{
if (!requestURL.endsWith (path))
{
// Panic and use something else... your choice!
}
else
servletURL = requestURL.substring (0, requestURL.length()-path.length());
}
Jon
RE: Application Path
You can use the "getDocumentBase()" method to find the path/URL of your servlet. and/or "getCodeBase()" which gets the base URL. No - both of those methods are for *applets*, not servlets. Jon
Re: java.lang.ClassCastException
Is it perhaps due to a new classloader being used? Does this happen when the servlet is recompiled half way through the operation? No, the servlet it not compiled in the server. It's compiled on my PC and uploaded. However, thanks for the tip. I can reproduce the error consistently now. Yes, I essentially meant "has the servlet changed". It happens whenever my colleague or I uploaded servlet1 or servlet2 and the servlet reloads. I have stop/start tomcat to get rid of the exception. Presumably it forces tomcat to reload all the classes, not just the servlet in question. Funny thing is, the changes to servlet1/2 is trivial (e.g. add another statement "System.err.println();") and not related to the type casting/usage of the SearchResult class/object. Even the SearchResult class/object remains the same. Is this what you mean by new classloader being used? A new classloader will be used to load the new servlet. That classloader will be used within that servlet, and two different classloaders' versions of the same class count as different classes in the JVM. Thus the object in the session has the old classloader, whereas the thing trying to use it is using the new classloader. Just starting a new session each time you upload your servlet should cure the problem. Jon
Re: directory listing
Please help me.. I currently have Apache 1.3.12 passing any .jsp to Tomcat. (I'm new at this). How do I turn off the Directory listing in Tomcat? I've tried editing every file I can think of. This is getting VERY frustrating. Thanks in advance, Greg Give your StaticInterceptor in server.xml the parameter suppress="true". Jon
Re: Class verify errors with large(?) JSP pages
I have seen in the archives several posts detailing the same problem. However I could find no response. Hence I'm posting again. OS - Win NT 4 sp6a Suns JDK 1.2.1 Tomcat 3.2 final The error occurs with JSP pages with a large number (250+) of taglib actions. The java source file is generated (500k). The class file is also generated (90k). When the page is accessed you get the java.lang.VerifyError. My guess is that this could be something to do with methods not being able to contain more than 64K of code. How much of the generated source file is in one method? Jon
Re: Hi folks!
First day in this mailing list and first question: Does anyone know something about the Basic Authentication mechanism with Tomcat? It was supposed to be fixed in this release. Did anyone try it? Is it working? Thanks, Vittorio It's working for me, *but* you need to following in web.xml: login-config auth-methodBASIC/auth-method realm-nameYour realm/realm-name /login-config Jon
Re: WAP Configuration
Second, the content type that is created by a JSP page is controlled by what your page declares in the "page" directive, not by Tomcat. If you wish to have the output treated as XML, for example, you would include a directive like this at the top of your pages: %@ page contentType="text/xml" % You will need to review the documentation of the WAP Toolkit you are using to determine what content type it is expecting, but the choice of content type is up to the page author, not the servlet container. Just to save the original poster the trouble of looking it up, the content type you want is: text/vnd.wap.wml Jon
Requesting / hangs Tomcat with no static interceptor?
I'm using Tomcat 3.2b7 (also happens under 3.2b6) and I'm trying to run a slightly cut-down version. In particular, I don't want to serve any static files, show any directories etc. I thought that to do this, I could remove the line: RequestInterceptor className="org.apache.tomcat.request.StaticInterceptor" / from server.xml. Unfortunately, this seems to mean that a request for / on the server sends Tomcat into a tight loop (Java takes up 99% of my CPU). Any ideas? Is removing the StaticInterceptor just a really bad idea? Win2K, JDK1.3 btw. Jon
Re: Netscape can't find css
I have written a servlet that uses a StyleSheet to produce an HTML Page. While the app works fine in IE5, NS4.75 returns the following error Message: Error: 404 Location: /examples/servlet/D:/jakarta-tomcat/webapps/examples/Web-inf/classes/spc.css That D:/ looks extremely odd. Why is the HTML requesting it? Jon
Re: Apache is writing 800\n to servlet response outputstream.
Sounds like apache is chunking the output stream, which seems a reasonable thing to do. Do the headers mention anything about chunking? What happens if you have a static image served by apache, out of interest? Jon
RE: WML postfield tomcat 3.1
Nope, we are using post. And note that it works if the container is JRun, but not tomcat. Ah - in that case it can't entirely be the emulator. Have you put a network sniffer on to see what's actually being sent to the server? It could be that JRun is more tolerant of broken post requests or something similar. Jon
