Re: Catalina + Apache
James Duncan Davidson wrote: On 1/19/01 2:03 PM, "Jon Stevens" [EMAIL PROTECTED] wrote: on 1/19/01 12:21 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I know Pier has a bunch of bugfixes currently in his local CVS tree, so hopefully we will be much closer to the "reality" end of the scale soon. Why isn't development happening in public? Having local CVS tree does not encourage community development. Before anybody gets freaked out :) there's not an "internal to Sun" CVS tree. Thanks James .. I did make a *very* poor choice of words :-( I'm sure that Craig meant that they were in Pier's checked out sandbox. As to why Pier hasn't been checking in code more often, that's a different story. Pier will need to answer that question himself. -- James Duncan Davidson[EMAIL PROTECTED] !try; do() Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Catalina + Apache
Can you recommend any documents for trying to understand the architecture of mod_webapp and catalina connectors, or is the source the best place. I am fairly keen in getting involved in this area, so any indication of where to get started would be gratefully received. I am a fairly good 'C' and Java programmer. Regards, Arshad - Original Message - From: "Craig R. McClanahan" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 19, 2001 8:21 PM Subject: Re: Catalina + Apache Nick Bauman wrote: Craig, These design goals are AWESOME. It makes much more sense to do this way. However, I _did_ do this as you mentioned: I have *.jsp and *.j mapped to specific servlets in my ROOT/WEB-INF/web.xml and all I got was the output of index.jsp as something Netscape had to download. telnetting to the webserver port revealed that the index.jsp was being served by Apache, not Catalina. I'll mess around with it this weekend and see if I can get it to work "as advertised" and report back my results, but I have a couple of guys waiting on a servlet container that works with our *.j framework to test today, so I'm temporarily falling back to 3.2. I'm really happy that this approach is being followed as it's much more (ultimately) intuitive than the way it's done in 3.2 because it's simpler. I'm glad you like it, although you should really thank Pier Fumagalli -- it's his vision (which I agree with) and effort that has really been working towards this. As I mentioned several times, what I was describing is the *theory* of what mod_webapp is supposed to accomplish. To ensure that it becomes *reality*, please feel free to volunteer your time (as you did above) in testing the current connector, identifying places where there are bugs, posting patches, etc. I know Pier has a bunch of bugfixes currently in his local CVS tree, so hopefully we will be much closer to the "reality" end of the scale soon. Thanks again, -Nick Craig On Fri, 19 Jan 2001, Craig R. McClanahan wrote: Nick Bauman wrote: On Fri, 19 Jan 2001, Craig R. McClanahan wrote: Nick Bauman wrote: Uhhh, I just realized something With TC 3x, you could map an extension from Apache to the servlet engine with an AddHandler directive. I see nothing like this for TC4. Can someone enlighten me? The design goals for mod_webapp say that it should respect web.xml mappings -- in other words, if you added a servlet-mapping entry for "*.foo" to a particular servlet, then that is what would happen at runtime. I totally do not understand this! I'm dense or something: How does Apache / DSO* know about something in the web.xml? This is the key architectural difference between mod_webapp and the current generation of connectors. When mod_webapp establishes its initial connection from Apache to Tomcat, the configuration information (extracted from the property getters of the internal Context object) is sent back to the connector in order to configure everything about this particular webapp. From the sysadmin perspective, this means we can forget all about having to configure things twice (once in httpd.conf and once in web.xml). It's also a requirement of the 2.3 spec -- if we create a "servlet container" using Apache+Tomcat together, it (the combination) must still obey all the servlet spec requirements, including respecting things in web.xml. If I grok you, this still relies on having /foo mapped to the servlet container in Apache. I'm in a situation where Apache's DocumentRoot _is the same as_ the top level of the WAR, but I want Apache to serve the *.html and *.gif and *.jpg and *.png and I want Tomcat to only do the *jsp and a special mapping (in this case *.j). Then what you'd want is to configure the ROOT webapp to have a context base equal to your Apache document root. If you want things mapped to servlets, just do them with servlet-mapping entries *exactly* like you would for Tomcat stand-alone. As I mentioned earlier, the connector takes over the "default servlet" mapping, so it will handle everything that is *not* explicitly mapped to a servlet (i.e. all the static files). Again, this is all the design goals -- I have not tested the current implementation to see if it achieves these goals yet. In particular, I recall seeing bug reports about mapping the ROOT context. The primary difference between Tomcat 4.0 stand alone and Tomcat 4.0 behind Apache is the mapping for the "default" servlet. In the stand-alone case, this is mapped to the Tomcat servlet that serves static resources. In the connected case, they would be served by Apache. I don't see how this works in my case. I'm being dense
Re: Catalina + Apache
On 1/19/01 2:03 PM, "Jon Stevens" [EMAIL PROTECTED] wrote: on 1/19/01 12:21 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I know Pier has a bunch of bugfixes currently in his local CVS tree, so hopefully we will be much closer to the "reality" end of the scale soon. Why isn't development happening in public? Having local CVS tree does not encourage community development. Before anybody gets freaked out :) there's not an "internal to Sun" CVS tree. I'm sure that Craig meant that they were in Pier's checked out sandbox. As to why Pier hasn't been checking in code more often, that's a different story. -- James Duncan Davidson[EMAIL PROTECTED] !try; do() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Catalina + Apache
Craig, These design goals are AWESOME. It makes much more sense to do this way. However, I _did_ do this as you mentioned: I have *.jsp and *.j mapped to specific servlets in my ROOT/WEB-INF/web.xml and all I got was the output of index.jsp as something Netscape had to download. telnetting to the webserver port revealed that the index.jsp was being served by Apache, not Catalina. I'll mess around with it this weekend and see if I can get it to work "as advertised" and report back my results, but I have a couple of guys waiting on a servlet container that works with our *.j framework to test today, so I'm temporarily falling back to 3.2. I'm really happy that this approach is being followed as it's much more (ultimately) intuitive than the way it's done in 3.2 because it's simpler. Thanks again, -Nick On Fri, 19 Jan 2001, Craig R. McClanahan wrote: Nick Bauman wrote: On Fri, 19 Jan 2001, Craig R. McClanahan wrote: Nick Bauman wrote: Uhhh, I just realized something With TC 3x, you could map an extension from Apache to the servlet engine with an AddHandler directive. I see nothing like this for TC4. Can someone enlighten me? The design goals for mod_webapp say that it should respect web.xml mappings -- in other words, if you added a servlet-mapping entry for "*.foo" to a particular servlet, then that is what would happen at runtime. I totally do not understand this! I'm dense or something: How does Apache / DSO* know about something in the web.xml? This is the key architectural difference between mod_webapp and the current generation of connectors. When mod_webapp establishes its initial connection from Apache to Tomcat, the configuration information (extracted from the property getters of the internal Context object) is sent back to the connector in order to configure everything about this particular webapp. From the sysadmin perspective, this means we can forget all about having to configure things twice (once in httpd.conf and once in web.xml). It's also a requirement of the 2.3 spec -- if we create a "servlet container" using Apache+Tomcat together, it (the combination) must still obey all the servlet spec requirements, including respecting things in web.xml. If I grok you, this still relies on having /foo mapped to the servlet container in Apache. I'm in a situation where Apache's DocumentRoot _is the same as_ the top level of the WAR, but I want Apache to serve the *.html and *.gif and *.jpg and *.png and I want Tomcat to only do the *jsp and a special mapping (in this case *.j). Then what you'd want is to configure the ROOT webapp to have a context base equal to your Apache document root. If you want things mapped to servlets, just do them with servlet-mapping entries *exactly* like you would for Tomcat stand-alone. As I mentioned earlier, the connector takes over the "default servlet" mapping, so it will handle everything that is *not* explicitly mapped to a servlet (i.e. all the static files). Again, this is all the design goals -- I have not tested the current implementation to see if it achieves these goals yet. In particular, I recall seeing bug reports about mapping the ROOT context. The primary difference between Tomcat 4.0 stand alone and Tomcat 4.0 behind Apache is the mapping for the "default" servlet. In the stand-alone case, this is mapped to the Tomcat servlet that serves static resources. In the connected case, they would be served by Apache. I don't see how this works in my case. I'm being dense, I think. If you were running Tomcat stand-alone, you would accomplish the goal of mapping *.j files to a particular servlet like this (in your webapp's web.xml file): servlet servlet-nameMyServlet/servlet-name servlet-classcom.mycompany.mypackage.MyServlet/servlet-class /servlet servlet-mapping servlet-nameMyServlet/servlet-mapping url-pattern*.j/url-pattern /servlet-mapping and this rule would get applied to all incoming requests -- a request for "foo.j" would be sent to your servlet, while a request for "foo.html" would be handled by the default file-serving servlet. In Tomcat4+Apache, you do *exactly* the same thing. The only difference at runtime is that Apache becomes the "default file-serving servlet" instead of the servlet inside Tomcat. Does that help? At any rate, this is the theory -- Pier can comment on current practice. I know he's working on a bunch of bug fixes for the originally reported problems. Craig I would like to have it work in my case, but in order for me to help make it happen, I need to understand the goal, which I don't understand. If you or Pier can nurse me along a bit, I will work on making it happen in my case (I do know C) and give it back to the community. Thanks a ton anyway, Craig. -- Nicolaus Bauman
Re: Catalina + Apache
Nick Bauman wrote: Craig, These design goals are AWESOME. It makes much more sense to do this way. However, I _did_ do this as you mentioned: I have *.jsp and *.j mapped to specific servlets in my ROOT/WEB-INF/web.xml and all I got was the output of index.jsp as something Netscape had to download. telnetting to the webserver port revealed that the index.jsp was being served by Apache, not Catalina. I'll mess around with it this weekend and see if I can get it to work "as advertised" and report back my results, but I have a couple of guys waiting on a servlet container that works with our *.j framework to test today, so I'm temporarily falling back to 3.2. I'm really happy that this approach is being followed as it's much more (ultimately) intuitive than the way it's done in 3.2 because it's simpler. I'm glad you like it, although you should really thank Pier Fumagalli -- it's his vision (which I agree with) and effort that has really been working towards this. As I mentioned several times, what I was describing is the *theory* of what mod_webapp is supposed to accomplish. To ensure that it becomes *reality*, please feel free to volunteer your time (as you did above) in testing the current connector, identifying places where there are bugs, posting patches, etc. I know Pier has a bunch of bugfixes currently in his local CVS tree, so hopefully we will be much closer to the "reality" end of the scale soon. Thanks again, -Nick Craig On Fri, 19 Jan 2001, Craig R. McClanahan wrote: Nick Bauman wrote: On Fri, 19 Jan 2001, Craig R. McClanahan wrote: Nick Bauman wrote: Uhhh, I just realized something With TC 3x, you could map an extension from Apache to the servlet engine with an AddHandler directive. I see nothing like this for TC4. Can someone enlighten me? The design goals for mod_webapp say that it should respect web.xml mappings -- in other words, if you added a servlet-mapping entry for "*.foo" to a particular servlet, then that is what would happen at runtime. I totally do not understand this! I'm dense or something: How does Apache / DSO* know about something in the web.xml? This is the key architectural difference between mod_webapp and the current generation of connectors. When mod_webapp establishes its initial connection from Apache to Tomcat, the configuration information (extracted from the property getters of the internal Context object) is sent back to the connector in order to configure everything about this particular webapp. From the sysadmin perspective, this means we can forget all about having to configure things twice (once in httpd.conf and once in web.xml). It's also a requirement of the 2.3 spec -- if we create a "servlet container" using Apache+Tomcat together, it (the combination) must still obey all the servlet spec requirements, including respecting things in web.xml. If I grok you, this still relies on having /foo mapped to the servlet container in Apache. I'm in a situation where Apache's DocumentRoot _is the same as_ the top level of the WAR, but I want Apache to serve the *.html and *.gif and *.jpg and *.png and I want Tomcat to only do the *jsp and a special mapping (in this case *.j). Then what you'd want is to configure the ROOT webapp to have a context base equal to your Apache document root. If you want things mapped to servlets, just do them with servlet-mapping entries *exactly* like you would for Tomcat stand-alone. As I mentioned earlier, the connector takes over the "default servlet" mapping, so it will handle everything that is *not* explicitly mapped to a servlet (i.e. all the static files). Again, this is all the design goals -- I have not tested the current implementation to see if it achieves these goals yet. In particular, I recall seeing bug reports about mapping the ROOT context. The primary difference between Tomcat 4.0 stand alone and Tomcat 4.0 behind Apache is the mapping for the "default" servlet. In the stand-alone case, this is mapped to the Tomcat servlet that serves static resources. In the connected case, they would be served by Apache. I don't see how this works in my case. I'm being dense, I think. If you were running Tomcat stand-alone, you would accomplish the goal of mapping *.j files to a particular servlet like this (in your webapp's web.xml file): servlet servlet-nameMyServlet/servlet-name servlet-classcom.mycompany.mypackage.MyServlet/servlet-class /servlet servlet-mapping servlet-nameMyServlet/servlet-mapping url-pattern*.j/url-pattern /servlet-mapping and this rule would get applied to all incoming requests -- a request for "foo.j" would be sent to your servlet, while a request for "foo.html" would be handled by the default
RE: Catalina + Apache
I'd like to see the fixes for mod_webapp about cookies. I've asked many time on the list about the problem but never got any answers -( "...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 11:03 PM To: [EMAIL PROTECTED] Subject: Re: Catalina + Apache on 1/19/01 12:21 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I know Pier has a bunch of bugfixes currently in his local CVS tree, so hopefully we will be much closer to the "reality" end of the scale soon. Why isn't development happening in public? Having local CVS tree does not encourage community development. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Catalina + Apache
Uhhh, I just realized something With TC 3x, you could map an extension from Apache to the servlet engine with an AddHandler directive. I see nothing like this for TC4. Can someone enlighten me? On Thu, 18 Jan 2001, Nick Bauman wrote: Hello Jakarta Tribe, We are targeting Tomcat 4.0 for a project to be released within 30 days. We currently have an app in production at Exodus in Chicago that utilizes many megabits of throughput and runs on multiple webservers that are load balanced using TC 3.1 and Apache 1.3. This is a new release of this app. I have some questions: 1) If we are choosing to go with 4.0, should we also be taking a look at Apache 2.0? How far has the integration come on that front? 2) Using the mod_webapp.so, do we need to specify a "Tomcat Standalone" service with our ROOT context, or is the "Tomcat-Apache" all we need (and we should define the ROOT context int there) Thanks, -Nick Bauman (The guy running BugRat for Jakarta) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
