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/11/28 02:00:36 UTC
[VOTE] Tomcat 3.2 Final Release (!) and Ongoing Maintenance Plan
Dear TOMCAT-DEV folks,
Well, it appears that we successfully licked a large number of the problems with
3.2-beta-8, without introducing any serious new regressions. Therefore, I'd
like to ask that we vote on the following three propositions:
(1) Build and release Tomcat 3.2 final on Wednesday 11/29/2000
There are some known outstanding issues (documented in the release notes), plus
some remaining work to be done on the AJP13 connector -- but in my option these
can be dealt with successfully in a maintenance cycle that is proposed below.
The current code base appears to be stable enough for production use in large
numbers of environments, and is *substantially* improved in quality and
performance over Tomcat 3.1.
Therefore, I propose that we cut a final release of Tomcat 3.2 on Wednesday
night, and publish it for the world to grab. It will be based on the current
state of the "tomcat_32" branch -- on which there have been only a couple of low
risk and documentation oriented updates since 3.2b8.
(2) Ongoing Support Plan for Tomcat 3.2
Even though we will finish the initial release cycle for Tomcat 3.2 (finally :-)
if the previous proposal is accepted, we will not really be through with it.
Many environments have adopted beta versions of Tomcat 3.2 with the anticipation
that it will continue to be supported. What these folks need is quick
turnaround on bugs that are discovered after the 3.2 final release, and/or when
outstanding issues that are already known are resolved.
Therefore, I propose that we begin accepting and processing patches to the
existing code base (i.e. the "tomcat_32" branch), and produce maintenance
releases of this version (3.2.1, 3.2.2, and so on) as appropriate. Such fixes
will be minimal risk bug fixes to the existing code -- not new features. As
such, this proposal is completely independent of any major development efforts
on any other code base.
(3) Release Manager for Tomcat 3.2.x Maintenance Releases
In order to ensure that the ball doesn't get dropped (again :-) on 3.2, we need
to ensure that a release manager has been identified who has the time to test
and integrate new patches, and create timely releases, in accordance to the
ongoing support plan identified in the previous proposal.
I am willing to continue this role for the 3.2.x code series (at least for a
couple of releases), but would happily assist any other committer who wished to
gain the thanks of the Tomcat 3.2 user community for taking on this important
task. (NOTE: I will be involved in bug fixes for 3.2.x even if I'm not the
release manager.)
A +1 vote on this says "I'm fine with Craig continuing this role." A -1 is
likely to lead to you getting nominated to take my place :-). Any other
volunteers, please feel free to speak up!
Please respond with your votes on these three proposals by 5pm Pacific TIme on
Wednesday, November 29, 2000.
Thanks!
Craig McClanahan
Re: [VOTE] Tomcat 3.2 Final Release (!) and Ongoing Maintenance Plan
Posted by Hari <ha...@kumaran.com>.
(1) +1
(2) +1
(3) +1
Hari.
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <to...@jakarta.apache.org>
Sent: Tuesday, November 28, 2000 6:30 AM
Subject: [VOTE] Tomcat 3.2 Final Release (!) and Ongoing Maintenance Plan
> Dear TOMCAT-DEV folks,
>
> Well, it appears that we successfully licked a large number of the
problems with
> 3.2-beta-8, without introducing any serious new regressions. Therefore,
I'd
> like to ask that we vote on the following three propositions:
>
>
> (1) Build and release Tomcat 3.2 final on Wednesday 11/29/2000
>
> There are some known outstanding issues (documented in the release notes),
plus
> some remaining work to be done on the AJP13 connector -- but in my option
these
> can be dealt with successfully in a maintenance cycle that is proposed
below.
> The current code base appears to be stable enough for production use in
large
> numbers of environments, and is *substantially* improved in quality and
> performance over Tomcat 3.1.
>
> Therefore, I propose that we cut a final release of Tomcat 3.2 on
Wednesday
> night, and publish it for the world to grab. It will be based on the
current
> state of the "tomcat_32" branch -- on which there have been only a couple
of low
> risk and documentation oriented updates since 3.2b8.
>
>
> (2) Ongoing Support Plan for Tomcat 3.2
>
> Even though we will finish the initial release cycle for Tomcat 3.2
(finally :-)
> if the previous proposal is accepted, we will not really be through with
it.
> Many environments have adopted beta versions of Tomcat 3.2 with the
anticipation
> that it will continue to be supported. What these folks need is quick
> turnaround on bugs that are discovered after the 3.2 final release, and/or
when
> outstanding issues that are already known are resolved.
>
> Therefore, I propose that we begin accepting and processing patches to the
> existing code base (i.e. the "tomcat_32" branch), and produce maintenance
> releases of this version (3.2.1, 3.2.2, and so on) as appropriate. Such
fixes
> will be minimal risk bug fixes to the existing code -- not new features.
As
> such, this proposal is completely independent of any major development
efforts
> on any other code base.
>
>
> (3) Release Manager for Tomcat 3.2.x Maintenance Releases
>
> In order to ensure that the ball doesn't get dropped (again :-) on 3.2, we
need
> to ensure that a release manager has been identified who has the time to
test
> and integrate new patches, and create timely releases, in accordance to
the
> ongoing support plan identified in the previous proposal.
>
> I am willing to continue this role for the 3.2.x code series (at least for
a
> couple of releases), but would happily assist any other committer who
wished to
> gain the thanks of the Tomcat 3.2 user community for taking on this
important
> task. (NOTE: I will be involved in bug fixes for 3.2.x even if I'm not
the
> release manager.)
>
> A +1 vote on this says "I'm fine with Craig continuing this role." A -1
is
> likely to lead to you getting nominated to take my place :-). Any other
> volunteers, please feel free to speak up!
>
>
> Please respond with your votes on these three proposals by 5pm Pacific
TIme on
> Wednesday, November 29, 2000.
>
> Thanks!
>
> Craig McClanahan
>
>
>
Re: [VOTE] Tomcat 3.2 Final Release (!) and Ongoing Maintenance Plan
Posted by Pierre Delisle <pi...@sun.com>.
> (1) Build and release Tomcat 3.2 final on Wednesday 11/29/2000
+1
> (2) Ongoing Support Plan for Tomcat 3.2
+1
> (3) Release Manager for Tomcat 3.2.x Maintenance Releases
+1
-- Pierre
Re: [VOTE] Tomcat 3.2 Final Release (!) and Ongoing Maintenance Plan
Posted by Remy Maucherat <re...@apache.org>.
> Dear TOMCAT-DEV folks,
>
> Well, it appears that we successfully licked a large number of the
problems with
> 3.2-beta-8, without introducing any serious new regressions. Therefore,
I'd
> like to ask that we vote on the following three propositions:
>
>
> (1) Build and release Tomcat 3.2 final on Wednesday 11/29/2000
+1
> (2) Ongoing Support Plan for Tomcat 3.2
+1
> (3) Release Manager for Tomcat 3.2.x Maintenance Releases
>
> A +1 vote on this says "I'm fine with Craig continuing this role." A -1
is
> likely to lead to you getting nominated to take my place :-).
+1 (easy choice here)
Remy
Re: [VOTE] Tomcat 3.2 Final Release (!) and Ongoing Maintenance Plan
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Pierre Delisle" <pi...@sun.com>
> The JSP spec is quite clear on the subject:
>
> "The only types of properties that can be assigned to from String
> constants and request parameter values are those listed in TABLE 2-4; the
conversion applied
> is that shown in the table. Request-time expressions can be assigned to
properties of any
> type; no automatic conversions will be performed."
>
> boolean or Boolean As indicated in java.lang.Boolean.valueOf(String)
> byte or Byte As indicated in java.lang.Byte.valueOf(String)
> char or Character As indicated in java.lang.Character.valueOf(String)1
> double or Double As indicated in java.lang.Double.valueOf(String)
> int or Integer As indicated in java.lang.Integer.valueOf(String)
> float or Float As indicated in java.lang.Float.valueOf(String)
> long or Long As indicated in java.lang.Long.valueOf(String)
>
> [Please note that short/Short is missing from the list].
>
> We had a discussion on the topic sometimes this summer (if you look at
> the archives). Also seems to me that this would make sense.
I've tried to search the list archive (the search message feature is down,
so I had to manually search the subjects for "tag"), and I found the
discussion you had with Arun Re: Spec Q/TagBeginGenerator behavior. He
layed out the same issue, and your response was that you would forward it to
the JSP spec group. I can't find any resolution message.
<ornery>
Anyway, it seems you've made your mind or received work from the JSP spec
group and I can't find the response.
Consider this one point though... I'm reading over the JLS as to what
exactly a "conversion" is... I'm probably misreading this, but it seems to
say that passing the String constant to the String setter method involves
the "identity" conversion and passing the String constant to the Object
setter method is a "widening reference" conversion. (a note about widening
conventions: "Such conversions never require a special action at run time
and therefore never throw an exception at run time.") Given TABLE 2-4 does
not list either how to handle String's identity or Object's widening
conversion to the Object setter method, why support one but not the other?
</ornery>
> Let me try to ping the spec lead on this to see if we could get
> final resolution.
Thanks very much appreciated (please take my orneriness as amusement if
nothing else). I'll harass Eduardo as well if it will help.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
Re: [VOTE] Tomcat 3.2 Final Release (!) and Ongoing Maintenance Plan
Posted by Pierre Delisle <pi...@sun.com>.
The JSP spec is quite clear on the subject:
"The only types of properties that can be assigned to from String
constants and request parameter values are those listed in TABLE 2-4; the conversion applied
is that shown in the table. Request-time expressions can be assigned to properties of any
type; no automatic conversions will be performed."
boolean or Boolean As indicated in java.lang.Boolean.valueOf(String)
byte or Byte As indicated in java.lang.Byte.valueOf(String)
char or Character As indicated in java.lang.Character.valueOf(String)1
double or Double As indicated in java.lang.Double.valueOf(String)
int or Integer As indicated in java.lang.Integer.valueOf(String)
float or Float As indicated in java.lang.Float.valueOf(String)
long or Long As indicated in java.lang.Long.valueOf(String)
[Please note that short/Short is missing from the list].
We had a discussion on the topic sometimes this summer (if you look at
the archives). Also seems to me that this would make sense.
Let me try to ping the spec lead on this to see if we could get
final resolution.
-- Pierre
Serge Knystautas wrote:
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <Cr...@eng.sun.com>
> > Well, it appears that we successfully licked a large number of the
> problems with
> > 3.2-beta-8, without introducing any serious new regressions. Therefore,
> I'd
> > like to ask that we vote on the following three propositions:
> >
> > (1) Build and release Tomcat 3.2 final on Wednesday 11/29/2000
>
> I'd like to request that a minor patch be applied to Tomcat 3.2 so that it
> can fully support tags with object properties. The patch to
> org.apache.jasper.compiler.TagBeginGenerator on 7/12/2000 on the tomcat_32
> branch disabled this capability (yes, I should have caught this sooner but
> didn't start using the 3.2 branch until about a month ago). This was done
> in preparation for the JSP 1.2 spec, and while I think this is a good
> direction, nobody got the chance to finish it.
>
> To summarize the behavior, if you have a tag with an object property and in
> your TLD rtexprvalue is set to true, you cannot pass it a static string. In
> Tomcat 3.1 and Tomcat 3.2 prior to 7/12/2000, the setter method for the
> Object property would be called passing the static String value. In JSP 1.2
> (so I would assume Tomcat 4.0 and Tomcat 3.X once JSP 1.2 support is added),
> the specification is more complete and specifies the use of
> BeanInfo/PropertyEditor and the setAsText method, and once this is
> implemented, we can have tags with object properties. However as of right
> now, Tomcat 3.2 does not support passing static Strings to Object properties
> on tags.
>
> In the interest of not delaying Tomcat 3.2's release, I would suggest the
> diff included below be applied and included into Tomcat 3.2. It passes the
> static String to the Object property using the setter method. While this
> means tag writers could develop tags that would not comply with the JSP 1.2
> spec, I believe this is acceptable as 1) there is clear direction as to how
> to make their tags JSP 1.2 compliant and 2) Tomcat 3.2 is not a JSP 1.2
> environment. The disadvantage to not doing this is that tags writers have
> no way to support receiving static Strings to their tags' Object properties.
> Instead page writers would have to use the workaround Craig (I believe)
> suggested in every JSP (attr='<%="value"%>').
>
> Thanks for hearing me out. I know I can just apply my own patch and build
> my own instance of Tomcat 3.2, but this seems like an important part of the
> spec to consider, especially as custom tags are gradually becoming a more
> important component of JSPs.
>
> Serge Knystautas
> Loki Technologies
> http://www.lokitech.com/
>
> cvs diff TagBeginGenerator.java (in directory
> C:\DEV\cvs-apache\jakarta-tomcat\src\share\org\apache\jasper\compiler\)
> Index: TagBeginGenerator.java
> ===================================================================
> RCS file:
> /home/cvspublic/jakarta-tomcat/src/share/org/apache/jasper/compiler/TagBegin
> Generator.java,v
> retrieving revision 1.14.2.2
> diff -r1.14.2.2 TagBeginGenerator.java
> 223a224,225
> > } else if (c == Object.class) {
> > return writer.quoteString(s);
>
> *****CVS exited normally with code 1*****
Re: [VOTE] Tomcat 3.2 Final Release (!) and Ongoing Maintenance Plan
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
> Well, it appears that we successfully licked a large number of the
problems with
> 3.2-beta-8, without introducing any serious new regressions. Therefore,
I'd
> like to ask that we vote on the following three propositions:
>
> (1) Build and release Tomcat 3.2 final on Wednesday 11/29/2000
I'd like to request that a minor patch be applied to Tomcat 3.2 so that it
can fully support tags with object properties. The patch to
org.apache.jasper.compiler.TagBeginGenerator on 7/12/2000 on the tomcat_32
branch disabled this capability (yes, I should have caught this sooner but
didn't start using the 3.2 branch until about a month ago). This was done
in preparation for the JSP 1.2 spec, and while I think this is a good
direction, nobody got the chance to finish it.
To summarize the behavior, if you have a tag with an object property and in
your TLD rtexprvalue is set to true, you cannot pass it a static string. In
Tomcat 3.1 and Tomcat 3.2 prior to 7/12/2000, the setter method for the
Object property would be called passing the static String value. In JSP 1.2
(so I would assume Tomcat 4.0 and Tomcat 3.X once JSP 1.2 support is added),
the specification is more complete and specifies the use of
BeanInfo/PropertyEditor and the setAsText method, and once this is
implemented, we can have tags with object properties. However as of right
now, Tomcat 3.2 does not support passing static Strings to Object properties
on tags.
In the interest of not delaying Tomcat 3.2's release, I would suggest the
diff included below be applied and included into Tomcat 3.2. It passes the
static String to the Object property using the setter method. While this
means tag writers could develop tags that would not comply with the JSP 1.2
spec, I believe this is acceptable as 1) there is clear direction as to how
to make their tags JSP 1.2 compliant and 2) Tomcat 3.2 is not a JSP 1.2
environment. The disadvantage to not doing this is that tags writers have
no way to support receiving static Strings to their tags' Object properties.
Instead page writers would have to use the workaround Craig (I believe)
suggested in every JSP (attr='<%="value"%>').
Thanks for hearing me out. I know I can just apply my own patch and build
my own instance of Tomcat 3.2, but this seems like an important part of the
spec to consider, especially as custom tags are gradually becoming a more
important component of JSPs.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
cvs diff TagBeginGenerator.java (in directory
C:\DEV\cvs-apache\jakarta-tomcat\src\share\org\apache\jasper\compiler\)
Index: TagBeginGenerator.java
===================================================================
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/jasper/compiler/TagBegin
Generator.java,v
retrieving revision 1.14.2.2
diff -r1.14.2.2 TagBeginGenerator.java
223a224,225
> } else if (c == Object.class) {
> return writer.quoteString(s);
*****CVS exited normally with code 1*****
Re: [VOTE] Tomcat 3.2 Final Release (!) and Ongoing Maintenance Plan
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
"Craig R. McClanahan" wrote:
>
> Dear TOMCAT-DEV folks,
>
> Well, it appears that we successfully licked a large number of the problems with
> 3.2-beta-8, without introducing any serious new regressions. Therefore, I'd
> like to ask that we vote on the following three propositions:
>
> (1) Build and release Tomcat 3.2 final on Wednesday 11/29/2000
> [...]
+1
> (2) Ongoing Support Plan for Tomcat 3.2
> [...]
+1
> (3) Release Manager for Tomcat 3.2.x Maintenance Releases
> [...]
+1
Thanks to everyone involved for finally getting Tomcat 3.2 ready for
release!
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: [VOTE] Tomcat 3.2 Final Release (!) and Ongoing Maintenance Plan
Posted by cm...@yahoo.com.
> (1) Build and release Tomcat 3.2 final on Wednesday 11/29/2000
+1
> (2) Ongoing Support Plan for Tomcat 3.2
+1 ( until 3.3 is released and we'll switch to 3.3.1, etc)
In 3.3 the core will be finally finished in most aspects, and almost all
functionality will be part of replaceable modules. Given the recent vote
on not supporting Servlet 2.3 in the apache release, and the fact that
modules can have an indepenent lifecycle - we'll need to figure a
different naming scheme and mechanisms for post-3.3 releases.
My proposal would be to move all non-essential modules in a separate
directory and build module sub-releases. ( that means 3.3.0 will be only
the core plus a minimal set of modules, and each module/module set can
have it's own life - including tc33-facade23-1.0 and other modules
distributed outside Apache )
> (3) Release Manager for Tomcat 3.2.x Maintenance Releases
A big +1 :-)
Costin