Henri Gomez wrote: > > > > Graham Leggett wrote: > > > >>Just rewriting mod_ajp for v2.0 isn't anything different to > >>what exists now, so I don't see the point. > > > > Well, that's how you see it. > > IMO trying again to squize the apache2->Tomcat module > inside some already > > present solution would again lead to nowhere, and finally > rise the questions > > like we are rising today. > > Not sure since mod_proxy will associate to a ajp://VIRTUALNAME, and in > such case it's up to proxy_ajp to decide to : >
I think that we forked from jk/jk2 to be able to write from the scratch the module that will do exactly _one_ and _only_one_ thing; and that is effectively communicate with TC server using ajp13+ protocol. So, my question is. Why do we need again some container to accomplish that? There are just too many compromises that we need to take if building proxy_ajp, and I thought that we wish no compromises at all. If we don' t build a module that will do exactly what it's meant to be doing, well... Same story again, and I don't understand why one would wish to do that? If someone wishes to make a proxy_ajp I don't have a problem with that, quite opposite, but I still wish to write (like initially said) the module that will only and only communicate to application server cluster, nothing less, nothing more. We already have a bunch of modules that can use WTF protocol you wish, but no one can configure or use it without reading 500 page book that doesn't even exists. > - keep the socket open > - handle a pool of socket > - fall back to another AJP instance in the cluster. > > So I think it could be done I'm sure it can, but like I said, you can mimic the mod_proxy inside jk2. It also can be done :) MT.
smime.p7s
Description: S/MIME cryptographic signature
