> [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]>
