RE: [ANN] Apache Tomcat Connectors 1.2.41 released
@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
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=. 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
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=. 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
-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=. 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-unsubscr...@tomcat.apache.org For additional commands, e-mail:
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
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=. 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
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
-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=. 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
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [ANN] Apache Tomcat Connectors 1.2.41 released
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
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [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. [...] Downloads: http://tomcat.apache.org/download-connectors.cgi Is there a binary release for Windows scheduled? Greetings, Jessica - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Unsubscibe On 19 August 2015 at 13:30, jean-frederic clere jfcl...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@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
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
