Web server integration / NameTrans stage
I've been looking at the existing web server integration stuff (both mod_jk and mod_webapp), and it seems to me that there is one significant piece missing - a NameTrans directive that takes its configuration from a separate file. I know I'm talking iPlanet here - but that's where my experience is. At the moment I'm running a bodged together iPlanet / Tomcat 4 combo where the servlet requests are http-proxied to Tomcat, but I need to to the NameTrans part myself: NameTrans fn=assign-name from=/myapp/firsturl name=tomcat NameTrans fn=assign-name from=/myapp/secondurl name=tomcat Obviously you don't want hundreds on NameTrans directives to maintain in obj.conf, and you don't want your Java developers fiddling with your web server configuration. I don't do Apache, so I don't know whether there is an equivalent issue there. It seems to me that a single configuration file that is read at web server init time, that tells the web server where the webapps are, what url prefixes they map to, and whether they are distributable etc would be a good idea. Something like: deployment connection name=serverone type=warp hosthostone/host port8081/port /connection connection name=servertwo type=warp hosthosttwo/host port8081/port /connection webapp name=myapp distributable=no url-mapping/myapp/url-mapping connections connectionserverone/connection connectionservertwo/connection /connections /webapp /deployment Does this sound sensible? I think I want this for myself anyway, so I might see if I can knock it up. The only complex thing would be parsing the file (I want to stick to C - so I don't know what I'd do about XML parsing). Does anyone have any opinions? Am I duplicating any previous work?
Re: Web server integration / NameTrans stage
Hi Colin, This idea is ( surprise ) already implemented, as part of the IIS connector. It isn't a config file, but a properties file ( much easier to parse and work with ). We already discussed few times about adding this configuration style to the other containers ( apache, nes ) - so your work will certainly be helpfull. One problem ( and that's common to apache as well ) is that if you are using the NameTrans ( or SetHandler ), that means netscape/apache is managing the mappings. By using the jk mapper, the whole thing is duplicated, and that will affect ( slow down ) _all_ requests that are processed by the server. We are trying to enhance the native config style, allowing the user to use standard Apache directives ( SetHandler, etc ). This is also part of the effort to integrate the authentication ( use apache to do auth, etc ). Of course, this is just a choice - each config style has its benefits. Regarding the config, the most common 2 cases shouldn't require any additional user configuration. - one web server, one tomcat instance - all the contexts are configured in server.xml, tomcat can generate a config or, via Ajp14, send the config on the wire - one web server, pool of load-balanced tomcats - almost the same, there is only one worker ( lb ) and the config can be generated with no extra user info. - one/many web servers, dispatching to different tomcats based on context using different workers. For this you'll need some extra info, but I would place it on the Context level ( or/and AutoWebApp ), it's much easier to have it in a single place. Again, the properties file can be generated from server.xml or sent on the wire. The goal is to have the user do minimal configuration. It's not easy, and it also mean the user will have less flexibility, but it's a good idea. Anyway - it would be great to add this to NES and apache, and IMHO it would be better if instead of spending your time parsing xml in C you would add support for virtual host in the config file ( that would be usefull for IIS, NES and Apache ). Right now virtual hosts work only with manual configuration. Costin ( I hope I didn't confused you - there is a lot of flexibility and choices, and many possibilities ) On Thu, 9 Aug 2001, Colin Wilson-Salt wrote: I've been looking at the existing web server integration stuff (both mod_jk and mod_webapp), and it seems to me that there is one significant piece missing - a NameTrans directive that takes its configuration from a separate file. I know I'm talking iPlanet here - but that's where my experience is. At the moment I'm running a bodged together iPlanet / Tomcat 4 combo where the servlet requests are http-proxied to Tomcat, but I need to to the NameTrans part myself: NameTrans fn=assign-name from=/myapp/firsturl name=tomcat NameTrans fn=assign-name from=/myapp/secondurl name=tomcat Obviously you don't want hundreds on NameTrans directives to maintain in obj.conf, and you don't want your Java developers fiddling with your web server configuration. I don't do Apache, so I don't know whether there is an equivalent issue there. It seems to me that a single configuration file that is read at web server init time, that tells the web server where the webapps are, what url prefixes they map to, and whether they are distributable etc would be a good idea. Something like: deployment connection name=serverone type=warp hosthostone/host port8081/port /connection connection name=servertwo type=warp hosthosttwo/host port8081/port /connection webapp name=myapp distributable=no url-mapping/myapp/url-mapping connections connectionserverone/connection connectionservertwo/connection /connections /webapp /deployment Does this sound sensible? I think I want this for myself anyway, so I might see if I can knock it up. The only complex thing would be parsing the file (I want to stick to C - so I don't know what I'd do about XML parsing). Does anyone have any opinions? Am I duplicating any previous work?
Re: Web server integration / NameTrans stage
Colin Wilson-Salt at [EMAIL PROTECTED] wrote: I've been looking at the existing web server integration stuff (both mod_jk and mod_webapp), and it seems to me that there is one significant piece missing - a NameTrans directive that takes its configuration from a separate file. I know I'm talking iPlanet here - but that's where my experience is. Hmm... I don't know anything about NES as of now. I don't know how it works, how it's configured, how the API looks like... NOTHING :) I suppose that JK has something like that. They rely on external configuration files. Regarding mod_webapp, external configuration files are a big -1... No-No... Configuration should be effective, minimal and integrated with the web-server... If you see how Apache works, you have only ONE line of configuration per web-application, and all the rest is taken care automatically... Pier
Re: Web server integration / NameTrans stage
The only way (that I'm aware) to do what you are suggesting is to implement a PathCheck or a Service method in the Default object block. It has been a while since I worked with these, but as I recall, every request is handed off to these functions to determine if it should be handled by a particular plugin. The PathCheck lets you check the incoming URI and see if it is one that you should handle and possibly add some additional information into the request for later processing. Depending on how (and where) the Service method is called, it can either process the request or respond that it isn't interested. The NameTrans directive has to have a specific pattern to match and can then direct the processing to different object blocks which is how the current connectors work. It is more efficient because only the requests that match a particular pattern are actually handed of to the additional processing. The Service and PathCheck methods in the Default object block are more dynamic, but will be hit for every request and so have the potential of slowing down the overall performance of the web server. Again, this is based on what I've read in the NSAPI programming guide and played with on other plugins so I could be completely off base, but it matches behavior that I've seen. Mike Anderson [EMAIL PROTECTED] 08/09/01 10:13AM Colin Wilson-Salt at [EMAIL PROTECTED] wrote: I've been looking at the existing web server integration stuff (both mod_jk and mod_webapp), and it seems to me that there is one significant piece missing - a NameTrans directive that takes its configuration from a separate file. I know I'm talking iPlanet here - but that's where my experience is. Hmm... I don't know anything about NES as of now. I don't know how it works, how it's configured, how the API looks like... NOTHING :) I suppose that JK has something like that. They rely on external configuration files. Regarding mod_webapp, external configuration files are a big -1... No-No... Configuration should be effective, minimal and integrated with the web-server... If you see how Apache works, you have only ONE line of configuration per web-application, and all the rest is taken care automatically... Pier
RE: Web server integration / NameTrans stage
But... you still need to edit the web server configuration file to deploy a web app. If the file that describes how the two pieces integrate is owned by the tomcat user, then the Java guys can look after that and the only thing that they need to do with iPlanet is use its admin tool to restart it. iPlanet is not nice to configure, it's not very forgiving (a single space in the wrong place can prevent it starting with no sensible error message), and its configuration files are typically owned by root - I want to let the webapp coders deploy their applications, but I don't want them anywhere near the web server that I've spent so long configuring and tuning. -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 09, 2001 17:13 To: [EMAIL PROTECTED] Subject: Re: Web server integration / NameTrans stage ... I suppose that JK has something like that. They rely on external configuration files. Regarding mod_webapp, external configuration files are a big -1... No-No... Configuration should be effective, minimal and integrated with the web-server... If you see how Apache works, you have only ONE line of configuration per web-application, and all the rest is taken care automatically... Pier
Re: Web server integration / NameTrans stage
Colin Wilson-Salt at [EMAIL PROTECTED] wrote: But... you still need to edit the web server configuration file to deploy a web app. If the file that describes how the two pieces integrate is owned by the tomcat user, then the Java guys can look after that and the only thing that they need to do with iPlanet is use its admin tool to restart it. iPlanet is not nice to configure, it's not very forgiving (a single space in the wrong place can prevent it starting with no sensible error message), and its configuration files are typically owned by root - I want to let the webapp coders deploy their applications, but I don't want them anywhere near the web server that I've spent so long configuring and tuning. Oh, well, in that case, you can just the autodeploy feature I'm building for the WebApp module. Basically, everything you need to configure is a WARP connection. The warp protocol allows you to query the servlet containers what web applications are deployable, and from then all is done automatically. All you need to configure is the Tomcat 4.0 server.xml configuration file, and everything is done automatically for you... Pier
RE: Web server integration / NameTrans stage
On Thu, 9 Aug 2001, Colin Wilson-Salt wrote: iPlanet is not nice to configure, it's not very forgiving (a single space in the wrong place can prevent it starting with no sensible error message), and its configuration files are typically owned by root - I want to let the webapp coders deploy their applications, but I don't want them anywhere near the web server that I've spent so long configuring and tuning. Unless you want to fine-tune a webapplication. There are 2 ways to do what you want: either what IIS is doing ( with mod_jk reading a properties file, that is generated from server.xml and autoconfigured apps ), or via Ajp14, where the same information is sent on the wire at the initial connection time ( this is only in experimental stage right now, it seems to work fine but it needs more work ). The 2 are almost identical - same information is used. The first is easier to debug and trace, and may allow extra customizations. The second is very usefull if tomcat is on different machine, and is easier ( but a bit less flexible ). The third option, using the native config format ( i.e. the only current solution for NES, and one of the choices for Apache ) is the most powerfull and the hardest to configure. It seems you don't like this choice ( or at least you don't want this to be the only choice for NES :-), but it is the most powerfull one. It seems Pier believes only one options should be available in webapp, it's his choice. For jk we hope to have all choices available on all containers. BTW, if properties or Ajp14 are used the autoconfiguration makes sure the user _doesn't_ have to edit anything manually when he adds a webapp, so besides the initial setup it's zero lines per webapp. Unless the user wants something special, and then the web server sets the limits on what he can do. Costin
Re: Web server integration / NameTrans stage
You probably want to start with org.apache.tomcat.modules.config.NSConfig (it's 3.3 name, I don't know where it lives in 4.0), and see what needs to be changed to go from NS-iPlanet. - Original Message - From: Colin Wilson-Salt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 09, 2001 10:15 AM Subject: RE: Web server integration / NameTrans stage But... you still need to edit the web server configuration file to deploy a web app. If the file that describes how the two pieces integrate is owned by the tomcat user, then the Java guys can look after that and the only thing that they need to do with iPlanet is use its admin tool to restart it. iPlanet is not nice to configure, it's not very forgiving (a single space in the wrong place can prevent it starting with no sensible error message), and its configuration files are typically owned by root - I want to let the webapp coders deploy their applications, but I don't want them anywhere near the web server that I've spent so long configuring and tuning. -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 09, 2001 17:13 To: [EMAIL PROTECTED] Subject: Re: Web server integration / NameTrans stage ... I suppose that JK has something like that. They rely on external configuration files. Regarding mod_webapp, external configuration files are a big -1... No-No... Configuration should be effective, minimal and integrated with the web-server... If you see how Apache works, you have only ONE line of configuration per web-application, and all the rest is taken care automatically... Pier
