You are viewing a plain text version of this content. The canonical link for it is here.
Posted to announce@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2015/08/17 13:10:58 UTC
[ANN] Apache Tomcat Connectors 1.2.41 released
The Apache Tomcat Project is proud to announce the release of version
1.2.41 of the Apache Tomcat Connectors.
This version fixes one security issue (CVE-2014-8111) and a number of
bugs found in previous releases.
Full details of these changes and new features,
are available in the Apache Tomcat Connectors changelog:
http://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html
Downloads:
http://tomcat.apache.org/download-connectors.cgi
Thank you,
--
The Apache Tomcat Team
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by chris derham <ch...@derham.me.uk>.
All,
I still don't quite understand how I ended up in this position, but
when Stephen from the Apache Lounge builds a new tomcat native build
of something, he asks me to inform the tomcat mailing list. I consider
it the very least I can do for the community, but struggle to see how
I am adding value. Anyway his notification below. His original subject
was "mod_jk-1.2.41 VC11" but it seemed prudent to send on this thread.
Chris
Hi Chris,
Just build it for VC11, see https://www.apachelounge.com/viewtopic.php?p=31471
Maybe you can inform the list.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by Rainer Jung <ra...@kippdata.de>.
Am 25.08.2015 um 23:59 schrieb Christopher Schultz:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Rainer,
>
> On 8/25/15 5:53 PM, Rainer Jung wrote:
>> Am 25.08.2015 um 20:41 schrieb Christopher Schultz:
>>
>>> On 8/25/15 11:49 AM, Rainer Jung wrote:
>>
>>>> I just tried the isapi_redirector build using VC 2010 and the
>>>> Makefile.amd64. No additional flags, just setting up the
>>>> compiler with "setenv /Release /x64" (as usual for MSVC) before
>>>> running it. Then changing into the iis src directory and
>>>> running "nmake -f Makefile.amd64" which results in
>>>> Release_amd64/isapi_redirect.dll (the IIS plugin) and
>>>> Release_amd64/isapi_redirect.pdb (the symbol file needed for
>>>> debugging). The build was done on Windows 7 64 Bits
>>>> Professional, but I think that is less important then the MSVC
>>>> version used.
>>>>
>>>> Since I'm using the 2010 compiler, the produced binary has a
>>>> dependency on the MSVCR100.dll runtime library, which must be
>>>> installed independently on the system if not yet available, but
>>>> at least there are redistributables for it provided by
>>>> Microsoft, see
>>>> https://www.microsoft.com/en-US/download/details.aspx?id=5555.
>>>> I have checked the dependency using the "depends.exe"
>>>> dependency walker (similar to Unix/Linux ldd), see
>>>> http://www.dependencywalker.com/.
>>>>
>>>> I'd hope that the usual runtime library compatibility issues
>>>> are not the problematic for the ISAPI redirector as for mod_jk
>>>> on Windows. Maybe IIS can cope better with plugins using
>>>> different versions of the runtime libs. I definitely don't have
>>>> a version 6 compiler to prevent using the newer runtime libs.
>>>
>>> I believe we go through great pains with tcnative to build
>>> against MSVCRT.DLL because, evidently, that is guaranteed to be
>>> available on any modern Windows system (I think that means
>>> win2k/NT4.0+... possibly back to win95). This reduces the
>>> installation complexity for the end user, but requires lots of
>>> work on the part of the packager.
>>>
>>> I'd like to know what the community thinks about building
>>> against MSVCRT100.DLL, which is essentially the same thing and I
>>> would imagine that everyone has that DLL these days. (The issue,
>>> of course, is that we can't bundle it ourselves due to licensing
>>> restrictions.)
>>>
>>> Can we statically-link instead of using the DLL? Would that be
>>> very stupid? Seems like it would solve everything.
>>
>> AFAIR the original problem about the msvc runtime libs is, that
>> different versions are not compatible with each other. The one
>> needed by MSVC 6 (msvcrt.dll) is compatible with newer ones (the
>> ones with numbers in their name), but newer ones for different
>> numbers are not compatible with each other. Using different
>> numbered versions in the same process can lead to crashes etc.
>
> I'm pretty sure that fprintf is compatible across versions, no? But
Ha! Not far from one of the real problem examples:
http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell
And MS says in
http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring.aspx:
"The "best" example of this maintainability problem could be found in
the old implementation of the printf family of functions. The CRT
provides 142 different variations of printf, but most of the behavior is
the same for all of the functions, so there are a set of common
implementation functions that do the bulk of the work. These common
implementation functions were all defined in output.c in the CRT
sources(1). This 2,696 line file had 223 conditionally compiled regions
of code (#ifdef, #else, etc.), over half of which were in a single 1,400
line function. This file was compiled 12 different ways to generate all
of the common implementation functions. Even with the large number of
tests that we have for these functions, the code was exceedingly brittle
and difficult to modify."
But it seems, if this old blog describes what actually happened in the
meantime, that starting with version 14 they moved from incompatible
versions to using backwards compatible libs. Maybe some light at the
horizon.
> the version-less DDL is reliably available on all modern systems,
> right? That's the real issue: is the library available on the target
> system. Using the version-less library gives us the widest
> compatibility without requiring the user to install one of the MSVC++
> redistributable packages.
>
>> This is a problem, if your process consists of different pieces
>> compiled with different MSVC versions and thus loading different
>> msvc libs.
>
> Oh, so it might depend upon whatever IIS uses. So.. how can we tell
> which MSVC was used by a particular IIS version?
>
>> I'd hope that this is less likely to happen for IIS, but I haven't
>> yet checked, whether IIS on newer systems itself still only has a
>> dependency on MSVCRT.dll or also on newer versions. I hope not.
>> Still there could be a problem if people add other extensions
>> introducing such incompatibilities.
>>
>> So I think this is less about end user installation hassle. Adding
>> the msvc redistribution once to systems isn't that uncommon as a
>> task on windows. It is more about being compatible with msvc
>> runtime libs loaded by other components inside the same process.
>> The MS tool chain isn't suited to support modular software that's
>> combined from different suppliers.
>
> Okay, good to know.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Rainer,
On 8/25/15 5:53 PM, Rainer Jung wrote:
> Am 25.08.2015 um 20:41 schrieb Christopher Schultz:
>
>> On 8/25/15 11:49 AM, Rainer Jung wrote:
>
>>> I just tried the isapi_redirector build using VC 2010 and the
>>> Makefile.amd64. No additional flags, just setting up the
>>> compiler with "setenv /Release /x64" (as usual for MSVC) before
>>> running it. Then changing into the iis src directory and
>>> running "nmake -f Makefile.amd64" which results in
>>> Release_amd64/isapi_redirect.dll (the IIS plugin) and
>>> Release_amd64/isapi_redirect.pdb (the symbol file needed for
>>> debugging). The build was done on Windows 7 64 Bits
>>> Professional, but I think that is less important then the MSVC
>>> version used.
>>>
>>> Since I'm using the 2010 compiler, the produced binary has a
>>> dependency on the MSVCR100.dll runtime library, which must be
>>> installed independently on the system if not yet available, but
>>> at least there are redistributables for it provided by
>>> Microsoft, see
>>> https://www.microsoft.com/en-US/download/details.aspx?id=5555.
>>> I have checked the dependency using the "depends.exe"
>>> dependency walker (similar to Unix/Linux ldd), see
>>> http://www.dependencywalker.com/.
>>>
>>> I'd hope that the usual runtime library compatibility issues
>>> are not the problematic for the ISAPI redirector as for mod_jk
>>> on Windows. Maybe IIS can cope better with plugins using
>>> different versions of the runtime libs. I definitely don't have
>>> a version 6 compiler to prevent using the newer runtime libs.
>>
>> I believe we go through great pains with tcnative to build
>> against MSVCRT.DLL because, evidently, that is guaranteed to be
>> available on any modern Windows system (I think that means
>> win2k/NT4.0+... possibly back to win95). This reduces the
>> installation complexity for the end user, but requires lots of
>> work on the part of the packager.
>>
>> I'd like to know what the community thinks about building
>> against MSVCRT100.DLL, which is essentially the same thing and I
>> would imagine that everyone has that DLL these days. (The issue,
>> of course, is that we can't bundle it ourselves due to licensing
>> restrictions.)
>>
>> Can we statically-link instead of using the DLL? Would that be
>> very stupid? Seems like it would solve everything.
>
> AFAIR the original problem about the msvc runtime libs is, that
> different versions are not compatible with each other. The one
> needed by MSVC 6 (msvcrt.dll) is compatible with newer ones (the
> ones with numbers in their name), but newer ones for different
> numbers are not compatible with each other. Using different
> numbered versions in the same process can lead to crashes etc.
I'm pretty sure that fprintf is compatible across versions, no? But
the version-less DDL is reliably available on all modern systems,
right? That's the real issue: is the library available on the target
system. Using the version-less library gives us the widest
compatibility without requiring the user to install one of the MSVC++
redistributable packages.
> This is a problem, if your process consists of different pieces
> compiled with different MSVC versions and thus loading different
> msvc libs.
Oh, so it might depend upon whatever IIS uses. So.. how can we tell
which MSVC was used by a particular IIS version?
> I'd hope that this is less likely to happen for IIS, but I haven't
> yet checked, whether IIS on newer systems itself still only has a
> dependency on MSVCRT.dll or also on newer versions. I hope not.
> Still there could be a problem if people add other extensions
> introducing such incompatibilities.
>
> So I think this is less about end user installation hassle. Adding
> the msvc redistribution once to systems isn't that uncommon as a
> task on windows. It is more about being compatible with msvc
> runtime libs loaded by other components inside the same process.
> The MS tool chain isn't suited to support modular software that's
> combined from different suppliers.
Okay, good to know.
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV3OVJAAoJEBzwKT+lPKRYtlAQAK9fjKt8GBjdYPS+X0VwFZJh
q+7H81fCRayq8TEFFEA5wArJjzDrhxk4kPI9t6lz53zOQEH5hqS7XgvhvAJc7kFW
iWbm2w0XL7j4tx4arZtmWVF49jjayKx/wlJirzR0uy3A26075aovDyha6UcTerah
CwViFV5DVpEDZc1gTd/KWAkkZ+D0prZIdF02rC0YlR/U7cdbHUtJMil6LtxgrSNL
lZ1G6xmaDe1nZ2GFaDCcTEacyseEFFk14nBwtGgfu2KYkx37wVgnb8Ixs35ah+FK
J+Bn6/pQOgIy3oebgCa4JS2ELndz75Lp+JIrsR0/tJbY5ku7LJgYGfg/cSch9697
z6sAfr9iqgXSjab4zdsSkOz7HH3B2LOPFYFFlh0wDloMRClig/hSpYf5DFt2PA7w
3PK7qy/9UoyWSU3qAHEtTnSB35jCtaY4t0PzXyhaSS7fhSNr2Fsid4AOJX9Oi2BV
WX8lONlrANxXtyUJMd01nQjvu7H5nmCEVagBCN9Qx/xdUSb8v9oBfqGYkdnNdY7I
hYM3GHJyNX5LS3jSFoUc+TcawTZbAwjAw1dDu9YTGpSPZhWlCspyJ5pLe5+11WiD
i2avR3blmKn6OLIX2YPO0e/5vPNDBBWelLslod2DAcPqnqqilRsdabFDOJPOxVgY
a/riwxnkWspvGcFysdX3
=QJtF
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by Rainer Jung <ra...@kippdata.de>.
Am 25.08.2015 um 20:41 schrieb Christopher Schultz:
> On 8/25/15 11:49 AM, Rainer Jung wrote:
>> I just tried the isapi_redirector build using VC 2010 and the
>> Makefile.amd64. No additional flags, just setting up the compiler
>> with "setenv /Release /x64" (as usual for MSVC) before running it.
>> Then changing into the iis src directory and running "nmake -f
>> Makefile.amd64" which results in Release_amd64/isapi_redirect.dll
>> (the IIS plugin) and Release_amd64/isapi_redirect.pdb (the symbol
>> file needed for debugging). The build was done on Windows 7 64 Bits
>> Professional, but I think that is less important then the MSVC
>> version used.
>>
>> Since I'm using the 2010 compiler, the produced binary has a
>> dependency on the MSVCR100.dll runtime library, which must be
>> installed independently on the system if not yet available, but at
>> least there are redistributables for it provided by Microsoft, see
>> https://www.microsoft.com/en-US/download/details.aspx?id=5555. I
>> have checked the dependency using the "depends.exe" dependency
>> walker (similar to Unix/Linux ldd), see
>> http://www.dependencywalker.com/.
>>
>> I'd hope that the usual runtime library compatibility issues are
>> not the problematic for the ISAPI redirector as for mod_jk on
>> Windows. Maybe IIS can cope better with plugins using different
>> versions of the runtime libs. I definitely don't have a version 6
>> compiler to prevent using the newer runtime libs.
>
> I believe we go through great pains with tcnative to build against
> MSVCRT.DLL because, evidently, that is guaranteed to be available on
> any modern Windows system (I think that means win2k/NT4.0+... possibly
> back to win95). This reduces the installation complexity for the end
> user, but requires lots of work on the part of the packager.
>
> I'd like to know what the community thinks about building against
> MSVCRT100.DLL, which is essentially the same thing and I would imagine
> that everyone has that DLL these days. (The issue, of course, is that
> we can't bundle it ourselves due to licensing restrictions.)
>
> Can we statically-link instead of using the DLL? Would that be very
> stupid? Seems like it would solve everything.
AFAIR the original problem about the msvc runtime libs is, that
different versions are not compatible with each other. The one needed by
MSVC 6 (msvcrt.dll) is compatible with newer ones (the ones with numbers
in their name), but newer ones for different numbers are not compatible
with each other. Using different numbered versions in the same process
can lead to crashes etc.
This is a problem, if your process consists of different pieces compiled
with different MSVC versions and thus loading different msvc libs. One
example is the Apache web server provided/compiled by someone and a
module provided/compiled by someone else. Another might be the jvm
(java.exe) and a native library loaded into it. For instance the
java.dll contained in Java 1.8.0_51 and in 1.7.0_80 load msvcr100.dll.
So when Oracle updates their tool chain, they might switch to a newer
msvc runtime lib version.
I'd hope that this is less likely to happen for IIS, but I haven't yet
checked, whether IIS on newer systems itself still only has a dependency
on MSVCRT.dll or also on newer versions. I hope not. Still there could
be a problem if people add other extensions introducing such
incompatibilities.
So I think this is less about end user installation hassle. Adding the
msvc redistribution once to systems isn't that uncommon as a task on
windows. It is more about being compatible with msvc runtime libs loaded
by other components inside the same process. The MS tool chain isn't
suited to support modular software that's combined from different suppliers.
For reference see e.g.
https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
or
https://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.100%29.aspx
for MSVC 2010
(especially the paragraph starting with "If you have more than one DLL") and
https://msdn.microsoft.com/en-us/library/ms235460.aspx
I think from those descriptions the compatibility problem for tcnative
might be void, because likely we don't pass native objects across the
boundary, just references which are only natively used inside tcnative,
not in the JVM anywhere else.
For mod_jk the problem is harder, because there's a lot of data passed
between httpd and mod_jk.so. As someone wrote: "The same holds true in
case of simple C structures too. Although it is unlikely that, say for
an example, the order of struct tm or struct FILE, would change from one
version of Visual Studio to another, one can’t reply on such
assumptions." For the isapi redirector I'm undecided how likely a
problem is.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Rainer,
On 8/25/15 11:49 AM, Rainer Jung wrote:
> Am 24.08.2015 um 21:23 schrieb Mark Thomas:
>> On 24/08/2015 16:40, Alten, Jessica-Aileen wrote:
>
>>>> We'd love to provide Windows binaries for mod_jk, but they
>>>> are a real pain in the neck to actually build: they require
>>>> very specific build environment, and the library must be
>>>> built in such a way that it's compatible with the web server
>>>> in which it's running (e.g. httpd 1.3/2.2/2.4 or IIS
>>>> 5/6/7/8/9, proper architecture (32/63) and chipset
>>>> (x86/x86-64/itanium/alpha). It's gotten to the point where
>>>> it's tough to provide all of those combinations with any
>>>> regularity.
>>>
>>> I understand that it is difficult - perhaps too difficult for
>>> the developers of this module, but the average Windows admin or
>>> Java programmer should do this? ;) There were binaries of this
>>> module at least for the last 10 years! I'm very disappointed on
>>> this attitude. You are closing out the whole Windows/IIS
>>> world.
>>
>> Yes, we (the Tomcat community) has a problem here.
>>
>> We needed a jk release to address a security issue that had been
>> made public before we were ready. The developers that normally
>> work on jk have been quiet lately so one of the other Tomcat
>> developers stepped up to do the release. The source code side of
>> things is relatively simple but the binaries are not and the
>> document build process is not sufficient to generate a binary
>> release.
>>
>
>> This is the documented build process for ISAPI:
>> http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/README?view=a
nnotate
>>
>>
>>
>>
We don't have the equivalent 'How to build a release' documentation.
>>
>> It is not at all clear how release builds (which options have
>> been used, what have they been compiled with / against?) have
>> been built in the past so it is next to impossible to reproduce a
>> similar build.
>>
>>>> Unfortunately, I don't believe they provide builds for the
>>>> ISAPI redirector for IIS. If that's what you need... umm...
>>>
>>> Umm - yes - this is what I need.
>>
>> There are a couple of options:
>>
>> Hope the jk committers provide enough information to document
>> the release process so anyone can run it.
>>
>> Figure out how to build something that works for you and share
>> that with the Tomcat community so anyone can build it. Then one
>> of the active Tomcat committers will be able to include the
>> binary in the next release (and provide an official binary for
>> this release).
>
> I just tried the isapi_redirector build using VC 2010 and the
> Makefile.amd64. No additional flags, just setting up the compiler
> with "setenv /Release /x64" (as usual for MSVC) before running it.
> Then changing into the iis src directory and running "nmake -f
> Makefile.amd64" which results in Release_amd64/isapi_redirect.dll
> (the IIS plugin) and Release_amd64/isapi_redirect.pdb (the symbol
> file needed for debugging). The build was done on Windows 7 64 Bits
> Professional, but I think that is less important then the MSVC
> version used.
>
> Since I'm using the 2010 compiler, the produced binary has a
> dependency on the MSVCR100.dll runtime library, which must be
> installed independently on the system if not yet available, but at
> least there are redistributables for it provided by Microsoft, see
> https://www.microsoft.com/en-US/download/details.aspx?id=5555. I
> have checked the dependency using the "depends.exe" dependency
> walker (similar to Unix/Linux ldd), see
> http://www.dependencywalker.com/.
>
> I'd hope that the usual runtime library compatibility issues are
> not the problematic for the ISAPI redirector as for mod_jk on
> Windows. Maybe IIS can cope better with plugins using different
> versions of the runtime libs. I definitely don't have a version 6
> compiler to prevent using the newer runtime libs.
I believe we go through great pains with tcnative to build against
MSVCRT.DLL because, evidently, that is guaranteed to be available on
any modern Windows system (I think that means win2k/NT4.0+... possibly
back to win95). This reduces the installation complexity for the end
user, but requires lots of work on the part of the packager.
I'd like to know what the community thinks about building against
MSVCRT100.DLL, which is essentially the same thing and I would imagine
that everyone has that DLL these days. (The issue, of course, is that
we can't bundle it ourselves due to licensing restrictions.)
Can we statically-link instead of using the DLL? Would that be very
stupid? Seems like it would solve everything.
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV3LbzAAoJEBzwKT+lPKRYZJAP/jcbABmW39urbWUDQ6OYIJHB
jXLhOyb4ibH9fGesEeNL/ye/i29WbX+uxp3TJWbQ2eKK5Lraom5TRzqm0zjJFgYR
MEjuk7djBWX0TgnC2S2YlAnfxkzUCC4D2+1S9olPlX8J/mDmvbwS3ei4k+6QLjMO
IvJ/fBYdga1dAhE8cnT4yIxj5MRzZk9GCQkwKrknksoTzU1J+UNbaVUomTAnDcqe
akkvq0m/C8ubXRuq7bRLcYWBlgbYy22GxJClczMgmKTfIHoHnkG/nONgpvLxtq+i
CDPt3B2ULoYsjz0xTWo94NtNdl8BceNWfsd8JBSF2YFW35Bd1SDVsNQHQV6J3gU3
iIhtbyaiApyBwBm0c/1hiz7toCG1jMZ2yXgb2RInr/X7nqibauab7s7B8j1WMwRL
yjMeXtSYaqibTGok5DH8v184m6mSit/RL/9BU7V/holx+8kcVI956/OG+9eIBWpg
RdQ4QR63UGf2do1kU6Bo1qG7RIfWXdC2D0TtX5PgsbpMfyKWiuDjfKgiL0iLJ0hB
M7AAsRUfArBlPtZTm7JDDWRDajrhYoEgwW0UXB2fVrkabkAxODEWlxZeX6wxH5xR
g7VQcwO11CvsKb9di9h2WiW8cGoffWfXQSEubbSrvCivAcLVBOStdpbo6MjOElXv
36oZEj6hxAqMpwdHbOnG
=ZRj0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by "Alten, Jessica-Aileen" <Je...@liag-hannover.de>.
> @Jessica: which CPU architecture are you using: x86 (32 Bit), x64 (64
> Bits) or even Itanium 64? Which OS version do you have? If you are
> willing to test, I can provide an example binary from which we might
> learn, how well it works and whether that type of build is suitable for
> others as well.
Windows Server 2008R2 (productive/staging), x64 architecture.
Installing different redistributables (vcredist.exe) is in fact really common under Windows. Some installations require lots of redistributables (x86 and/or x64) on the same server.
Your link is for the x86 version, the x64 architecture redistributable is
http://www.microsoft.com/en-us/download/details.aspx?id=14632.
Greetings,
Jessica
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by Rainer Jung <ra...@kippdata.de>.
Am 24.08.2015 um 21:23 schrieb Mark Thomas:
> On 24/08/2015 16:40, Alten, Jessica-Aileen wrote:
>>> We'd love to provide Windows binaries for mod_jk, but they are a real
>>> pain in the neck to actually build: they require very specific build
>>> environment, and the library must be built in such a way that it's
>>> compatible with the web server in which it's running (e.g. httpd
>>> 1.3/2.2/2.4 or IIS 5/6/7/8/9, proper architecture (32/63) and chipset
>>> (x86/x86-64/itanium/alpha). It's gotten to the point where it's tough
>>> to provide all of those combinations with any regularity.
>>
>> I understand that it is difficult - perhaps too difficult for the developers of this module, but the average Windows admin or Java programmer should do this? ;)
>> There were binaries of this module at least for the last 10 years!
>> I'm very disappointed on this attitude. You are closing out the whole Windows/IIS world.
>
> Yes, we (the Tomcat community) has a problem here.
>
> We needed a jk release to address a security issue that had been made
> public before we were ready. The developers that normally work on jk
> have been quiet lately so one of the other Tomcat developers stepped up
> to do the release. The source code side of things is relatively simple
> but the binaries are not and the document build process is not
> sufficient to generate a binary release.
>
> This is the documented build process for ISAPI:
> http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/README?view=annotate
>
> We don't have the equivalent 'How to build a release' documentation.
>
> It is not at all clear how release builds (which options have been used,
> what have they been compiled with / against?) have been built in the
> past so it is next to impossible to reproduce a similar build.
>
>>> Unfortunately, I don't believe they provide builds for the ISAPI
>>> redirector for IIS. If that's what you need... umm...
>>
>> Umm - yes - this is what I need.
>
> There are a couple of options:
>
> Hope the jk committers provide enough information to document the
> release process so anyone can run it.
>
> Figure out how to build something that works for you and share that with
> the Tomcat community so anyone can build it. Then one of the active
> Tomcat committers will be able to include the binary in the next release
> (and provide an official binary for this release).
I just tried the isapi_redirector build using VC 2010 and the
Makefile.amd64. No additional flags, just setting up the compiler with
"setenv /Release /x64" (as usual for MSVC) before running it. Then
changing into the iis src directory and running "nmake -f
Makefile.amd64" which results in Release_amd64/isapi_redirect.dll (the
IIS plugin) and Release_amd64/isapi_redirect.pdb (the symbol file needed
for debugging). The build was done on Windows 7 64 Bits Professional,
but I think that is less important then the MSVC version used.
Since I'm using the 2010 compiler, the produced binary has a dependency
on the MSVCR100.dll runtime library, which must be installed
independently on the system if not yet available, but at least there are
redistributables for it provided by Microsoft, see
https://www.microsoft.com/en-US/download/details.aspx?id=5555. I have
checked the dependency using the "depends.exe" dependency walker
(similar to Unix/Linux ldd), see http://www.dependencywalker.com/.
I'd hope that the usual runtime library compatibility issues are not the
problematic for the ISAPI redirector as for mod_jk on Windows. Maybe IIS
can cope better with plugins using different versions of the runtime
libs. I definitely don't have a version 6 compiler to prevent using the
newer runtime libs.
@Jessica: which CPU architecture are you using: x86 (32 Bit), x64 (64
Bits) or even Itanium 64? Which OS version do you have? If you are
willing to test, I can provide an example binary from which we might
learn, how well it works and whether that type of build is suitable for
others as well.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by Mark Thomas <ma...@apache.org>.
On 24/08/2015 16:40, Alten, Jessica-Aileen wrote:
>> The official position of the ASF is that we provide code, not
>> binaries.
>
> Sorry, I can't follow this argument - there are lots of binaries in the download area, even for Tomcat and the Httpd flagship.
ASF policy is that we MUST release in source code form. Many projects
provide convenience binaries but they are just that, convenience binaries.
>> We'd love to provide Windows binaries for mod_jk, but they are a real
>> pain in the neck to actually build: they require very specific build
>> environment, and the library must be built in such a way that it's
>> compatible with the web server in which it's running (e.g. httpd
>> 1.3/2.2/2.4 or IIS 5/6/7/8/9, proper architecture (32/63) and chipset
>> (x86/x86-64/itanium/alpha). It's gotten to the point where it's tough
>> to provide all of those combinations with any regularity.
>
> I understand that it is difficult - perhaps too difficult for the developers of this module, but the average Windows admin or Java programmer should do this? ;)
> There were binaries of this module at least for the last 10 years!
> I'm very disappointed on this attitude. You are closing out the whole Windows/IIS world.
Yes, we (the Tomcat community) has a problem here.
We needed a jk release to address a security issue that had been made
public before we were ready. The developers that normally work on jk
have been quiet lately so one of the other Tomcat developers stepped up
to do the release. The source code side of things is relatively simple
but the binaries are not and the document build process is not
sufficient to generate a binary release.
To give you an idea, this is the documented build process for the
tc-native DLL:
http://tomcat.apache.org/native-doc/#Building/Windows
This is what is actually required to generate a release:
http://wiki.apache.org/tomcat/BuildTcNativeWin
This is the documented build process for ISAPI:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/README?view=annotate
We don't have the equivalent 'How to build a release' documentation.
It is not at all clear how release builds (which options have been used,
what have they been compiled with / against?) have been built in the
past so it is next to impossible to reproduce a similar build.
>> Unfortunately, I don't believe they provide builds for the ISAPI
>> redirector for IIS. If that's what you need... umm...
>
> Umm - yes - this is what I need.
There are a couple of options:
Hope the jk committers provide enough information to document the
release process so anyone can run it.
Figure out how to build something that works for you and share that with
the Tomcat community so anyone can build it. Then one of the active
Tomcat committers will be able to include the binary in the next release
(and provide an official binary for this release).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jessica,
On 8/24/15 11:40 AM, Alten, Jessica-Aileen wrote:
>> The official position of the ASF is that we provide code, not
>> binaries.
>
> Sorry, I can't follow this argument - there are lots of binaries
> in the download area, even for Tomcat and the Httpd flagship.
Note that the "binary" downloads for Tomcat are largely compiled Java
code and not native code. We do package-up the tcnative library, it's
true. See the archives on the dev list for the recent gnashing of
teeth surrounding that issue.
>> We'd love to provide Windows binaries for mod_jk, but they are a
>> real pain in the neck to actually build: they require very
>> specific build environment, and the library must be built in such
>> a way that it's compatible with the web server in which it's
>> running (e.g. httpd 1.3/2.2/2.4 or IIS 5/6/7/8/9, proper
>> architecture (32/63) and chipset (x86/x86-64/itanium/alpha). It's
>> gotten to the point where it's tough to provide all of those
>> combinations with any regularity.
>
> I understand that it is difficult - perhaps too difficult for the
> developers of this module, but the average Windows admin or Java
> programmer should do this? ;)
>
> There were binaries of this module at least for the last 10 years!
In this particular case, we were forced to issue a hasty release (and
I would agree it wasn't hasty enough) due to the premature disclosure
of a security problem with the previous version.
The core Tomcat team is very small, and the *one* guy who usually does
these builds has been MIA for a while. We don't have an army of
developers ready to build a release binary at a moment's notice. We
are all volunteers, here.
> I'm very disappointed on this attitude. You are closing out the
> whole Windows/IIS world.
It will get built. The question is when.
>> Unfortunately, I don't believe they provide builds for the ISAPI
>> redirector for IIS. If that's what you need... umm...
>
> Umm - yes - this is what I need.
Okay. Do you have a compiler handy? ;)
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV21n1AAoJEBzwKT+lPKRYabAQAKCKvJgUscsHJvyj33t2CQJM
cVX004l27Lq7yAH+xY2Tr05zZ5JOZ6JrLI5hnjPSBTzIvOjL4Dc5O4/7Ebd8VzUx
ESJSPCnIB/JLipfDjYakmB/hLaC5t8Y+IyuW21n+Sy/9/9rp23QtECi+zewEk7RR
TAeEcylLBpH5SATizV3Zkc0uhmDEEUJVo/TQG7WxMxMnjmPV0XuR40+z8OxBCP70
8GuFXQysONeQRTSB1ZFLZJD1WqNB3Om87OxuMFXs8fE/hkqqCoZkefhKHlcx2Gb1
O+FEjwQEHBDaB202my3X3/NU7RH0FRujGjgo8Ati+kQMeCmC7R540fLYqgrN235/
AN2IPaBqh6QH+z4M7hIJ6FdG8UonPe2Q8LAiFw1eB8f44iVpdjaI8eY4USmKgP0O
zuXDy4OEAwzpTwXtSgG2TXY6/bOAR706swrMlsgEfhTd/CL2S3eJ8/yQRkCUizyT
LFJ8SGGIHj/DpAmFaWg9WiWzi5lo/Fje2G4fYtrhIQuBpHIq1mHoW/WgG4qOur89
OQODwRY4YDb4at1C3n7sCHg1kTfU4jwvtXHnS67WB7TXfd6TloALnzx4iVZc5/gC
13jTrx343xD2WxQJLFqZs/cJi5qWx5HmcWRjCUXiuYnP0JwdkqR3lkKH/d2wEbO8
aAVnJ9WBZ9mCkr8jSZSk
=cYpr
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by "Alten, Jessica-Aileen" <Je...@liag-hannover.de>.
> The official position of the ASF is that we provide code, not
> binaries.
Sorry, I can't follow this argument - there are lots of binaries in the download area, even for Tomcat and the Httpd flagship.
> We'd love to provide Windows binaries for mod_jk, but they are a real
> pain in the neck to actually build: they require very specific build
> environment, and the library must be built in such a way that it's
> compatible with the web server in which it's running (e.g. httpd
> 1.3/2.2/2.4 or IIS 5/6/7/8/9, proper architecture (32/63) and chipset
> (x86/x86-64/itanium/alpha). It's gotten to the point where it's tough
> to provide all of those combinations with any regularity.
I understand that it is difficult - perhaps too difficult for the developers of this module, but the average Windows admin or Java programmer should do this? ;)
There were binaries of this module at least for the last 10 years!
I'm very disappointed on this attitude. You are closing out the whole Windows/IIS world.
> Unfortunately, I don't believe they provide builds for the ISAPI
> redirector for IIS. If that's what you need... umm...
Umm - yes - this is what I need.
Greetings,
Jessica
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jessica,
On 8/24/15 4:25 AM, Alten, Jessica-Aileen wrote:
>> The Apache Tomcat Project is proud to announce the release of
>> version 1.2.41 of the Apache Tomcat Connectors. This version
>> fixes one security issue (CVE-2014-8111) and a number of bugs
>> found in previous releases.
>>
>> [...]
>>
>> Downloads: http://tomcat.apache.org/download-connectors.cgi
>
> Is there a binary release for Windows scheduled?
The official position of the ASF is that we provide code, not
binaries. That said, providing binaries for Windows users is a really
nice thing to do because most Windows users don't have compilers
handy, and the range of environments can be ... difficult.
We'd love to provide Windows binaries for mod_jk, but they are a real
pain in the neck to actually build: they require very specific build
environment, and the library must be built in such a way that it's
compatible with the web server in which it's running (e.g. httpd
1.3/2.2/2.4 or IIS 5/6/7/8/9, proper architecture (32/63) and chipset
(x86/x86-64/itanium/alpha). It's gotten to the point where it's tough
to provide all of those combinations with any regularity.
We are trying to work on software, not spend our (volunteer) time
wrestling with build processes.
Our friends over at the Apache Lounge [1], while not being directly or
officially affiliated with the ASF in any way, have been building
httpd and various modules for it (including mod_jk) for a while, now.
I see that they don't yet have a build for mod_jk 1.2.41, but I'm sure
if you asked nicely, they'd tell you what their schedule is.
Unfortunately, I don't believe they provide builds for the ISAPI
redirector for IIS. If that's what you need... umm... wait to see if
anyone volunteers to make a build for you? (Remember that you must
trust the source of the build: don't just accept a binary from some
random person on the web and install it into your production web
servers. You never know what you're going to get!)
- -chris
[1] http://www.apachelounge.com/
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV2yXxAAoJEBzwKT+lPKRYJ1wQAJWMbDxPDfGKGOtIrOaBDhkK
XHa46i+JfRI+Gpc7pKMmHNC6OmWvBHGRtTdq7wdWkiLzgJKvHi1Ufl1O3WsD6MZP
dCf68tjxnnY6GvGQ/WPxP7I3WetshOrrW1b0TxFtfjrcM5OjjQ6jCQ278sKsGXmh
g2A10dyqjpUTfACy4atnFW2axJhIUt30ypmogoRFQnY+RID4fgJALzW2oscUC7Px
Vv+yG0jzTpvbSBZ6bd5aozlMgA9c6IEXmcYyDQerUF9+7KJ63LJwJZxPSC8Pvrlo
EH1YCMIiUn3n91pLE8WiC1Rc1vhMi5w8ilQ1aFMe5o1NIYZ7N/Fdh17AvRnWUFNW
YFf2/uvRPppsevd9P4PyQuRsGbdUccl0jyKO+d/CYhRDTec9554LlpYsvaRKrhVp
eYLoQBZmvOYxG3phgKPkL55Yz6BfKRJIUEST1D4b/FrieamO82xQBJomJl7/twzT
qBRKfGp2zICBTLKLXeiPOXTJX6huCTG/JNG3PE0ekC8bx5GReyDmjhwd8eyX+N+q
lirfbuG2aqwzF/eEYFSccG5LTx38rh8MMgpywPEQMBzwakQ4sXyqfxFfM9lTCiTM
QB0MuvcDS0xo3y4PGX89hpr80O/VWqHWA9XqPFVC31n5kZCFYYBWKmaL5WuRP8/o
wgg5qruemEg9xoKwzZKG
=aFlO
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by "Alten, Jessica-Aileen" <Je...@liag-hannover.de>.
> The Apache Tomcat Project is proud to announce the release of version
> 1.2.41 of the Apache Tomcat Connectors.
> This version fixes one security issue (CVE-2014-8111) and a number of
> bugs found in previous releases.
>
> [...]
>
> Downloads:
> http://tomcat.apache.org/download-connectors.cgi
Is there a binary release for Windows scheduled?
Greetings,
Jessica
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by John Byrne <jb...@gmail.com>.
Unsubscibe
On 19 August 2015 at 13:30, jean-frederic clere <jf...@gmail.com> wrote:
> On 08/17/2015 01:10 PM, Mark Thomas wrote:
>
>> The Apache Tomcat Project is proud to announce the release of version
>> 1.2.41 of the Apache Tomcat Connectors.
>> This version fixes one security issue (CVE-2014-8111) and a number of
>> bugs found in previous releases.
>>
>
> Many thanks for the release and sorry for all the troubles around
> CVE-2014-8111.
>
> Cheers
>
> Jean-Frederic
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Mult-i-tel better by design.
http://www.multitel.co.uk
tel: 44(0)151 548 8122
fax: 44(0)709 210 1464
skype jcbyrne
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Jean-Frederic,
On 8/19/15 8:30 AM, jean-frederic clere wrote:
> On 08/17/2015 01:10 PM, Mark Thomas wrote:
>> The Apache Tomcat Project is proud to announce the release of version
>> 1.2.41 of the Apache Tomcat Connectors.
>> This version fixes one security issue (CVE-2014-8111) and a number of
>> bugs found in previous releases.
>
> Many thanks for the release and sorry for all the troubles around
> CVE-2014-8111.
We understand it's not your fault.
...but Red Hat does owe us all a bunch of beer at the next ApacheCon!
-chris
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by jean-frederic clere <jf...@gmail.com>.
On 08/17/2015 01:10 PM, Mark Thomas wrote:
> The Apache Tomcat Project is proud to announce the release of version
> 1.2.41 of the Apache Tomcat Connectors.
> This version fixes one security issue (CVE-2014-8111) and a number of
> bugs found in previous releases.
Many thanks for the release and sorry for all the troubles around
CVE-2014-8111.
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Posted by jean-frederic clere <jf...@gmail.com>.
On 08/17/2015 01:10 PM, Mark Thomas wrote:
> The Apache Tomcat Project is proud to announce the release of version
> 1.2.41 of the Apache Tomcat Connectors.
> This version fixes one security issue (CVE-2014-8111) and a number of
> bugs found in previous releases.
Many thanks for the release and sorry for all the troubles around
CVE-2014-8111.
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org