Re: JSP Newbie seeking guidance
Justin Jaynes wrote: I would HIGHLY recommend using SuSE Linux 10 which can be purchased or download from Novell directly at suse.com. Also, see the openSuSE project (essentially the open source community effort half of the SuSE/novell team). I used to run RedHat but was disappointed in the drop to Fedora. I tried SuSE a few years ago and have never looked back. So easy to install and configure. The YaST systems management tool is amazing. You can still do everything the manual way (and I do sometimes). But the firewall is easy and strong, the package management is simple, the install resizes partitions (even NTFS). Just so many highly polished surfaces there. Try SuSE and see if you ever go back. I have run tomcat and SuSE in production for over a year and not had a problem and am now in the process of upgrading my production server to SuSE 10 and tomcat 5.5.12. So far so good. It's all working in my development area. The improvements in 5.5.12 are EXCELLENT. But there are significant changes in how you set up the server.xml file, so read up on the 5.5 doc page. I had previously only been using 5.0.x. ALso, I had some glitchy problems with 5.5.9. No reason to download it now anyhow, since 5.5.12 is stable release. I also recommend PostgreSQL 8.0 from postgresql.org if you need database (as i imagine you must) (open source and fully ansiSQL standard and RDBMS compliant, unlike mySQL --don't yell at me for saying so, please-- i know how much many people love mySQL. You have to build Postgresql from source on SuSE 10 since no rpms are out in the combination of those versions of SuSE and PGSQL. I tired to use older RPMS--not a good idea. But the build and install went perfectly. Be sure you have the proper dev packages installed before you try. If not, the documentation tells all you need to know. PostgreSQL 8.0, Tomcat 5.5.12, and SuSE 10 are real winners. I have had --no-- problems with the past versions, and these new versions seem up to par or better. I LOVE SuSE 10.0 for my desktop environment/school computing/web surfing/DVD watching(i use KDE) and run everything just described on my Dell Inspiron 6000 notebook. That's my developemnt envrionment. Obviously the combination of KDE and the servers on a notebook are no match for my production environment. but I must say, my notebook and the software on it do all I ever ask them to--school work, web surfing, large SQL routines, JVM, Tomcat--and a fair bit of graphics design. All on open source software. What a wonderful world we live in. (The DVD's I run on XINE, which I had to build, since XINE is stripped down for leagal reasons in SuSE 10, but the build installed great and runs with no problem just by typing xine in KDE). Justin --with more to say than you probably wanted to here By no means--useful to me as well. Thanks for sharing. Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Newbie seeking guidance
Not at all, Justin. Thank you, thank you! Also, thank you, Mark Eggers. As I am so new to this, I run the risk of veering off-topic, which I realize is inappropriate. That said, I will get my newbie noggin back into the woodshed so that I may be true to this list. Best wishes, John G. on 10/10/05 10:11 PM, Justin Jaynes at [EMAIL PROTECTED] wrote: Justin --with more to say than you probably wanted to here *** John Geiger Fox Parlor Design Pho 415-821-7100 Fax 415-821-7102 Cell 415-307-2554 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Newbie seeking guidance
John, If you need help with setting up the environment I described (and BOY could I have used help my first time--mostly I tutored myself and failed and failed before succeeding) you can ask me and I will know at least where to point you for relevant information. I assume you have done your own building of software packages from source like PostgreSQL, but if you haven't, that alone can feel like a daunting task--really, its quite simple. Just email me directly and I'll fill you in as much as I can. Justin --- John Geiger [EMAIL PROTECTED] wrote: Not at all, Justin. Thank you, thank you! Also, thank you, Mark Eggers. As I am so new to this, I run the risk of veering off-topic, which I realize is inappropriate. That said, I will get my newbie noggin back into the woodshed so that I may be true to this list. Best wishes, John G. on 10/10/05 10:11 PM, Justin Jaynes at [EMAIL PROTECTED] wrote: Justin --with more to say than you probably wanted to here *** John Geiger Fox Parlor Design Pho 415-821-7100 Fax 415-821-7102 Cell 415-307-2554 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Newbie seeking guidance
John Geiger escribió: Hello: This is a little intimidating, but I am eager. I hope I am in the right place. I am a DHTML developer‹intermediate level. I¹ve been exposed to JSP on an iPlanet server, Sun OS 5.8 (but it is my client¹s production server, and I¹m reluctant to mess around there!) I now have my own Tomcat install kind-of-working on a Fedora Core 2 box. It is Tomcat 5.0.x with Apache 1.3. Besides the other answers you will get, I would think you would want to run Tomcat standalone (i.e., have it process HTML pages as well), and not bother with connecting it to the Apache web server. You are just learning about JSP right now; not hosting web applications, so Apache is probably an unnecessary distraction at this time. Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Newbie seeking guidance
I am avoiding the real issue--OK, I am ready to face it: javax.servlet.ServletException: javax.servlet.jsp.JspTagException: In lt;drivergt;, invalid driver class name: java.lang.ClassNotFoundException: com.mysql.jdbc.Driver This is the error I get running an exercise from the Apress book. I can not seem to find my way using Google. I think maybe MySQL is not installed--or I am missing an important file...somewhere! Eeek. Thanks. on 10/10/05 8:45 PM, Glen Mazza at [EMAIL PROTECTED] wrote: John Geiger escribió: Hello: This is a little intimidating, but I am eager. I hope I am in the right place. I am a DHTML developer‹intermediate level. I¹ve been exposed to JSP on an iPlanet server, Sun OS 5.8 (but it is my client¹s production server, and I¹m reluctant to mess around there!) I now have my own Tomcat install kind-of-working on a Fedora Core 2 box. It is Tomcat 5.0.x with Apache 1.3. Besides the other answers you will get, I would think you would want to run Tomcat standalone (i.e., have it process HTML pages as well), and not bother with connecting it to the Apache web server. You are just learning about JSP right now; not hosting web applications, so Apache is probably an unnecessary distraction at this time. Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** John Geiger Fox Parlor Design Pho 415-821-7100 Fax 415-821-7102 Cell 415-307-2554 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Newbie seeking guidance
I am not familiar with the book. If they are recommending using Tomcat's connection pools and JNDI, then you will need to add the jar file that contains the MySQL driver to $CATALINA_HOME/common/lib. If you are connecting to the database directly from your web application then you probably need to place the jar file containing the MySQL driver in $CATALINA_HOME/webapps/app-name/WEB-INF/lib, where app-name is the name of your application. You can pick up the MySQL jdbc driver from: http://dev.mysql.com/downloads/connector/j/3.1.html If you are just starting out on jsp/servlet programming, then running Tomcat standalone is probably a good first choice. The later versions of Tomcat (5.5.x) perform pretty much the same as Apache 2.0.x for static pages. Coupling Apache and Tomcat together makes sense when you start using some of the features that Apache supports but that Tomcat may not be optimal for. HTH /mde/ --- John Geiger [EMAIL PROTECTED] wrote: I am avoiding the real issue--OK, I am ready to face it: javax.servlet.ServletException: javax.servlet.jsp.JspTagException: In lt;drivergt;, invalid driver class name: java.lang.ClassNotFoundException: com.mysql.jdbc.Driver This is the error I get running an exercise from the Apress book. I can not seem to find my way using Google. I think maybe MySQL is not installed--or I am missing an important file...somewhere! Eeek. Thanks. __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Newbie seeking guidance
I would HIGHLY recommend using SuSE Linux 10 which can be purchased or download from Novell directly at suse.com. Also, see the openSuSE project (essentially the open source community effort half of the SuSE/novell team). I used to run RedHat but was disappointed in the drop to Fedora. I tried SuSE a few years ago and have never looked back. So easy to install and configure. The YaST systems management tool is amazing. You can still do everything the manual way (and I do sometimes). But the firewall is easy and strong, the package management is simple, the install resizes partitions (even NTFS). Just so many highly polished surfaces there. Try SuSE and see if you ever go back. I have run tomcat and SuSE in production for over a year and not had a problem and am now in the process of upgrading my production server to SuSE 10 and tomcat 5.5.12. So far so good. It's all working in my development area. The improvements in 5.5.12 are EXCELLENT. But there are significant changes in how you set up the server.xml file, so read up on the 5.5 doc page. I had previously only been using 5.0.x. ALso, I had some glitchy problems with 5.5.9. No reason to download it now anyhow, since 5.5.12 is stable release. I also recommend PostgreSQL 8.0 from postgresql.org if you need database (as i imagine you must) (open source and fully ansiSQL standard and RDBMS compliant, unlike mySQL --don't yell at me for saying so, please-- i know how much many people love mySQL. You have to build Postgresql from source on SuSE 10 since no rpms are out in the combination of those versions of SuSE and PGSQL. I tired to use older RPMS--not a good idea. But the build and install went perfectly. Be sure you have the proper dev packages installed before you try. If not, the documentation tells all you need to know. PostgreSQL 8.0, Tomcat 5.5.12, and SuSE 10 are real winners. I have had --no-- problems with the past versions, and these new versions seem up to par or better. I LOVE SuSE 10.0 for my desktop environment/school computing/web surfing/DVD watching(i use KDE) and run everything just described on my Dell Inspiron 6000 notebook. That's my developemnt envrionment. Obviously the combination of KDE and the servers on a notebook are no match for my production environment. but I must say, my notebook and the software on it do all I ever ask them to--school work, web surfing, large SQL routines, JVM, Tomcat--and a fair bit of graphics design. All on open source software. What a wonderful world we live in. (The DVD's I run on XINE, which I had to build, since XINE is stripped down for leagal reasons in SuSE 10, but the build installed great and runs with no problem just by typing xine in KDE). Justin --with more to say than you probably wanted to here --- John Geiger [EMAIL PROTECTED] wrote: Hello: This is a little intimidating, but I am eager. I hope I am in the right place. I am a DHTML developerintermediate level. I¹ve been exposed to JSP on an iPlanet server, Sun OS 5.8 (but it is my client¹s production server, and I¹m reluctant to mess around there!) I now have my own Tomcat install kind-of-working on a Fedora Core 2 box. It is Tomcat 5.0.x with Apache 1.3. I am studying an APress book called ³JSP 2.0 Novice to Professional,² but get errors with some of the exercises. (The book is great! Makes it sound so easy ;-) My main question is: Can someone recommend a proven Linux, Apache 2 Tomcat 5.5 combinationcould be unix, too. I figure I should set up a stable development rig firstone that I could eventually rely on in a light production environment. Also: I am interested in finding a tutor/mentor in the San Francisco Bay Area. Any advice would be much appreciated. Thanks, John G. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to serve just JSP (was: Re: JSP on RHEL4 with Apache http d RPM?
On Wed, 2005-09-14 at 13:22, KEREM ERKAN wrote: OK, start with downloading and installing a binary version of Tomcat for your OS and also download the 1.2.10 version of mod_jk. I think we should handle the rest off list not to bother the list anymore. Yes, that's lot's already installed and has been running fine. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to serve just JSP (was: Re: JSP on RHEL4 with Apache httpd RPM?
On Wed, 2005-09-14 at 14:04, Michael Lai wrote: KEREM ERKAN wrote: OK, start with downloading and installing a binary version of Tomcat for your OS and also download the 1.2.10 version of mod_jk. I think we should handle the rest off list not to bother the list anymore. Just to give you another option if you like. I don't even use mod_jd. I make use of Apache's reverse proxy feature. In my httpd.conf, I add the following lines in my virtual host: [snip] That's extremely useful, thanks. But I don't want to serve a single whole directory Tomcat, I need to server about a dozen isolated JSP files. Can ProxyPass hand off *.jsp to Tomcat rather than a whole directory? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to serve just JSP (was: Re: JSP on RHEL4 with Apache httpd RPM?
[Sorry for the repost but I still don't have an answer to this one] On Fri, 2005-09-09 at 15:50, Steve Dodge wrote: 1. VirtualHostis an apache http server directive. Right, but it was put there by Tomcat's auto-config. What I was trying to find out was, by localhost did Tomcat mean my (Tomcat's) localhost -- the server on 8080 -- or Apache's localhost, which is the server on port 80, which responds to many Virtual Hosts already in the httpd.conf file. 2. With JkMount you're not actually mapping a physical directory, it's a url pattern. Yes, but all the ones that Tomcat auto-config'd into mod_jk.conf are relative to the Tomcat webapps directory. How do I write a url pattern that can be interpreted as relative to Apache's document root, so that JSP files in there will be passed to Tomcat for serving? If you have a tomcat webapp that serves jsp's such as http://localhost:8080/mywebapp, then you can map jsp requests to that webapp using JkMount /mywebapp/*.jsp Ah...this exposes the gap in my understanding. Where do I get a tomcat webapp that serves jsp's? This is what I need. I thought one was built into Tomcat -- in fact I thought JSP serving was the original purpose of Tomcat. If Tomcat doesn't have any such webapp, where do I get one? I certainly can't write one, as I'm not a Java programmer. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to serve just JSP (was: Re: JSP on RHEL4 with Apache httpd RPM?
Peter Flynn wrote: If you have a tomcat webapp that serves jsp's such as http://localhost:8080/mywebapp, then you can map jsp requests to that webapp using JkMount /mywebapp/*.jsp Ah...this exposes the gap in my understanding. Where do I get a tomcat webapp that serves jsp's? This is what I need. I thought one was built into Tomcat -- in fact I thought JSP serving was the original purpose of Tomcat. If Tomcat doesn't have any such webapp, where do I get one? I certainly can't write one, as I'm not a Java programmer. I am limited in my knowledge of tomcat but from my understanding, tomcat can be ran either as a standalone server or behind a webserver. In your case, it seems like you don't actually need a webserver in front so you should be able to connect to tomcat using the url: http://localhost:8080/ Just make sure in your server.xml that you have this line: Connector port=8080 / or whatever port you want to connect to. In fact, I don't think you even need mod_jk if you are using tomcat as a standalone. Hope that helps. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to serve just JSP (was: Re: JSP on RHEL4 with Apache httpd RPM?
On Wed, 2005-09-14 at 10:17, Michael Lai wrote: Peter Flynn wrote: If Tomcat doesn't have any such webapp, where do I get one? I certainly can't write one, as I'm not a Java programmer. I am limited in my knowledge of tomcat but from my understanding, tomcat can be ran either as a standalone server or behind a webserver. In your case, it seems like you don't actually need a webserver in front so you should be able to connect to tomcat using the url: Unfortunately I have to keep the main port 80 httpd, as it's serving 20Gb of other material (the entire campus web site). All I need is the trick to make Apache httpd hand off any .jsp files to Tomcat. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to serve just JSP (was: Re: JSP on RHEL4 with Apache http d RPM?
Unfortunately I have to keep the main port 80 httpd, as it's serving 20Gb of other material (the entire campus web site). All I need is the trick to make Apache httpd hand off any .jsp files to Tomcat. As I am newly subscribed to this list, I don't know if you have got a satisfactory answer for your question, but if you don't; I have the same configuration like yours, static files are served by Apache and *.jsp files are served by Tomcat. All you have to do is to use Java Connector to mount jsp files to Tomcat. You can find the necessary documentation in Connectors part of Tomcat documentation. If you can't get out of it, I can help you set it up off or on list. Cheers, Kerem
RE: How to serve just JSP (was: Re: JSP on RHEL4 with Apache http d RPM?
On Wed, 2005-09-14 at 12:19, KEREM ERKAN wrote: Unfortunately I have to keep the main port 80 httpd, as it's serving 20Gb of other material (the entire campus web site). All I need is the trick to make Apache httpd hand off any .jsp files to Tomcat. As I am newly subscribed to this list, I don't know if you have got a satisfactory answer for your question, but if you don't; I have the same configuration like yours, static files are served by Apache and *.jsp files are served by Tomcat. That's exactly what I want. All you have to do is to use Java Connector to mount jsp files to Tomcat. You can find the necessary documentation in Connectors part of Tomcat documentation. Aha! Yes, AJP connector looks like what I need. Unfortunaely the documentation doesn't seem to show how to do this. If you can't get out of it, I can help you set it up off or on list. That would be great, many thanks. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to serve just JSP (was: Re: JSP on RHEL4 with Apache http d RPM?
-Original Message- From: Peter Flynn [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 14, 2005 2:40 PM To: Tomcat Users List Subject: RE: How to serve just JSP (was: Re: JSP on RHEL4 with Apache http d RPM? On Wed, 2005-09-14 at 12:19, KEREM ERKAN wrote: Unfortunately I have to keep the main port 80 httpd, as it's serving 20Gb of other material (the entire campus web site). All I need is the trick to make Apache httpd hand off any .jsp files to Tomcat. As I am newly subscribed to this list, I don't know if you have got a satisfactory answer for your question, but if you don't; I have the same configuration like yours, static files are served by Apache and *.jsp files are served by Tomcat. That's exactly what I want. OK, start with downloading and installing a binary version of Tomcat for your OS and also download the 1.2.10 version of mod_jk. I think we should handle the rest off list not to bother the list anymore.
Re: How to serve just JSP (was: Re: JSP on RHEL4 with Apache httpd RPM?
KEREM ERKAN wrote: OK, start with downloading and installing a binary version of Tomcat for your OS and also download the 1.2.10 version of mod_jk. I think we should handle the rest off list not to bother the list anymore. Just to give you another option if you like. I don't even use mod_jd. I make use of Apache's reverse proxy feature. In my httpd.conf, I add the following lines in my virtual host: ProxyPass /app http://localhost:8081/ ProxyPassReverse /app http://localhost:8081/ Just make sure you have loaded the following modules: LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_ftp_module modules/mod_proxy_ftp.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule proxy_connect_module modules/mod_proxy_connect.so What the above does is when Apache sees an url like: http://www.myhost.com/app It passes all traffic to tomcat which is listening to port 8081 (on the same machine). The beauty of this is that you can put this in your ssl.conf too and Apache will handle all encrypted traffic and passes it on to tomcat. The only advantage I see from mod_jk is if you are using it for load balancing too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP on RHEL4 with Apache httpd RPM?
On Fri, 2005-09-09 at 06:13, Nikola Milutinovic wrote: Peter Flynn wrote: I need to add JSP ability to a RHEL4 server running the current Apache httpd from the Red Hat RPM. Apparently the httpd RPM available from Red Hat doesn't have the hooks needed to allow JSP files to be passed to Tomcat (or if it does, I can't find them). Has anyone managed to serve JSP with Tomcat on a RHEL4 machine running their stock httpd? I'd rather not have to resort to building Apache httpd from scratch, as that would mean also moving away from RPMs for MySQL and PHP, in order to maintain synchronisation between them. You're looking for mod_jk RPM or mod_jk2 (which has been dropped from development). Thanks very much. Unfortunately the Tomcat I am using is one I installed from source, as I didn't know at the time that Red Hat had gotten around to making an RPM...and their RPM doesn't appear to support Cocoon (I tested it on a clone box and adding the war file to webapps just causes error messages about missing jar files to go into the logs). If you see mod_webapp RPM, run for your life. I'm getting good at that :-) As a workaround, you should be able to use mod_proxy to proxy requests for TC to it. Interesting idea, thanks. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP on RHEL4 with Apache httpd RPM?
On Fri, 2005-09-09 at 06:13, Nikola Milutinovic wrote: Peter Flynn wrote: I need to add JSP ability to a RHEL4 server running the current Apache httpd from the Red Hat RPM. [...] Has anyone managed to serve JSP with Tomcat on a RHEL4 machine running their stock httpd? You're looking for mod_jk RPM or mod_jk2 (which has been dropped from development). I found mod_jk-ap20-1.2.10-1jpp.i386.rpm at http://www.jpackage.org and It installed without error on RHEL4 running stock httpd-2.0.52-9.ent.rpm So far, so good. So I added the suggested element Listener className=org.apache.jk.config.ApacheConfig modJk=/usr/lib/httpd/modules/mod_jk.so / to the Engine name=Catalina ... container in server.xml and restarted Tomcat. This created /usr/local/jakarta-tomcat-5.5.9/conf/auto/mod_jk.conf (NOT mod_jk.conf.auto as the Jakarta Tomcat Connector Apache HowTo documentation says). The mod_jk.conf was pretty skeletal, so I added: JkWorkersFile /usr/local/jakarta-tomcat-5.5.9/conf/workers.properties and edited workers.properties to reflect the locations workers.tomcat_home=/usr/local/jakarta-tomcat-5.5.9 workers.java_home=/usr/java/jdk1.5.0_03 and added this line to /etc/httpd/conf/httpd.conf Include /usr/local/jakarta-tomcat-5.5.9/conf/auto/mod_jk.conf and finally restarted Apache. No error, but it doesn't do anything meaningful with my JSP files: it just serves them through Apache. Looking in mod_jk.conf I see it mentions all the subdirectories in Tomcat's webapps directory, but nowhere does it reference any directories in my Apache document tree. I've obviously missed how to get it configured to serve JSP files from the Apache web server directories. I have no interest in serving any JSPs from the Tomcat directories, as all I use Tomcat:8080 for is serving Cocoon, which already works fine. The JkMount directives in mod_jk.conf all refer to /directory being in Tomcat's webapps directory. How do I reference directories which are actually below /var/www/html so that they get handled by Tomcat? In mod_jk.conf, what does this refer to: VirtualHost localhost ServerName localhost The Tomcat:8080 server or the Apache httpd:80 server? If it's Tomcat, then I can understand why JkMount /directory refers to Tomcat's webapps, but it seems very weird that the autoconf should configure mod_jk.conf to mount only Tomcat's directories, when the entire point of the operation is to enable serving of Apache's own JSP files. If it's Apache's httpd, which it is presumably intended for, as this file gets Include'd from Apache's httpd.conf, then why does it still refer to localhost instead of picking up the ServerName from the httpd.conf? Should I change both localhost's to my server's FQDN? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP on RHEL4 with Apache httpd RPM?
Peter Flynn wrote: On Fri, 2005-09-09 at 06:13, Nikola Milutinovic wrote: Peter Flynn wrote: I need to add JSP ability to a RHEL4 server running the current Apache httpd from the Red Hat RPM. [...] Has anyone managed to serve JSP with Tomcat on a RHEL4 machine running their stock httpd? You're looking for mod_jk RPM or mod_jk2 (which has been dropped from development). I found mod_jk-ap20-1.2.10-1jpp.i386.rpm at http://www.jpackage.org and It installed without error on RHEL4 running stock httpd-2.0.52-9.ent.rpm So far, so good. So I added the suggested element Listener className=org.apache.jk.config.ApacheConfig modJk=/usr/lib/httpd/modules/mod_jk.so / to the Engine name=Catalina ... container in server.xml and restarted Tomcat. This created /usr/local/jakarta-tomcat-5.5.9/conf/auto/mod_jk.conf (NOT mod_jk.conf.auto as the Jakarta Tomcat Connector Apache HowTo documentation says). The mod_jk.conf was pretty skeletal, so I added: JkWorkersFile /usr/local/jakarta-tomcat-5.5.9/conf/workers.properties and edited workers.properties to reflect the locations workers.tomcat_home=/usr/local/jakarta-tomcat-5.5.9 workers.java_home=/usr/java/jdk1.5.0_03 and added this line to /etc/httpd/conf/httpd.conf Include /usr/local/jakarta-tomcat-5.5.9/conf/auto/mod_jk.conf and finally restarted Apache. No error, but it doesn't do anything meaningful with my JSP files: it just serves them through Apache. Looking in mod_jk.conf I see it mentions all the subdirectories in Tomcat's webapps directory, but nowhere does it reference any directories in my Apache document tree. I've obviously missed how to get it configured to serve JSP files from the Apache web server directories. I have no interest in serving any JSPs from the Tomcat directories, as all I use Tomcat:8080 for is serving Cocoon, which already works fine. The JkMount directives in mod_jk.conf all refer to /directory being in Tomcat's webapps directory. How do I reference directories which are actually below /var/www/html so that they get handled by Tomcat? In mod_jk.conf, what does this refer to: VirtualHost localhost ServerName localhost The Tomcat:8080 server or the Apache httpd:80 server? If it's Tomcat, then I can understand why JkMount /directory refers to Tomcat's webapps, but it seems very weird that the autoconf should configure mod_jk.conf to mount only Tomcat's directories, when the entire point of the operation is to enable serving of Apache's own JSP files. If it's Apache's httpd, which it is presumably intended for, as this file gets Include'd from Apache's httpd.conf, then why does it still refer to localhost instead of picking up the ServerName from the httpd.conf? Should I change both localhost's to my server's FQDN? ///Peter Peter, 1. VirtualHostis an apache http server directive. 2. With JkMount you're not actually mapping a physical directory, it's a url pattern. If you have a tomcat webapp that serves jsp's such as http://localhost:8080/mywebapp, then you can map jsp requests to that webapp using JkMount /mywebapp/*.jsp Hope that helps, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP on RHEL4 with Apache httpd RPM?
On Fri, 2005-09-09 at 15:50, Steve Dodge wrote: 1. VirtualHostis an apache http server directive. Right, but it was put there by Tomcat's auto-config. What I was trying to find out was, by localhost did Tomcat mean my (Tomcat's) localhost -- the server on 8080 -- or Apache's localhost, which is the server on port 80, which responds to many Virtual Hosts already in the httpd.conf file. 2. With JkMount you're not actually mapping a physical directory, it's a url pattern. Yes, but all the ones that Tomcat auto-config'd into mod_jk.conf are relative to the Tomcat webapps directory. How do I write a url pattern that can be interpreted as relative to Apache's document root, so that JSP files in there will be passed to Tomcat for serving? If you have a tomcat webapp that serves jsp's such as http://localhost:8080/mywebapp, then you can map jsp requests to that webapp using JkMount /mywebapp/*.jsp Ah...this exposes the gap in my understanding. Where do I get a tomcat webapp that serves jsp's? This is what I need. I thought one was built into Tomcat -- in fact I thought JSP serving was the original purpose of Tomcat. If Tomcat doesn't have any such webapp, where do I get one? I certainly can't write one, as I'm not a Java programmer. ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP on RHEL4 with Apache httpd RPM?
Peter Flynn wrote: I need to add JSP ability to a RHEL4 server running the current Apache httpd from the Red Hat RPM. Apparently the httpd RPM available from Red Hat doesn't have the hooks needed to allow JSP files to be passed to Tomcat (or if it does, I can't find them). Has anyone managed to serve JSP with Tomcat on a RHEL4 machine running their stock httpd? I'd rather not have to resort to building Apache httpd from scratch, as that would mean also moving away from RPMs for MySQL and PHP, in order to maintain synchronisation between them. You're looking for mod_jk RPM or mod_jk2 (which has been dropped from development). If you see mod_webapp RPM, run for your life. As a workaround, you should be able to use mod_proxy to proxy requests for TC to it. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP 2.1 support?
There has been no talk of tomcat 6. It is expected that once the 2.5 version of the servlet spec is announced (in draft form) - work would begin on tomcat6. -Tim Jonathan Eric Miller wrote: Does anyone know when JSP 2.1 support is expected? Will that be in Tomcat 6? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jsp stuff
thanks From: Adile Abbadi [EMAIL PROTECTED] Reply-To: Tomcat Users List tomcat-user@jakarta.apache.org To: Tomcat Users List tomcat-user@jakarta.apache.org Subject: RE: jsp stuff Date: Fri, 22 Jul 2005 11:12:16 -0600 You don't need to change anything in tomcat to make it access a database except one thing - you need is a compliant JDBC driver which you through into the Common Library directory of tomcat. Once tomcat starts it will load the driver and then at that point you can use code to access the Database. I would recommend you use a pooling tool as well - to pool your connections and limit resource use. Check google - lots of info out there. HTH Adile -Original Message- From: ganesan malairaja [mailto:[EMAIL PROTECTED] Sent: July 21, 2005 8:53 PM To: tomcat-user@jakarta.apache.org Subject: jsp stuff hi guys i want to know is there any setting to be done with tomcat so the JSP codes can access the database ( MySQL) and display the information ? thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/54 - Release Date: 7/21/05 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.9.2/55 - Release Date: 7/21/05 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ganesan_Malairaja - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp stuff
Thankyou very much for your info,best regards,Gregory - Original Message - From: ganesan malairaja [EMAIL PROTECTED] To: tomcat-user@jakarta.apache.org Sent: Saturday, July 23, 2005 2:17 AM Subject: RE: jsp stuff thanks From: Adile Abbadi [EMAIL PROTECTED] Reply-To: Tomcat Users List tomcat-user@jakarta.apache.org To: Tomcat Users List tomcat-user@jakarta.apache.org Subject: RE: jsp stuff Date: Fri, 22 Jul 2005 11:12:16 -0600 You don't need to change anything in tomcat to make it access a database except one thing - you need is a compliant JDBC driver which you through into the Common Library directory of tomcat. Once tomcat starts it will load the driver and then at that point you can use code to access the Database. I would recommend you use a pooling tool as well - to pool your connections and limit resource use. Check google - lots of info out there. HTH Adile -Original Message- From: ganesan malairaja [mailto:[EMAIL PROTECTED] Sent: July 21, 2005 8:53 PM To: tomcat-user@jakarta.apache.org Subject: jsp stuff hi guys i want to know is there any setting to be done with tomcat so the JSP codes can access the database ( MySQL) and display the information ? thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/54 - Release Date: 7/21/05 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.9.2/55 - Release Date: 7/21/05 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ganesan_Malairaja - 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: jsp stuff
Hi, One way to access database from JSP pages is using connection pool from JNDI. You can find more information from here: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jndi-datasource-examples-howto.html On 7/21/05, ganesan malairaja [EMAIL PROTECTED] wrote: hi guys i want to know is there any setting to be done with tomcat so the JSP codes can access the database ( MySQL) and display the information ? thank you - 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: Jsp and xml
Two things I can think of:
1. Remember that a line that contains % ...code... % will also
produce an end-of-line (eol) character, so instead of something like this:
% for (int i=0; ilist.length; i++) { %
tag name=%= list[i] %
% } %
do something like this:
% for (int i=0; ilist.length; i++) { %tag name=%= list[i] %
% } %
or this:
% for (int i=0; ilist.length; i++) {
%tag name=%= list[i] %
% } %
2. Maybe you are producing the xml/jsp on a Windows computer that
produces CR + LF characters and viewing it on a computer that interprets
these as two separate EOL characters. This is not as likely as number 1
above.
Tim Koop
Kiran Patel wrote:
Hello all,
I am creating a xml document using JSP. The JAVA codes in JSP creates blank
lines in xml document. How can I remove this or how can I don't create. I
will appreciate any help.
Thank You,
Kiran Patel
Software Engineer
Solutions Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: jsp stuff
You don't need to change anything in tomcat to make it access a database except one thing - you need is a compliant JDBC driver which you through into the Common Library directory of tomcat. Once tomcat starts it will load the driver and then at that point you can use code to access the Database. I would recommend you use a pooling tool as well - to pool your connections and limit resource use. Check google - lots of info out there. HTH Adile -Original Message- From: ganesan malairaja [mailto:[EMAIL PROTECTED] Sent: July 21, 2005 8:53 PM To: tomcat-user@jakarta.apache.org Subject: jsp stuff hi guys i want to know is there any setting to be done with tomcat so the JSP codes can access the database ( MySQL) and display the information ? thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/54 - Release Date: 7/21/05 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.9.2/55 - Release Date: 7/21/05 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jsp Pre-compilation
Yeboo,
The pathes needed to be absolute. Thanks for the help. Sorry for the late
reply.
Gruss
Nils
mtgglf
-Original Message-
From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 30, 2005 3:18 PM
To: 'Tomcat Users List'
Subject: AW: Jsp Pre-compilation
Hi Nils,
two things:
1. I would use an absolute path instead of the realitive one ./hummingbird
I guess jasper just can't pick up your jsps!
2. outputDir: You set it to WEB-INF/classes but what you create are
actually java source files, so this is not right, even tohough it doesn't
explain the failure of the precompliation
Good luck
Bernhard
-Ursprüngliche Nachricht-
Von: Nils Liebelt [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 30. Juni 2005 15:09
An: tomcat-user@jakarta.apache.org
Cc: [EMAIL PROTECTED]
Betreff: Jsp Pre-compilation
Hi all,
I have trouble pre-compiling my jsp-pages. I wrote following
ant target:
target name=jspc depends=build
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath id=jspc.classpath
fileset dir=${tomcat.home}/bin
include name=*.jar/
/fileset
fileset dir=${tomcat.home}/server/lib
include name=*.jar/
/fileset
fileset dir=${tomcat.home}/common/lib
include name=*.jar/
/fileset
/classpath
/taskdef
jasper2 validateXml=false
compile=true
verbose=99
listErrors=true
uriroot=./hummingbird
webXmlFragment=./hummingbird/WEB-INF/generated_web.xml
outputDir=./hummingbird/WEB-INF/classes /
/target
The task executes successful but it does not create a single
java file nor
its outputs anything? I want execute the task out of my
project src folder.
The libraries should be at the right place. I am really stuck here...
Regards,
Nils
-
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: jsp include/RequestDispatcher incompatible?
So before each request dispatcher call I need to call a flush on the
out in the JspPage? How do I get access to it?
Do I also need to call flush at the end of each request dispatcher call?
--George
On 6/28/05, Tim Funk [EMAIL PROTECTED] wrote:
The out from the jspwriter is NOT the same out as receieved by
response.getWriter();
The out in the JspPage is buffered.
-Tim
George Finklang wrote:
have the following code in my jsp, which is called by a forward from my
Controller servlet. The various Dispatchers are either servlets or jsps
declared
in my web.xml.
All the servlets and jsps get run correctly. The problem is the output. The
output of the root jsp and the 3-4 included jsps are arbitrarily
rearranged, see
below. Bizarre shuffling, not reverse order, but a different order and not
interleaved with the text from the jsp.
If I translate the jsp into servlet code, and use RequestDispatchers
for all the components,
the page works. The documentation says something about flushing buffers,
but I
can't see how to do this with RequestDispatchers.
Code:
BODY
jsp:include page=WEB-INF/jsps/portal/header.jsp flush=true/
% if(option1) {
application.getNamedDispatcher(Option1Servlet).include(request,response);
} else { %
tabletr
% if(option2) { %
td%
application.getNamedDispatcher(Option2Servlet).include(request,response);
%/td
% } %
td%
application.getNamedDispatcher(page).include(request,response);
%/td
td%
application.getNamedDispatcher(InfoServlet).include(request,response);
%/td
/tr/table
% } %
/BODY
generated html:
BODY
Page text // from the page dispatcher
Info servlet text // from the infoservlet dispatcher
Header form text // from the header.jsp dispatcher
tabletr
td/td
td/td
/tr/table
/BODY
-
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: jsp include/RequestDispatcher incompatible?
Try flush first, otherwise you might need to pass a
HttpServletResponseWrapper() to include() where the wrapper oversrides
getOutputStream() (or getWriter()
-Tim
George Finklang wrote:
So before each request dispatcher call I need to call a flush on the
out in the JspPage? How do I get access to it?
Do I also need to call flush at the end of each request dispatcher call?
--George
On 6/28/05, Tim Funk [EMAIL PROTECTED] wrote:
The out from the jspwriter is NOT the same out as receieved by
response.getWriter();
The out in the JspPage is buffered.
-Tim
George Finklang wrote:
have the following code in my jsp, which is called by a forward from my
Controller servlet. The various Dispatchers are either servlets or jsps declared
in my web.xml.
All the servlets and jsps get run correctly. The problem is the output. The
output of the root jsp and the 3-4 included jsps are arbitrarily rearranged, see
below. Bizarre shuffling, not reverse order, but a different order and not
interleaved with the text from the jsp.
If I translate the jsp into servlet code, and use RequestDispatchers
for all the components,
the page works. The documentation says something about flushing buffers, but I
can't see how to do this with RequestDispatchers.
Code:
BODY
jsp:include page=WEB-INF/jsps/portal/header.jsp flush=true/
% if(option1) {
application.getNamedDispatcher(Option1Servlet).include(request,response);
} else { %
tabletr
% if(option2) { %
td%
application.getNamedDispatcher(Option2Servlet).include(request,response);
%/td
% } %
td%
application.getNamedDispatcher(page).include(request,response); %/td
td%
application.getNamedDispatcher(InfoServlet).include(request,response);
%/td
/tr/table
% } %
/BODY
generated html:
BODY
Page text // from the page dispatcher
Info servlet text // from the infoservlet dispatcher
Header form text // from the header.jsp dispatcher
tabletr
td/td
td/td
/tr/table
/BODY
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp include/RequestDispatcher incompatible?
Feh. Easier to just translate the whole jsp into a servlet by hand
which is what I already did.
--George
On 6/29/05, Tim Funk [EMAIL PROTECTED] wrote:
Try flush first, otherwise you might need to pass a
HttpServletResponseWrapper() to include() where the wrapper oversrides
getOutputStream() (or getWriter()
-Tim
George Finklang wrote:
So before each request dispatcher call I need to call a flush on the
out in the JspPage? How do I get access to it?
Do I also need to call flush at the end of each request dispatcher call?
--George
On 6/28/05, Tim Funk [EMAIL PROTECTED] wrote:
The out from the jspwriter is NOT the same out as receieved by
response.getWriter();
The out in the JspPage is buffered.
-Tim
George Finklang wrote:
have the following code in my jsp, which is called by a forward from my
Controller servlet. The various Dispatchers are either servlets or jsps
declared
in my web.xml.
All the servlets and jsps get run correctly. The problem is the output. The
output of the root jsp and the 3-4 included jsps are arbitrarily
rearranged, see
below. Bizarre shuffling, not reverse order, but a different order and not
interleaved with the text from the jsp.
If I translate the jsp into servlet code, and use RequestDispatchers
for all the components,
the page works. The documentation says something about flushing buffers,
but I
can't see how to do this with RequestDispatchers.
Code:
BODY
jsp:include page=WEB-INF/jsps/portal/header.jsp flush=true/
% if(option1) {
application.getNamedDispatcher(Option1Servlet).include(request,response);
} else { %
tabletr
% if(option2) { %
td%
application.getNamedDispatcher(Option2Servlet).include(request,response);
%/td
% } %
td%
application.getNamedDispatcher(page).include(request,response);
%/td
td%
application.getNamedDispatcher(InfoServlet).include(request,response);
%/td
/tr/table
% } %
/BODY
generated html:
BODY
Page text // from the page dispatcher
Info servlet text // from the infoservlet dispatcher
Header form text // from the header.jsp dispatcher
tabletr
td/td
td/td
/tr/table
/BODY
-
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]
-
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: jsp include/RequestDispatcher incompatible?
The out from the jspwriter is NOT the same out as receieved by
response.getWriter();
The out in the JspPage is buffered.
-Tim
George Finklang wrote:
have the following code in my jsp, which is called by a forward from my
Controller servlet. The various Dispatchers are either servlets or jsps declared
in my web.xml.
All the servlets and jsps get run correctly. The problem is the output. The
output of the root jsp and the 3-4 included jsps are arbitrarily rearranged, see
below. Bizarre shuffling, not reverse order, but a different order and not
interleaved with the text from the jsp.
If I translate the jsp into servlet code, and use RequestDispatchers
for all the components,
the page works. The documentation says something about flushing buffers, but I
can't see how to do this with RequestDispatchers.
Code:
BODY
jsp:include page=WEB-INF/jsps/portal/header.jsp flush=true/
% if(option1) {
application.getNamedDispatcher(Option1Servlet).include(request,response);
} else { %
tabletr
% if(option2) { %
td%
application.getNamedDispatcher(Option2Servlet).include(request,response);
%/td
% } %
td%
application.getNamedDispatcher(page).include(request,response); %/td
td%
application.getNamedDispatcher(InfoServlet).include(request,response);
%/td
/tr/table
% } %
/BODY
generated html:
BODY
Page text // from the page dispatcher
Info servlet text // from the infoservlet dispatcher
Header form text // from the header.jsp dispatcher
tabletr
td/td
td/td
/tr/table
/BODY
-
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: JSP pre-compile and Apache
I have the precompiled JSP's working with Apache now. Thanks. Apart from the first-time-hit compilation penalty on a normal jsp (as apposed to a precompiled one), why would you choose one option above the other? Standard jsp is easier to do updates if you work in an unpacked war setup - you just change the file and it is updated. Precompiled you have to acctually precompile the file. But how about performance and other issues? I guess it depends on your application, but is there somewhere a good checklist to determine when to choose the one option over the other? --- Terence M. Bandoian [EMAIL PROTECTED] wrote: Have you granted the site accessClassInPackage runtime permission? -Terence M. Bandoian [EMAIL PROTECTED] I used to precompile my JSP's (which worked great and was a big time saver in testing), but since running Tomcat 4.1.31 together with Apache, all sorts of weird errors occurred. I remember reading somewhere that Apache expected the actual jsp file, not the compiled version. So I reverted back to *not* precompiling JSP's and everything worked as expected. Question now, obviously there is a first-time-compile penalty per jsp, but once compiled, should performance be the same? How about the overhead to check if the .jsp file indeed matches the compiled version? Has someone managed to get precompiled JSP's running in combination with Apache? - 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: JSP including servlet output
Never mind, got it... changed: ServletOutputStream out = response.getOutputStream(); ..to... PrintWriter out = response.getWriter(); ...and it now works. I wouldn't mind an explanation though :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Fri, June 17, 2005 2:02 pm, Frank W. Zammetti said: Hey all... I have a situation where I want to use a jsp:include whos target is actually a servlet... Problem is, in the servlet I do: ServletOutputStream out = response.getOutputStream(); out.println(items.getItem()); ...which yields: java.lang.IllegalStateException org.apache.jasper.runtime.ServletResponseWrapperInclude.getOutputStream(ServletResponseWrapperInclude.java:62) Commenting out those two lines gets rid of the exception. If I call the servlet directly on its own I get my expected result, so I know the servlet itself works. I'm assuming this is some sort of limitation of the include mechanism, question is, can it be overcome? I added flush=true to the include tag, which gets rid of the exception but makes the resultant page end where the include is, so that's not the answer. An ideas? Is this something that can be done in the first place? If so, how does one overcome this problem? TIA! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSP including servlet output
Not a full explanation, but the Javadoc for ServletResponse.getOutputStream() does say: Throws: java.lang.IllegalStateException - if the getWriter method has been called on this response Conversely, getWriter() says: Throws: java.lang.IllegalStateException - if the getOutputStream method has already been called for this response object It'd seem that the Writer had already been acquired. Jay | Jay Burgess [Vertical Technology Group] | Essential Technology Links via RSS | http://www.vtgroup.com/ -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Friday, June 17, 2005 1:21 PM To: tomcat-user@jakarta.apache.org Subject: Re: JSP including servlet output Never mind, got it... changed: ServletOutputStream out = response.getOutputStream(); ..to... PrintWriter out = response.getWriter(); ...and it now works. I wouldn't mind an explanation though :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Fri, June 17, 2005 2:02 pm, Frank W. Zammetti said: Hey all... I have a situation where I want to use a jsp:include whos target is actually a servlet... Problem is, in the servlet I do: ServletOutputStream out = response.getOutputStream(); out.println(items.getItem()); ...which yields: java.lang.IllegalStateException org.apache.jasper.runtime.ServletResponseWrapperInclude.getOutputStream(ServletResponseWrapperInclude.java:62) Commenting out those two lines gets rid of the exception. If I call the servlet directly on its own I get my expected result, so I know the servlet itself works. I'm assuming this is some sort of limitation of the include mechanism, question is, can it be overcome? I added flush=true to the include tag, which gets rid of the exception but makes the resultant page end where the include is, so that's not the answer. An ideas? Is this something that can be done in the first place? If so, how does one overcome this problem? TIA! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - 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: JSP including servlet output
Yeah, I saw those notes too... I found them a tad confusing :) I would have thought it was the OutputStream that was already gotten, contrary to what the note says... If it was the PrintWriter that was already gotten, then why was the solution to call getWriter() instead? I get the feeling those notes are actually backwatds because as they are it doesn't make sense to me. Or something else entirely is going on. That's the problem for me... if I don't really understand what was wrong, and why the fix is what it was, I can't be sure this code will work in all cases going forward, and that worries me since it is part of a generic package. Frank Jay Burgess wrote: Not a full explanation, but the Javadoc for ServletResponse.getOutputStream() does say: Throws: java.lang.IllegalStateException - if the getWriter method has been called on this response Conversely, getWriter() says: Throws: java.lang.IllegalStateException - if the getOutputStream method has already been called for this response object It'd seem that the Writer had already been acquired. Jay | Jay Burgess [Vertical Technology Group] | Essential Technology Links via RSS | http://www.vtgroup.com/ -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Friday, June 17, 2005 1:21 PM To: tomcat-user@jakarta.apache.org Subject: Re: JSP including servlet output Never mind, got it... changed: ServletOutputStream out = response.getOutputStream(); ..to... PrintWriter out = response.getWriter(); ...and it now works. I wouldn't mind an explanation though :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP pre-compile and Apache
Apache doesn't care about the existence of a jsp. There is one exception - default pages when / (or /stuff/) is requested. In that case - apache will look for index.jsp (Assuming that is a default page to be served) and then on seeing the existence of that file - pass the request onto tomcat. I have had webapps where *.html is served by tomcat, so I had to create dummy index.html files so trcik apache into forwarding the request to tomcat. But there is also a JK option to forward the serving of directory requests to tomcat (but I'm too lazy to look it up at the moment) -Tim Charl Gerber wrote: I used to precompile my JSP's (which worked great and was a big time saver in testing), but since running Tomcat 4.1.31 together with Apache, all sorts of weird errors occurred. I remember reading somewhere that Apache expected the actual jsp file, not the compiled version. So I reverted back to *not* precompiling JSP's and everything worked as expected. Question now, obviously there is a first-time-compile penalty per jsp, but once compiled, should performance be the same? How about the overhead to check if the .jsp file indeed matches the compiled version? Has someone managed to get precompiled JSP's running in combination with Apache? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP pre-compile and Apache
OK, so it migth be well worth my while to look into the issue again and see if I can get the precompiled JSP's running with Apache. (I originally did this a year ago). Charl --- Tim Funk [EMAIL PROTECTED] wrote: Apache doesn't care about the existence of a jsp. There is one exception - default pages when / (or /stuff/) is requested. In that case - apache will look for index.jsp (Assuming that is a default page to be served) and then on seeing the existence of that file - pass the request onto tomcat. I have had webapps where *.html is served by tomcat, so I had to create dummy index.html files so trcik apache into forwarding the request to tomcat. But there is also a JK option to forward the serving of directory requests to tomcat (but I'm too lazy to look it up at the moment) -Tim Charl Gerber wrote: I used to precompile my JSP's (which worked great and was a big time saver in testing), but since running Tomcat 4.1.31 together with Apache, all sorts of weird errors occurred. I remember reading somewhere that Apache expected the actual jsp file, not the compiled version. So I reverted back to *not* precompiling JSP's and everything worked as expected. Question now, obviously there is a first-time-compile penalty per jsp, but once compiled, should performance be the same? How about the overhead to check if the .jsp file indeed matches the compiled version? Has someone managed to get precompiled JSP's running in combination with Apache? - 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: JSP pre-compile and Apache
Have you granted the site accessClassInPackage runtime permission? -Terence M. Bandoian [EMAIL PROTECTED] I used to precompile my JSP's (which worked great and was a big time saver in testing), but since running Tomcat 4.1.31 together with Apache, all sorts of weird errors occurred. I remember reading somewhere that Apache expected the actual jsp file, not the compiled version. So I reverted back to *not* precompiling JSP's and everything worked as expected. Question now, obviously there is a first-time-compile penalty per jsp, but once compiled, should performance be the same? How about the overhead to check if the .jsp file indeed matches the compiled version? Has someone managed to get precompiled JSP's running in combination with Apache? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSP-specific newsgroups/mailing list
Javaranch. http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi -Original Message- From: David Wall [mailto:[EMAIL PROTECTED] Sent: Saturday, June 04, 2005 3:07 PM To: Tomcat Users List Subject: JSP-specific newsgroups/mailing list Can anybody recommend a good JSP/servlet newsgroups or mailing lists for questions. Obviously, this list is directed towards Tomcat in particular, but while I'm using Tomcat, I'm trying to get an answer regarding some a way in JSP to allow a page developer to create his own bean that can be passed between JSP pages (such as by putting the object in the session or request object). Thanks, David - 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: JSP-specific newsgroups/mailing list
Javalobby - Sun Java, JSP and J2EE technology programming forums, software downloads, jobs and tutorials http://www.javalobby.org/ * Barry KimelmanToronto, Ontario, Canada ---Original Message--- From: David Wall Date: 06/04/05 16:08:00 To: Tomcat Users List Subject: JSP-specific newsgroups/mailing list Can anybody recommend a good JSP/servlet newsgroups or mailing lists for questions.Obviously, this list is directed towards Tomcat in particular, but while I'm using Tomcat, I'm trying to get an answer regarding some a way in JSP to allow a page developer to create his own bean that can be passed between JSP pages (such as by putting the object in the session or request object). Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSP too big to compile?
It's a global java limitation.
You'are limited to around 10 000 lines of code in a try catch block.
Try to use dynamic includes instead of static includes.
Pascal Gehl
-Original Message-
From: David Wall [mailto:[EMAIL PROTECTED]
Sent: Friday, June 03, 2005 16:31
To: tomcat-user@jakarta.apache.org
Subject: JSP too big to compile?
We have a web page that contains many business documents laid out one after
the other so a user can just click print and have all of them print together
(with a stylesheet that starts each contract on its own printed page).
But we seem to be having an error that the generated servlet code is too big
because of service method's try block is too long.
Is there anything I can tweak to allow this to be bigger for the java
compiler, or is this just a limit of Java in general?
Thanks,
David
Generated servlet error:
[javac] Compiling 1 source file
[javac]
/home/tomcat/jakarta-tomcat-4.1.30/work/Standalone/localhost/app/application
_jsp.java:8946:
compiler message file broken:
key=compiler.err.compiler.err.limit.code.too.large.for.try.stmt
arguments=null, null, null, null, null, null, null
[javac] } catch (Throwable t) {
[javac] ^
[javac]
/home/tomcat/jakarta-tomcat-4.1.30/work/Standalone/localhost/app/application
_jsp.java:1118:
compiler message file broken:
key=compiler.err.compiler.err.limit.code.too.large.for.try.stmt
arguments=null, null, null, null, null, null, null
[javac] try {
[javac] ^
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP too big to compile?
You are actually limited by Java. I can't recall the actual size off
hand, but a method can only be so big.
From what I remember, it has something to do with server side includes
vs jsp includes. We ended up doing some pretty nasty stuff by
conditionally doing a server side include. I can't really remember much
more than that it was several years ago.
David Wall wrote:
We have a web page that contains many business documents laid out one
after the other so a user can just click print and have all of them
print together (with a stylesheet that starts each contract on its own
printed page).
But we seem to be having an error that the generated servlet code is too
big because of service method's try block is too long.
Is there anything I can tweak to allow this to be bigger for the java
compiler, or is this just a limit of Java in general?
Thanks,
David
Generated servlet error:
[javac] Compiling 1 source file
[javac]
/home/tomcat/jakarta-tomcat-4.1.30/work/Standalone/localhost/app/application_jsp.java:8946:
compiler message file broken:
key=compiler.err.compiler.err.limit.code.too.large.for.try.stmt
arguments=null, null, null, null, null, null, null
[javac] } catch (Throwable t) {
[javac] ^
[javac]
/home/tomcat/jakarta-tomcat-4.1.30/work/Standalone/localhost/app/application_jsp.java:1118:
compiler message file broken:
key=compiler.err.compiler.err.limit.code.too.large.for.try.stmt
arguments=null, null, null, null, null, null, null
[javac] try {
[javac] ^
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP too big to compile?
The jsp:include is coming very close for us, but we're doing some tricks
on these JSP pages that are causing us a problem with this approach.
In the main JSP, we are creating a class inside that has the data
elements for that page as well as a bunch of custom routines that act on
the bean data. In this case, we use a construct like:
%!
public class BeanData
{
public String field1;
public String field2;
public void method1()
{ }
}
void doSomething(BeanData bean)
{}
%
This has worked well. Normally, we'd create a regular bean and use
jsp:useBean to access it, but we did this so we could just upload the
JSP and the bean would go together for ease of update without
restarting, etc. These JSP pages are bit special in that they are
customer-defined pages that need to be changeable without having to
upload a new JAR/WAR/.class file and have the application reload.
Of course, a jsp:include page cannot access the BeanData defined in the
other page because the BeanData class is nested inside the servlet class
created from the JSP (even if we pass it as a parameter, the receiving
end will get a security access exception).
First, is there a better way for a JSP to define a class that could be
accessed outside of it rather than using the %! % mechanism to declare
the code? If not, are there any thoughts on how to pass such a private
bean instance to the jsp:include page so it can also use it?
Thanks,
David
Pascal Gehl wrote:
It's a global java limitation.
You'are limited to around 10 000 lines of code in a try catch block.
Try to use dynamic includes instead of static includes.
Pascal Gehl
-Original Message-
From: David Wall [mailto:[EMAIL PROTECTED]
Sent: Friday, June 03, 2005 16:31
To: tomcat-user@jakarta.apache.org
Subject: JSP too big to compile?
We have a web page that contains many business documents laid out one after
the other so a user can just click print and have all of them print together
(with a stylesheet that starts each contract on its own printed page).
But we seem to be having an error that the generated servlet code is too big
because of service method's try block is too long.
Is there anything I can tweak to allow this to be bigger for the java
compiler, or is this just a limit of Java in general?
Thanks,
David
Generated servlet error:
[javac] Compiling 1 source file
[javac]
/home/tomcat/jakarta-tomcat-4.1.30/work/Standalone/localhost/app/application
_jsp.java:8946:
compiler message file broken:
key=compiler.err.compiler.err.limit.code.too.large.for.try.stmt
arguments=null, null, null, null, null, null, null
[javac] } catch (Throwable t) {
[javac] ^
[javac]
/home/tomcat/jakarta-tomcat-4.1.30/work/Standalone/localhost/app/application
_jsp.java:1118:
compiler message file broken:
key=compiler.err.compiler.err.limit.code.too.large.for.try.stmt
arguments=null, null, null, null, null, null, null
[javac] try {
[javac] ^
-
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: JSP too big to compile?
you can us includes and then delete the compiled file in the work directory.
So split page up by using %@ include file=checklogin.jsp %
for each block of general code coded in a include jsp. After upload delete
the file in the work directory, so compilation is done at runtime of tomcat.
And its working..for me it do.
Maarten
-Oorspronkelijk bericht-
Van: David Wall [mailto:[EMAIL PROTECTED]
Verzonden: zaterdag 4 juni 2005 0:18
Aan: Tomcat Users List
Onderwerp: Re: JSP too big to compile?
The jsp:include is coming very close for us, but we're doing some tricks
on these JSP pages that are causing us a problem with this approach.
In the main JSP, we are creating a class inside that has the data
elements for that page as well as a bunch of custom routines that act on
the bean data. In this case, we use a construct like:
%!
public class BeanData
{
public String field1;
public String field2;
public void method1()
{ }
}
void doSomething(BeanData bean)
{}
%
This has worked well. Normally, we'd create a regular bean and use
jsp:useBean to access it, but we did this so we could just upload the
JSP and the bean would go together for ease of update without
restarting, etc. These JSP pages are bit special in that they are
customer-defined pages that need to be changeable without having to
upload a new JAR/WAR/.class file and have the application reload.
Of course, a jsp:include page cannot access the BeanData defined in the
other page because the BeanData class is nested inside the servlet class
created from the JSP (even if we pass it as a parameter, the receiving
end will get a security access exception).
First, is there a better way for a JSP to define a class that could be
accessed outside of it rather than using the %! % mechanism to declare
the code? If not, are there any thoughts on how to pass such a private
bean instance to the jsp:include page so it can also use it?
Thanks,
David
Pascal Gehl wrote:
It's a global java limitation.
You'are limited to around 10 000 lines of code in a try catch block.
Try to use dynamic includes instead of static includes.
Pascal Gehl
-Original Message-
From: David Wall [mailto:[EMAIL PROTECTED]
Sent: Friday, June 03, 2005 16:31
To: tomcat-user@jakarta.apache.org
Subject: JSP too big to compile?
We have a web page that contains many business documents laid out one after
the other so a user can just click print and have all of them print
together
(with a stylesheet that starts each contract on its own printed page).
But we seem to be having an error that the generated servlet code is too
big
because of service method's try block is too long.
Is there anything I can tweak to allow this to be bigger for the java
compiler, or is this just a limit of Java in general?
Thanks,
David
Generated servlet error:
[javac] Compiling 1 source file
[javac]
/home/tomcat/jakarta-tomcat-4.1.30/work/Standalone/localhost/app/applicatio
n
_jsp.java:8946:
compiler message file broken:
key=compiler.err.compiler.err.limit.code.too.large.for.try.stmt
arguments=null, null, null, null, null, null, null
[javac] } catch (Throwable t) {
[javac] ^
[javac]
/home/tomcat/jakarta-tomcat-4.1.30/work/Standalone/localhost/app/applicatio
n
_jsp.java:1118:
compiler message file broken:
key=compiler.err.compiler.err.limit.code.too.large.for.try.stmt
arguments=null, null, null, null, null, null, null
[javac] try {
[javac] ^
-
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]
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.5.1 - Release Date: 2-6-2005
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.5.1 - Release Date: 2-6-2005
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP compiled files created with different users
tomcat does not switch user, it runs as the user who ran bin/startup.sh So tomcat will indeed attempt to write file as the user who ran it. Don't forget only way for an application to switch user at runtime is to have it setuid root, which is not the case of tomcat. Le Lundi 30 Mai 2005 13:49, Yves-Marie Brault a écrit : Hi, I'm working on a Mandrake 10.1. I launch Tomcat 5.5.9 with an user called gama to which belong all files in the Tomcat home directory and has been granted 777 rights on it. However, when I launch my webapp, Tomcat writes some files in the TOMCAT_HOME/work/ directory with the user root and have only 444 rights on these files, which causes FileNotFound errors. Is there a mean for Tomcat to compile and write all files with the same user that have launched it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Delbecq Royal Meteorological Institute of Belgium - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSP compiled files created with different users
Ok, thank you very much. Actually, I used to launch Tomcat with bin/catalina.sh start, which seemed to cause the problem. -Message d'origine- De : delbd [mailto:[EMAIL PROTECTED] Envoyé : lundi 30 mai 2005 13:56 À : Tomcat Users List Objet : Re: JSP compiled files created with different users tomcat does not switch user, it runs as the user who ran bin/startup.sh So tomcat will indeed attempt to write file as the user who ran it. Don't forget only way for an application to switch user at runtime is to have it setuid root, which is not the case of tomcat. Le Lundi 30 Mai 2005 13:49, Yves-Marie Brault a écrit : Hi, I'm working on a Mandrake 10.1. I launch Tomcat 5.5.9 with an user called gama to which belong all files in the Tomcat home directory and has been granted 777 rights on it. However, when I launch my webapp, Tomcat writes some files in the TOMCAT_HOME/work/ directory with the user root and have only 444 rights on these files, which causes FileNotFound errors. Is there a mean for Tomcat to compile and write all files with the same user that have launched it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Delbecq Royal Meteorological Institute of Belgium - 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: jsp imports
-Original Message- From: Darek Czarkowski I am not sure if this is relevant but, is session data a full name of the package? I would expect to see something like com.packagename.sessionData As I've been told, I need to wrap it in a package... or in my case I'm going to re-write 3 jsp's in Java, its easier. regards DaveP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp imports
On Thu, 24 Mar 2005 08:58:48 -, Pawson, David [EMAIL PROTECTED] wrote: -Original Message- From: Darek Czarkowski I am not sure if this is relevant but, is session data a full name of the package? I would expect to see something like com.packagename.sessionData As I've been told, I need to wrap it in a package... or in my case I'm going to re-write 3 jsp's in Java, its easier. Just out of curiosity why is that easier? Adding a package statement to a Java class, changing your import statements and creating the package directory structure isn't exactly difficult and could probably be quite easily done by a search and replace of the source files, plus it would be more standards compliant and make it easier for someone else to maintain if they need to. -- Jason Bainbridge http://kde.org - [EMAIL PROTECTED] Personal Site - http://jasonbainbridge.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp imports
It must be in a package. -Tim Pawson, David wrote: Tomcat 5.0.28 In my index.jsp file I have %@ page import=sessionData% % sessionData s = new sessionData(); s.clrSession(session, index.jsp); % And I get the error, Cannot resolve symbol 'sessionData'. It is not in a package. What syntax must I use to locate the class please? Or is it required to be packaged? Regards DaveP. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jsp imports
-Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 23 March 2005 11:31 To: Tomcat Users List Subject: Re: jsp imports It must be in a package. thanks Tim. Is there any logic in that? If tomcat searches %servlet%/WEB-INF/classes/package/class why can't it search without the package layer? Ah well. regards DaveP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp imports
On Wed, Mar 23, 2005 at 11:49:38AM -, Pawson, David wrote: : Is there any logic in that? :If tomcat searches %servlet%/WEB-INF/classes/package/class :why can't it search without the package layer? It's got naught to do with a Tomcat failing; packageless classes are considered a poor programming practice. As such, they're not allowed under servlet spec 2.4. Is this question in the wiki/FAQ? (I can't check right now.) It seems to come up often enough. -QM -- software -- http://www.brandxdev.net/ tech news -- http://www.RoarNetworX.com/ code scan -- http://www.JxRef.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp imports
The java file generated by the JSP is in a package. The java lanaguage disallows a packageless class if you are in a package. -Tim Pawson, David wrote: -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 23 March 2005 11:31 To: Tomcat Users List Subject: Re: jsp imports It must be in a package. thanks Tim. Is there any logic in that? If tomcat searches %servlet%/WEB-INF/classes/package/class why can't it search without the package layer? Ah well. regards DaveP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jsp imports
-Original Message- From: QM :If tomcat searches %servlet%/WEB-INF/classes/package/class :why can't it search without the package layer? It's got naught to do with a Tomcat failing; I'm not 'blaming' Tomcat, just saying its a mismatch with standard java. packageless classes are considered a poor programming practice. As such, they're not allowed under servlet spec 2.4. Sounds like a 'sound' committee decision :-) That's a view I don't share. I'd say its a judgement that Sun shouldn't have made IMHO. regards DaveP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jsp imports
-Original Message- From: Tim Funk The java file generated by the JSP is in a package. The java lanaguage disallows a packageless class if you are in a package. Makes more sense Tim. Thanks for that. Boring rewrites ahead, or convert the jsp to java. Probably the latter. regards DaveP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp imports
I am not sure if this is relevant but, is session data a full name of the package? I would expect to see something like com.packagename.sessionData DarekC On Wed, 2005-03-23 at 03:20, Pawson, David wrote: Tomcat 5.0.28 In my index.jsp file I have %@ page import=sessionData% % sessionData s = new sessionData(); s.clrSession(session, index.jsp); % And I get the error, Cannot resolve symbol 'sessionData'. It is not in a package. What syntax must I use to locate the class please? Or is it required to be packaged? Regards DaveP. snip here * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP being interpreted?
Am Samstag, 19. Mrz 2005 12:36 schrieb Robert Mark Bram:
==
%@ taglib uri=/WEB-INF/tld/c.tld prefix=c %
html
body bgcolor=white
c:set var=message value=Hi there!/
c:out value=6. ${message}/br/
c:out value=7. ${'message'}/br/
bParameter values passed to this page for each parameter: /b
c:forEach var=current items=${param}
bc:out value=${current.key} //b
c:forEach var=aVal items=${paramValues[current.key]}
c:out value=${aVal} /
/c:forEach
/c:forEach
/body
/html
==
But the result is this:
==
6. ${message}
7. ${'message'}
Parameter values passed to this page for each parameter:
${current.key}${aVal}
==
Is it possible that my jsp code is not being interpreted?
Does the deployment descriptor of yout web-app declare conformance to the
Servlet-API spec 2.4 - i. e. does it contain something like
web-app xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
version=2.4
?
Regards
mks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP being interpreted?
That was the answer mks! Is it possible that my jsp code is not being interpreted? Does the deployment descriptor of yout web-app declare conformance to the Servlet-API spec 2.4 - i. e. does it contain something like web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 ? Once I put this in my web.xml, undeployed the application and redeployed it through the manager, it worked! Shameful thing is that the basic web.xml file in the developer's guid did not have this - it only had web-app. One question left.. I had to undeploy/redeploy using the WebApp manager because command line install doesn't work for me atm (as per my java.lang.NoClassDefFoundError: org/apache/tools/ant/types/RedirectorElement post). How do you deploy your apps and update them after code changes? Thank you for your response! Rob :) -- Robert Mark Bram http://phd.netcomp.monash.edu.au/RobertMarkBram/default.asp B.Comp.(Systems Development/Business Systems) B.Net.Comp.(Hons) Doctor of Philosophy Student School of Network Computing Faculty of Information Technology Monash University Peninsula Campus McMahons Rd Frankston, VIC 3199 AUSTRALIA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP/Servlet Mailing List?
For JSP authoring questions related to JSTL, custom tag libraries (especially those supported by jakarta taglibs), you can post to [EMAIL PROTECTED] If your questions are Jasper or TC deployment specific, you're better off staying here ;-) -Rahul On Mon, 7 Mar 2005 07:56:23 -0500, Anderson, M. Paul [EMAIL PROTECTED] wrote: Does anyone know of a good JSP/Servlet mailing list/help list that is both active and similar in format to this group? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jsp mapping
This example explains as to make mapping filter on servlet: snip How to make mapping with JSP ? Have you tried url-pattern? (instead of servlet-name in the filter mapping) Since I'm all for precompilation, I don't see JSPs differently ;-) http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP-Servlet tutorial
Hi, TheServerSide.com has a free pdf which should cover the jsp/servlet part. You can download it from here: http://www.theserverside.com/books/addisonwesley/ServletsJSP/index.tss For jdbc I would recommend the jdbc tutorial from Sun. Trond Venkat Radha Venkataramanan wrote: Can somebody direct me to a tutorial on jsp/servlet that pulls data from a database and displays the content via a jsp? 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]
RE: jsp version of session variable access. Pointer to syntax wanted.
-Original Message-
From: Tim Funk
Via EL: (assuming sessionData.FILECOUNT = mySessionVariableName)
${sessionContext.mySessionVariableName}
Via snippet:
%=session.getAttribute(sessionData.FILECOUNT)%
In a jsp - the session variable is given to you as implicit
variable.
Thanks Tim ( and fstmncn ).
Hadn't come across 'EL'.
So the choice is one from 3?
JSP 1.0 rev B.
JSP (is it 1.2 or 2.0?) (XML syntax)
and
Expression Language.
so what's JSTL,
http://jakarta.apache.org/taglibs/doc/standard-doc/standard/GettingStarted.html
?
quoteJSTL encapsulates, as simple tags, core functionality common to many JSP
applications./quote
Is that the full name of the EL?
http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/index.html seems
to be the spec. Is there a reasonable tutorial anywhere please?
Can they be mixed in a page?
I *think* the JSP version is determined by the vsn of Tomcat,
which relates to the servlets version, but can I mix EL and JSP?
Is the relationship documented anywhere please?
regards DaveP
--
DISCLAIMER:
NOTICE: The information contained in this email and any attachments is
confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of the
content of it or of any attachment; you are requested to notify the
sender immediately of your receipt of the email and then to delete it
and any attachments from your system.
RNIB endeavours to ensure that emails and any attachments generated by
its staff are free from viruses or other contaminants. However, it
cannot accept any responsibility for any such which are transmitted.
We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email and
any attachments are those of the author and do not necessarily represent
those of RNIB.
RNIB Registered Charity Number: 226227
Website: http://www.rnib.org.uk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp version of session variable access. Pointer to syntax wanted.
EL first arrives as part of JSTL. Which was available in JSP 1.2. But using
EL required that is was used in a tag.
With JSP 2.0 - EL can be used anywhere one a page. As an added bonus - you
can pass expressions as values to your own custom tags and the container will
translate the EL expression before the set...() of your tag is called.
-Tim
Pawson, David wrote:
-Original Message-
From: Tim Funk
Via EL: (assuming sessionData.FILECOUNT = mySessionVariableName)
${sessionContext.mySessionVariableName}
Via snippet:
%=session.getAttribute(sessionData.FILECOUNT)%
In a jsp - the session variable is given to you as implicit
variable.
Thanks Tim ( and fstmncn ).
Hadn't come across 'EL'.
So the choice is one from 3?
JSP 1.0 rev B.
JSP (is it 1.2 or 2.0?) (XML syntax)
and
Expression Language.
so what's JSTL,
http://jakarta.apache.org/taglibs/doc/standard-doc/standard/GettingStarted.html
?
quoteJSTL encapsulates, as simple tags, core functionality common to many JSP
applications./quote
Is that the full name of the EL?
http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/index.html seems
to be the spec. Is there a reasonable tutorial anywhere please?
Can they be mixed in a page?
I *think* the JSP version is determined by the vsn of Tomcat,
which relates to the servlets version, but can I mix EL and JSP?
Is the relationship documented anywhere please?
regards DaveP
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: jsp version of session variable access. Pointer to syntax wanted.
-Original Message- From: Tim Funk EL first arrives as part of JSTL. Which was available in JSP 1.2. But using EL required that is was used in a tag. With JSP 2.0 - EL can be used anywhere one a page. Worthy of note! Thanks Tim. Do you know of any web pages that put this mix into context please? Sun don't do very well on this one. regards DaveP -- DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp version of session variable access. Pointer to syntax wanted.
The JSP examples from a default tomcat install might have some. -Tim Pawson, David wrote: -Original Message- From: Tim Funk EL first arrives as part of JSTL. Which was available in JSP 1.2. But using EL required that is was used in a tag. With JSP 2.0 - EL can be used anywhere one a page. Worthy of note! Thanks Tim. Do you know of any web pages that put this mix into context please? Sun don't do very well on this one. regards DaveP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp version of session variable access. Pointer to syntax wanted.
you can use expression language:
e.g.:
${sessionData.FILECOUNT}
--- Pawson, David [EMAIL PROTECTED] wrote:
Looking for the syntax to gain access to a session
variable
in a jsp page, rather than converting it to java.
HttpSession session=request.getSession();
String s =
(String)session.getAttribute(sessionData.FILECOUNT);
I'm not using the xml syntax (as yet).
tomcat 5028.
any pointers appreciated please.
Regards DaveP.
snip here *
--
DISCLAIMER:
NOTICE: The information contained in this email and
any attachments is
confidential and may be privileged. If you are not
the intended
recipient you should not use, disclose, distribute
or copy any of the
content of it or of any attachment; you are
requested to notify the
sender immediately of your receipt of the email and
then to delete it
and any attachments from your system.
RNIB endeavours to ensure that emails and any
attachments generated by
its staff are free from viruses or other
contaminants. However, it
cannot accept any responsibility for any such which
are transmitted.
We therefore recommend you scan all attachments.
Please note that the statements and views expressed
in this email and
any attachments are those of the author and do not
necessarily represent
those of RNIB.
RNIB Registered Charity Number: 226227
Website: http://www.rnib.org.uk
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
=
[--°--]
__
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp version of session variable access. Pointer to syntax wanted.
Via EL: (assuming sessionData.FILECOUNT = mySessionVariableName)
${sessionContext.mySessionVariableName}
Via snippet:
%=session.getAttribute(sessionData.FILECOUNT)%
In a jsp - the session variable is given to you as implicit variable.
-Tim
Pawson, David wrote:
Looking for the syntax to gain access to a session variable
in a jsp page, rather than converting it to java.
HttpSession session=request.getSession();
String s = (String)session.getAttribute(sessionData.FILECOUNT);
I'm not using the xml syntax (as yet).
tomcat 5028.
any pointers appreciated please.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Compilation Problem
1) try a newer version 2) you might have older jasper libraries in your path -Tim Rodrigo Avila wrote: Hi! When I create a new JSP file in tomcat 5.0.24 and try to run it, the Tomcat send me this error: org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: -1 in the jsp file: null Generated servlet error: [javac] Compiling 1 source file /usr/local/jakarta-tomcat-5.0.24/work/Catalina/localhost/intranet/org/apache/jsp/web/Test_jsp.java:7: org.apache.jsp.web.Test_jsp is not abstract and does not override abstract method getIncludes() in org.apache.jasper.runtime.HttpJspBase public final class Test_jsp extends org.apache.jasper.runtime.HttpJspBase ^ 1 error org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:83) org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:306) org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:398) [...] The jsp file is Test.jsp. I don try to compile it manually; that error appear when Tomcat try to compile it. I try clean work/ directory; no sucess. I try to change to newest Tomcat binary: no sucess. And, it occur in only one context. If I create another context, create a new .jsp file, all works ok. I make searches in Google, but nothing resolve my problem. Thanks the attention! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Compilation Problem
Oh, my God... Idiot! I have in my classpath the jasper-runtime.jar (I use it in the Eclipse classpath)... duh! Clouse, it works now! Thanks the attention! On Thu, 03 Feb 2005 09:25:29 -0500, Tim Funk [EMAIL PROTECTED] wrote: 1) try a newer version 2) you might have older jasper libraries in your path -Tim Rodrigo Avila wrote: Hi! When I create a new JSP file in tomcat 5.0.24 and try to run it, the Tomcat send me this error: org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: -1 in the jsp file: null Generated servlet error: [javac] Compiling 1 source file /usr/local/jakarta-tomcat-5.0.24/work/Catalina/localhost/intranet/org/apache/jsp/web/Test_jsp.java:7: org.apache.jsp.web.Test_jsp is not abstract and does not override abstract method getIncludes() in org.apache.jasper.runtime.HttpJspBase public final class Test_jsp extends org.apache.jasper.runtime.HttpJspBase ^ 1 error org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:83) org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:306) org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:398) [...] The jsp file is Test.jsp. I don try to compile it manually; that error appear when Tomcat try to compile it. I try clean work/ directory; no sucess. I try to change to newest Tomcat binary: no sucess. And, it occur in only one context. If I create another context, create a new .jsp file, all works ok. I make searches in Google, but nothing resolve my problem. Thanks the attention! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Rodrigo de Avila [EMAIL PROTECTED] http://www.avila.eti.br - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
In regard to our caching discussion, Frank, I think you will like the following article. The prior article about two essential filters is interesting too. http://www.onjava.com/pub/a/onjava/2004/03/03/filters.html?page=1 One thing seems certain: there is complete serverside cache control. -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
snip I suspect that it is relatively small and, when you introduce sophisticated state and caching options, it may be faster. Relative to what? To the web server dealing with it? I would suspect it's actually relatively BIG compared to that. I'm certainly willing to be proved wrong though. /snip As we agree, we just need to get the data. I think there should be a lot of standard testing out there that is more reliable than I am probably going to do off the top. I will look around a bit and maybe someone will chime in with some help here. snip That might be true... one other point to remember though is that the more unusual things you do, the harder it will be to get people able to maintain it. I fight standards at work as much as the next guy just because creative people don't like standards forced on them, but clever solutions usual equal difficult to maintain solutions. I don't think I'm telling you something you don't know :) But, that's not my argument, so don't spend any time on it. Just another side track we could go down :) /snip I am 100% in favor of keeping maintenance low. That was my original primary objective going here. I could not believe how much time was being spent on URLs, base tags, etc., etc., with all the concomittant confusion throughout the development process. snip I think the bigger hit is reading the danged thing. This obviously is especially so when there is an ongoing use of changing the JSP page. This has no penalty with ProtocolPages. /snip I just mean the more complicated parsing rules that go with JSP, as well as everything else. snip That's what I like, woman that are easy to please :) (You were left SO wide open there I just couldn't resist!) /snip Heh, heh! Remind me never to fence with you, Frank. Actually, and this is really off topic, in my milieu I am dearly loved because I have really learned how to be a friend, husband, etc. This has been the largest accomplishment by far in my life and the one I most cherish. snip * (Does the app server pass the response back to the web server to serve, or does it serve it directly to the client at that point? I'm actually not sure, but let's be optimistic and say the web server is out of the equation at this point, although I suspect that's NOT the case) In any case, images are returned to client- /snip I think that the ResourceAction class actually acts as the web server and that is why the return is null. The class writes to the responses output stream and that is all the server does, right? FileInputStream fis = new FileInputStream(fileName); BufferedInputStream bis = new BufferedInputStream(fis); byte[] bytes = new byte[bis.available()]; OutputStreamos= response.getOutputStream(); bis.read(bytes); os.write(bytes); os.flush(); os.close(); snip There is clearly more work done with the second chart because the app server is now involved. How costly is all that work? /snip Again, I am not sure about this, and it is the sort of thing that one typically makes mistakes about if one does not go by the data. So, I am going to hold judgment on it, but my intuitions are not running in the same direction as yours. I keep remembering how the following of good OOP principles can make Java applications faster that C applications doing the exact same thing, although most think that would not be the case. Just the other day I was reading about a guy who tried and failed to do some imaging work in early Java and had to go to C. Now Java is faster in that area. snip You could make the argument that because any servlet-based application is incurring those costs with most requests, what's the big deal about adding a few more? To a degree that would be a reasonable argument, but scalability is most certainly at risk because viewed from the point of view of the app server, a single page really corresponds to 10 app server requests. /snip I think there are trade-offs that will need to be measured. For example, I can envision with some of the stuff I do creating whole pages dynamically with images. The new Java imaging stuff is really, really, cool on this. Flash has its side too. snip Even if it's all done in the most efficient way, those ten requests look, for all intents and purposes, like 10 simultaneous USERS (assuming 1 request per user). So, maybe your app server can handle 100 concurrent requests... If the web server was allowed to serve the images, your app server still has 100 slots available to service requests, which corresponds generally to 100 concurrent users... If it's serving 10 images for each physical user though, now you can only service 10 concurrent users, so you've reduced your overall server capacity (as viewed by outside clients) by 90%. Ouch. /snip Now just one moment, Bub! LOL ;-) You really are not seeing the ways you can save time here. For
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
I think the worst case is 22 versus 32, Frank. with 10 images. See your note and then my reasoning below that. snip Even if it's all done in the most efficient way, those ten requests look, for all intents and purposes, like 10 simultaneous USERS (assuming 1 request per user). So, maybe your app server can handle 100 concurrent requests... If the web server was allowed to serve the images, your app server still has 100 slots available to service requests, which corresponds generally to 100 concurrent users... If it's serving 10 images for each physical user though, now you can only service 10 concurrent users, so you've reduced your overall server capacity (as viewed by outside clients) by 90%. Ouch. I fully acknowledge those are rough, worst-case numbers... I certainly don't mean to imply that your approach is 90% worse. Not at all! Just trying to illustrate the problem, as I see it, in certain environments. /snip app server = (AS) struts server = (SS) req = request -- = pass res = response With ResourceAction ___ First case HTML = req (AS) res (AS) = 2 Second image JPEG (say) = req (AS) -- res (SS) = 3 . Tenth image JPEG (say) = req (AS) -- res (SS) = 3 WIthout ResourceAction ___ First case HTML = req (AS) res (AS) = 2 First image JPEG (say) = req (AS) res (AS) = 2 Second image JPEG (say) = req (AS) res (AS) = 2 . Tenth image JPEG (say) = req (AS) res (AS) = 2 This is 22 versus 32. Apparently you forgot (I think?) that the app server has to handle ten images too. They don't just go out with the page, although we are looking at this in a very oversimplified sense. There is no question that the AS is quicker with HTML than the SS, but I am not so sure about the images. The SS may be faster. There is lots of room here for tuning. -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Dakota Jack wrote: I just mean the more complicated parsing rules that go with JSP, as well as everything else. Ok, gotcha. But, this only applies for the first access to the JSP, right? From then on it's a servlet invocation (which is more expensive than returning just a plain'old HTML document, right? But now I am splitting hairs) Heh, heh! Remind me never to fence with you, Frank. Actually, and this is really off topic, in my milieu I am dearly loved because I have really learned how to be a friend, husband, etc. This has been the largest accomplishment by far in my life and the one I most cherish. That's all that counts in the end. I have a wife of ten years and two great kids (well, most of the time they are great anyway), and although I have to remind myself of it sometimes because I get so wrapped up in other things that aren't as important, they are without a doubt my greatest accomplishment. I think that the ResourceAction class actually acts as the web server and that is why the return is null. The class writes to the responses output stream and that is all the server does, right? I thought so too at first, but upon further reflection I'm not so sure... If a request comes in to the web server and then it forwards it on to the app server, that would mean at some very low level that the web server was passing along the connection to the app server... I'm not so sure it's anything that complex... It may be that the app server renders the response stream, but then passes it back to the web server to return to the client. The bottom line though is that we're talking a level low enough that I don't know the answer for sure. Again, I am not sure about this, and it is the sort of thing that one typically makes mistakes about if one does not go by the data. So, I am going to hold judgment on it, but my intuitions are not running in the same direction as yours. I keep remembering how the following of good OOP principles can make Java applications faster that C applications doing the exact same thing, although most think that would not be the case. Just the other day I was reading about a guy who tried and failed to do some imaging work in early Java and had to go to C. Now Java is faster in that area. snip I too await the data :) But, I think you'd have to agree that for your approach to wind up being faster, much like when Java programs are faster than C programs, it must be due to some hidden optimization going on. I mean, on an operation-per-operation basis, C will ALWAYS beat Java... Simply put, there will always be less machine code ops going on with a C program at the lowest levels (assuming they algorithmically equivalent) than a Java program. But, because a Java program can be optimized at runtime, that's where the speed gains occur that you can't get with C. Something similar must be happening if your approach winds up being faster. All things being equal (ceteris paribus), that's the only logical conclusion to reach. That doesn't make it the right one of course :) The data will be the decider... I think there are trade-offs that will need to be measured. For example, I can envision with some of the stuff I do creating whole pages dynamically with images. The new Java imaging stuff is really, really, cool on this. Flash has its side too. No argument there... it's the same with OOP vs. strictly procedural code... if we assume we're always talking a straight compile to machine code and similar optimizations in both, procedural code should generally be faster for the same reason I talked about above. Clearly though, the benefits of an OOP approach outweigh any difference. Same could be true here. Now just one moment, Bub! LOL ;-) You really are not seeing the ways you can save time here. For example, there is such a thing as caching, pragmas and expiry headers which can be set with a response in a way that the meta tags just cannot handle. But now your pushing those caching decisions back on the browser, right? I thought one of your basic premises was to not trust the browser to construct URLs and such? Wouldn't you have the same distrust for caching? (and probably worse since that is at least at the users' discrection) There will be savings of creating no calls where pure HTML would be lost. There will be other things like this too. Remember too that the ResourceAction class is acting as a multithreaded alternative mini-server. Indeed, the approach allows us to get the images, for example, from some other server that is maximized to do just this. Conceivably that could be quicker for cached images. Remember I said conceivably. The ability to be flexible can make for great rewards in efficiency and fluidity that are not immediately obvious. Granted, some additional flexibility might outweigh any problems. If you rolled my BLOBServerAction into your ResourceAction, then you could transparently serve images from
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Dakota Jack wrote: app server = (AS) struts server = (SS) req = request -- = pass res = response You lost me here already... What's the difference between the app server and the struts server? Isn't Struts running IN your app server? With ResourceAction ___ First case HTML = req (AS) res (AS) = 2 Second image JPEG (say) = req (AS) -- res (SS) = 3 . Tenth image JPEG (say) = req (AS) -- res (SS) = 3 WIthout ResourceAction ___ First case HTML = req (AS) res (AS) = 2 First image JPEG (say) = req (AS) res (AS) = 2 Second image JPEG (say) = req (AS) res (AS) = 2 . Tenth image JPEG (say) = req (AS) res (AS) = 2 This is 22 versus 32. Apparently you forgot (I think?) that the app server has to handle ten images too. They don't just go out with the page, although we are looking at this in a very oversimplified sense. I don't see how you got 22 OR 32! :) The first request from the client is for the HTML document, right? So that's one request. The browser then sees ten img tags, regardless of what they point to. So for each one it makes a request. That's 10 requests, right? So it's 11 in all from the client to the server (ignoring for the moment whether server means app server alone or web server in front of app server, or whatever other configuration you might dream up). The only different between the two approaches we've been discussing is what on the server is going to handle each of those 11 requests... Is it a web server sending back a static HTML page for the first request, and then an image for each of the subsequent 10 image requests, or is it a web server returning the HTML page and then an app server returning the images, or an app server returning the page AND the images? There is no question that the AS is quicker with HTML than the SS, but I am not so sure about the images. The SS may be faster. There is lots of room here for tuning. Let me ask you this question... If you are accessing a web site, and you connect directly to the Internet, is that, ignoring things like caching and such, generally going to be faster than going through a proxy? I'd hope you would say yes. Now, clearly, if the proxy is doing caching and/or other optimizations, it might turn out to be faster, but that further proves my point: the web server is like the proxy in this example. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
snip I think that the ResourceAction class actually acts as the web server and that is why the return is null. The class writes to the responses output stream and that is all the server does, right? I thought so too at first, but upon further reflection I'm not so sure... If a request comes in to the web server and then it forwards it on to the app server, that would mean at some very low level that the web server was passing along the connection to the app server... I'm not so sure it's anything that complex... It may be that the app server renders the response stream, but then passes it back to the web server to return to the client. The bottom line though is that we're talking a level low enough that I don't know the answer for sure. /snip I am certain on this one, because you can do this sort of thing *without* the web or app servers at all. I do this fairly frequently with code not unlike and heavily borrowing in principle from Jason Hunters HttpMessage and HttpsMessage in COS. The ResourceAction sends the response and ends the whole process by returning null. snip I too await the data :) But, I think you'd have to agree that for your approach to wind up being faster, much like when Java programs are faster than C programs, it must be due to some hidden optimization going on. I mean, on an operation-per-operation basis, C will ALWAYS beat Java... /snip Well, maybe on on an operation basis. An operation by any other name is still an operation. However, I don't disagree and would merely quibble about the language and the description. snip Simply put, there will always be less machine code ops going on with a C program at the lowest levels (assuming they algorithmically equivalent) than a Java program. /snip Well put! Yes! snip But, because a Java program can be optimized at runtime, that's where the speed gains occur that you can't get with C. /snip At the very least this is a main place to gain speed: the Tortoise and the Hare come to mind. snip ceteris paribus /snip Heh, I meant to tell you last time, this is Latin, not Greek. LOL ///;-) www.m-w.com Main Entry: ce·te·ris pa·ri·bus Pronunciation: 'kA-tr-s-'par--bs, 'ke-, 'se- Function: adverb Etymology: New Latin, other things being equal : if all other relevant things, factors, or elements remain unaltered snip But now your pushing those caching decisions back on the browser, right? I thought one of your basic premises was to not trust the browser to construct URLs and such? Wouldn't you have the same distrust for caching? (and probably worse since that is at least at the users' discrection) /snip The answers are no, yes, no. Setting caching in the response object is not equivalent to setting caching in the meta tags. This is why the ResourceAction has an edge. Note also that the setting of cache, pragma and expires are runtime alterable, and can override the meta tags, in ResourceAction. I left those decisions out of the code I sent you. Did you notice where I added in it response to someone's query on that? snip Granted, some additional flexibility might outweigh any problems. If you rolled my BLOBServerAction into your ResourceAction, then you could transparently serve images from WEB-INF *or* a database, transparently to the user and front-end. That's a nice bit of flexibility to be sure. /snip And, if you imagined more radical uses of images for whole pages, etc., then you might start thinking about BufferedImages cached in sessions, etc. snip I leave the leg-work to you :) /snip You got it! Jack -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Too late when I sent this. Let me make the necessary alterations to the nomenclature. Sorry! web server = df. (WS) app server = df. (AS) request= df. req response = df. res = df. passing the control With ResourceAction 1.0 WS req WS res HTML [2] 1.1 WS req AS res [3] 1.2 WS req AS res [3] 1.3 WS req AS res [3] 1.4 WS req AS res [3] 1.5 WS req AS res [3] 1.6 WS req AS res [3] 1.7 WS req AS res [3] 1.8 WS req AS res [3] 1.9 WS req AS res [3] 1.10 WS req AS res [3] Total 32 Without ResourceAction 1.0 WS req WS res HTML [2] 1.1 WS req AS res [2] 1.2 WS req AS res [2] 1.3 WS req AS res [2] 1.4 WS req AS res [2] 1.5 WS req AS res [2] 1.6 WS req AS res [2] 1.7 WS req AS res [2] 1.8 WS req AS res [2] 1.9 WS req AS res [2] 1.10 WS req AS res [2] Total 22 However, let me note, once again, that we can make it 22 to 22 by simply sending the attributes that are relevant back to a different server. For example, we could have img src='http://blahblahblah.com/ResourceAction.do?file=whatever.gif' Doing this, if we are talking about serving images to a large-scale site, we could get rid of both the WS and the AS and use a SCS (small custom server) optimized for this situation. I do this sort of thing constantly, *sub rosa*, on my sites. This is probably quicker than using WS to serve the images, and certainly so if the images are in any way dynamic in nature and if we make use of the multithreading opportunities that crop up in this situation. But, this is going afield. And, this is only looking at the upside too. Jack -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Dakota Jack wrote: I am certain on this one, because you can do this sort of thing *without* the web or app servers at all. I do this fairly frequently with code not unlike and heavily borrowing in principle from Jason Hunters HttpMessage and HttpsMessage in COS. The ResourceAction sends the response and ends the whole process by returning null. I agree, obviously you can take Tomcat for instance and use it to serve everything... I have a production app that is a single server running Tomcat and Oracle and that's it, no web server anywhere, everything is served from Tomcat whether it's a JSP, an image, an HTML document or whatever else. The question that's in my mind though is what happens when you have a web server in front of Tomcat? Just rendering to the response in a servlet might not be enough in that case... Think of a proxy analogy... Does the web server almost appear like a proxy? In other words, a request comes in to the web server, does it (a) pass the connection to the app server to fulfill, at which point it's done and can service more requests, or (b) does it ask the app server for the resource, whatever it is, wait for the response from the app server and send it along to the client when the app server is done responding? Same idea as a network proxy. The point being, just because the app server CAN serve everything, doesn't necasserily mean it WILL with a web server in front. But again, I don't know the answer here, it's just a question in my mind. ceteris paribus /snip Heh, I meant to tell you last time, this is Latin, not Greek. LOL ///;-) Really?? Well, I have something to yell at my Macroeconomics professor for then! I know for sure she said it was Greek! :) Funny aside... My Macroeconomics professor... her last name, and I couldn't have made this up, is Economopolous. That just rules! But now your pushing those caching decisions back on the browser, right? I thought one of your basic premises was to not trust the browser to construct URLs and such? Wouldn't you have the same distrust for caching? (and probably worse since that is at least at the users' discrection) /snip The answers are no, yes, no. Setting caching in the response object is not equivalent to setting caching in the meta tags. This is why the ResourceAction has an edge. Note also that the setting of cache, pragma and expires are runtime alterable, and can override the meta tags, in ResourceAction. I left those decisions out of the code I sent you. Did you notice where I added in it response to someone's query on that? I did notice, but my point is that the browser settings would override any tags or headers you set. I might be wrong about that, but that would be my expectation. After all, what good is a setting in my browser that says don't cache anything if a web site designer can come along and overrule that? Surely the FOSS community would be up in arms over their loss of freedom, right?!? ;) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
I still don't understanding the 32 and 22... What do the [2] and [3]'s represent? Dakota Jack wrote: Too late when I sent this. Let me make the necessary alterations to the nomenclature. Sorry! web server = df. (WS) app server = df. (AS) request= df. req response = df. res = df. passing the control With ResourceAction 1.0 WS req WS res HTML [2] 1.1 WS req AS res [3] 1.2 WS req AS res [3] 1.3 WS req AS res [3] 1.4 WS req AS res [3] 1.5 WS req AS res [3] 1.6 WS req AS res [3] 1.7 WS req AS res [3] 1.8 WS req AS res [3] 1.9 WS req AS res [3] 1.10 WS req AS res [3] Total 32 Without ResourceAction 1.0 WS req WS res HTML [2] 1.1 WS req AS res [2] 1.2 WS req AS res [2] 1.3 WS req AS res [2] 1.4 WS req AS res [2] 1.5 WS req AS res [2] 1.6 WS req AS res [2] 1.7 WS req AS res [2] 1.8 WS req AS res [2] 1.9 WS req AS res [2] 1.10 WS req AS res [2] Total 22 However, let me note, once again, that we can make it 22 to 22 by simply sending the attributes that are relevant back to a different server. For example, we could have img src='http://blahblahblah.com/ResourceAction.do?file=whatever.gif' Doing this, if we are talking about serving images to a large-scale site, we could get rid of both the WS and the AS and use a SCS (small custom server) optimized for this situation. I do this sort of thing constantly, *sub rosa*, on my sites. This is probably quicker than using WS to serve the images, and certainly so if the images are in any way dynamic in nature and if we make use of the multithreading opportunities that crop up in this situation. But, this is going afield. And, this is only looking at the upside too. Jack If we are talking about dynamically-created resources, then I would tend to agree with your view. But we have, at least as far as I was concerned, been talking about strictly static resources. In that case, your basic premise boils down to, as I see it: An app server running ResourceAction can serve resources more efficiently than a web server. Again, strictly talking about static resources, I would be absolutely SCHOCKED to learn this is the case under most circumstances. That would be like saying a Cadillac could beat a NASCAR vehicle in 1 ten-lap race... It might be able to under some circumstances, like the NASCAR driver being drunk!, and certainly there are some very nice trade-offs to driving the Caddy like more room and a better stereo, but in general you wouldn't expect the Caddy to lose. A bit of hyperbole there, but the underlying point is what's important. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
snip The question that's in my mind though is what happens when you have a web server in front of Tomcat? Just rendering to the response in a servlet might not be enough in that case... /snip *Before* ResourceAction returns null, the response output stream has been written, flushed, and closed. The only thing that the app server or the web server have left to deal with is that null. There is no wrapper in this case and no proxy in the sense you are talking. The OutputStream from an HttpResponse object writes to the client. snip The point being, just because the app server CAN serve everything, doesn't necasserily mean it WILL with a web server in front. /snip But, in this case, the OutputStream does and there is no pass it on functionality in there that would incorporate any reference or use of the web or app server. The fact that this OutputStream ends the process might be one of the factors favoring ResourceAction. snip ceteris paribus /snip Heh, I meant to tell you last time, this is Latin, not Greek. LOL ///;-) Really?? Well, I have something to yell at my Macroeconomics professor for then! I know for sure she said it was Greek! :) Funny aside... My Macroeconomics professor... her last name, and I couldn't have made this up, is Economopolous. That just rules! /snip LOL Economopolous! Hilarious Remember My Big Fat Greek Wedding where the Greek guy has a way of turning everything to Greek history, etc.? Well, Ms. Economopolous is clearly Greek and her name is Economic-city. (Plato's Republic was really Politia which means The City. Republic comes from Republica which was a Latin translation.) Anyway, this is ALL ceteris paribus. (You can tell Latin from the endings, ibus is the dative plural.) snip I did notice, but my point is that the browser settings would override any tags or headers you set. I might be wrong about that, but that would be my expectation. After all, what good is a setting in my browser that says don't cache anything if a web site designer can come along and overrule that? Surely the FOSS community would be up in arms over their loss of freedom, right?!? ;) /snip The good is that the web site designer knows when a change has been made and the assumption is that you are going to see what the web site designer has to offer. No? Jack -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
snip On Sun, 30 Jan 2005 14:11:24 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: I still don't understanding the 32 and 22... What do the [2] and [3]'s represent? /snip A total of three possible processes (1) getting the request; (2) passing the request to another server; (3) handling the response. If you have them all, you have a three. If only 1 and 3, then you have a two. snip If we are talking about dynamically-created resources, then I would tend to agree with your view. But we have, at least as far as I was concerned, been talking about strictly static resources. /snip If there are static resources, then we can get it down to 22 versus 22 by sending the images to a separate server. Not only can we do this, but we can send the images to a super efficient separate server if we are talking about static images only. snip An app server running ResourceAction can serve resources more efficiently than a web server. /snip Not that an app server is faster under any circumstances tha a web server. That really is not close to true. I've seen the stats on that one and I would doubt that they will ever be the same or close to the same. I would be as SCHOCKED as you (is this an Italian-Jewish SHOCKED? ///;-) ) in that case. What I am talking about is a custom server for images which gets rid of a LOT of baggage, including WEB-INF but having the same protections as being under WEB-INF. snip Again, strictly talking about static resources, I would be absolutely SCHOCKED to learn this is the case under most circumstances. That would be like saying a Cadillac could beat a NASCAR vehicle in 1 ten-lap race... It might be able to under some circumstances, like the NASCAR driver being drunk!, and certainly there are some very nice trade-offs to driving the Caddy like more room and a better stereo, but in general you wouldn't expect the Caddy to lose. /snip In this case the analogy, IF apt, is the reverse. The custom server is the NASCAR. All the doodads needed on an app or a web server can be pealed off and serious savings with multithreading, parsing presumptions, etc. can be realized. snip A bit of hyperbole there, but the underlying point is what's important. /snip I enjoyed the ride in the caddy. Had the stereo on a good jazz station in my mind with Lead Belly growling at me. The metaphor is apt but really, when you are talking a mini-quick-custom server, reversed. I am actually surprised that there are not more of these little speedy and specialized servers around. Jack This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Dakota Jack wrote: The good is that the web site designer knows when a change has been made and the assumption is that you are going to see what the web site designer has to offer. No? Jack I concur with the assumption, but I don't see it making any difference... Remember that what we affectionately refer to as the web these days is really a lot more than what it was originally. One of the things that was originally intended is that the client is in complete control. If the user wants to request a resource from a server, and they tell their browser via a setting that no, I WANT you to go ask that server EVERY SINGLE TIME for the resources, NEVER use what you might have in the local cache, then they should be allowed to do that, and whatever the web site creator wants you to do is irrelevant. Same idea when the user can override fonts and colors and the like with their own local settings. Nowadays though, us web app/site designers think WE know how best a client should view our site, and we actually go out of our way to make it so... how many times have you visited a site where the font is too small and the usual font size adjustments don't make any difference? So you have to go in to setting and uncheck that User Font Sizes Specified By Site option. Annoying, and not what was originally intended. This is of course all only relevant to the extent that it supports my point, that anything you do on the server side to try and control caching is either (a) useless because the end user can override it anyway or (b) not in keeping with the spirit of the web, at least, not as originally intended. Now I'm off on a bit of a tangent though :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP under /WEB-INF folder
Just from a curiosity standpoint Jack... I've already decided it's not an approach I'd advocate, but I am interested to know how you serve things like graphics and stylesheets from under WEB-INF. I assume all your graphics are actually server by an Action (a trick I've pulled when serving images from a database), and I further assume your stylesheets aren't just linked in... -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Dakota Jack wrote: snip On Tue, 28 Dec 2004 13:57:33 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: I think his problem is probably linking to stylesheets and such... Actually, now I have to ask you... if you put *everything* under WEB-INF, I assume you are serving all graphics from a fronting web server then? Otherwise, any document returned to the user that links back to a resource under WEB-INF won't be reachable, which was the crux of his problem as I understood it, that's why he was talking about includes and such all over the place. But, if you really are serving everything from there, how are you doing it? Just curious at this point :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Dakota Jack wrote: I don't know why you are saying that css and/or js must be placed directly under WebRoot. Why do you? I can give you various solutions, once I find out what the problem is supposed to be. There is no issue, by the way, with putting your JSP files under WEB-INF. There are other ways to protect access, but this is, I think, a good one too. Jack /snip Frank, are you still interested in this? I just noticed it. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP under /WEB-INF folder
snip
On Sat, 29 Jan 2005 09:00:39 -0500, Frank W. Zammetti
[EMAIL PROTECTED] wrote:
Just from a curiosity standpoint Jack... I've already decided it's not
an approach I'd advocate, but I am interested to know how you serve
things like graphics and stylesheets from under WEB-INF. I assume all
your graphics are actually server by an Action (a trick I've pulled when
serving images from a database), and I further assume your stylesheets
aren't just linked in...
/snip
img src='resource.do?file=whatever.jpg'
link
href='resource.do?file=whatever.css'
rel='stylesheet'
type='text/css'
You can also put this sort of Struts protocol into Flash ActionScript, etc.
To be complete on this list:
public final class ResourceAction
extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException,
ServletException {
String file = request.getParameter(file);
String ext = file.substring(file.lastIndexOf('.') + 1);
String type = null;
String path = null;
if (gif.equals(ext)) {
type = image/gif;
path = path(gif);
} else if (jpg.equals(ext)) {
type = image/jpeg;
path = path(jpeg);
} else if (css.equals(ext)) {
type = text/css;
path = path(css);
} else if (flash.equals(ext)) {
type = application/x-shockwave-flash;
path = path(flash);
} else if (text.equals(ext)) {
type = text/plain;
path = path(text);
} else if (js.equals(ext)) {
type = text/javascript;
path = path(js);
} else if (png.equals(ext)) {
type = image/png;
path = path(png);
} else if (html.equals(ext)) {
type = text/html;
path = path(html);
} else if (applet.equals(ext)) {
type = application/x-java-applet;
path = classes + File.separator + com + File.separator +
crackwillow + File.separator + applet;
}
String name = Classpath.WEB_INF + path + file;
response.setContentType(type);
response.setHeader(Cache-Control, );
response.setHeader(Pragma, );
response.setHeader(Expires, );
response.addHeader(Content-Disposition,filename= + name);
try {
FileInputStream fis = new FileInputStream(name);
BufferedInputStream bis = new BufferedInputStream(fis);
byte[] bytes = new byte[bis.available()];
OutputStreamos= response.getOutputStream();
bis.read(bytes);
os.write(bytes);
os.flush();
os.close();
} catch (IOException ioe) {
StdOut.log(SiteConstant.ERROR_LOG,ResourceAction: problem file
is: + name + \n + StackTrace.trace(ioe) + \n +
ioe.getMessage());
}
return null;
}
private String path(String fileType) {
return resource + File.separator + content_type +
File.separator + fileType + File.separator;
}
} ///;-)
--
You can lead a horse to water but you cannot make it float on its back.
~Dakota Jack~
You can't wake a person who is pretending to be asleep.
~Native Proverb~
Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free.
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP under /WEB-INF folder
One thing worth pointing out about this is that you'll lose the benefit
of fronting your app server with a web server... You won't be able to
offload the serving of images, stylesheets and such, from the app server
to the web server. That's probably not a big problem in many cases
where a single server with a decent set of specs can handle the load
anyway, but in a more robust enterprise environment, your really kind
of defeating the purpose of a fleet of web servers in front of a number
of app servers.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Dakota Jack wrote:
snip
On Sat, 29 Jan 2005 09:00:39 -0500, Frank W. Zammetti
[EMAIL PROTECTED] wrote:
Just from a curiosity standpoint Jack... I've already decided it's not
an approach I'd advocate, but I am interested to know how you serve
things like graphics and stylesheets from under WEB-INF. I assume all
your graphics are actually server by an Action (a trick I've pulled when
serving images from a database), and I further assume your stylesheets
aren't just linked in...
/snip
img src='resource.do?file=whatever.jpg'
link
href='resource.do?file=whatever.css'
rel='stylesheet'
type='text/css'
You can also put this sort of Struts protocol into Flash ActionScript, etc.
To be complete on this list:
public final class ResourceAction
extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException,
ServletException {
String file = request.getParameter(file);
String ext = file.substring(file.lastIndexOf('.') + 1);
String type = null;
String path = null;
if (gif.equals(ext)) {
type = image/gif;
path = path(gif);
} else if (jpg.equals(ext)) {
type = image/jpeg;
path = path(jpeg);
} else if (css.equals(ext)) {
type = text/css;
path = path(css);
} else if (flash.equals(ext)) {
type = application/x-shockwave-flash;
path = path(flash);
} else if (text.equals(ext)) {
type = text/plain;
path = path(text);
} else if (js.equals(ext)) {
type = text/javascript;
path = path(js);
} else if (png.equals(ext)) {
type = image/png;
path = path(png);
} else if (html.equals(ext)) {
type = text/html;
path = path(html);
} else if (applet.equals(ext)) {
type = application/x-java-applet;
path = classes + File.separator + com + File.separator +
crackwillow + File.separator + applet;
}
String name = Classpath.WEB_INF + path + file;
response.setContentType(type);
response.setHeader(Cache-Control, );
response.setHeader(Pragma, );
response.setHeader(Expires, );
response.addHeader(Content-Disposition,filename= + name);
try {
FileInputStream fis = new FileInputStream(name);
BufferedInputStream bis = new BufferedInputStream(fis);
byte[] bytes = new byte[bis.available()];
OutputStreamos= response.getOutputStream();
bis.read(bytes);
os.write(bytes);
os.flush();
os.close();
} catch (IOException ioe) {
StdOut.log(SiteConstant.ERROR_LOG,ResourceAction: problem file
is: + name + \n + StackTrace.trace(ioe) + \n +
ioe.getMessage());
}
return null;
}
private String path(String fileType) {
return resource + File.separator + content_type +
File.separator + fileType + File.separator;
}
} ///;-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP under /WEB-INF folder
snip On Sat, 29 Jan 2005 17:17:03 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: One thing worth pointing out about this is that you'll lose the benefit of fronting your app server with a web server... You won't be able to offload the serving of images, stylesheets and such, from the app server to the web server. That's probably not a big problem in many cases where a single server with a decent set of specs can handle the load anyway, but in a more robust enterprise environment, your really kind of defeating the purpose of a fleet of web servers in front of a number of app servers. /snip Lo, Frank. You really don't lose anything. You just gain a choice. There is a lot more to be said on this, but you probably would know everything on this anyway, so I will leave it at that. Jack -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP under /WEB-INF folder
Lo, Frank. You really don't lose anything. You just gain a choice. There is a lot more to be said on this, but you probably would know everything on this anyway, so I will leave it at that. That's not strictly true though Jack (neither your premise that you don't lose anything or that I know everything about this, I almost certainly don't!)... In some environments, as I'm sure you know and probably have even dealt with, you have a bunch of web servers in front of a bunch of app servers. The web servers serve static content like images, stylesheets and usually server-side includes, things like that, while the app server handles JSPs and actual server-side (servlet) code. Putting everything under WEB-INF removes this choice because every request has to be routed to your app servers now. In larger scenarios, the whole point of the web servers (well, most of the point anyway) is to offload that work from the app servers and gain efficiency. Division of labor and all that jazz. :) I'd certainly agree that if a particular situation doesn't call for such a distributed environment in the first place, than it's a moot point, and what you suggest certainly has some benefits. But if that's not the case, or if it some day might not be the case (i.e., your app might have to scale into such an environment), then it could become an issue and people should be aware of it before they make their decision. I also don't know what effect this might have in a true distributed environment (i.e., might it be a problem if one request, say for an image, is serviced by one machine, while another services the JSP execuetion itself?). This might never arise, or it might not be a problem at all even if it does, but it could be something for someone to explore is my point. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Dakota Jack wrote: snip On Sat, 29 Jan 2005 17:17:03 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: One thing worth pointing out about this is that you'll lose the benefit of fronting your app server with a web server... You won't be able to offload the serving of images, stylesheets and such, from the app server to the web server. That's probably not a big problem in many cases where a single server with a decent set of specs can handle the load anyway, but in a more robust enterprise environment, your really kind of defeating the purpose of a fleet of web servers in front of a number of app servers. /snip Lo, Frank. You really don't lose anything. You just gain a choice. There is a lot more to be said on this, but you probably would know everything on this anyway, so I will leave it at that. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Hi, Frank, Always good discussing these matters with you. I think you are going to get a kick out of the turn this reply to your response will get. I AM GOING TO REVEAL WHY I THINK THAT THE BASIC STRUTS ARCHITECTURE, AND .do IN PARTICULAR, IS THE WAVE OF THE FUTURE, NOT THE PAST. [Imagine Mission Impossible music in the background.] I have great faith in the Servlet, but not the JSP, idea. I am going to tell you something that you might have missed. There is no need to have a JSP page to do this. This is NOT dynamic content. This is strictly HTML. So, the page that has this is not thereby crippled at all in this sense. There is nothing in using this that changes HTML to JSP or any other dynamic pages. That is the miracle of returns null; This is a different kettle of fish. Please note, also that the HTML for the ResourceAction can access any server it wants. This is highly flexible, not staid and bound. ' The key here is the use of a PROTOCOL instead of a URL. What happens when you do that is not immediately obvious. Personally, I avoid URLs whenever possible as they merely couple your work to options you probably will frequently wish you did not have to take. Read on! snip On Sat, 29 Jan 2005 20:10:08 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: Lo, Frank. You really don't lose anything. You just gain a choice. There is a lot more to be said on this, but you probably would know everything on this anyway, so I will leave it at that. That's not strictly true though Jack (neither your premise that you don't lose anything or that I know everything about this, I almost certainly don't!)... In some environments, as I'm sure you know and probably have even dealt with, you have a bunch of web servers in front of a bunch of app servers. The web servers serve static content like images, stylesheets and usually server-side includes, things like that, while the app server handles JSPs and actual server-side (servlet) code. /snip The ResourceAction requires Struts but does not require JSP. Cool? Remember that Struts has nothing to do with JSP, Velocity, etc. This is pure HTML requiring Struts. snip Putting everything under WEB-INF removes this choice because every request has to be routed to your app servers now. /snip Surprisingly, perhaps, not so! There is nothing in an HTML page that has the Struts protocol for the ResourceAction code which makes that page dynamic, even though the content is. This is pure HTML. That is why it works so great inside Flash ActionScript too. You cannot, after all, put JSP inside Flash ActionScript. Frankly, no pun intended, Frank, I have considered doing all tags via something like this and through Struts Actions. That would mean that your page designers would have freedom you could not believe and that the same pages could work for any backend language. I have done some dabbling with this and have internally called them ProtoCallPages. I suspect the use of JPP (a sort of Action page language which is based on having to have the code off the page) in conjunction with Servlets is much better than in conjunction with JSP or other tag based ideas. We'll see in time. What do you think? I am sure that there are huge issues to consider but my experience with ResoureAction tells me that things might work out fine. I actually sort of compound JPP with some Struts form tags to get dynamic images with language, size, background and foreground colors (or images), fonts, etc. all dynamic but requiring only a protocol for my part. I have considered just droping the Struts part altogether and keeping JPP doing all the form stuff with pure HTML but with all the dynamic results you get from things like JSP, ASP, etc. Anyway, enough of this. Don't you know better than to get me talking? ;-) LOL That's why I love talking to you. You not only have a lot to say, you also listen. Nice combination! snip In larger scenarios, the whole point of the web servers (well, most of the point anyway) is to offload that work from the app servers and gain efficiency. Division of labor and all that jazz. :) /snip Agreed, although I would certainly love to see a huge discussion by the mavens in the area on that one. I think that there is more than meets the eye to that. Still, however, agreed! snip I'd certainly agree that if a particular situation doesn't call for such a distributed environment in the first place, than it's a moot point, and what you suggest certainly has some benefits. But if that's not the case, or if it some day might not be the case (i.e., your app might have to scale into such an environment), then it could become an issue and people should be aware of it before they make their decision. I also don't know what effect this might have in a true distributed environment (i.e., might it be a problem if one request, say for an image, is serviced by one machine, while another services the JSP execuetion
Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Dakota Jack wrote: I am going to tell you something that you might have missed. There is no need to have a JSP page to do this. This is NOT dynamic content. This is strictly HTML. I fully understand that. Keep in mind that a recent project I did required that images be served out of a database. To do this I wrote a BLOBServerAction that results in tags like this: img src=BLOBServer.do?table=logos%field=logoquery=where id='123' (with the query URL encoded of course). This is very much like what you do, except that my BLOBServerAction allows me to serve any BLOB-type from a database. Very similar concept, which is why I know where you are coming from full well. The key here is the use of a PROTOCOL instead of a URL. What happens when you do that is not immediately obvious. Personally, I avoid URLs whenever possible as they merely couple your work to options you probably will frequently wish you did not have to take. Read on! I can't say I understand what your saying here. Can you dumb it down a bit for an old man? :) The ResourceAction requires Struts but does not require JSP. Cool? Remember that Struts has nothing to do with JSP, Velocity, etc. This is pure HTML requiring Struts. Absolutely. snip Putting everything under WEB-INF removes this choice because every request has to be routed to your app servers now. /snip Surprisingly, perhaps, not so! There is nothing in an HTML page that has the Struts protocol for the ResourceAction code which makes that page dynamic, even though the content is. This is pure HTML. That is why it works so great inside Flash ActionScript too. You cannot, after all, put JSP inside Flash ActionScript. What I was getting at is the fact that if I return a page to the browser that have ten images, all referencing ResourceAction, what's happening is that the browser is making ten separate requests TO THE APP SERVER, whereas in a typical setup, these requests would be handled by the fronting web servers. It's clearly more resource-intensive in your approach. As I said before, if your environment is a single server anyway, even if you have a web server in front of an app server, this probably doesn't make much difference, although it will always make some becuase the app server is involved instead of just the web server. That was my original point. Frankly, no pun intended, Frank, I have considered doing all tags via something like this and through Struts Actions. That would mean that your page designers would have freedom you could not believe and that the same pages could work for any backend language. Agreed. I do see the advantage of this approach, but it's the minuses I'm more concerned with. No matter which way you slice it, there's more server resources being utilized. That's a big minus when your talking about scalability. What do you think? I think you point out some valid advantages... if nothing else, just doing away with having to deal with URLs is a very good thing. But I think the performance hit, and certainly the server load, in a typical Enterprise environment, would make this not a great idea. Then again, I say the exact same thing about ASP.Net and JSF because the whole idea of calling a server for relatively simple UI events strikes me as a horrible idea until we have far better networks than we have today, and I seem to be in the minority there, so if I might be wrong there, I might be wrong here too :) Don't you know better than to get me talking? ;-) LOL That's why I love talking to you. You not only have a lot to say, you also listen. Nice combination! My wife wouldn't agree with the listening part :) snip In larger scenarios, the whole point of the web servers (well, most of the point anyway) is to offload that work from the app servers and gain efficiency. Division of labor and all that jazz. :) /snip Agreed, although I would certainly love to see a huge discussion by the mavens in the area on that one. I think that there is more than meets the eye to that. Still, however, agreed! snip I think in enterprise-type environments this is a pretty standard approach with fairly well agreed upon benefits. Anything that breaks it has to exceed those benefits. As my father used to say, that's a tough nut to crack! Nothing wrong with trying to build the hammer though :) Certainly there are things one would have to do in a distributed environment, but the fact that there is a complete decoupling by using a protocol rather than a URL makes all these problems easily solveable. You can do wonders with this sort of thing which you would never consider prior to doing this. You ought to try it on some project and watch where you will be surprised. This is so efficient and flexible. Remember, the code src='resource.do?file='my.css' is stricly HTML. Absolutely it is, but as I pointed out, it's being interpreted on the browser side. That's where the issue comes in to play I think, especially in
Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Well, I sure got excited, though. Back to reality! ;-) snip What I was getting at is the fact that if I return a page to the browser that have ten images, all referencing ResourceAction, what's happening is that the browser is making ten separate requests TO THE APP SERVER, whereas in a typical setup, these requests would be handled by the fronting web servers. It's clearly more resource-intensive in your approach. /snip I am not clear what part of the process you are referring to, Frank. We both agree that the first delivery of the page is via the front server (I tend to only use the back server anyway). If there are ten calls to ten images, as you assume for discussion purposes, then there will be ten calls either way. I think you are saying that in addition there will be a penalty of a pass to a server that can handle Servlets or an equivalent technology that will respond to the ProtocolPage by routing the call to some Action, Command, or whatever in some language, in the way I suggest. Is that right? If so, let me know and we will go from there after you confirm. snip Agreed. I do see the advantage of this approach, but it's the minuses I'm more concerned with. No matter which way you slice it, there's more server resources being utilized. That's a big minus when your talking about scalability. /snip I wouild need, as you would too I assume, more information on the actual penalty. I suspect that it is relatively small and, when you introduce sophisticated state and caching options, it may be faster. I don't dismiss what you are saying. Don't get me wrong. I just have learned to get the data and then to see what the real difference is. When considering costs and so on, I am not sure whether the balance goes to which side. I would suspect, from my experience, that software maintenance and so on would clearly outweigh the hardware and associated requirements. snip I think you point out some valid advantages... if nothing else, just doing away with having to deal with URLs is a very good thing. But I think the performance hit, and certainly the server load, in a typical Enterprise environment, would make this not a great idea. /snip I am surprised at this. You may be right, but my sense is that this difference is not really that important when everything else is taken into account. Even if you had to cluster multiple machines instead of one, say, as a ratio, that would seem to be *probably* cheaper as a GUESS. I don't know. We could look at some data and if you have any handy I would love to see it. snip Then again, I say the exact same thing about ASP.Net and JSF because the whole idea of calling a server for relatively simple UI events strikes me as a horrible idea until we have far better networks than we have today, and I seem to be in the minority there, so if I might be wrong there, I might be wrong here too :) /snip I think the bigger hit is reading the danged thing. This obviously is especially so when there is an ongoing use of changing the JSP page. This has no penalty with ProtocolPages. snip My wife wouldn't agree with the listening part :) /snip Well, I bet you are being too humble. I am happy to say that my wife just thinks I am the most adorable, wonderful, guy. Go figure, eh? snip I think in enterprise-type environments this is a pretty standard approach with fairly well agreed upon benefits. Anything that breaks it has to exceed those benefits. As my father used to say, that's a tough nut to crack! Nothing wrong with trying to build the hammer though :) /snip Technology seems to get ahead of rumor in our little world of web work. So, I definitely would like to revisit this. I am going to squeeze getting the *facts* in here soon. snip Absolutely it is, but as I pointed out, it's being interpreted on the browser side. That's where the issue comes in to play I think, especially in a distributed environment. I'd be interested to hear your thoughts on this point... /snip This seems to be false to me. Maybe I misunderstand you. I don't think the browser has a clue whether we are looking at src='myCss.css' or src='resource.do?file=myCss.css'. Right? Jack -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
[OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
I marked my response as OT, I think we're going down that road (not exactly unusual for us)... Dakota Jack wrote: What I was getting at is the fact that if I return a page to the browser that have ten images, all referencing ResourceAction, what's happening is that the browser is making ten separate requests TO THE APP SERVER, whereas in a typical setup, these requests would be handled by the fronting web servers. It's clearly more resource-intensive in your approach. /snip I am not clear what part of the process you are referring to, Frank. We both agree that the first delivery of the page is via the front server (I tend to only use the back server anyway). I wasn't clear on that part I guess, but it doesn't change my argument. I guess your saying the pages aren't even JSPs, which is fine. Doesn't really change anything though except that there's no servlet involvement to serve the initial page, which is slightly better. That's cool... If there are ten calls to ten images, as you assume for discussion purposes, then there will be ten calls either way. That's correct. Just basic HTTP here :) I think you are saying that in addition there will be a penalty of a pass to a server that can handle Servlets or an equivalent technology that will respond to the ProtocolPage by routing the call to some Action, Command, or whatever in some language, in the way I suggest. Is that right? If so, let me know and we will go from there after you confirm. That's it exactly. The web server has to forward the .do request to the app server, which then serves the images, 10 total servlet invocations in all. Yes, there would be ten requests either way, but one assumes that the web server can serve static content more efficiently than any Action you can devise. Perfectly logical argument, ceteris paribus (I love using Greek in real conversations!), because that's exactly what web servers are optimized to do. I wouild need, as you would too I assume, more information on the actual penalty. Absolutely. The only assumption I'm making is that there IS a penalty. There are any number of factors that would go into how big or small it is, whether it's enough to outweigh the benefits of the approach. I make no attempt here to reach any conclusion on the magnitude of the problem, if it is a problem at all. I suspect that it is relatively small and, when you introduce sophisticated state and caching options, it may be faster. Relative to what? To the web server dealing with it? I would suspect it's actually relatively BIG compared to that. I'm certainly willing to be proved wrong though. I don't dismiss what you are saying. Don't get me wrong. I just have learned to get the data and then to see what the real difference is. And I would agree that's the right frame of mind in all things :) It may in fact be such a small penalty that it's worth ignoring. I have a suspicion it's not, but without empirical data, it's just a hypothesis. When considering costs and so on, I am not sure whether the balance goes to which side. I would suspect, from my experience, that software maintenance and so on would clearly outweigh the hardware and associated requirements. That might be true... one other point to remember though is that the more unusual things you do, the harder it will be to get people able to maintain it. I fight standards at work as much as the next guy just because creative people don't like standards forced on them, but clever solutions usual equal difficult to maintain solutions. I don't think I'm telling you something you don't know :) But, that's not my argument, so don't spend any time on it. Just another side track we could go down :) I am surprised at this. You may be right, but my sense is that this difference is not really that important when everything else is taken into account. Even if you had to cluster multiple machines instead of one, say, as a ratio, that would seem to be *probably* cheaper as a GUESS. I don't know. We could look at some data and if you have any handy I would love to see it. I don't have any handy, but I agree, some real data here would be better than us bantering back and forth for the next week :) I suppose the simplest thing to do is set up a test where you serve 10 static images from a web server vs. 10 images from your ResourceAction with a web server in front of the app server and see what the overall response time is. It would be a little rough, but at least we could tell if there is a perceivable difference or not. Then we get into whether thousands of imperceivable hits accumulate enough over time to hurt us. That's obviously far trickier to guage, but that's the kind of things us enterprise architects have to bother about. :) I think the bigger hit is reading the danged thing. This obviously is especially so when there is an ongoing use of changing the JSP page. This has no penalty with ProtocolPages. Not
Re: JSP under /WEB-INF folder
snip On Tue, 28 Dec 2004 13:57:33 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: I think his problem is probably linking to stylesheets and such... Actually, now I have to ask you... if you put *everything* under WEB-INF, I assume you are serving all graphics from a fronting web server then? Otherwise, any document returned to the user that links back to a resource under WEB-INF won't be reachable, which was the crux of his problem as I understood it, that's why he was talking about includes and such all over the place. But, if you really are serving everything from there, how are you doing it? Just curious at this point :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Dakota Jack wrote: I don't know why you are saying that css and/or js must be placed directly under WebRoot. Why do you? I can give you various solutions, once I find out what the problem is supposed to be. There is no issue, by the way, with putting your JSP files under WEB-INF. There are other ways to protect access, but this is, I think, a good one too. Jack /snip Frank, are you still interested in this? I just noticed it. Jack -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Compile size error.
Its a limit of the java compiler. This was once an issue with an older version of jasper then some refactorings made that problem less apparent. Odds are your jsp is *huge* so it will probbaly be painful to debug. Split the jsp into seperate pieces and use jsp:include. If you are using @includes to include source - that could be another reason for such a large file. [Personally .. @includes are evil] -Tim Kelly, Steve wrote: When trying to run my web app (Tomcat 5.5.6 on RedHat Linux 9) I get the following error:- org.apache.jasper.JasperException: Unable to compile class for JSP Generated servlet error: The code of method _jspService(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) is exceeding the 65535 bytes limit Is this a JSP, tomcat or Linux limit ? Where can I change it ? Thanks in advance, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSP Compile size error.
Thanks Tim. You're right the jsp is pretty huge. Is this limit configurable anywhere? Steve. -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 21 January 2005 11:48 To: Tomcat Users List Subject: Re: JSP Compile size error. Its a limit of the java compiler. This was once an issue with an older version of jasper then some refactorings made that problem less apparent. Odds are your jsp is *huge* so it will probbaly be painful to debug. Split the jsp into seperate pieces and use jsp:include. If you are using @includes to include source - that could be another reason for such a large file. [Personally .. @includes are evil] -Tim Kelly, Steve wrote: When trying to run my web app (Tomcat 5.5.6 on RedHat Linux 9) I get the following error:- org.apache.jasper.JasperException: Unable to compile class for JSP Generated servlet error: The code of method _jspService(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) is exceeding the 65535 bytes limit Is this a JSP, tomcat or Linux limit ? Where can I change it ? Thanks in advance, Steve. - 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: JSP Compile size error.
From: Tim Funk [mailto:[EMAIL PROTECTED] Subject: Re: JSP Compile size error. Its a limit of the java compiler. Actually it's a limitation of the Virtual Machine Specification. The method size in a class file is a 16-bit field. (I thought it was supposed to get bigger in 5.0 - I'm still looking for an updated VM Spec). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP/JDBC question
Looks like you put a statement intended for preparation into a regular statement. [EMAIL PROTECTED] 01-19-2005 18:23 I'm getting the following error when my JSP form POSTs: 17:15:23,500 INFO [STDOUT] -SQLException- 17:15:23,500 INFO [STDOUT] SQLState: 42000 17:15:23,500 INFO [STDOUT] Message: Syntax error or access violation message from server: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '?, Subscriber = ?, RenewalDate = ?, SubscriptionExpired = ?, Cuisine = ?, ChefsN' at line 1 17:15:23,500 INFO [STDOUT] Vendor: 1064 17:15:23,500 INFO [STDOUT] access: on I'm running eclipse 3.0.1 and MySQL on the same machine. Is there a way to display the exact contents of the POST that the form submits? I've tried using TcpMon from the Axis project but can't get anything to show up. Thanks, Jack - 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: Re: JSP compilation problem
As QM mentioned, Tomcat 5.0 doesn't support Java 5.0 out of the box, so to speak. I believe there's a patch you need to make them play nicely. Tomcat 5.5, as he pointed out, is very tight with Java 5.0. -Original Message- From: Frank W. Zammetti[EMAIL PROTECTED] To: Tomcat Users Listtomcat-user@jakarta.apache.org Date: Sun Jan 02 11:46:49 PST 2005 Subject: Re: JSP compilation problem Very interesting... Switching to JDK 1.4.2 solved the problem. I didn't even do an uninstall/reinstall... I always install my SDK to c:\java, so all I did was rename it and copy the directory over from another PC, so any paths and registry settings should still be valid, there's just an older version in it's place. I made sure to delete the Tomcat work folder for the app, started up Tomcat and tried it, everything worked fine... JSP class was generared, servlet compiled, and page came up, no problem. So... Is there actually a problem using JDK 5.0 with Tomcat 5.0.29? If so, what version of Tomcat is OK with 5.0? (assuming any are, which I DO assume). Or is this just some sort of fluke situation? In any case, my problem is solved, and that was the resolution. ___ Check-out GO.com GO get your free GO E-Mail account with expanded storage of 6 MB! http://mail.go.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP compilation problem
Very interesting... Switching to JDK 1.4.2 solved the problem. I didn't even do an uninstall/reinstall... I always install my SDK to c:\java, so all I did was rename it and copy the directory over from another PC, so any paths and registry settings should still be valid, there's just an older version in it's place. I made sure to delete the Tomcat work folder for the app, started up Tomcat and tried it, everything worked fine... JSP class was generared, servlet compiled, and page came up, no problem. So... Is there actually a problem using JDK 5.0 with Tomcat 5.0.29? If so, what version of Tomcat is OK with 5.0? (assuming any are, which I DO assume). Or is this just some sort of fluke situation? In any case, my problem is solved, and that was the resolution. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Ryan Stewart wrote: First, I apologize if I came of sounding rude before. As an infrequent visitor to this list, I wasn't aware that you are a frequent contributor. I also don't seem to have received the other reply you mention. My next thought is that you might have two versions of Java installed. If so, which version is Tomcat using? Are you sure you compiled the servlet with the same one? -Original Message- From: Frank W. Zammetti[EMAIL PROTECTED] To: Tomcat Users Listtomcat-user@jakarta.apache.org Date: Sat Jan 01 07:22:09 PST 2005 Subject: Re: JSP compilation problem I did not post twice Ryan. If two posts appeared, it is the same problem with the list processor that we've been seeing for weeks now. I did post a reply however... I tried your suggestion and manually compiled. I have NO classpath variable in the environment (I thought this might have been a classpath issue, and I guess it could still be, but I don't see how at this point). I manually put servlet-api.jar, jsp-api.jar and jasper-runtime.jar in /tomcat/common/lib on the classpath and compiled, and it compiles cleanly. So the problem would not appear to be a problem with the generated servlet. Any other ideas? Thank you! ___ Check-out GO.com GO get your free GO E-Mail account with expanded storage of 6 MB! http://mail.go.com - 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: JSP compilation problem
On Sun, Jan 02, 2005 at 02:46:49PM -0500, Frank W. Zammetti wrote: : So... Is there actually a problem using JDK 5.0 with Tomcat 5.0.29? Perhaps... I have a vague recollection of seeing such posts a long time ago. : so, what version of Tomcat is OK with 5.0? (assuming any are, which I DO : assume). The 5.5 series is not only OK with JDK 1.5, it requires it. =) (OK, there's the JDK 1.4 compat package, but that didn't sound as cool) -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP compilation problem
I answered you yesterday on this. There's generally no reason to post the same question two days in a row. Just wait and see if an answer shows up. Your problem is (still) that you have one or more errors in your JSP. If you can't figure out where the compiler output is, then go and compile the translated servlet manually. -Original Message- From: Frank W. Zammetti[EMAIL PROTECTED] To: Tomcat Usertomcat-user@jakarta.apache.org Date: Thu Dec 30 06:53:31 PST 2004 Subject: JSP compilation problem Hello. I'm using Tomcat 5.0.29. Working from home today and trying to run a working application on my laptop, and I'm seeing an exception when trying to access the first JSP of the app. Here's the on-screen display: [...] exception org.apache.jasper.JasperException: Unable to compile class for JSP [...] ___ Check-out GO.com GO get your free GO E-Mail account with expanded storage of 6 MB! http://mail.go.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP compilation problem
I did not post twice Ryan. If two posts appeared, it is the same problem with the list processor that we've been seeing for weeks now. I did post a reply however... I tried your suggestion and manually compiled. I have NO classpath variable in the environment (I thought this might have been a classpath issue, and I guess it could still be, but I don't see how at this point). I manually put servlet-api.jar, jsp-api.jar and jasper-runtime.jar in /tomcat/common/lib on the classpath and compiled, and it compiles cleanly. So the problem would not appear to be a problem with the generated servlet. Any other ideas? Thank you! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Ryan Stewart wrote: I answered you yesterday on this. There's generally no reason to post the same question two days in a row. Just wait and see if an answer shows up. Your problem is (still) that you have one or more errors in your JSP. If you can't figure out where the compiler output is, then go and compile the translated servlet manually. -Original Message- From: Frank W. Zammetti[EMAIL PROTECTED] To: Tomcat Usertomcat-user@jakarta.apache.org Date: Thu Dec 30 06:53:31 PST 2004 Subject: JSP compilation problem Hello. I'm using Tomcat 5.0.29. Working from home today and trying to run a working application on my laptop, and I'm seeing an exception when trying to access the first JSP of the app. Here's the on-screen display: [...] exception org.apache.jasper.JasperException: Unable to compile class for JSP [...] ___ Check-out GO.com GO get your free GO E-Mail account with expanded storage of 6 MB! http://mail.go.com - 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]
