On Thu, 20 Dec 2001, Paul Speed wrote: > > My thinking ( for 4.1/3.3 ) was to have j-t-c built as a > > 'standalone module', a trusted/priviledged webapp that can be deployed and > > is self-contained. > > > > Keeping all container adapters in j-t-c has the extra benefit that we can > > share more code among them. > > It still feels wierd to me. Imagine if JNDI did things this way... > we'd have to have every provider installed just to build it. :)
JNDI is an API. j-t-c is a provider - it implements the 'connection' between web server and servlet container. It has a 'common' part, and pieces that are specific to the different containers and servers it supports. Those 'adapters' are supposed to be small and simple. They are not, and one of the things I'm trying to do in jk2 is to fix that. I'm talking about both the java and the c side. > I think if the layer of abstraction is at the right point you can > get a compromise between code reuse and modularity. Otherwise, since > the container adapters are in a different module than the containers > themselves, there are always going to be cases where container > improvements break the connector build. This is because they are > tagged differently, etc.. Tomcat3.3 and 4.0 are supposed to be frozen at API level. If a documented API no longer works, that's a bug in the container. BTW, we have container adapters but also server adapters - I see no reason to treat them differently ( and I doubt the IIS adapter will be included in iis sources :-). Moving the adapters would require a stable API for jk - wich I don't think we'll have until jk2 is completed. Using the jk1 API will be a mistake IMHO ( if you consider the Ajp13 and Ajp13Packet as an API ). > Right now it seems to be structured that j-t-c is the application > and the containers are its libraries. It seems like it should j-t-c is structured ( at least try to do ) as a provider ( or driver, add-on, whatever) for each container. It supports multiple servers, multiple containers - and I think it's normal for it to depend on them, and not the other way around. > > For the current release - I don't think we should move the code. > > For jk2 - I also think we should wait until it's in a more concrete shape. > > So are you saying that the dependencies should be restructured as > discussed above, but just not yet? I think we should keep the current model until things are stable. I see no problem with some containers having the 'jk adapter' built-in, or with jk having a container adapter. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
