Re: Workaround for login page direct reference
Ben, I'm not sure but I believe that I've seen mention that you can forward to a page that is not accessible to the outside. That is, put the Login.jsp page within WEB-INF of your web app and it will not be available to the outside world but you can forward to it from inside the web app. I don't know if this will work because I have not tried it but it might. Brett - Original Message - From: Ben Jessel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 16, 2002 11:14 AM Subject: Workaround for login page direct reference Hi, I've got a realm set up on Tomcat. It works fine - whenever I go to a protected page, I am forwarded to the login.jsp page. However, if I go to the login.jsp page directly and fill in my details I get Invalid direct reference to form login page. not surprising really as tomcat would get itself into an endless cycle. Now what are the strategies for hiding this page, so a hapless user who goes directly to the login page and enters his details doesn't get this message. I'd want to forward them onto the index page. Any ideas? Would I explicity bar the request of the requesting of the login page using my web server?..I doubt it, as I reckon tht the realm probably uses a sendRedirect(). I guess that I could check the refering page...hmm dunno...any ideas? Thanks -b -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Why deployment using xml file doesn't work?
Vernon, is the error message below cut'n'pasted to your email? If so, it looks like you have a space between the in the directory. It looks like there is a space between b2- and the 01. Document base c:\tomcat\jakarta-tomcat-4.0.4-b2- 01\webapps\mm ^ Looks like a space here. Tomcat does not like spaces in paths. Hope this helps. Brett - Original Message - From: Vernon Wu [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 29, 2002 11:18 AM Subject: Re: Why deployment using xml file doesn't work? Can someone please help me on this problem. Thx. 4/26/2002 1:24:18 PM, Vernon Wu [EMAIL PROTECTED] wrote: During the development phrase, I would like to use xml to deploy my application without copy all file, directories to the tomcat installation directory. My deployment xml is very simple with two or three lines as Context path=/mm docBase=c:\eclipse\workspace\nicematch\build\webapp debug=2 reloadable=true /Context The error message I got in the localhost log file is: Error initializing resources: Document base c:\tomcat\jakarta-tomcat-4.0.4-b2- 01\webapps\mm does not exist or is not a readable directory I think the problem is a incorrect docBase. But I am very sure the path is right. I also have tried to use another format of the path as: ../../../eclipse/workspace/nicematch/build/webapp What am I missing here? v. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: IE 6 upgrade and java plug-in causing problems
From the command line, type java -version. To find out which java you would run, I've included a .bat file for NT that will tell you. Have which.bat on your path and type which java.exe. - Original Message - From: Steve Bearss [EMAIL PROTECTED] To: Tomcat [EMAIL PROTECTED] Sent: Thursday, December 06, 2001 11:28 AM Subject: IE 6 upgrade and java plug-in causing problems Hello All, I recently upgraded to IE 6 and I was prompted to install the latest java plug-in as well. Now my Tomcat is not running. All my java development is on a separate partition, which includes the jdk and tomcat. I'm not sure what IE did (it is on another partition) to this setup and I tried to update my JAVA_HOME variable, still no luck. Is there any way to determine which version of java is currently running (I seem to have a few copies now) and where it is located? After that I should be able to re-configure JAVA_HOME and all is good? Thanks, s attachment: which.bat -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: IE 6 upgrade and java plug-in causing problems (reset without attachement)
From the command line, type java -version. To find out which java you would run, I've included a .bat file for NT that will tell you. Have which.bat on your path and type which java.exe. Here is the batch file inline. Just cut and paste it and save it to a file called which.bat. -- CUT HERE --- @echo off :: Parameter error checking: if %1== goto Syntax echo %1 | find /v : | find /v \ | find /v * | find /v ? | find /v , | find /v ; | find /v / | find %1 nul if errorlevel 1 goto Syntax :: Actual program is only one line: for %%a in (.;%pathext%) do for %%b in (%1%%a) do ( echo %%~f$PATH:b | find /i %1 ) goto End :Syntax :: Help screen: echo WHICH, Version 1.20 echo UNIX-like WHICH utility for NT echo Written by Rob van der Woude echo. echo Usage: WHICH program_name echo. echo You may specify program_name with or without echo extension, but without a drive or path. echo Spaces or wildcards aren't allowed either. :End -- CUT HERE -- - Original Message - From: Steve Bearss [EMAIL PROTECTED] To: Tomcat [EMAIL PROTECTED] Sent: Thursday, December 06, 2001 11:28 AM Subject: IE 6 upgrade and java plug-in causing problems Hello All, I recently upgraded to IE 6 and I was prompted to install the latest java plug-in as well. Now my Tomcat is not running. All my java development is on a separate partition, which includes the jdk and tomcat. I'm not sure what IE did (it is on another partition) to this setup and I tried to update my JAVA_HOME variable, still no luck. Is there any way to determine which version of java is currently running (I seem to have a few copies now) and where it is located? After that I should be able to re-configure JAVA_HOME and all is good? Thanks, s --- Brett Bergquist email: [EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Distribution/Licensing question
Jeff, I just noticed on Sun's Java web pages that as of the 10/17/2001 that javac and tools.jar are now redistributable. Here's a link to a page with this information: http://java.sun.com/j2se/1.3/jre/ - Original Message - From: Jeff Corliss [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 3:50 PM Subject: Re: Distribution/Licensing question Cool, I will check that out. Thanks! --- Brett M. Bergquist [EMAIL PROTECTED] wrote: Jeff, you need to contact Sun in regards to redistributing the Java compiler. But, you could go the route that we did and use the IBM Jikes Java compiler which is freely distributable provided that you show the proper notices and such. - Original Message - From: Jeff Corliss [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Wednesday, October 31, 2001 1:14 PM Subject: Distribution/Licensing question Quick newbie question, and if its just a case of RTFM (which I have, but maybe I missed it), please feel free to say so ... I am writing a webapp that includes tag libraries and the intent is to sell this to multiple customers, each of whom will be designing their own JSPs using those tags. Now, since that means the JSPs will need to be compiled by Tomcat at least once at each customer's site, does this mean I need to actually distribute not only Tomcat but also the JDK (not just the JRE)? If that is the case, does that mean I have to make an arrangement with Sun for licensing the redistribution of the JDK? Many thanks, Jeff __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Distribution/Licensing question
Jeff, you need to contact Sun in regards to redistributing the Java compiler. But, you could go the route that we did and use the IBM Jikes Java compiler which is freely distributable provided that you show the proper notices and such. - Original Message - From: Jeff Corliss [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Wednesday, October 31, 2001 1:14 PM Subject: Distribution/Licensing question Quick newbie question, and if its just a case of RTFM (which I have, but maybe I missed it), please feel free to say so ... I am writing a webapp that includes tag libraries and the intent is to sell this to multiple customers, each of whom will be designing their own JSPs using those tags. Now, since that means the JSPs will need to be compiled by Tomcat at least once at each customer's site, does this mean I need to actually distribute not only Tomcat but also the JDK (not just the JRE)? If that is the case, does that mean I have to make an arrangement with Sun for licensing the redistribution of the JDK? Many thanks, Jeff __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Limits of Web
Basically what is done is to use an URL to identify the servlet, get an HttpURLConnection, from the URL, setup the connection to do output and input, set the request header for the content type to be text/xml, get an output stream for the connection, and write the XML document to the stream. Then, get an input stream from the connection, read the stream, and reconstruct the response XML document from the data read. The various XML parsing packages have the ability to write the XML document given a stream and to read a stream and construct an XML document. I'm sure that the same could be done without using applets, by constructing a document and posting it using one of the scripting languages such as JavaScript. It appears to me, however, that it would be cumbersome, and I have not attempted to do so. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 24, 2001 4:38 PM Subject: Re: Limits of Web Brett, I 've a question regarding the communication between the Applet and Servelt (server). How can I send the XML file to the Sevlet from the Applet(Client) And also how can I get back the XML file with results from the Servlet to Applet, so that I can parse the results into fields.. And also, is there any way to get same above XML communication between client and WebServer with out using Applets. For Ex:- submitting a XML file instead of submitting a FORM. Thanks in advance. -Chinni. --- V R Chinni (DPRA). Contractor for EPA. 214-665-6783 --- Brett M. Bergquist To: [EMAIL PROTECTED] brettb@mail.cc: com Subject: Re: Limits of Web 09/24/01 03:08 PM Please respond to tomcat-user Exactly. In my case, instead of performing SQL on a database, I perform SNMP on a network device. The same logic applies, however. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 24, 2001 3:49 PM Subject: Re: Limits of Web Brett, Again thanks for the reply. One more question regarding XML. When you send the XML request info, do you send the data as well? For example if the applet requests data from the server I, would then process it, preform the necessary SQLs on the database and then send the data back to the applet as an XML document and have the applet parse it and desplay it? Brett M. Bergquist To: [EMAIL PROTECTED] brettb@mail.cc: com Subject: Re: Limits of Web 09/24/01 01:46 PM Please respond to tomcat-user Okay for the internet. That's what we support as well as intranet. I wanted to make sure that my application was easy to deploy in an internet environment so I did not what to start using RMI or IIOP or something else that would not flow over a firewall, so I chose to use XML over HTTP. Basically, our applets create an XML document that describes the request data needed and then use an HTTP POST to pass this data to the backend servlet. The servlet processes the HTTP POST data, transforms it back into a XML DOM document. It then analyzes and processes the request. It then creates a XML document as the response and passes this back to the applet using the HTTP response. We use an early version of Sun's XML parser and I also modified the sample XML-RPC client and servlet classes for my own use to support this. It works pretty good and performance of creating and parsing the XML is a non-issue; the major processing time is taken by actually performing the requested service. If I had to do it over, I would definitely look at using the quasi standard XML-RPC protocol or maybe even SOAP, but I have a feeling that these are getting to esoteric for my taste. One other benefit of this approach was that the front end is loosely coupled from the backend. I could change the front end side, maybe having a native application or something similar, and the backend would be blissfully unaware. The XML is the binding protocol between the two. Our applications currently have about 5 to 7 tab pages with about 10 to 15 items per page. From the time the applet starts on the browser to the time that it displays the data is about 1 to 2 seconds. This is using just Tomcat as our web server and java servlet engine. We
Re: Why won't tomcat run with jre
You can use the IBM jikes compiler, which is redistributable provided you provide follow the licensing agreement and put the correct notices in your software and documentation. - Original Message - From: Alex Colic [EMAIL PROTECTED] To: Tomcat-User [EMAIL PROTECTED] Sent: Tuesday, September 25, 2001 3:04 PM Subject: RE: Why won't tomcat run with jre Hi, what I mean is that servlets will work but JSP's will not. As for the JSPC I did not think about that but..lets say you want to make changes to the jsp page. Do you have to make the change, recompile the page and then replace it? If so does that not make it more difficult to manage the pages? Alex What do you mean by failing? Tomcat only needs the JDK if you are using JSPs. What we do is use JSPs in development and then use JSPC to convert the JSPs to servlets for testing and production. Randy
Re: Limits of Web
Jeff, will your application be deployed in an intranet or internet environment? This might make a difference in the solutions that are available. Just for your information, I faced as similar situation in the development of a Network Management System used to control and manage fiber optic communications equipment that we manufacture. I needed a robust and complex gui with things such as greying out fields depending on the selections of other fields, validation on fields as they are entered, indicating to a user a field has been changed, etc. These needed to be done on the client side. I looked at a few possibilities, namely JavaScript or Java applets. At the time Sun's Jump Start was not available. I chose to use Swing based Java applets. To get around the differences in browsers, I chose to use the Java Plugin to provide this stable (fairly) environment. In addition, in the back end we are using Tomcat with servlets, JSP pages, and XML as the communications between our Java applets and the backend. I chose Java over JavaScript because of the complexities involved in managing browser specific within JavaScript and also because of the better development and debugging environment I had in Java. Using a packaging tool that produces Jar files with the absolute minimum need for the applet, we are able to keep out applet size down to between 250k and 350k. Once downloaded the applets are cached, so this is pretty much a one time hit. Our applications are quite responsive and have the gui needed. Just to let you know what we did. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 24, 2001 12:54 PM Subject: Re: Limits of Web I asked for help w/technical issues not advice on how to manage clients. Please limit the answers to such. Nobody's trying to get sympathy or pity; just trying to do our jobs. Pae Choi paechoi@eartTo: [EMAIL PROTECTED] hlink.net cc: Subject: Re: Limits of Web 09/24/01 11:12 AM Please respond to tomcat-user Then, they need to get help by getting professionals. One would be the architect who can help you folks at least understand what is the difference between the thin and thick clients. Second would be the security speciality who can help you folks understand that the security is not a joke like anyone suddenly realized and think they can grab and use it like a plugable COTS. I've seen many folks use the terms like client, customer, boss, etc just to win the battle and get some sympathy or pity. You need to know how to manage the customer expectaton as well as teach your stakeholders learn that they will not get over night whatever they want and demand just because they think they can piss around you. Pae When we started with this app it we did not have the skills needed to develop Swing applets. Now the problem appears to be the speed of these applets. They are way to slow. They also expect it to be as fast as their Client Server Applications. Plus the company I work for is paranoid about security to the point of irrationality. If they ever got wind of the security problems involved in applets they would shut development down.
Re: Limits of Web
Okay for the internet. That's what we support as well as intranet. I wanted to make sure that my application was easy to deploy in an internet environment so I did not what to start using RMI or IIOP or something else that would not flow over a firewall, so I chose to use XML over HTTP. Basically, our applets create an XML document that describes the request data needed and then use an HTTP POST to pass this data to the backend servlet. The servlet processes the HTTP POST data, transforms it back into a XML DOM document. It then analyzes and processes the request. It then creates a XML document as the response and passes this back to the applet using the HTTP response. We use an early version of Sun's XML parser and I also modified the sample XML-RPC client and servlet classes for my own use to support this. It works pretty good and performance of creating and parsing the XML is a non-issue; the major processing time is taken by actually performing the requested service. If I had to do it over, I would definitely look at using the quasi standard XML-RPC protocol or maybe even SOAP, but I have a feeling that these are getting to esoteric for my taste. One other benefit of this approach was that the front end is loosely coupled from the backend. I could change the front end side, maybe having a native application or something similar, and the backend would be blissfully unaware. The XML is the binding protocol between the two. Our applications currently have about 5 to 7 tab pages with about 10 to 15 items per page. From the time the applet starts on the browser to the time that it displays the data is about 1 to 2 seconds. This is using just Tomcat as our web server and java servlet engine. We started to front the backend with Apache, but the connection between Apache and Tomcat was flaky and we seem to get good enough response time with just Tomcat. It also simplifies the configuration quite a bit. We do one other thing that's a little interesting. We needed to send asynchronous updates to an alarm application. As you know, a web based application is primarily request/response driven. Again, I did not want a big configuration issue in dealing with opening ports on the firewall, etc. so what I did was fake out the system by issuing a HTTP request and I have the response never end. That is, the servlet side generates alarm information whenever it needs and sends it down the response pipe back to the client. Now this tacks up a TCP connection from the server to the client so it puts a little stress on the server resources, but with the number of clients we were looking to support this was acceptable. As for the jar package, we use a tool called cannery. You give it a starting Java class file and it will find an package any other classes that the starting class file depends on into a jar file. This optimizes the jar file for the applet to be as small as it can be. It's pretty good but it may miss classes that are needed through runtime reflection, in which case, you simply have to tell cannery to include those class files manually. Just another thought. I worked on a previous system that tried to do some other client side processing such as having a client side hidden component that would open up a port and listen for updates, etc. This involved getting into code signing using a certificate such as from Verisign. Each browser does this differently with different code signing requirements. This was a nightmare and I don't think you want to go there. With the solution that I came up with, the client has a one-time download of the Java Plugin to install into their browser. This is not to small, about 5Mb, but not to large either. Similar to the Flash plugin. We also host the Java Plugin on our own web site so that the client can get it from our company as apposed to Sun's web site. Sun has a habit of changing and removing links to the Java Plugin when new versions come out. We needed something a little more stable. Hope this helps. Brett - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 24, 2001 2:16 PM Subject: Re: Limits of Web Brett, Thanks for your detailed reply. The application will be deployed in an internet environment. A few more questions. Some of our applets will have 12 - 15 tab pages each w/its own set of data. Is it feasible to get an quick enough response with this type of gui? Also, what packing tool did you use to produce the Jar files? And, if can in a sentence or to, explain how you used XML for communication between the applets and the backend? Thanks again Jeff Brett M. Bergquist To: [EMAIL PROTECTED] brettb@mail.cc: com Subject: Re: Limits of Web 09/24/01 12:45 PM
Re: Limits of Web
Exactly. In my case, instead of performing SQL on a database, I perform SNMP on a network device. The same logic applies, however. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 24, 2001 3:49 PM Subject: Re: Limits of Web Brett, Again thanks for the reply. One more question regarding XML. When you send the XML request info, do you send the data as well? For example if the applet requests data from the server I, would then process it, preform the necessary SQLs on the database and then send the data back to the applet as an XML document and have the applet parse it and desplay it? Brett M. Bergquist To: [EMAIL PROTECTED] brettb@mail.cc: com Subject: Re: Limits of Web 09/24/01 01:46 PM Please respond to tomcat-user Okay for the internet. That's what we support as well as intranet. I wanted to make sure that my application was easy to deploy in an internet environment so I did not what to start using RMI or IIOP or something else that would not flow over a firewall, so I chose to use XML over HTTP. Basically, our applets create an XML document that describes the request data needed and then use an HTTP POST to pass this data to the backend servlet. The servlet processes the HTTP POST data, transforms it back into a XML DOM document. It then analyzes and processes the request. It then creates a XML document as the response and passes this back to the applet using the HTTP response. We use an early version of Sun's XML parser and I also modified the sample XML-RPC client and servlet classes for my own use to support this. It works pretty good and performance of creating and parsing the XML is a non-issue; the major processing time is taken by actually performing the requested service. If I had to do it over, I would definitely look at using the quasi standard XML-RPC protocol or maybe even SOAP, but I have a feeling that these are getting to esoteric for my taste. One other benefit of this approach was that the front end is loosely coupled from the backend. I could change the front end side, maybe having a native application or something similar, and the backend would be blissfully unaware. The XML is the binding protocol between the two. Our applications currently have about 5 to 7 tab pages with about 10 to 15 items per page. From the time the applet starts on the browser to the time that it displays the data is about 1 to 2 seconds. This is using just Tomcat as our web server and java servlet engine. We started to front the backend with Apache, but the connection between Apache and Tomcat was flaky and we seem to get good enough response time with just Tomcat. It also simplifies the configuration quite a bit. We do one other thing that's a little interesting. We needed to send asynchronous updates to an alarm application. As you know, a web based application is primarily request/response driven. Again, I did not want a big configuration issue in dealing with opening ports on the firewall, etc. so what I did was fake out the system by issuing a HTTP request and I have the response never end. That is, the servlet side generates alarm information whenever it needs and sends it down the response pipe back to the client. Now this tacks up a TCP connection from the server to the client so it puts a little stress on the server resources, but with the number of clients we were looking to support this was acceptable. As for the jar package, we use a tool called cannery. You give it a starting Java class file and it will find an package any other classes that the starting class file depends on into a jar file. This optimizes the jar file for the applet to be as small as it can be. It's pretty good but it may miss classes that are needed through runtime reflection, in which case, you simply have to tell cannery to include those class files manually. Just another thought. I worked on a previous system that tried to do some other client side processing such as having a client side hidden component that would open up a port and listen for updates, etc. This involved getting into code signing using a certificate such as from Verisign. Each browser does this differently with different code signing requirements. This was a nightmare and I don't think you want to go there. With the solution that I came up with, the client has a one-time download of the Java Plugin to install into their browser. This is not to small, about 5Mb, but not to large either. Similar to the Flash plugin. We also host the Java Plugin on our own web site so that the client can get it from our company as apposed to Sun's web site. Sun has a habit
Re: ContextManager: SocketException reading request, ignored
Dan, I might be able to help on your second problem. I've read and experienced that on HP-UX 11, that the there is an issue on closing a socket with a read pending. We have Tomcat 3.2 running on HP-UX 11 and I needed to add the following to the line that starts Tomcat. This is a parameter passed to the java jvm: -XdoCloseWithReadPending You can search on doCloseWithReadPending on the HP site and see what this relates to. - Original Message - From: Dan R. Labonte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 23, 2001 12:46 PM Subject: RE: ContextManager: SocketException reading request, ignored Any ideas? So I was receiving the out of Buffer errors and the census was for me to upgrade to Tomcat 3.2.3, which I did. So far so good, no Buffer errors as of yet. I do have two new issues now: 1. I'm receiving this error often: $2001-08-21 15:56:29 - ContextManager: SocketException reading request, ignored - java.net.SocketException: Connection refused: Connection refused at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at org.apache.tomcat.service.http.HttpRequestAdapter.doRead(HttpRequestAdapter. java:115) at org.apache.tomcat.core.BufferedServletInputStream.doRead(BufferedServletInpu tStream.java:106) at org.apache.tomcat.core.BufferedServletInputStream.read(BufferedServletInputS tream.java:128) at javax.servlet.ServletInputStream.readLine(ServletInputStream.java:138) at org.apache.tomcat.service.http.HttpRequestAdapter.readNextRequest(HttpReques tAdapter.java:129) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:198) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Unknown Source) 2. When I try to shutdown Tomcat with tomcat.sh it never dies and I end up having to use the kill command. Here is the environment: HP-UX 11.00 JDK 1.3 Tomcat 3.2.3 Any and all replies are welcomed Thanks in advance, Dan
Re: ContextManager: SocketException reading request, ignored
No problem Dan. I've received much help from others and am happy to contribute where I can. BTW, what does 100pts get me :) - Original Message - From: Dan R. Labonte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 23, 2001 1:35 PM Subject: RE: ContextManager: SocketException reading request, ignored Brett, I thank you for your expertise... Shutdown smoothly! You get 100pts. for your effort. Dan -Original Message- From: Brett M. Bergquist [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 23, 2001 1:24 PM To: [EMAIL PROTECTED] Subject: Re: ContextManager: SocketException reading request, ignored Dan, I might be able to help on your second problem. I've read and experienced that on HP-UX 11, that the there is an issue on closing a socket with a read pending. We have Tomcat 3.2 running on HP-UX 11 and I needed to add the following to the line that starts Tomcat. This is a parameter passed to the java jvm: -XdoCloseWithReadPending You can search on doCloseWithReadPending on the HP site and see what this relates to. - Original Message - From: Dan R. Labonte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 23, 2001 12:46 PM Subject: RE: ContextManager: SocketException reading request, ignored Any ideas? So I was receiving the out of Buffer errors and the census was for me to upgrade to Tomcat 3.2.3, which I did. So far so good, no Buffer errors as of yet. I do have two new issues now: 1. I'm receiving this error often: $2001-08-21 15:56:29 - ContextManager: SocketException reading request, ignored - java.net.SocketException: Connection refused: Connection refused at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at org.apache.tomcat.service.http.HttpRequestAdapter.doRead(HttpRequestAdapter. java:115) at org.apache.tomcat.core.BufferedServletInputStream.doRead(BufferedServletInpu tStream.java:106) at org.apache.tomcat.core.BufferedServletInputStream.read(BufferedServletInputS tream.java:128) at javax.servlet.ServletInputStream.readLine(ServletInputStream.java:138) at org.apache.tomcat.service.http.HttpRequestAdapter.readNextRequest(HttpReques tAdapter.java:129) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:198) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Unknown Source) 2. When I try to shutdown Tomcat with tomcat.sh it never dies and I end up having to use the kill command. Here is the environment: HP-UX 11.00 JDK 1.3 Tomcat 3.2.3 Any and all replies are welcomed Thanks in advance, Dan
Re: Unsafe path
I had something similar when I ported from Tomcat 3.1 to Tomcat 3.2.2. It turned out I was calling a getResourceAsStream or something similar with a trailing space at the end of the path that I was passing. For example I was calling something like 'getResourceAsStream(/foo/bar )' as apposed to 'getResourceAsStream(/foo/bar). Take a look to make sure that your path to cocoon.properties does not contain a trailing space. - Original Message - From: Keuck, Carl Jan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 26, 2001 8:53 AM Subject: Unsafe path Hi out there, I'm trying to run Cocoon 1.8.2 on Apache 1.3.12 an Tomcat 3.2.2 on WinNT4.0. Installation looks fine to me, but somehow it's not working. Tomcat tells me: 2001-06-26 01:52:42 - Ctx( /cocoon ): Unsafe path D:\Programme\Apache_Group\jakarta-tomcat-3.2.2\webapps\cocoon /Web-inf/cocoon.properties What can I do? Charly
Re: flushing
Which version of Tomcat are you refering to? If Tomcat 3.2.X, try the HttpServletResponse.flushBuffer() method. This works for me in Tomcat 3.2.2. - Original Message - From: T [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 19, 2001 6:26 PM Subject: flushing How can I flush Tomcat? Nothing from the PrintWriter reaches the browser until the servlet completes. flush() does nothing. Has anybody altered the facade classes to enable flushing? Why is Tomcat set up that way? Thanks.
Re: Default web.xml
In tomcat 3.2.x, the web.xml in the conf directory is not used at all. I fact, you can completely remove it with no ill effects. Internally, Tomcat 3.2.x compiles in some defaults; mime mappings, the JSP servlet mapping, etc. In your application's web.xml specify anything that you need too override the defaults. I believe I read the Tomcat 4.0 will once again have a default web.xml. I'm not sure about Tomcat 3.3, however. Check the Tomcat mailing list archives for more info - Original Message - From: Timothy Shadel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 15, 2001 3:07 PM Subject: Default web.xml I have a quick question about how the default web.xml found in the conf directory is supposed to act. The Tomcat User's guide says it acts as a default web.xml for all web applications. I tried to add the following to it: servlet-mapping !-- This was there by default -- servlet-name jsp /servlet-name url-pattern *.jsp /url-pattern /servlet-mapping servlet-mapping !-- I added this -- servlet-name jsp /servlet-name url-pattern *.tem /url-pattern /servlet-mapping because we wanted to logically separate our JSP files used as templates from those providing major content. However, accessing a valid JSP file that's been renamed with a .tem extension returns only the actual file contents instead of being translated as a JSP. The same servlet-mapping tag works perfectly in an application's web.xml. Am I supposed to be able to modify the web.xml in the conf directory and have it affect all applications, or is it only supposed to work with the one that comes with Tomcat by default? Thanks, Tim Shadel
Re: Jikes and Tomcat for JSP compilation
I've got Jikes working with Tomcat 3.2.2. Tomcat 3.2.x does not read the web.xml file that is in conf so you need to update your own web application's web.xml. Add the following lines: servlet servlet-name jsp /servlet-name servlet-class org.apache.jasper.servlet.JspServlet /servlet-class init-param param-namejspCompilerPlugin/param-name param-valueorg.apache.jasper.compiler.JikesJavaCompiler/param-value /init-param init-param param-namejspCompilerPath/param-name param-valued:\test\CanogaView\Jikes\win32\1.12\bin\jikes.exe/param-value /init-param load-on-startup -2147483646 /load-on-startup /servlet changing d:\test\CanogaView\Jikes\win32\1.12\bin\jikes.exe to the path where you have jikes installed and also servlet-mapping servlet-name jsp /servlet-name url-pattern *.jsp /url-pattern /servlet-mapping Note that you will get a warning from stderr of something like: 2001-06-06 04:06:34 - Ctx( /CanogaView ): Removing duplicate servlet jsp jsp(org.apache.jasper.servlet.JspServlet/null) 2001-06-06 04:06:34 - Ctx( /CanogaView ): Removing duplicate *.jsp - jsp(org.apache.jasper.servlet.JspServlet/null) This is because Tomcat has a builtin JSP servlet and mapping configuration and you are overriding this. - Original Message - From: chris brown [EMAIL PROTECTED] To: tomcat-user [EMAIL PROTECTED] Sent: Thursday, June 07, 2001 4:45 AM Subject: Re: Jikes and Tomcat for JSP compilation Hi Peter (and anyone else following this thread), If it's any consolation, I've asked the same question on many mailing lists over a long period of time, and nobody's given a working answer yet. I have a JDK installed (hence I've got javac), plus Jikes. When using Jikes from the commandline, it works fine. I've even uncommented the line in web.xml. But I never seemed to get it working, as in the pages still compiled, but there was no way of knowing if it was jikes or javac that did it I tried renaming Jikes.exe to _jikes._exe to see if Tomcat missed it, but it didn't complain, so I just assumed it hadn't been taken into account anyway. I suspected that I needed to copy all (or part) of the default web.xml into each web-app's WEB-INF folder, uncommenting the jikes line as appropriate. However, this didn't work at all well, as it seemed to give Tomcat a headache. I've already posted on this (overriding default web.xml with custom web.xml). Not a lot of luck there either... Hope someone can give a clear answer as to how to do this -- and verify that it works! -Chris Brown - Original Message - From: WEST, Peter To: [EMAIL PROTECTED] Sent: Wednesday, June 06, 2001 8:19 PM Subject: Jikes and Tomcat for JSP compilation can anybody point me to a straightforward how to get Tomcat to compile JSPs with Jikes rather than JDK tutorial? So far I have changed web.xml server.xml (both of which made no difference). I have also read that it may be necessary to change the source of a line in webserver.jar I have the details of this but dont exactly believe it is necessary?? Any pointers? Ideas? thanks, Pete
Re: thanks...
\com\canoga\c
anogaview\views\domainview\applet\DomainView.plugin(150,47)
2001-06-07 07:25:54 -
Handling Directive: include
{file=/com/canoga/canogaview/lib/jsp/AppletSmallFooter.jsp}
2001-06-07 07:25:54 - Accepted org.apache.jasper.compiler.Parser$Directive
at
D:\test\CanogaView\Tomcat\3.1\jakarta-tomcat\webapps\CanogaView\com\canoga\c
anogaview\views\domainview\applet\DomainView.plugin(158,0)
2001-06-07 07:25:54 - Accepted org.apache.jasper.compiler.Parser$Scriptlet
at
D:\test\CanogaView\Tomcat\3.1\jakarta-tomcat\webapps\CanogaView\jsp\DomainVi
ew.jsp(5,0)
2001-06-07 07:25:54 - Compiling with: -encoding UTF8 -classpath
d:\test\CanogaView\jre\lib\rt.jar;d:\test\CanogaView\Tomcat\3.1\jakarta-tomc
at\classes;d:\test\CanogaView\Tomcat\3.1\jakarta-tomcat\lib\jaxp.jar;d:\test
\CanogaView\Tomcat\3.1\jakarta-tomcat\lib\parser.jar;d:\test\CanogaView\Tomc
at\3.1\jakarta-tomcat\lib\webserver.jar;d:\test\CanogaView\Tomcat\3.1\jakart
a-tomcat\lib\servlet.jar;d:\test\CanogaView\Tomcat\3.1\jakarta-tomcat\lib\ja
sper.jar;D:\test\CanogaView\Tomcat\3.1\jakarta-tomcat\webapps\CanogaView\WEB
-INF\classes;null;D:\test\CanogaView\Tomcat\3.1\jakarta-tomcat\work\localhos
t_8080%2FCanogaView -d
D:\test\CanogaView\Tomcat\3.1\jakarta-tomcat\work\localhost_8080%2FCanogaVie
w
D:\test\CanogaView\Tomcat\3.1\jakarta-tomcat\work\localhost_8080%2FCanogaVie
w\_0002fjsp_0002fDomainView_0002ejspDomainView_jsp_0.java
- Original Message -
From: WEST, Peter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 07, 2001 7:19 AM
Subject: thanks...
thanks Brett that makes some sense. I'll try it out and see.
We're also looking at JSPC which claims to precompile JSPs a directory ata
time into class files and also generate the appropriate web.xml info to
use
it.
at this stage we'll try anything.
Pete
-Original Message-
From: Brett M. Bergquist [mailto:[EMAIL PROTECTED]]
Sent: 07 June 2001 11:58
To: [EMAIL PROTECTED]
Subject: Re: Jikes and Tomcat for JSP compilation
I've got Jikes working with Tomcat 3.2.2. Tomcat 3.2.x does not read the
web.xml file that is in conf so you need to update your own web
application's web.xml. Add the following lines:
servlet
servlet-name
jsp
/servlet-name
servlet-class
org.apache.jasper.servlet.JspServlet
/servlet-class
init-param
param-namejspCompilerPlugin/param-name
param-valueorg.apache.jasper.compiler.JikesJavaCompiler/param-value
/init-param
init-param
param-namejspCompilerPath/param-name
param-valued:\test\CanogaView\Jikes\win32\1.12\bin\jikes.exe/param-value
/init-param
load-on-startup
-2147483646
/load-on-startup
/servlet
changing d:\test\CanogaView\Jikes\win32\1.12\bin\jikes.exe to the path
where
you have jikes installed and also
servlet-mapping
servlet-name
jsp
/servlet-name
url-pattern
*.jsp
/url-pattern
/servlet-mapping
Note that you will get a warning from stderr of something like:
2001-06-06 04:06:34 - Ctx( /CanogaView ): Removing duplicate servlet
jsp
jsp(org.apache.jasper.servlet.JspServlet/null)
2001-06-06 04:06:34 - Ctx( /CanogaView ): Removing duplicate *.jsp -
jsp(org.apache.jasper.servlet.JspServlet/null)
This is because Tomcat has a builtin JSP servlet and mapping configuration
and you are overriding this.
- Original Message -
From: chris brown [EMAIL PROTECTED]
To: tomcat-user [EMAIL PROTECTED]
Sent: Thursday, June 07, 2001 4:45 AM
Subject: Re: Jikes and Tomcat for JSP compilation
Hi Peter (and anyone else following this thread),
If it's any consolation, I've asked the same question on many mailing
lists
over a long period of time, and nobody's given a working answer yet.
I have a JDK installed (hence I've got javac), plus Jikes. When using
Jikes from the commandline, it works fine. I've even uncommented the
line
in web.xml. But I never seemed to get it working, as in the pages
still
compiled, but there was no way of knowing if it was jikes or javac that
did
it I tried renaming Jikes.exe to _jikes._exe to see if Tomcat
missed
it, but it didn't complain, so I just assumed it hadn't been taken into
account anyway.
I suspected that I needed to copy all (or part) of the default web.xml
into
each web-app's WEB-INF folder, uncommenting the jikes line as
appropriate.
However, this didn't work at all well, as it seemed to give Tomcat a
headache. I've already posted on this (overriding default web.xml with
custom web.xml). Not a lot of luck there either...
Hope someone can give a clear answer as to how to do this -- and verify
that
it works!
-Chris Brown
- Original Message -
From: WEST, Peter
To: [EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 8:19 PM
Subject: Jikes and Tomcat for JSP compilation
Re: Error: Could not find package named:
Jack, your not using Jikes by any chance are you? If so, I had the same error but with Sun's JVM 1.3 and I needed to add "rt.jar" to my path. Just a shot... - Original Message - From: Jack Lauman [EMAIL PROTECTED] To: Tomcat User List [EMAIL PROTECTED] Sent: Sunday, February 18, 2001 10:47 PM Subject: Error: Could not find package named: I got the following error when trying to run jsp examples in tomcat 4.0b1. The servlet examples run without any problems. I would appreciate any guidance on how to resolve this. Regards, Jack org.apache.jasper.JasperException: Unable to compile class for JSP Found 2 system errors: *** Error: Could not find package named: /opt/tomcat/bin/bootstrap.jar(java/util), /opt/tomcat/bin/servlet.jar(java/util), /opt/tomcat/bin/naming.jar(java/util), /opt/IBMJava2-13/lib/tools.jar(java/util), /opt/tomcat/webapps/examples/WEB-INF/classes/java/util, /opt/tomcat/lib/jasper.jar(java/util), /opt/tomcat/lib/jaxp.jar(java/util), /opt/tomcat/lib/crimson.jar(java/util), /opt/tomcat/lib/namingfactory.jar(java/util), /opt/tomcat/bin/jndi.jar(java/util) or /opt/tomcat/work/localhost/examples/java/util - 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: Caching with Tomcat 3.2
What I do touch the JSP page by bringing it up an and editor and changing something (adding a space and removing it) so that it appears modified. Then Jasper will see that it needs to recompile the JSP page creating a new servlet with a new class loaded and then the classes that the JSP pages uses will be loaded by this new class loader. Seems to work for me. - Original Message - From: Ryan To: [EMAIL PROTECTED] Sent: Wednesday, February 14, 2001 5:43 PM Subject: Caching with Tomcat 3.2 With my current setup I will change classes and recompile them and then hit reload in the web browser to reload the jsp page that uses a certain class but the older version seems to be stuck in cache. Is this a bug? I just thinking about turning it off altogether. Does anyone know how to disable caching in tomcat 3.21? -thanx Ryan
