RE: Connector compatibility between TC 4.0 and 4.1
On Fri, 21 Dec 2001, Craig R. McClanahan wrote: As appealing an idea as this sounds (packaging plug-in modules as webapps), it doesn't solve the underlying issue -- different containers have radically different internal architectures, and packaging the plug-in as webapp doesn't avoid having to deal with that. You still have to bridge the architectural differences for installing the plug-in functionality in the container, using container-specific APIs. Except that 'packaging' of the module doesn't even try to solve that problem ( of different internal architectures, etc). The problem it tries to solve is simplifing the live of the user, who will use the ( hopefully ) simple pattern of deploying and configuring web applications. If a container's architecture allow certain functionality ( whatever that is ) - we'll try to take advantage of it, and make the connector aware of it. If not - then that feature will not be available on that container. We don't try to create a common API or a meta architecture - just to take advantage of the maximum set of APIs and features a container provides. To be successful at bridging this gap, you've really only got a couple of choices: * Create an external common API for things that are not architecture dependent (like web connectors) that a container can choose to support or not support, and don't bother trying to standardize things that are radically different between architectures (for example, RequestInterceptor vs. Valve, or the very different concepts of how the core components of the container are organized). That assumes the container should ( or should not ) support a particular API or connector. IMHO the connector is a module that should support different containers by using their APIs. It's unlikely IIS or iPlanet will start supporting jk. And I see no reason for 3.3 ( for example ) to be changed to support whatever internal API the connector will use on the java side. On the other side, jk should try to use whatever API the web server ( on one side ) and servlet container ( on the other ) provides. If certain things are possible only with Apache2 ( like dynamic configuration of the server using the cfgtree ) or a container - we should use them in that particular case. If not - we can either try to provide a workaround or just document that this feature is available only with a particular configuration. * Create a meta-architecture (via a set of common APIs) that all containers must support -- never mind that it might mandate doing things in a totally different way than any existing container. Again something that wouldn't make sense - the role of the module is to augment the functionality, not to dicatate a particular API or model. IMHO, the latter option is not practical. Packaging plug-in functionality as a web app does nothing to help resolve the basic issue that containers are different on the inside. And, if you went to the effort to do this, you'd spend your time more efficiently by just creating a container conforming to those APIs and be done with it. Packaging the plug-in as a webapp doesn't try to resolve that problem ! Containers and web server are different on the inside, and that's not even something bad or a 'problem' that needs to be solved. Packaging the plugin as a webapp is intended for the users deploying or using plug-ins - if a particular plugin has support for a container, than the user's experience will be consistent ( not the complete set of features the plugin can provide - that depends on the container's architecture - but the basic functionality and problem the plugin is supposed to solve ). Oh wait ... we've already done that ... twice :-). That seems entirely sufficient to me. I think it have been done few dozen times - and there's still plenty of space for improvements :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Connector compatibility between TC 4.0 and 4.1
On Fri, 21 Dec 2001, Kevin Seguin 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. can you provide some more detail? i'm quite interested in learning more. It's quite simple - the idea is to 'package' tomcat modules ( i.e. anything providing additional functionality ) as 'plain' WAR files. Why ? Many good reasons: - reuse - all the infrastructure for webapps will apply to modules as well. With a bit of work we can get dynamic module loading/reloading, deployment ( including 'hot' ) etc. Even setting module properties will benefit from the UI for web.xml admin ( i.e. most config can be done using Context attributes in web.xml ). - self-contained and well defined environment for modules. We'll know that the directory structure on deployment will be clear, we can call getRealPath(/) and know where all our files are located. That's container independent, etc. ( I assume modules will be 'expanded' - that's a requirement, as we'll use the directory structure to generate configs, etc) - a lot of the module can be implemented as plain servlet/jsp. Like 'seeing' jk status, logs, etc. Again, everything is self-contained and have a defined structure ( like in a webapp ) - the original reason for doing that ( in 3.3 ) was simplifying the code. We wanted 3.3 to be as simple as possible, with a minimal core providing the 'referenece implementation' part and nothing else, and have all the 'features' implemented as optional modules. That's what the 'modules/' directory is for. 3.3 does have all the features from 3.2.x, but we tried to not add anything else - any feature should be provided as a module. - of course, the build environment and everything else becomes more 'faimiliar' for people. It's a webapp that happens to implement and use one extra API ( or few APIs ) to interface with the container. It's no different from a webapp that is using diferent parsers or databases. The only 'special' thing is that our webapp can affect the container behavior ( exacly like /admin or /manager ). The only problem is making the 'webapp' usable on multiple containers ( that support the concept ). This is quite painfull for 4.x ( including 4.1 ), because in order to access the internals you need to implement an interface on a servlet ( and that will not load in 3.3 ). But I think there are some ( maybe ugly ) ways to get around this. Again, in a webapp that does database access or xml you want to be able to support multiple 'drivers' - a module doing authentication will also have 'drivers' for different servlet containers, same for jk. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Connector compatibility between TC 4.0 and 4.1
As appealing an idea as this sounds (packaging plug-in modules as webapps), it doesn't solve the underlying issue -- different containers have radically different internal architectures, and packaging the plug-in as webapp doesn't avoid having to deal with that. You still have to bridge the architectural differences for installing the plug-in functionality in the container, using container-specific APIs. To be successful at bridging this gap, you've really only got a couple of choices: * Create an external common API for things that are not architecture dependent (like web connectors) that a container can choose to support or not support, and don't bother trying to standardize things that are radically different between architectures (for example, RequestInterceptor vs. Valve, or the very different concepts of how the core components of the container are organized). * Create a meta-architecture (via a set of common APIs) that all containers must support -- never mind that it might mandate doing things in a totally different way than any existing container. IMHO, the latter option is not practical. Packaging plug-in functionality as a web app does nothing to help resolve the basic issue that containers are different on the inside. And, if you went to the effort to do this, you'd spend your time more efficiently by just creating a container conforming to those APIs and be done with it. Oh wait ... we've already done that ... twice :-). That seems entirely sufficient to me. Craig On Fri, 21 Dec 2001 [EMAIL PROTECTED] wrote: Date: Fri, 21 Dec 2001 11:34:57 -0800 (PST) From: [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: RE: Connector compatibility between TC 4.0 and 4.1 On Fri, 21 Dec 2001, Kevin Seguin 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. can you provide some more detail? i'm quite interested in learning more. It's quite simple - the idea is to 'package' tomcat modules ( i.e. anything providing additional functionality ) as 'plain' WAR files. Why ? Many good reasons: - reuse - all the infrastructure for webapps will apply to modules as well. With a bit of work we can get dynamic module loading/reloading, deployment ( including 'hot' ) etc. Even setting module properties will benefit from the UI for web.xml admin ( i.e. most config can be done using Context attributes in web.xml ). - self-contained and well defined environment for modules. We'll know that the directory structure on deployment will be clear, we can call getRealPath(/) and know where all our files are located. That's container independent, etc. ( I assume modules will be 'expanded' - that's a requirement, as we'll use the directory structure to generate configs, etc) - a lot of the module can be implemented as plain servlet/jsp. Like 'seeing' jk status, logs, etc. Again, everything is self-contained and have a defined structure ( like in a webapp ) - the original reason for doing that ( in 3.3 ) was simplifying the code. We wanted 3.3 to be as simple as possible, with a minimal core providing the 'referenece implementation' part and nothing else, and have all the 'features' implemented as optional modules. That's what the 'modules/' directory is for. 3.3 does have all the features from 3.2.x, but we tried to not add anything else - any feature should be provided as a module. - of course, the build environment and everything else becomes more 'faimiliar' for people. It's a webapp that happens to implement and use one extra API ( or few APIs ) to interface with the container. It's no different from a webapp that is using diferent parsers or databases. The only 'special' thing is that our webapp can affect the container behavior ( exacly like /admin or /manager ). The only problem is making the 'webapp' usable on multiple containers ( that support the concept ). This is quite painfull for 4.x ( including 4.1 ), because in order to access the internals you need to implement an interface on a servlet ( and that will not load in 3.3 ). But I think there are some ( maybe ugly ) ways to get around this. Again, in a webapp that does database access or xml you want to be able to support multiple 'drivers' - a module doing authentication will also have 'drivers' for different servlet containers, same for jk. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Connector compatibility between TC 4.0 and 4.1
Hi, After a lot of efforts, it turns out the connectors (in j-t-c) still can't be compiled against both the 4.0 branch and the HEAD branch of the Tomcat CVS. There are a few solutions to this: 1) Force the connectors to be built against the HEAD branch. They should run fine on Tomcat 4.0 (although that needs some testing). 2) The main problem is the move of the ServerSocketFactory interface from o.a.c.net to o.a.c. We could revert that change, and fixing the rest is extremely simple. Which one do you think is best ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Connector compatibility between TC 4.0 and 4.1
Hi, After a lot of efforts, it turns out the connectors (in j-t-c) still can't be compiled against both the 4.0 branch and the HEAD branch of the Tomcat CVS. There are a few solutions to this: 1) Force the connectors to be built against the HEAD branch. They should run fine on Tomcat 4.0 (although that needs some testing). 2) The main problem is the move of the ServerSocketFactory interface from o.a.c.net to o.a.c. We could revert that change, and fixing the rest is extremely simple. Which one do you think is best ? perhaps now is the time to do some rethinking of where the connectors for each serlvet container live. today, in j-t-c, there is the framework (for lack of a better word) for connectors plus the individual connectors or adapters for tomcat 3 and tomcat 4. personally, i think it would be better to have the individual connectors/adapters live with the servlet container itself. i.e. put the ajp13 connector for tomcat 4 in the jakarta-tomcat-4.0 source tree. this way, j-t-c can build without having dependencies on any servlet containers, and servlet containers that want to provide connectors that make use of j-t-c can (optionally) depend on j-t-c. just my $0.02. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Connector compatibility between TC 4.0 and 4.1
On Thu, 20 Dec 2001, Kevin Seguin wrote: perhaps now is the time to do some rethinking of where the connectors for each serlvet container live. today, in j-t-c, there is the framework (for lack of a better word) for connectors plus the individual connectors or adapters for tomcat 3 and tomcat 4. personally, i think it would be better to have the individual connectors/adapters live with the servlet container itself. i.e. put the ajp13 connector for tomcat 4 in the jakarta-tomcat-4.0 source tree. this way, j-t-c can build without having dependencies on any servlet containers, and servlet containers that want to provide connectors that make use of j-t-c can (optionally) depend on j-t-c. 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. And the build changes I'm trying to make should simplify building for all or just individual containers. 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. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Connector compatibility between TC 4.0 and 4.1
On Thu, 20 Dec 2001, Remy Maucherat wrote: Hi, After a lot of efforts, it turns out the connectors (in j-t-c) still can't be compiled against both the 4.0 branch and the HEAD branch of the Tomcat CVS. There are a few solutions to this: 1) Force the connectors to be built against the HEAD branch. They should run fine on Tomcat 4.0 (although that needs some testing). If we add void setFactory(org.apache.catalina.ServerSocketFactory $1), then it'll be impossible to build it against 4.0. If we don't - it's impossible to build against 4.1. 2) The main problem is the move of the ServerSocketFactory interface from o.a.c.net to o.a.c. We could revert that change, and fixing the rest is extremely simple. That's the only solution AFAIK. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Connector compatibility between TC 4.0 and 4.1
[EMAIL PROTECTED] wrote: On Thu, 20 Dec 2001, Kevin Seguin wrote: perhaps now is the time to do some rethinking of where the connectors for each serlvet container live. today, in j-t-c, there is the framework (for lack of a better word) for connectors plus the individual connectors or adapters for tomcat 3 and tomcat 4. personally, i think it would be better to have the individual connectors/adapters live with the servlet container itself. i.e. put the ajp13 connector for tomcat 4 in the jakarta-tomcat-4.0 source tree. this way, j-t-c can build without having dependencies on any servlet containers, and servlet containers that want to provide connectors that make use of j-t-c can (optionally) depend on j-t-c. 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. :) 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.. 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 really be the other way around. But that's just my non-committer $0.02. And I run Tomcat stand-alone anyway... the engineer in me just had to say something. :) And the build changes I'm trying to make should simplify building for all or just individual containers. 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? -Paul Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Connector compatibility between TC 4.0 and 4.1
[EMAIL PROTECTED] wrote: 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. :) 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.. 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 really be the other way around. But that's just my non-committer $0.02. And I run Tomcat stand-alone anyway... the engineer in me just had to say something. :) The standalone connector (at least the future version of it) for TC 4.x is also in j-t-c, and I'd like it to work with both versions of TC with only one codebase. Why ? It saves time, and that also avoid mistakes (like forgetting to apply a patch on one of the versions). This connector would then be optional with TC 4.0.x (use it if you need better performance), and would be the default in the next 4.x release (if of course, it turns out it's better than the current one). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Connector compatibility between TC 4.0 and 4.1
On Thu, 20 Dec 2001, Remy Maucherat wrote: Hi, After a lot of efforts, it turns out the connectors (in j-t-c) still can't be compiled against both the 4.0 branch and the HEAD branch of the Tomcat CVS. There are a few solutions to this: 1) Force the connectors to be built against the HEAD branch. They should run fine on Tomcat 4.0 (although that needs some testing). If we add void setFactory(org.apache.catalina.ServerSocketFactory $1), then it'll be impossible to build it against 4.0. If we don't - it's impossible to build against 4.1. 2) The main problem is the move of the ServerSocketFactory interface from o.a.c.net to o.a.c. We could revert that change, and fixing the rest is extremely simple. That's the only solution AFAIK. The proposal was heavily weigthed towards 2), since I think it's the only acceptable solution. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Connector compatibility between TC 4.0 and 4.1
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]
