You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2004/03/23 00:53:50 UTC
[5.0.20] New build
The new build is now available (a bit late, but with additional fixes).
Thanks for the help with the license transition and the bugfixing.
http://www.apache.org/dist/jakarta/tomcat-5/v5.0.20-alpha/
This has no JMX and no Windows installer.
The build may not be very useful except for basic regression testing,
despite a number of good fixes :(
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.20] New build
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> I'm guessing that tomcat(w).exe are the old ones from 5.0.19?
It's whatever is in CVS. So here it's the same as for 5.0.19 (which
AFAIK didn't have major issues).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.20] New build
Posted by Bill Barker <wb...@wilshire.com>.
I'm guessing that tomcat(w).exe are the old ones from 5.0.19?
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Monday, March 22, 2004 3:53 PM
Subject: [5.0.20] New build
The new build is now available (a bit late, but with additional fixes).
Thanks for the help with the license transition and the bugfixing.
http://www.apache.org/dist/jakarta/tomcat-5/v5.0.20-alpha/
This has no JMX and no Windows installer.
The build may not be very useful except for basic regression testing,
despite a number of good fixes :(
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 2.0.4 tagged
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> jk2 2.0.4 has been tagged.
>
> jk2_2_0_4
>
> We're now in HEAD at 2.0.5-dev
Congratulations :)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: jk2 2.0.4 tagged
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez
> >
> > http://jakarta.apache.org/~hgomez/
>
Sources shoud be put and signed in the:
/x1/www/www.apache.org/dist/jakarta/tomcat-connectors/jk2/source
You may change the README.html too.
Also in the root of jk2 there are some current sources that IMO should be
removed (they are not mirroded thought).
> Hi to all,
>
> What's the status of the various binaries ?
>
> I've done the Fedora 1, Suse 9.0 and Suse SLES 8.0 (PPC) and
> I'm waiting for others bins (Mladen, Kurt, Mike ?)
>
I'm waiting for the oficial sources.
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 2.0.4 tagged
Posted by Henri Gomez <hg...@apache.org>.
I upload jk 2.0.4 source to official location :
http://www.apache.org/dist/jakarta/tomcat-connectors/jk2/
BTW, Did there is a candidate here for a MacOS/X build ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 2.0.4 tagged
Posted by Kurt Miller <tr...@apache.org>.
From: "Henri Gomez" <hg...@apache.org>
> Henri Gomez wrote:
>
> > Jess Holle wrote:
> >
> >> Is there a source tarball for 2.0.4 available for download somewhere yet?
> >>
> >> --
> >> Jess Holle
> >>
> >> Henri Gomez wrote:
> >>
> >>> jk2 2.0.4 has been tagged.
> >>>
> >>> jk2_2_0_4
> >>>
> >>> We're now in HEAD at 2.0.5-dev
> >
> >
> > yes :
> >
> > http://jakarta.apache.org/~hgomez/
>
> Hi to all,
>
> What's the status of the various binaries ?
>
> I've done the Fedora 1, Suse 9.0 and Suse SLES 8.0 (PPC)
> and I'm waiting for others bins (Mladen, Kurt, Mike ?)
>
> Regards
I'm working on updating the FreeBSD port of www/mod_jk2.
Previously it was building mod_jk for apache2 which is quite
misleading (being called mod_jk2 and all). The www/mod_jk
port builds mod_jk for either apache13 or apache2 anyway.
I should be done with it shortly.
Thanks for fixing the name of the tarball. Could I ask you to
make another change? The tarball extracts into a directory
name that doesn't match the tarball name ( missing the jk2
again ). Could you recreate the tarball with the directory name
jakarta-tomcat-connectors-jk2-2.0.4-src? The *BSD porting
schemes assume the source tarball extracts into a dir name that
matches the tarball name (can be overridden if necessary).
For OpenBSD 3.4 it shipped with tomcat 4.0.6, so I'll skip the
binary for that and make one for 3.5 when its available.
Thanks,
-Kurt
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 2.0.4 tagged
Posted by Kurt Miller <tr...@apache.org>.
From: "Henri Gomez" <hg...@apache.org>
> Henri Gomez wrote:
>
> > Jess Holle wrote:
> >
> >> Is there a source tarball for 2.0.4 available for download somewhere yet?
> >>
> >> --
> >> Jess Holle
> >>
> >> Henri Gomez wrote:
> >>
> >>> jk2 2.0.4 has been tagged.
> >>>
> >>> jk2_2_0_4
> >>>
> >>> We're now in HEAD at 2.0.5-dev
> >
> >
> > yes :
> >
> > http://jakarta.apache.org/~hgomez/
>
> Hi to all,
>
> What's the status of the various binaries ?
>
> I've done the Fedora 1, Suse 9.0 and Suse SLES 8.0 (PPC)
> and I'm waiting for others bins (Mladen, Kurt, Mike ?)
>
Packages for FreeBSD 4.9 and the port that I used to create
them are available at:
http://jakarta.apache.org/~truk/
Mladen you may want to use the port I created for FreeBSD 5
for consistency. One item to note, you will need to set
WITH_APACHE2=YES in your environment to get the package
depends to work right for apache2.
I followed Guenter's proposed structure with adjustment for the OS
directory conventions and some file additions. We must include
LICENSE and NOTICE files. I added the docs in jk/docs/ too.
-Kurt
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 2.0.4 tagged
Posted by Henri Gomez <hg...@apache.org>.
Henri Gomez wrote:
> Jess Holle wrote:
>
>> Is there a source tarball for 2.0.4 available for download somewhere yet?
>>
>> --
>> Jess Holle
>>
>> Henri Gomez wrote:
>>
>>> jk2 2.0.4 has been tagged.
>>>
>>> jk2_2_0_4
>>>
>>> We're now in HEAD at 2.0.5-dev
>
>
> yes :
>
> http://jakarta.apache.org/~hgomez/
Hi to all,
What's the status of the various binaries ?
I've done the Fedora 1, Suse 9.0 and Suse SLES 8.0 (PPC)
and I'm waiting for others bins (Mladen, Kurt, Mike ?)
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 2.0.4 tagged
Posted by Henri Gomez <hg...@apache.org>.
Jess Holle wrote:
> Is there a source tarball for 2.0.4 available for download somewhere yet?
>
> --
> Jess Holle
>
> Henri Gomez wrote:
>
>> jk2 2.0.4 has been tagged.
>>
>> jk2_2_0_4
>>
>> We're now in HEAD at 2.0.5-dev
yes :
http://jakarta.apache.org/~hgomez/
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 2.0.4 tagged
Posted by Jess Holle <je...@ptc.com>.
Is there a source tarball for 2.0.4 available for download somewhere yet?
--
Jess Holle
Henri Gomez wrote:
> jk2 2.0.4 has been tagged.
>
> jk2_2_0_4
>
> We're now in HEAD at 2.0.5-dev
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 2.0.4 tagged
Posted by Kurt Miller <tr...@apache.org>.
From: "Henri Gomez" <hg...@apache.org>
> Mladen Turk wrote:
>
> >
> >
> >
> >>-----Original Message-----
> >>From: Henri Gomez
> >>
> >>>Will you build the sources?
> >>>
> >>
> >>I'm preparing a source tarball, and will build Linux binaries
> >>for Fedora Core 1, Suse 9.0 and Suse SLES 8.0 (PPC).
> >>
> >>Others archs, are welcomed
> >>
> >
> >
> > Did we agreed on binary dist?
>
> I was thinking providing something very similar to the one
> in jk 1.2.5, but we could still discuss.
>
> > What's gonna be the dir layout and files included?
>
> Do you think at your proposal ? Why not
>
> > Can you write some guidelines?
>
> The one proposed by Guenter ?
>
> ./apache2
> /conf
> /workers2.properties.minimal
> /mod_jk2.conf
> /modules
> /mod_jk2.dll|nlm|so
> /ver-info
> /mod_jk2
> /README
> /CHANGES
> /STATUS
> /INSTALL
>
We should add LICENCE to the above list of files in /ver-info.
I will do packages for OpenBSD/i386 3.4 and FreeBSD 4.9.
I'd like to use the ports/package conventions of these OS's instead
of the above directory structure. In general do we need one
directory layout for all OS's?
>
> > I'll build all the WIN32 executables, and can do FreeBSD 5.2.1 package.
>
> Thanks
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 2.0.4 tagged
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Henri Gomez
>>
>>>Will you build the sources?
>>>
>>
>>I'm preparing a source tarball, and will build Linux binaries
>>for Fedora Core 1, Suse 9.0 and Suse SLES 8.0 (PPC).
>>
>>Others archs, are welcomed
>>
>
>
> Did we agreed on binary dist?
I was thinking providing something very similar to the one
in jk 1.2.5, but we could still discuss.
> What's gonna be the dir layout and files included?
Do you think at your proposal ? Why not
> Can you write some guidelines?
The one proposed by Guenter ?
./apache2
/conf
/workers2.properties.minimal
/mod_jk2.conf
/modules
/mod_jk2.dll|nlm|so
/ver-info
/mod_jk2
/README
/CHANGES
/STATUS
/INSTALL
> I'll build all the WIN32 executables, and can do FreeBSD 5.2.1 package.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: jk2 2.0.4 tagged
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez
> >
> > Will you build the sources?
> >
>
> I'm preparing a source tarball, and will build Linux binaries
> for Fedora Core 1, Suse 9.0 and Suse SLES 8.0 (PPC).
>
> Others archs, are welcomed
>
Did we agreed on binary dist?
What's gonna be the dir layout and files included?
Can you write some guidelines?
I'll build all the WIN32 executables, and can do FreeBSD 5.2.1 package.
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 2.0.4 tagged
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Henri Gomez [mailto:hgomez@apache.org]
>>Sent: Wednesday, March 24, 2004 2:41 PM
>>To: Tomcat Developers List
>>Subject: jk2 2.0.4 tagged
>>
>>jk2 2.0.4 has been tagged.
>>
>>jk2_2_0_4
>>
>>We're now in HEAD at 2.0.5-dev
>
>
> Cool :)
>
> Will you build the sources?
>
I'm preparing a source tarball, and will build Linux
binaries for Fedora Core 1, Suse 9.0 and Suse SLES 8.0 (PPC).
Others archs, are welcomed
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: jk2 2.0.4 tagged
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez [mailto:hgomez@apache.org]
> Sent: Wednesday, March 24, 2004 2:41 PM
> To: Tomcat Developers List
> Subject: jk2 2.0.4 tagged
>
> jk2 2.0.4 has been tagged.
>
> jk2_2_0_4
>
> We're now in HEAD at 2.0.5-dev
Cool :)
Will you build the sources?
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
jk2 2.0.4 tagged
Posted by Henri Gomez <hg...@apache.org>.
jk2 2.0.4 has been tagged.
jk2_2_0_4
We're now in HEAD at 2.0.5-dev
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 2.0.4 to be tagged soon
Posted by Henri Gomez <hg...@apache.org>.
I've got no report or showstopper which prevent me to
tag jk2 2.0.4.
I'll tag it later this afternoon (CET) and prepare the
source tarball.
Thanks to stop commit on jk2 native
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
jk2 2.0.4 to be tagged soon
Posted by Henri Gomez <hg...@apache.org>.
Hi to all,
I plan to tag jk2 2.0.4 tomorrow.
Did any of you see new things to add, or should we consider the
current HEAD without any showstopper ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.20] New build
Posted by Jess Holle <je...@ptc.com>.
As these are part of a shipping commercial product, I do not believe I
can do so without traversing a significant legal morasse.
At a high level they started as simple enough ventures which replace
configuration files with tokenized (e.g. @@varName@@) versions and then
do replace operations and set permissions appropriately on UNIX. At
that level they directly mimic the Apache web server's binary
distribution install scripts, but work on UNIX and Windows alike.
As time has passed these have grown to allow automated installation of
somewhat sophisticated web app configurations in Apache with
authenticated and anonymous sub-regions of the web apps and
configuration update/regeneration when a new option is added to the
configuration. The scripts also support installation as Windows
services, creation and installation of self-signed certificates, etc.
All of this has been just enough for our application's needs, but none
of it is specific to them.
--
Jess Holle
Tim Stewart wrote:
>Hey Jess,
>
>I would be interested in seeing your ant scripts to configure tomcat and
>apache. Would you mind posting a URL or sending them to me?
>
>Thanks,
>Tim
>----- Original Message -----
>From: "Jess Holle" <je...@ptc.com>
>To: "Tomcat Developers List" <to...@jakarta.apache.org>
>Sent: Tuesday, March 23, 2004 9:10 AM
>Subject: Re: [5.0.20] New build
>
>
>
>
>>Remy Maucherat wrote:
>>
>>
>>
>>>Jess Holle wrote:
>>>
>>>
>>>
>>>>One area of immediate concern: Is jmx.jar an additional top-level jar
>>>>that must be added to CLASSPATH or java command lines to run Tomcat?
>>>>Or is it automatically picked up by Bootstrap, etc, as before? [This
>>>>will clearly affect a number automated configurations if this has
>>>>indeed changed.]
>>>>
>>>>
>>>It's in the manifest of the bootstrap.jar. The change is because the
>>>bootstrap needs to register the classloaders so that Tomcat is fully
>>>configurable and remotely "embeddable" through JMX.
>>>
>>>
>>Ah. So this part of the change is not due to the licensing snafus.
>>That's good to know.
>>
>>
>>
>>>Of course, Tomcat will run out of the box on JDK 1.5.
>>>
>>>
>>As is this.
>>
>>Thanks again.
>>
>>--
>>Jess Holle
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
>
Re: [5.0.20] New build
Posted by Tim Stewart <ti...@logoworks.com>.
Hey Jess,
I would be interested in seeing your ant scripts to configure tomcat and
apache. Would you mind posting a URL or sending them to me?
Thanks,
Tim
----- Original Message -----
From: "Jess Holle" <je...@ptc.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Tuesday, March 23, 2004 9:10 AM
Subject: Re: [5.0.20] New build
> Remy Maucherat wrote:
>
> > Jess Holle wrote:
> >
> >> One area of immediate concern: Is jmx.jar an additional top-level jar
> >> that must be added to CLASSPATH or java command lines to run Tomcat?
> >> Or is it automatically picked up by Bootstrap, etc, as before? [This
> >> will clearly affect a number automated configurations if this has
> >> indeed changed.]
> >
> > It's in the manifest of the bootstrap.jar. The change is because the
> > bootstrap needs to register the classloaders so that Tomcat is fully
> > configurable and remotely "embeddable" through JMX.
>
> Ah. So this part of the change is not due to the licensing snafus.
> That's good to know.
>
> > Of course, Tomcat will run out of the box on JDK 1.5.
>
> As is this.
>
> Thanks again.
>
> --
> Jess Holle
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.20] New build
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Jess Holle wrote:
>
>> One area of immediate concern: Is jmx.jar an additional top-level jar
>> that must be added to CLASSPATH or java command lines to run Tomcat?
>> Or is it automatically picked up by Bootstrap, etc, as before? [This
>> will clearly affect a number automated configurations if this has
>> indeed changed.]
>
> It's in the manifest of the bootstrap.jar. The change is because the
> bootstrap needs to register the classloaders so that Tomcat is fully
> configurable and remotely "embeddable" through JMX.
Ah. So this part of the change is not due to the licensing snafus.
That's good to know.
> Of course, Tomcat will run out of the box on JDK 1.5.
As is this.
Thanks again.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.20] New build
Posted by Remy Maucherat <re...@apache.org>.
Jess Holle wrote:
> I concur that this is the normal expectation and that the Tomcat group
> should pressure the board to ease up.
>
> If they don't I might suggest:
>
> * A simple Ant-based configuration tool.
> o That grabs jmx.jar from the web as part of the configuration.
>
> I use Ant to configure Apache and Tomcat, but I must admit all
> components are bundled -- I don't assume a network connection over which
> to fetch them.
That's a possibility, but needs a network connection.
>>> So if I drop jmx.jar from 5.0.19 into 5.0.20's bin directory, what
>>> else is missing to have Tomcat 5.0.20 be every bit as good as 5.0.19
>>> but with more bug fixes?
>>
>>
>> Nothing. Other than the "not ready to run" effect, this should be a
>> good release (assuming there are no regressions).
>
>
> Thanks for the info.
>
> Once I get a chance I'll check this out.
>
> One area of immediate concern: Is jmx.jar an additional top-level jar
> that must be added to CLASSPATH or java command lines to run Tomcat? Or
> is it automatically picked up by Bootstrap, etc, as before? [This will
> clearly affect a number automated configurations if this has indeed
> changed.]
It's in the manifest of the bootstrap.jar. The change is because the
bootstrap needs to register the classloaders so that Tomcat is fully
configurable and remotely "embeddable" through JMX.
Of course, Tomcat will run out of the box on JDK 1.5.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.20] New build
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Jess Holle wrote:
>
>> Can you elaborate on "may not be very useful"?
>
> Generally, people expect to be able to run a binary out of the box.
I concur that this is the normal expectation and that the Tomcat group
should pressure the board to ease up.
If they don't I might suggest:
* A simple Ant-based configuration tool.
o That grabs jmx.jar from the web as part of the configuration.
I use Ant to configure Apache and Tomcat, but I must admit all
components are bundled -- I don't assume a network connection over which
to fetch them.
>> So if I drop jmx.jar from 5.0.19 into 5.0.20's bin directory, what
>> else is missing to have Tomcat 5.0.20 be every bit as good as 5.0.19
>> but with more bug fixes?
>
> Nothing. Other than the "not ready to run" effect, this should be a
> good release (assuming there are no regressions).
Thanks for the info.
Once I get a chance I'll check this out.
One area of immediate concern: Is jmx.jar an additional top-level jar
that must be added to CLASSPATH or java command lines to run Tomcat? Or
is it automatically picked up by Bootstrap, etc, as before? [This will
clearly affect a number automated configurations if this has indeed
changed.]
--
Jess Holle
Re: ETA for mod_jk 1.2.6 and mod_jk2 2.0.4
Posted by Henri Gomez <hg...@apache.org>.
Jess Holle wrote:
> It is my understanding mod_jk2 2.0.4 is due this week and that the plan
> is to release mod_jk 1.2.6 shortly thereafter.
>
> Is this still accurate?
>
> Any further light that can be shed on this (e.g. how long to expect to
> wait for 1.2.6) would be appreciated.
jk2 2.0.4 should be tagged tomorrow or on Thursday, tarball on Friday.
jk 1.2.6 as soon as Glenn could works on it.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
ETA for mod_jk 1.2.6 and mod_jk2 2.0.4
Posted by Jess Holle <je...@ptc.com>.
It is my understanding mod_jk2 2.0.4 is due this week and that the plan
is to release mod_jk 1.2.6 shortly thereafter.
Is this still accurate?
Any further light that can be shed on this (e.g. how long to expect to
wait for 1.2.6) would be appreciated.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.20] New build
Posted by Remy Maucherat <re...@apache.org>.
Jess Holle wrote:
> Can you elaborate on "may not be very useful"?
Generally, people expect to be able to run a binary out of the box.
> So if I drop jmx.jar from 5.0.19 into 5.0.20's bin directory, what else
> is missing to have Tomcat 5.0.20 be every bit as good as 5.0.19 but with
> more bug fixes?
Nothing. Other than the "not ready to run" effect, this should be a good
release (assuming there are no regressions).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.20] New build
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> The new build is now available (a bit late, but with additional fixes).
> Thanks for the help with the license transition and the bugfixing.
>
> http://www.apache.org/dist/jakarta/tomcat-5/v5.0.20-alpha/
>
> This has no JMX and no Windows installer.
> The build may not be very useful except for basic regression testing,
> despite a number of good fixes :(
Can you elaborate on "may not be very useful"?
I care nothing for the Windows installer as we produce our own installer
for our Tomcat distributions.
So if I drop jmx.jar from 5.0.19 into 5.0.20's bin directory, what else
is missing to have Tomcat 5.0.20 be every bit as good as 5.0.19 but with
more bug fixes?
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat 5.0.20 Issue
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Well, your pages are invalid. Really, I don't see what's so
> mysterious: anything used in useBean must be a JavaBean.
> This will not be fixed.
Did I miss something?
Are JavaBean default constructors required to succeed in any/all
environments?
Specifically are they required to succeed at compile time when none of
the runtime requirements they have are met?
This seems somewhat odd to say the least.
That said, I did not author any of the beans in question and could
certainly give the authors of said beans hell for their transgressions
*IF* I have sufficient proof that what they're doing is completely wrong.
Overall, however, the change in 5.0.20 still seems questionable -- at
least with respect to the many other details (e.g. that the default
causes new failures, that the compiler flag is not accessible via
JspC.main(), etc...)
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat 5.0.20 Issue
Posted by Remy Maucherat <re...@apache.org>.
Jess Holle wrote:
> Jess Holle wrote:
>
>> Works just great in quick testing at least.
>>
>> I'm still waiting for my precompilation script to return to determine
>> whether Jasper still compiles everything it used to (and should have).
>
>
> Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages
> (which Tomcat 5.0.19 compiled just fine).
>
> The issue can be traced directly to a single entry in the change log:
>
> Add some intellignece to the compiler for generating code for
> useBean action. Generate direct instantiation (use new) when
> possible, use bean.instantiate when bean name is specified, and for
> the case of invalid bean class, either issue a translation time
> error (instead of javac error), or generate codes to throw
> InstantiationException at runtime, depending on a new compiler
> switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman)
>
> There are several issues with this change:
>
> 1. The new logic assumes that the bean can be directly instantiated
> /at compile time/ and throws a page compilation error when this is
> not the case.
> * There are beans that can be directly instantiated at run
> time but not at compile time (e.g. upon precompilation).
> This was the case in all 6 of our failures. [Examples as to
> when this might occur include requirements for databases
> being accessible, other servers running, etc, etc, for
> successful bean instantiation.]
> * The error occurs in such a way that a partial Java source
> file is written, so later attempts to recompile the page
> (when the runtime environment is duplicated) also fail
> unless the partial Java source file is first deleted.
> 2. I note the errorOnUseBeanInvalidClassAttribute setting but there
> are issues here as well:
> * The default value, true, breaks existing code.
> * If errorOnUseBeanInvalidClassAttribute is set to false:
> o Instantiation of some (e.g. session or application
> scope) beans can be time and/or resource consuming.
> Besides being an invalid test as to whether a bean can
> be directly instantiated, instantiating such beans
> during compilation can be costly. [The combined time
> for precompiling all pages was longer in 5.0.20 with
> this behavior in place than when I removed it.]
> o The new behavior will cause beans to be instantiated
> via Beans.instantiate() rather than directly
> instantiated when compile time direct instantiation
> fails. This leads to a performance degradation
> whenever a bean has a runtime instantiation dependency.
> * As best I can tell, errorOnUseBeanInvalidClassAttribute is
> not accessible from / exposed via JspC main -- which I use
> from my pre-compilation scripts for various reasons.
>
> Due to these issues I have reverted this change in Generator to the
> 5.0.19 state (leaving the other valuable changes in this class intact).
> Once I did so all 985 JSP pages compiled -- including the 6 that had
> previously failed.
>
> I would urge that this change be reverted -- either in this release (or
> an immediate 5.0.21 release) or immediately changed in HEAD for the next
> release.
Well, your pages are invalid. Really, I don't see what's so mysterious:
anything used in useBean must be a JavaBean.
This will not be fixed.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat 5's service.bat, etc.
Posted by Jess Holle <je...@ptc.com>.
Bill Barker wrote:
>>The service.bat and tomcat.exe in Tomcat 5 have a number of issues as I
>>see it:
>>
>> 1. The new tomcat.exe (aka procrun) does not seem to reliably route
>> stdout and stderr to the specified files.
>> * Compare JavaService (aka Tomcat 4.1.x's tomcat.exe) stdout
>> and stderr treatment to procrun's. JavaService captures all
>> the startup stdout as well as System.out.println's, etc.
>> procrun does not.
>>
>>
>Procrun works fine with --Java=java. Yes, it needs work
>for --Java=c:\path\to\jvm.dll (known issue, with outstanding BZ entry :).
>
>
Hmmm....
--Java=pathToJvmDll did not work at all for me -- service failed to
install and other errors. [W2K with latest service packs and Java 2
v1.4.2_04.]
--Java=java worked but lost most of the stdout and stderr output --
including all the startup output. It did seem to start up faster than
JavaService...
>> 2. Tomcat 5 does not include any documentation on how to use procrun
>> (or even that tomcat.exe is procrun).
>> 3. I have not managed to get procrun to target the "server" JVM (as
>> opposed to the client) in any reliable fashion.
>> * With JavaService this was achieved by targeting the
>> appropriate jvm.dll. The procrun docs say the same thing is
>> possible, but this does not work.
>>
>>
>
>This works fine for me with either --Java=java -JavaOptions=-server#... or
>with --Java=c:\path\to\server\jvm.dll.
>
>
I was actually referring to the latter approach, which as I said did not
work for me.
I did not honestly trust the first approach -- I guess I should have....
>> 4. service.bat does not route as many arguments to procrun as what I
>> for one route to JavaService -- and thus it provides less
>> flexibility (especially with no documentation).
>> * For JavaService I provide heap sizing, etc, parameters, as
>> this is critical to any real use of Tomcat.
>> * Having built in support for passing JPDA debug args to the
>> JVM is also a must.
>>
>>
>So edit the service.bat file :). As usual, patches are always welcome ;-).
>
>
The fact that you have to replace all spaces with #'s and shovel all
JAVA_OPTS or CATALINA_OPTS into a single argument makes it more
difficult to just pass in and concatenate portions of the command line.
With JavaService, one can do:
set javaMemArgs=...
set debugArgs=...
set javaPropArgs=...
set javaArgs=%javaMemArgs% %debugArgs% %javaPropArgs%
JavaService.exe -install %serviceName% %jvmDllArg% %javaArgs%
%startArgs% %stopArgs% %stdioArgs% %currDirArgs%
In other words, one can flexibly and easily insert additional
arguments. With procrun, I have to worry about replacing some spaces
with #'s, properly escaping quotes, etc, within the aggregate argument
containing all the Java arguments, etc.
Essentially this makes it harder to have a one-size fits (most) all script.
>> 5. service.bat does not provide any default handling of tools.jar.
>> * By default the resulting service can't compile JSP pages.
>>
>>Overall, service.bat and procrun feel like they're not ready for
>>production use -- which is fine as long as that's understood by the user
>>community.
>>
>>
I should clarify that another reason for this was a number of crashes I
had just installing and removing my service with procrun.
--
Jess Holle
Re: Tomcat 5's service.bat, etc.
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Jess Holle" <je...@ptc.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, March 24, 2004 11:18 AM
Subject: Tomcat 5's service.bat, etc.
> The service.bat and tomcat.exe in Tomcat 5 have a number of issues as I
> see it:
>
> 1. The new tomcat.exe (aka procrun) does not seem to reliably route
> stdout and stderr to the specified files.
> * Compare JavaService (aka Tomcat 4.1.x's tomcat.exe) stdout
> and stderr treatment to procrun's. JavaService captures all
> the startup stdout as well as System.out.println's, etc.
> procrun does not.
Procrun works fine with --Java=java. Yes, it needs work
for --Java=c:\path\to\jvm.dll (known issue, with outstanding BZ entry :).
> 2. Tomcat 5 does not include any documentation on how to use procrun
> (or even that tomcat.exe is procrun).
> 3. I have not managed to get procrun to target the "server" JVM (as
> opposed to the client) in any reliable fashion.
> * With JavaService this was achieved by targeting the
> appropriate jvm.dll. The procrun docs say the same thing is
> possible, but this does not work.
This works fine for me with either --Java=java -JavaOptions=-server#... or
with --Java=c:\path\to\server\jvm.dll.
> 4. service.bat does not route as many arguments to procrun as what I
> for one route to JavaService -- and thus it provides less
> flexibility (especially with no documentation).
> * For JavaService I provide heap sizing, etc, parameters, as
> this is critical to any real use of Tomcat.
> * Having built in support for passing JPDA debug args to the
> JVM is also a must.
So edit the service.bat file :). As usual, patches are always welcome ;-).
> 5. service.bat does not provide any default handling of tools.jar.
> * By default the resulting service can't compile JSP pages.
>
> Overall, service.bat and procrun feel like they're not ready for
> production use -- which is fine as long as that's understood by the user
> community.
>
> Personally, JavaService and an Ant script to produce the right
> (enormous) command line for seem to do the trick nicely -- with Tomcat
> 4.1.x and 5.0.x.
>
Whatever makes you happy ;-).
> --
> Jess Holle
>
>
Tomcat 5's service.bat, etc.
Posted by Jess Holle <je...@ptc.com>.
The service.bat and tomcat.exe in Tomcat 5 have a number of issues as I
see it:
1. The new tomcat.exe (aka procrun) does not seem to reliably route
stdout and stderr to the specified files.
* Compare JavaService (aka Tomcat 4.1.x's tomcat.exe) stdout
and stderr treatment to procrun's. JavaService captures all
the startup stdout as well as System.out.println's, etc.
procrun does not.
2. Tomcat 5 does not include any documentation on how to use procrun
(or even that tomcat.exe is procrun).
3. I have not managed to get procrun to target the "server" JVM (as
opposed to the client) in any reliable fashion.
* With JavaService this was achieved by targeting the
appropriate jvm.dll. The procrun docs say the same thing is
possible, but this does not work.
4. service.bat does not route as many arguments to procrun as what I
for one route to JavaService -- and thus it provides less
flexibility (especially with no documentation).
* For JavaService I provide heap sizing, etc, parameters, as
this is critical to any real use of Tomcat.
* Having built in support for passing JPDA debug args to the
JVM is also a must.
5. service.bat does not provide any default handling of tools.jar.
* By default the resulting service can't compile JSP pages.
Overall, service.bat and procrun feel like they're not ready for
production use -- which is fine as long as that's understood by the user
community.
Personally, JavaService and an Ant script to produce the right
(enormous) command line for seem to do the trick nicely -- with Tomcat
4.1.x and 5.0.x.
--
Jess Holle
Re: Tomcat 5.0.20 Issue
Posted by Jess Holle <je...@ptc.com>.
P.S. Nothing in the quoted spec segments implies that the JSP compiler
should attempt to actually *instantiate* beans at compile time or expect
that that should work.
--
Jess Holle
Jess Holle wrote:
> Based on the given bug id, I would propose a different implementation
> than that found in 5.0.20.
>
> Specifically I would suggest that Generator:
>
> 1. Try to load the given class.
> 2. Look up its default (no-args) constructor via reflection. [This
> is the key part, look up the constructor but don't call it!]
> 3. If a public no-args constructor IS found, then code should be
> generated to use it to directly instantiate the bean.
> 4. If a public no-args constructor is NOT found, then a page error
> should be generated and Beans.instantiate() should be used if
> errorOnUseBeanInvalidClassAttribute is set to false.
>
> This should be more efficient, avoid breaking pages using beans with
> non-trivial environmental constraints for successful construction, and
> follow the letter of the spec better as I see it.
>
> --
> Jess Holle
>
> Tim Funk wrote:
>
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26444
>>
>> -Tim
>>
>> Jess Holle wrote:
>>
>>> Jess Holle wrote:
>>>
>>> Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages
>>> (which Tomcat 5.0.19 compiled just fine).
>>>
>>> The issue can be traced directly to a single entry in the change log:
>>>
>>> Add some intellignece to the compiler for generating code for
>>> useBean action. Generate direct instantiation (use new) when
>>> possible, use bean.instantiate when bean name is specified, and for
>>> the case of invalid bean class, either issue a translation time
>>> error (instead of javac error), or generate codes to throw
>>> InstantiationException at runtime, depending on a new compiler
>>> switch, errorOnUseBeanInvalidClassAttribute(defaulted to true)
>>> (kinman)
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
>
Re: Tomcat 5.0.20 Issue
Posted by Jess Holle <je...@ptc.com>.
Based on the given bug id, I would propose a different implementation
than that found in 5.0.20.
Specifically I would suggest that Generator:
1. Try to load the given class.
2. Look up its default (no-args) constructor via reflection. [This
is the key part, look up the constructor but don't call it!]
3. If a public no-args constructor IS found, then code should be
generated to use it to directly instantiate the bean.
4. If a public no-args constructor is NOT found, then a page error
should be generated and Beans.instantiate() should be used if
errorOnUseBeanInvalidClassAttribute is set to false.
This should be more efficient, avoid breaking pages using beans with
non-trivial environmental constraints for successful construction, and
follow the letter of the spec better as I see it.
--
Jess Holle
Tim Funk wrote:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26444
>
> -Tim
>
> Jess Holle wrote:
>
>> Jess Holle wrote:
>>
>> Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages
>> (which Tomcat 5.0.19 compiled just fine).
>>
>> The issue can be traced directly to a single entry in the change log:
>>
>> Add some intellignece to the compiler for generating code for
>> useBean action. Generate direct instantiation (use new) when
>> possible, use bean.instantiate when bean name is specified, and for
>> the case of invalid bean class, either issue a translation time
>> error (instead of javac error), or generate codes to throw
>> InstantiationException at runtime, depending on a new compiler
>> switch, errorOnUseBeanInvalidClassAttribute(defaulted to true)
>> (kinman)
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Re: Tomcat 5.0.20 Issue
Posted by Tim Funk <fu...@joedog.org>.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26444
-Tim
Jess Holle wrote:
> Jess Holle wrote:
>
> Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages
> (which Tomcat 5.0.19 compiled just fine).
>
> The issue can be traced directly to a single entry in the change log:
>
> Add some intellignece to the compiler for generating code for
> useBean action. Generate direct instantiation (use new) when
> possible, use bean.instantiate when bean name is specified, and for
> the case of invalid bean class, either issue a translation time
> error (instead of javac error), or generate codes to throw
> InstantiationException at runtime, depending on a new compiler
> switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Tomcat 5.0.20 Issue
Posted by Jess Holle <je...@ptc.com>.
Jess Holle wrote:
> Works just great in quick testing at least.
>
> I'm still waiting for my precompilation script to return to determine
> whether Jasper still compiles everything it used to (and should have).
Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages
(which Tomcat 5.0.19 compiled just fine).
The issue can be traced directly to a single entry in the change log:
Add some intellignece to the compiler for generating code for
useBean action. Generate direct instantiation (use new) when
possible, use bean.instantiate when bean name is specified, and for
the case of invalid bean class, either issue a translation time
error (instead of javac error), or generate codes to throw
InstantiationException at runtime, depending on a new compiler
switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman)
There are several issues with this change:
1. The new logic assumes that the bean can be directly instantiated
/at compile time/ and throws a page compilation error when this is
not the case.
* There are beans that can be directly instantiated at run
time but not at compile time (e.g. upon precompilation).
This was the case in all 6 of our failures. [Examples as to
when this might occur include requirements for databases
being accessible, other servers running, etc, etc, for
successful bean instantiation.]
* The error occurs in such a way that a partial Java source
file is written, so later attempts to recompile the page
(when the runtime environment is duplicated) also fail
unless the partial Java source file is first deleted.
2. I note the errorOnUseBeanInvalidClassAttribute setting but there
are issues here as well:
* The default value, true, breaks existing code.
* If errorOnUseBeanInvalidClassAttribute is set to false:
o Instantiation of some (e.g. session or application
scope) beans can be time and/or resource consuming.
Besides being an invalid test as to whether a bean can
be directly instantiated, instantiating such beans
during compilation can be costly. [The combined time
for precompiling all pages was longer in 5.0.20 with
this behavior in place than when I removed it.]
o The new behavior will cause beans to be instantiated
via Beans.instantiate() rather than directly
instantiated when compile time direct instantiation
fails. This leads to a performance degradation
whenever a bean has a runtime instantiation dependency.
* As best I can tell, errorOnUseBeanInvalidClassAttribute is
not accessible from / exposed via JspC main -- which I use
from my pre-compilation scripts for various reasons.
Due to these issues I have reverted this change in Generator to the
5.0.19 state (leaving the other valuable changes in this class intact).
Once I did so all 985 JSP pages compiled -- including the 6 that had
previously failed.
I would urge that this change be reverted -- either in this release (or
an immediate 5.0.21 release) or immediately changed in HEAD for the next
release.
--
Jess Holle
Re: [5.0.20] New build
Posted by Jess Holle <je...@ptc.com>.
Works just great in quick testing at least.
I'm still waiting for my precompilation script to return to determine
whether Jasper still compiles everything it used to (and should have).
--
Jess Holle
Remy Maucherat wrote:
> The new build is now available (a bit late, but with additional fixes).
> Thanks for the help with the license transition and the bugfixing.
>
> http://www.apache.org/dist/jakarta/tomcat-5/v5.0.20-alpha/
>
> This has no JMX and no Windows installer.
> The build may not be very useful except for basic regression testing,
> despite a number of good fixes :(
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org