You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Craig R. McClanahan" <Cr...@eng.sun.com> on 2000/08/09 08:04:02 UTC
[PROPOSALS] Three Proposals for Development of Tomcat 4.0
As the time approaches when the initial public drafts of the Servlet 2.3
and JSP 1.2 specifications will become available, it is appropriate for
the TOMCAT-DEV development community to discuss and decide how we are
going to deal with the implementation of the changes required to support
these specifications. According to the revision numbering scheme that
was agreed to when Jakarta was initially launched, changes to the
supported specification versions would correspond to a change in the
major version number of Tomcat (4.0 in this particular case).
To facilitate development of Tomcat 4.0, without compromising our
ability to support and enhance the existing Tomcat 3.x code base, I am
hereby submitting three "Long Term Plan" proposals to be discussed and
voted on by the Tomcat developer community. Rather than create
tremendously long EMAIL messages for everyone on TOMCAT-DEV, I have
checked the proposal documents into the jakarta-tomcat CVS repository in
a directory named "proposals/tomcat-4.0".
You can use the online CVS access to retrieve the current versions of
these proposals by following these links (beware that some mail readers
may wrap the fairly long URLs):
* Proposal for creation of a new CVS repository module
named "jakarta-tomcat-4.0", and renaming the current
CVS repository module from "jakarta-tomcat" to
"jakarta-tomcat-3.0".
<http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/proposals/tomcat-4.0/source-proposal.html>
* Proposal for re-architecting the Jasper JSP compiler
to deal with feature enhancements that will be required
by JSP 1.2, and to agree upon a set of development goals.
<http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/proposals/tomcat-4.0/jasper-proposal.html>
* Proposal to adopt the Catalina code base as the servlet
container code for Tomcat 4.0.
<http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/proposals/tomcat-4.0/catalina-proposal.html>
Please review these proposals and feel free to comment (and vote) on
them on the TOMCAT-DEV mailling list. There is certainly nothing cast
in concrete at this point, although we should intend to make final
decisions on these proposals in fairly short order.
Craig McClanahan
Re: [PROPOSALS] Three Proposals for Development of Tomcat 4.0
Posted by Remy Maucherat <re...@apache.org>.
> "Craig R. McClanahan" wrote:
> >
> > [...]
> > Please review these proposals and feel free to comment (and vote) on
> > them on the TOMCAT-DEV mailling list. There is certainly nothing cast
> > in concrete at this point, although we should intend to make final
> > decisions on these proposals in fairly short order.
>
> As I said to you previously (I had a copy of the proposal yesterday
> morning) I'm all +1 on this.
+1 too.
> To give just the status of what I'm doing, I'm right now looking at the
> mod_jk source to see how it can be ported to Catalina, and what needs to
> be done in terms of connections to the different webservers (back to
> square one :)
Remy
Re: [PROPOSALS] Three Proposals for Development of Tomcat 4.0
Posted by "Pier P. Fumagalli" <pi...@apache.org>.
"Craig R. McClanahan" wrote:
>
> [...]
> Please review these proposals and feel free to comment (and vote) on
> them on the TOMCAT-DEV mailling list. There is certainly nothing cast
> in concrete at this point, although we should intend to make final
> decisions on these proposals in fairly short order.
As I said to you previously (I had a copy of the proposal yesterday
morning) I'm all +1 on this.
To give just the status of what I'm doing, I'm right now looking at the
mod_jk source to see how it can be ported to Catalina, and what needs to
be done in terms of connections to the different webservers (back to
square one :)
Pier
Re: [PROPOSALS] Three Proposals for Development of Tomcat 4.0
Posted by "Pier P. Fumagalli" <pi...@apache.org>.
"Craig R. McClanahan" wrote:
>
> [...]
> Therefore, Catalina can rely on the Java2 features -- and in many cases
> it already does. Catalina will not compile or run on a JDK 1.1 platform.
+1 also a couple of things in the native interfaces changed, and I'd
like to use these new features :)
Pier
Re: [PROPOSALS] Three Proposals for Development of Tomcat 4.0
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Glenn Nielsen wrote:
> I didn't see anything that referred to what version of the JDK would
> be targeted. I know we went through a discussion about maintining jdk 1.1
> compatability with Tomcat 3.X. But I would like to propose that Tomcat 4.0
> require jdk 1.2 or greater. JDK 1.2 is available for most systems now, and
> should be available on even more systems by the time Tomcat 4.0 is released.
> Requiring JDK1.2 would allow us to take advantage of features of the 1.2 JDK
> to optimize Tomcat performance and remove the hoops Costin jumped through
> to make Tomcat 3.2 compile/run on jdk1.1 while still implementing some 1.2
> features for those using JDK 1.2.
As was pre-announced in the previous discussion, Servlet 2.3 will
require Java2 (i.e. JDK 1.2 or later) as a minimum
platform. Therefore, Catalina can rely on the Java2 features -- and in
many cases it already does. Catalina will not
compile or run on a JDK 1.1 platform.
We can take advantage of the same prerequisites when remodelling Jasper
as well.
>
> Regards,
>
> Glenn
>
Craig
Re: [PROPOSALS] Three Proposals for Development of Tomcat 4.0
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
I didn't see anything that referred to what version of the JDK would
be targeted. I know we went through a discussion about maintining jdk 1.1
compatability with Tomcat 3.X. But I would like to propose that Tomcat 4.0
require jdk 1.2 or greater. JDK 1.2 is available for most systems now, and
should be available on even more systems by the time Tomcat 4.0 is released.
Requiring JDK1.2 would allow us to take advantage of features of the 1.2 JDK
to optimize Tomcat performance and remove the hoops Costin jumped through
to make Tomcat 3.2 compile/run on jdk1.1 while still implementing some 1.2
features for those using JDK 1.2.
Regards,
Glenn
"Craig R. McClanahan" wrote:
>
> As the time approaches when the initial public drafts of the Servlet 2.3
> and JSP 1.2 specifications will become available, it is appropriate for
> the TOMCAT-DEV development community to discuss and decide how we are
> going to deal with the implementation of the changes required to support
> these specifications. According to the revision numbering scheme that
> was agreed to when Jakarta was initially launched, changes to the
> supported specification versions would correspond to a change in the
> major version number of Tomcat (4.0 in this particular case).
>
> To facilitate development of Tomcat 4.0, without compromising our
> ability to support and enhance the existing Tomcat 3.x code base, I am
> hereby submitting three "Long Term Plan" proposals to be discussed and
> voted on by the Tomcat developer community. Rather than create
> tremendously long EMAIL messages for everyone on TOMCAT-DEV, I have
> checked the proposal documents into the jakarta-tomcat CVS repository in
> a directory named "proposals/tomcat-4.0".
>
> You can use the online CVS access to retrieve the current versions of
> these proposals by following these links (beware that some mail readers
> may wrap the fairly long URLs):
>
> * Proposal for creation of a new CVS repository module
> named "jakarta-tomcat-4.0", and renaming the current
> CVS repository module from "jakarta-tomcat" to
> "jakarta-tomcat-3.0".
>
> <http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/proposals/tomcat-4.0/source-proposal.html>
>
> * Proposal for re-architecting the Jasper JSP compiler
> to deal with feature enhancements that will be required
> by JSP 1.2, and to agree upon a set of development goals.
>
> <http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/proposals/tomcat-4.0/jasper-proposal.html>
>
> * Proposal to adopt the Catalina code base as the servlet
> container code for Tomcat 4.0.
>
> <http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/proposals/tomcat-4.0/catalina-proposal.html>
>
> Please review these proposals and feel free to comment (and vote) on
> them on the TOMCAT-DEV mailling list. There is certainly nothing cast
> in concrete at this point, although we should intend to make final
> decisions on these proposals in fairly short order.
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: [PROPOSALS] Three Proposals for Development of Tomcat 4.0
Posted by "Pier P. Fumagalli" <pi...@apache.org>.
"Craig R. McClanahan" wrote:
>
> [...]
> One of the disadvantages of creating a new module is that you lose all of the
> previous history of changes to individual files, because you have to check in a
> complete set to start the new module.
... Unless you move files around into the CVS server... It is possible
to change repository maintaining revision numbers just moving files
between repositories on the server.
And it's possible also to incorporate modules into modules by symlinking
directories and files on the server.
Suppose we have jakarta-servletapi and jakarta-tomcat modules, under
jakarta-tomcat we want to have a subdirectory containing the servlet api
module, we just do:
ln -sf $CVSROOT/jakarta-servletapi $CVSROOT/jakarta-tomcat/servletapi
where CVSROOT is (in locus' example /home/cvs)
Pier
Re: [PROPOSALS] Three Proposals for Development of Tomcat 4.0
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Hans Bergsten wrote:
> Sorry for the late reply:
>
> "Craig R. McClanahan" wrote:
> > [...]
> > As th> * Proposal for creation of a new CVS repository module
> > named "jakarta-tomcat-4.0", and renaming the current
> > CVS repository module from "jakarta-tomcat" to
> > "jakarta-tomcat-3.0".
> >
>
> +1, but wouldn't it be easier manage Servlet/JSP API changes if we create a new
> module for jakarta-servletapi as well instead of using a branch?
One of the disadvantages of creating a new module is that you lose all of the
previous history of changes to individual files, because you have to check in a
complete set to start the new module. In the case of Catalina and Jasper, that is
not as important because the 4.0 code will be so radically different from previous
versions that the history isn't particuarly useful. For the servlet API classes
themselves, I do not expect the changes for Servlet 2.3 and JSP 1.2 to be quite as
radical as that; therefore, the fact that you can trace back the history of changes
to a particular file, through the branch back to the original roots, is still quite
useful.
In terms of source code management, it is a pretty easy CVS command to select which
jakarta-servletapi branch you want to use at the moment. To use the new branch,
simply execute:
cvs update -r SERVLET_23_JSP_12
or to revert to the main line branch (which supports Servlet 2.2 and JSP 1.1 until
the final release of the new specs),
cvs update -A
> I also share
> James Davidson's reservation about renaming the current "jakarta-tomcat" to
> "jakarta-tomcat-3.0".
>
This decision can be made later.
However, initial indications that the effort required to do this on the server is
minimal; users who have the "jakarta-tomcat" module checked out would need to check
out the new module instead, but that is not major heartache if it is announced and
coordinated properly.
>
> Hans
>
Craig
Re: [PROPOSALS] Three Proposals for Development of Tomcat 4.0
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Sorry for the late reply:
"Craig R. McClanahan" wrote:
> [...]
> As th> * Proposal for creation of a new CVS repository module
> named "jakarta-tomcat-4.0", and renaming the current
> CVS repository module from "jakarta-tomcat" to
> "jakarta-tomcat-3.0".
>
+1, but wouldn't it be easier manage Servlet/JSP API changes if we create a new
module for jakarta-servletapi as well instead of using a branch? I also share
James Davidson's reservation about renaming the current "jakarta-tomcat" to
"jakarta-tomcat-3.0".
> * Proposal for re-architecting the Jasper JSP compiler
> to deal with feature enhancements that will be required
> by JSP 1.2, and to agree upon a set of development goals.
+1. I think the structure suggested as part of the other proposal gives enough
separation, and that a separate jakarta-jasper-x.x module is not needed (as
James
Davidson proposed).
> * Proposal to adopt the Catalina code base as the servlet
> container code for Tomcat 4.0.
+1
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: Catalina 1.0 vs. Tomcat 4.0
Posted by "Pier P. Fumagalli" <pi...@apache.org>.
"Craig R. McClanahan" wrote:
>
> Alex Chaffee wrote:
>
> >
> > I don't want to open old wounds, but I thought I'd just explain my
> > tardy -1 (or -0 if I'm the only one) on renaming Catalina to Tomcat
> > 4.0.
> >
>
> More precisely, to use the Catalina code base as the servlet container for
> Tomcat 4.0.
>
> Per the Jakarta webside: Tomcat = Servlets + JSP
I've been drawing... And here's what how I "see" Tomcat...
Pier
Re: Catalina 1.0 vs. Tomcat 4.0
Posted by "Pier P. Fumagalli" <pi...@apache.org>.
Alex Chaffee wrote:
>
> OK, after sleeping on it and reading the replies from Remy and Craig,
> I withdraw my -1 (which was halfhearted at best).
>
> My biggest concern was that new patches to 3.x would be difficult to
> integrate, but I realized that that was silly since there will still
> be two separate CVS repositories. I would be completely mollified if
> mod_jk and mod_jserv got their own repositories as well
> (jakarta-mod-jserv and jakarta-mod-jk? jakarta-apache-mods?) so
> improvements to these could span 3.x and 4.x.
I'm trying to get a hold on the whole module thing... And getting back
to C has been pretty difficult... I'll be coming up with a some sort of
proposal in the upcoming days...
Pier
Re: Catalina 1.0 vs. Tomcat 4.0
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
OK, after sleeping on it and reading the replies from Remy and Craig,
I withdraw my -1 (which was halfhearted at best).
My biggest concern was that new patches to 3.x would be difficult to
integrate, but I realized that that was silly since there will still
be two separate CVS repositories. I would be completely mollified if
mod_jk and mod_jserv got their own repositories as well
(jakarta-mod-jserv and jakarta-mod-jk? jakarta-apache-mods?) so
improvements to these could span 3.x and 4.x.
> > Fact: Tomcat 3.x will soon support the new specs too, via Facades.
> >
>
> Lest there be any confusion here, it is important to point out that the draft
> Servlet 2.3 and JSP 1.2 specs are backwards compatible. That means any app that
> works in a servlet 2.2 / JSP 1.1 environment will happily run in a servlet 2.3 /
> JSP 1.2 container. This is true for any container, not just Tomcat.
>
> What this means here is that Tomcat 4.0,. as proposed, will run any
> spec-compliant app (i.e. one that doesn't rely on unspecified and/or buggy
> behavior) that runs in Tomcat 3.x. No special measures to support two versions
> of the API are needed.
True enough; my point was simply that people who want 2.3, but don't
want to change to Catalina, won't have to (since Tomcat 3.x will
support the latest and greatest specs too).
- A
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Catalina 1.0 vs. Tomcat 4.0
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Alex Chaffee wrote:
>
> I don't want to open old wounds, but I thought I'd just explain my
> tardy -1 (or -0 if I'm the only one) on renaming Catalina to Tomcat
> 4.0.
>
More precisely, to use the Catalina code base as the servlet container for
Tomcat 4.0.
Per the Jakarta webside: Tomcat = Servlets + JSP
> [snip]
> Fact: Tomcat 3.x will soon support the new specs too, via Facades.
>
Lest there be any confusion here, it is important to point out that the draft
Servlet 2.3 and JSP 1.2 specs are backwards compatible. That means any app that
works in a servlet 2.2 / JSP 1.1 environment will happily run in a servlet 2.3 /
JSP 1.2 container. This is true for any container, not just Tomcat.
What this means here is that Tomcat 4.0,. as proposed, will run any
spec-compliant app (i.e. one that doesn't rely on unspecified and/or buggy
behavior) that runs in Tomcat 3.x. No special measures to support two versions
of the API are needed.
Craig
[BUG] JavaDocs mismatch for all Tomcat versions
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
I just noticed that the versions of the JavaDocs included in the Tomcat
3.2 Beta and 3.3 Dev distributions (in src/webpages/docs/api) are not
up-to-date.
For instance, the documentation of the javax.servlet.jsp.tagext.TagSupport class
describes the methods get/setTagId() that are now called get/setId().
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: Catalina 1.0 vs. Tomcat 4.0
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Remy Maucherat wrote:
> [snip]
> BTW, at one point, there was an InterceptorValve which could be used to wrap
> Tomcat interceptors. It seems it had been removed at some point, though
> (Craig ?).
>
The InterceptorValve that was there originally implemented the Tomcat 3.0
interceptor behavior, which had just two entry points (preService and
postService), and didn't reflect the numerous evolutions that RequestInterceptor
has gone through since (along with the rest of the Tomcat 3.x architecture).
So, I removed it.
In principle it would be feasible to support a RequestInterceptor type interface
that conformed to the current definition. In practice, this would probably not
be a useful mechanism for porting existing interceptors, because such
interceptors would undoubtedly rely on other internal architectural things that
have changed.
Of course, as people who have relied on the 3.1 internals architecture are
finding out, 3.2 changed lots of the internal design. And 3.3dev is a even more
different (although in some aspects returning to some 3.1 approaches) Having
the same major version number hasn't seemed to help people writing code to these
interfaces very much ...
Craig
Re: Catalina 1.0 vs. Tomcat 4.0
Posted by Remy Maucherat <re...@apache.org>.
> I don't want to open old wounds, but I thought I'd just explain my
> tardy -1 (or -0 if I'm the only one) on renaming Catalina to Tomcat
> 4.0.
>
> The mandate of the Jakarta Project is to produce a servlet container
> that implements version X of the servlet and JSP specs. There's no
> mandate for this container to always be named Tomcat.
True.
> Fact: Catalina is (as everyone knows) a 99% different code base (I
> think the connectors will be reused, and some of the utility classes).
Ok. Usually in open source, a major revision number change is more
significant than in commercial software. It also means that a good part of
the product, if not everything, has been rewritten, so I don't see any
problem here.
> Fact: Tomcat has a long history of being improved, bugs fixed,
> robustness tested on thousands of platforms, tweaks and custom
> features added; it will be a long time until Catalina has this level
> of maturity.
We have to decide when too mature is too much ;-)
To give an extreme exemple, the DOS code in Win ME is probably extremely
mature, yet I would have liked to see it go away a long time ago.
> Fact: Even once it does, there may be people who want to use custom
> patches/Interceptors/etc., and will require support for their existing
> Tomcat 3.x installs, and will most likely keep coming up with patches
> for Tomcat 3.x.
Our friends from Apache are doing just that with Apache 2.0. They're
rewritting everything from scratch : the webserver, the configuration files
format, the API.
BTW, at one point, there was an InterceptorValve which could be used to wrap
Tomcat interceptors. It seems it had been removed at some point, though
(Craig ?).
> Fact: many sites have customized the server.xml config file; as I
> understand it, there will not be backwards compatibility for all
> (any?) aspects of Tomcat's server.xml in Catalina (though I may be
> wrong here).
I don't think that's a big deal. They're quite similar ...
> Fact: Tomcat 3.x will soon support the new specs too, via Facades.
Cool.
> Fact: Catalina has many advantages too, and I trust Craig et al.'s
> faith in the new design and code.
I trust him too ;-)
> Speculation: If Catalina is released as Tomcat 4.0, then we will end
> up with two separate products, with separate development efforts,
> separate code bases, and unfortunately and confusingly, the same name,
> leading to misunderstandings across the board. E.g., if a security
> hole or performance problem is discovered in one, then the reputation
> of the other will suffer.
I don't see why the Tomcat 3.x code base would have to be maintained in
parallel for a very long amount of time.
> Proposal: that Catalina keep its name, and be designed for release as
> Catalina 1.0, and we make it as clear as we can, on the web site and
> in the docs and announcements, that Catalina is the recommended
> container, and is where most new development will occur.
>
> The only disadvantage I can see is that people will constantly ask,
> "Which one should I use, Catalina or Tomcat," but this FAQ can be
> answered clearly in big bold letters on both the Tomcat and Catalina
> home pages and anywhere else that's appropriate.
>
> I know that the change in name has already happened, and I apologize
> for being on holiday when this thread was launched, but I'd like at
> least a token attempt to convince me that these concerns have been
> considered and deemed moot.
Apache does it with Apache 1.3 and Apache 2.0. Jakarta should be able to do
the same too with Tomcat.
I don't know a lot about marketting, it's not my job, but the trend seems to
be towards releasing products with the same name, but with higher version
number. Since the two products perform similar functions, I think it would
be a mistake to have two different names.
> If there's an old thread where this was hashed out, please point me to
> it (perhaps by date, so I can narrow my search of the archives).
Remy
Catalina 1.0 vs. Tomcat 4.0
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
On Wed, Aug 09, 2000 at 11:30:50PM -0700, James Duncan Davidson wrote:
> on 8/8/00 11:04 PM, Craig R. McClanahan at Craig.McClanahan@eng.sun.com
> wrote:
>
> > * Proposal for creation of a new CVS repository module
> > named "jakarta-tomcat-4.0", and renaming the current
> > CVS repository module from "jakarta-tomcat" to
> > "jakarta-tomcat-3.0".
>
> +1 on new development happening in jakarta-tomcat-4.0 (as CVS branches are
> nice, but not nice enough when it comes to turning code upside down and
> inside out.. :)
I don't want to open old wounds, but I thought I'd just explain my
tardy -1 (or -0 if I'm the only one) on renaming Catalina to Tomcat
4.0.
The mandate of the Jakarta Project is to produce a servlet container
that implements version X of the servlet and JSP specs. There's no
mandate for this container to always be named Tomcat.
Fact: Catalina is (as everyone knows) a 99% different code base (I
think the connectors will be reused, and some of the utility classes).
Fact: Tomcat has a long history of being improved, bugs fixed,
robustness tested on thousands of platforms, tweaks and custom
features added; it will be a long time until Catalina has this level
of maturity.
Fact: Even once it does, there may be people who want to use custom
patches/Interceptors/etc., and will require support for their existing
Tomcat 3.x installs, and will most likely keep coming up with patches
for Tomcat 3.x.
Fact: many sites have customized the server.xml config file; as I
understand it, there will not be backwards compatibility for all
(any?) aspects of Tomcat's server.xml in Catalina (though I may be
wrong here).
Fact: Tomcat 3.x will soon support the new specs too, via Facades.
Fact: Catalina has many advantages too, and I trust Craig et al.'s
faith in the new design and code.
Speculation: If Catalina is released as Tomcat 4.0, then we will end
up with two separate products, with separate development efforts,
separate code bases, and unfortunately and confusingly, the same name,
leading to misunderstandings across the board. E.g., if a security
hole or performance problem is discovered in one, then the reputation
of the other will suffer.
Proposal: that Catalina keep its name, and be designed for release as
Catalina 1.0, and we make it as clear as we can, on the web site and
in the docs and announcements, that Catalina is the recommended
container, and is where most new development will occur.
The only disadvantage I can see is that people will constantly ask,
"Which one should I use, Catalina or Tomcat," but this FAQ can be
answered clearly in big bold letters on both the Tomcat and Catalina
home pages and anywhere else that's appropriate.
I know that the change in name has already happened, and I apologize
for being on holiday when this thread was launched, but I'd like at
least a token attempt to convince me that these concerns have been
considered and deemed moot.
If there's an old thread where this was hashed out, please point me to
it (perhaps by date, so I can narrow my search of the archives).
Thanks for your indulgence -
- Alex
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: [PROPOSALS] Three Proposals for Development of Tomcat 4.0
Posted by "Pier P. Fumagalli" <pi...@apache.org>.
James Duncan Davidson wrote:
>
> +/-0 on renaming jakarta-tomcat to jakarta-tomcat-3.0. This rename would
> break a lot of people's buildscripts and existing checked out bases. ie -
> everyone here either a) agrees on a time to have everything checked in so
> that they can dispose of their checked out copies and move to the new name
> or b) have to do fun CVS/* directory mucking.
that was my idea... in my ideal world i would like to see everything
following the same pattern, so since 4.0 had the version number in the
repository, also 3.0 should, to be symmetrical... :)
it's not a big deal though :)
> +1 -- in fact, I'd go further and do jakarta-jasper-x.x and help the
> separation and modularity along even more. But that's just me. :)
way cool... another cvs module for JSPs would be _really_ nice to have,
so people like me and Jon would not even have to see the sources :) :)
:)
> +1 -- as long as you guys are comfy with the new code base, I'm ok with you
> moving on from that code base that I started way back when the Tomcat team
> was a team of 1 sitting in my office.. :)
I saw the first sources of -your- codebase... Those were nice :) (Thank
god Java can be soo easily decompiled!), but patch after patch it got
worse, like -my- mod-jserv (geez guys it was so nice back in the
days!)...
Pier :)
Re: [PROPOSALS] Three Proposals for Development of Tomcat 4.0
Posted by James Duncan Davidson <du...@x180.com>.
on 8/8/00 11:04 PM, Craig R. McClanahan at Craig.McClanahan@eng.sun.com
wrote:
> * Proposal for creation of a new CVS repository module
> named "jakarta-tomcat-4.0", and renaming the current
> CVS repository module from "jakarta-tomcat" to
> "jakarta-tomcat-3.0".
+1 on new development happening in jakarta-tomcat-4.0 (as CVS branches are
nice, but not nice enough when it comes to turning code upside down and
inside out.. :)
+/-0 on renaming jakarta-tomcat to jakarta-tomcat-3.0. This rename would
break a lot of people's buildscripts and existing checked out bases. ie -
everyone here either a) agrees on a time to have everything checked in so
that they can dispose of their checked out copies and move to the new name
or b) have to do fun CVS/* directory mucking.
To be clear -- as long as people are aware of the inconvenence of swapping
the names, I have no opposal.
> * Proposal for re-architecting the Jasper JSP compiler
> to deal with feature enhancements that will be required
> by JSP 1.2, and to agree upon a set of development goals.
+1 -- in fact, I'd go further and do jakarta-jasper-x.x and help the
separation and modularity along even more. But that's just me. :)
> * Proposal to adopt the Catalina code base as the servlet
> container code for Tomcat 4.0.
+1 -- as long as you guys are comfy with the new code base, I'm ok with you
moving on from that code base that I started way back when the Tomcat team
was a team of 1 sitting in my office.. :)
.duncan
Re: [PROPOSALS] Three Proposals for Development of Tomcat 4.0
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/8/2000 11:04 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:
> Please review these proposals and feel free to comment (and vote) on
> them on the TOMCAT-DEV mailling list. There is certainly nothing cast
> in concrete at this point, although we should intend to make final
> decisions on these proposals in fairly short order.
>
> Craig McClanahan
I'm totally late on this proposal...but I +1 it all.
-jon