Re: Announcing releases of tomcat native
Yoav Shapira wrote: Hi, On 5/22/07, William L. Thomson Jr. [EMAIL PROTECTED] wrote: If possible when new versions of Tomcat native be announced on list? Seems Tomcat 6.0.13 requires 1.1.10. First I became aware of it, was when user reported the problem. Granted I should have discovered it before them when packaging and testing Tomcat 6.0.13 release. Either way would be easier to follow and be aware of if new releases were announced. Like is done for Tomcat and mod_jk. Granted I understand both of those require vote and etc before release. So more of an official release process there. Just not ideal to have to check download area for new releases. Thanks much :) You're right, we should be better about them. If the tcnative releases are not part of another voted-upon package, such as Tomcat itself or the Connectors, then they need to be voted upon separately. The PMC has to ratify them as releases, like all the other code we release. On the other hand, if they are included in Tomcat as bundles and not distributed separately, we don't need another vote. Just a note in the release notes about the tcnative version change. It is part of Tomcat release and that shouldn't change. Each tomcat release has a detection of the Tomcat native, and it prints out the suggested version compared with the one user is running. For 6.0.13 the required version is 1.1.8 and recommended is 1.1.10 and that is clearly printed whenever Tomcat is started. I'm not sure what more is needed. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Announcing releases of tomcat native
William L. Thomson Jr. wrote: On Wed, 2007-05-23 at 13:19 +0200, Mladen Turk wrote: For 6.0.13 the required version is 1.1.8 and recommended is 1.1.10 and that is clearly printed whenever Tomcat is started. I'm not sure what more is needed. According to the bug report, it required 1.1.10, and Tomcat failed to start with 1.1.8. http://bugs.gentoo.org/show_bug.cgi?id=179462 In that case this is the bug in Tomcat, cause required version should be 1.1.10 not 1.1.8 then. Anyhow, the point is to have Tomcat Native as part of Tomcat release. If for example we find a bug that would require a new version of Tomcat native, then 5.5.x and 6.0.x should be released as well with required version matching that. That is why I'm not in favor of having separate releases of the Tomcat Native, because we use the so called releases *only* to be able to build with ant more easily. Ideally the build.xml should build the binaries as well, and that's not going to happen in the near future :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Automatic detection of CPU/JVM for Win32/Win64
Hi, I've committed to the trunk the modified service.bat that automatically detects the host CPU (x86, amd64, ia64) and whether the JVM is 64 bit or not. So it automatically picks tomcat6.exe, amd64/tomcat6.exe depending on the above rules. However it requires that the .zip distro contains those executables (I've modified dist.xml) as well. (Since there were no objections to that) Any problem I commit those to 5.5.x and 6.0.x branches? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk build: threading detection broken
Rainer Jung wrote: I suggest, that we build against httpd 2.x always thread-safe, at least unless the existing flag -enable-prefork is used and document this behaviour. +1 Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c
Jean-Frederic wrote: On Mon, 2007-06-04 at 12:08 +, [EMAIL PROTECTED] wrote: Author: mturk Date: Mon Jun 4 05:08:33 2007 New Revision: 544137 URL: http://svn.apache.org/viewvc?view=revrev=544137 Log: Add simple URI normalizer that can deal with things like %252e%252e. This is mostly copy/paste from the IIS module Note that we should rollback http://svn.apache.org/viewvc?view=revrevision=538975 too, shouldn't we? Of course. It was already reported by lots of users that FWDURICOMPATUNPARSED breaks many current deployments where users expect the uri passed will be r-uri, not r-unparsed_uri. In such situation users are forcing the JK_OPT_FWDURICOMPAT anyhow, and are still suffering from security implications. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c
William A. Rowe, Jr. wrote: [EMAIL PROTECTED] wrote: Author: mturk Date: Mon Jun 4 05:08:33 2007 New Revision: 544137 URL: http://svn.apache.org/viewvc?view=revrev=544137 Log: Add simple URI normalizer that can deal with things like %252e%252e. This is mostly copy/paste from the IIS module You have me way confused ;-) Right. I confused many. Just look at the thread about the subject. Almost nobody understood what was I talking about. The uri you are processing in the httpd connector has already been unfolded. So your desire is to double-unfold the uri? No. Nothing is neither unfolded nor double unfolded. This is internal for map_uri_to_worker. How it works: Imagine you have two applications on Tomcat appA and appB, and you wish *only* to expose the appA via JkMount /appA/* worker Request: http://host/appA/%252e%252e/appB/ mod_jk 1.2.22 (with default passing r-uri) will serve /appB/ mod_jk 1.2.23 (with default passing r-unparsed_uri) will return 404 from Tomcat becasue it will pass the original uri, not the one Httpd already unfolded) mod_jk 1.2.24 will return 404 from Httpd because there is no JkMount /appB/* This has some very ugly side effects for legitimately escaped paths, and if it is a security precaution, don't you just leave yet-a-new-hole for triply-folded uris? Again, no. It doesn't touch the original uri. Request for http://host/appA/%252e%252e/appB/ will be unfolded by httpd to http://host/appA/%2e%2e/appB/ before it hits mod_jk. Inside map_uri_to_worker it will be unescped (locally) to /appA/../appB/ and the normalized to /appB/ and then it looks for mounted path. In case one have JkMount /* or JkMount /appB/*, the original uri host/appA/%2e%2e/appB/ will be passed to Tomcat. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c
Mark Thomas wrote: Did I mention that uri is *not* decoded twice? You did and I still don't agree. The root cause of CVE-2007-1860 was a double decoding. Once in httpd/mod_jk and once in Tomcat. Why do you don't agree? Please provide a use case and confirm your statements are legitimate. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c
Remy Maucherat wrote: Mark Thomas wrote: As I see it, we have two options: a) Prevent Tomcat from decoding the uri a second time at step 7 above b) Re-encode the uri in mod_jk between steps 5 and 6 I think: - it's the proxy which should have options for adapting to what the proxied server does - mod_jk is supposed to be a transparent proxy (and as such give Tomcat a non decoded uri); despite what it could break in httpd, decoding the uri at all is evil, since the character encoding used could be different from the one used in Tomcat So I am not in favor of a). Agreed. I mean the sole purpose of having a proxy in front of Tomcat is that this proxy actually *does* something, weather its a static content delivery, uri rewriting, load balancing, security, its irrelevant. The uri as well as the entire request thus might end up completely different then the one client originally issued. It might have a different uri, different headers, etc. However options a) and b) that Mark gave have nothing to do with what we actually need and what was the actual problem. The sole problem was how to prevent unwanted mappings, and 1.2.23 solved that by passing the original client uri thus skipping the entire httpd filter chain. This is very bad and doesn't solve the problem, because if the user needs thing like mod_rewrite he will need to re-enable the original 'JkOptions ForwardURICompat' making him again vulnerable to the CVE-2007-1860. My patch (again does *not* double encode the uri) on the other hand simply has a smarter JkMount detection and prevents the requests to the Tomcat that were not explicitly defined. The uri passed is the same one that was passed as default for so many years. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c
Mark Thomas wrote: Single ajp13 worker jkMount /jsp-examples/* worker1 A simple 'hello world' html file was created at (directories created where required): appBase/jsp-examples/%2e%2e/servlets-examples/index.html Test 1: Tomcat only http://localhost:8080/jsp-examples/%252e%252e/servlets-examples/index.html This correctly showed the index.html I created above. But this is oxymoron. You wish to serve the content from servlets-examples with only jsp-examples mounted. This is also the exact reason of CVE-2007-1860. My expectation is that: A) A request for http://host:port/jsp-examples/%252e%225e/servlets-examples/index.html returns the correct file for Tomcat standalone and httpd + mod_jk + Tomcat Use 'JkMount /* worker1' if you need something like that. The entire point of the story is that if you have *only* JkMount /jsp-examples/* then *only* that Context is allowed to be served. Even hitting the Tomcat (that happens with 1.2.24) is a security break. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r546531 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_global.h common/jk_url.c common/jk_url.h common/list.mk.in
Jean-Frederic wrote: Add ForwardURIProxy to the URl handling option. common/jk_url.c is just a porting of the routines from proxy_util.c (Apache httpd). After quite a few discussions, I think this should be the only mode available for URI handling, as the two others are broken. Comments ? Additionaly I want to rollback r544137 too. Why? Let's stop a bit and test things before. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r546531 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_global.h common/jk_url.c common/jk_url.h common/list.mk.in
Remy Maucherat wrote: Mladen Turk wrote: Why? Let's stop a bit and test things before. Jean-Frédéric proposes implementing the same behavior as mod_proxy, so I don't see how this can be a bad thing. First of all I didn't said it's a bad thing or anything like that. We need the same behavior on Apache and IIS (at least), so this patch needs to be tested on IIS and Netscape as well. Also I think we should consider and discuss do we really need extra directive or it can be done by using existing or default. That's why I suggested to stop for a while and see all the possibilities. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK3 roadmap?
jean-frederic clere wrote: I have noted that nothing has happened in tomcat/connectors/trunk/jk3. Nearly 2 months without real road map nor clear specifications, what is wrong? I don't think anything is wrong. We are waiting for the list of requirements, and any suggestion from yours or anybody else side is more then welcome. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r550789 - /tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
Remy Maucherat wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: mturk Date: Tue Jun 26 05:28:00 2007 New Revision: 550789 URL: http://svn.apache.org/viewvc?view=revrev=550789 Log: Do not pass session id if it is zero length. For now only log those attempts. We should consider returning 400 if the jsessionid is empty perhaps. This serves no useful purpose. What if jsessionid is one char long (let's say ' ') ? Is it more valid ? Since I didn't get an answer, I suppose I have to clarify. This means I am vetoing this commit (if someone needs to filter out certain requests based on this sort of constraints, they should use a valve or a filter instead, which is very easy to do). This is not a valid veto. There is not specification nor security reason that my patch would break. If something can be done by some third party (like Tomcat) is completely unrelated with the purpose of why the veto can be used. See: http://www.apache.org/foundation/voting.html#Veto However this is my opinion, so I'm not sure what to do next if you don't revoke your veto. I suppose we should ask someone more familiar with the subject to give a independent verdict. From technical POV my patch is correct because session id can be anything except null or empty string. Thus a ' ' is a legitimate JSESSIONID identifier, of course not necessarily with tomcat, but mod_jk can be used as frontend to other AJP protocol servlet engines. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r551809 - /tomcat/connectors/trunk/jk/native/common/jk_msg_buff.c
jean-frederic clere wrote: /* We checked for space !! */ -strncpy((char *)msg-buf + msg-len, param, len + 1); /* including \0 */ +memcpy(msg-buf + msg-len, param, len + 1); /* including \0 */ Why do you remove the (char *)? Cause memcpy uses void* so no need for casting. This is backport from mod_proxy_ajp BTW. Cheers, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature request /Discussion: JK loadbalancer improvements for high load
Yefym Dmukh wrote: Actually the following was happening: the LB sends requests and gets the session sticky, continuously sending the upcoming requests to the same cluster node. At the certain period of time the JVM started the major garbage collection (full gc) and spent, mentioned above, 20 seconds. At the same time jk continued to send new requests and the sticky to node requests that led us to the situation where the one node broke the SLA on response times. You have oxymoron here. With session stickiness you are willingly tear down the load balancer correctness because you don't wish/can have session replication. Even with the smartest LB and even with the two way communication it's only possible to make that working in non session stickyness topology. In other case you would loose sessions on each GC cycle. However like Rainer said the solution is to choose the appropriate GC strategy for web based application. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature request /Discussion: JK loadbalancer improvements for high load
Yefym Dmukh wrote: Actually the following was happening: the LB sends requests and gets the session sticky, continuously sending the upcoming requests to the same cluster node. At the certain period of time the JVM started the major garbage collection (full gc) and spent, mentioned above, 20 seconds. At the same time jk continued to send new requests and the sticky to node requests that led us to the situation where the one node broke the SLA on response times. You have oxymoron here. With session stickiness you are willingly tear down the load balancer correctness because you don't wish/can have session replication. Even with the smartest LB and even with the two way communication it's only possible to make that working in non session stickyness topology. In other case you would loose sessions on each GC cycle. However like Rainer said the solution is to choose the appropriate GC strategy for web based application. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature request /Discussion: JK loadbalancer improvements for high load
Yefym Dmukh wrote: You have oxymoron here. With session stickiness you are willingly tear down the load balancer correctness because you don't wish/can have session replication. Generally you are right, but the ideal world is not the reality: we use apache my faces implementation of jsf where the core session class size is about 500KB, the compression of state kills CPU, the size kills session replication/failover approach. So we have is what we have aqnd we are trying to get the best out of it. For 10 nodes the replication cost would be to high even for a smaller session class, but you can at least use domain clustering model, and slice that to 5x2 nodes. BTW, what about the bidirectional jvm-lb connection and the stop-the-world GC managed by lb, as keep it simple approach ? This won't help much. The sticky session requests must be served by the same node (group of nodes if using domain clustering), and your requests will still be delayed by the JVM instance GC cycle (It has to happen sometime, and you cannot depend on request void intervals) Of course since LB updates it's statistics after the request, and if the request is delayed, right now we cannot react proactive on queued requests, so new request can be delayed as well instead passed to the node that is not within the GC cycle (during the GC cycle itself). To solve the later problem we don't need the two-way communication, because this can be solved by the LB by taking into account the number of queued request as well, but we need it for a different things. However all this is major technology upgrade and it's part of JK3 roadmap, because it requires both protocol and substantial code change. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Removing the examples (JSP/servlet) in TC Binaries
jean-frederic clere wrote: Hi, The examples (servlet and JSP) have caused a list of security issues. I think we should remove them from the Tomcat binary packages (6.0 and 5.x at least). Any comments? If the examples are broken, then we have serious problems, either with examples or with the release itself. The sole purpose of examples should be that the they *must* work and that random user can use them as start point for his code. However, the packaging is irrelevant, and I would prefer to have them separate from the main distribution. IMHO that would give the clear message to our users that examples are what they are; 'just examples', and as such should not be part of the main binary distribution. So, having separate 'examples' package would probably be much better compared with the one that we have right now, although not sure for a 5.5.x, because of presumed content from previous releases. Of course, beside adding apache-tomcat-6.0.xx-examples.tar.gz we can comment out the examples from the config. So, in essence +1 to your proposal (at least for 6.0) IMO it makes sense, and breaks nothing. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat supporting PHP
Joe Nathan wrote: Henri Gomez wrote: Do you want a 100% Java PHP engine or just a simple native to Java bridge ? I mean PHP scripts are processed as JSP are handled inside Tomcat without installing any other things as built-in features. Imagine if Tomcat can handle JSP, PHP, even ASP script pages! Then who will not use this! Why would someone wish to do that at the first place. Those are completely different systems with completely different technology. The only usage is consolidation of the technology and lowering down the time for consolidation to a particular technology. The are some attempts for PHP like a simple CGI or a JBoss Reflex, and even some project (think its commercial) that has PHP engine and modules rewritten in Java. However their main usage is for easing you to switch to the real stuff (main Tomcat technology; jsp and servlets). Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK 1.2.24
+1 Rainer Jung wrote: Hi, we had exactly 10 downloads of our quality check tarball since the announcement yesterday. Three of the testers reported back positively (one of them via direct mail), no reports were negative. Since I received already a lot of positive feedback from the preceding internal testing (6 testers, 7 platforms, all web server types), I propose to tag 1.2.24 at 10:00 GMT and immediately start a vote. I hope the vote goes through, so we might announce the release early next week. All changes I did since the test tarball only affected the docs, no code change. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.24
Apache Tomcat Connectors 1.2.24 is: [x] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Serious regression in JK 1.2.24
Hi, We have a problem with 1.2.24 that luckily is not security leak, but it is security related. The problem is that 401 from Tomcat without body (a standard HTTP_UNAUTHORIZED) is treated as 401, meaning that Apache is returning 401 page instead passing 401 to the client. I already patched the SVN. Can we roll 1.2.25? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r562022 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml
Rainer Jung wrote: Hi Mladen, I don't full yunderstand this fix. From your other mail i though it's a regression, but the code in this region is the same at least since 1.2.18 (more than a year). So I have the impression, that this is not a regression. You can try 1.2.23 (it works). 1.2.24 doesn't. With patch it works again. I'm not sure if the patch is correct, because it might be that request_rec-sent_bodyct flag is setup differently in 1.2.24 If so, I would prefer to not push 1.2.25 through with very high speed, i.e. 1.2.24 would still be pretty useful as an update. But it doesn't work. You can try 1.2.23 with Tomcat manager app. The browser displays login window for username/password. 1.2.24 displays 401 page from Apache. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r562022 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml
Rainer Jung wrote: OK, I'll go into it. I think I would propose a slightly different patch, but I'll investigate, why 23 and 24 are different. The reason why I started to pose querstions is, that I found it a little strange to make an exception for exactly one status code. My impression is: the code was supposed to let httpd produce the error page in case we got an error status without any content. But: for a 401 we actually do get a body content from tomcat. So in fact something is wrong with sent_bodycnt. I'll investigate. Probably it is. I personally don't like my patch either, cause it's the kind of 'what other status might be bogus' thing. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r562090 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c
[EMAIL PROTECTED] wrote: Author: rjung Date: Thu Aug 2 05:10:48 2007 New Revision: 562090 URL: http://svn.apache.org/viewvc?view=revrev=562090 Log: Revert the quickfix r562022. It looks like we found the real problem with r562085. Perfect. The fix makes login working once again. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.24 withdrawal?
I agree. Remove 1.2.24 and include all the patches.
Let's roll that ASAP.
Regards,
Mladen.
Rainer Jung wrote:
I think the problem with JK 1.2.24 is big enough to release soon. I
would also suggest to officially withdraw 1.2.24 from the download and
web site (with a comment indicating the problem) so that people will not
run into more complex problems related to the missing flush. Although
we've got no indication, that there will be a security problem, the
missing flushing can lead to undefined behaviour.
Users needed to wait for a post 1.2.23 update for 2.5 months, so 1-2
more weeks will be OK.
Additionally the question is: should we include other fixes or strictly
only 1.2.24 + this fix. If we remove 1.2.24 I think the other fixes
listed below will be safe. I would propose to include them and run
through the usual Quality check + release cycle, we've done a couple of
times for JK.
r560736 (fuankg): additional defines in jk_globalh. if __GNUC__ is
defined for WIN32 or Netware. This should enable gcc builds on these
platforms. Looks like very low risk, because until now we don't support
building with gcc on these platforms, so the change looks like it can't
break anything.
r560739 (fuankg): Change in Netware Makefile for Apache 1.3. I think
Günter knows best, if this should be released.
r560823 (rjung): changed pid_t print format detection for Solaris.
Tested with gcc and cc for 32 Bit and 64 Bit build on Solaris Sparc. Not
tested for Solaris x86, but until now I think we do not actively support
this.
r560831 (rjung): Fix nsapi crash with debug log during startup. Very
local change, low risk.
r562085 (rjung): Fix 401 problem. That's the one we definitely need.
Outstanding changes:
fail on status
--
http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch
Improve nsapi shut down
---
Index: netscape/jk_nsapi_plugin.c
===
--- netscape/jk_nsapi_plugin.c (revision 562051)
+++ netscape/jk_nsapi_plugin.c (working copy)
@@ -320,14 +320,15 @@
uri_worker_map_free(uw_map, logger);
}
+if (init_map) {
+jk_map_free(init_map);
+}
+
+jk_shm_close();
wc_close(logger);
if (logger) {
jk_close_file_logger(logger);
}
-
-if (init_map) {
-jk_map_free(init_map);
-}
}
Improve nsapi returning correctly when errors occur
---
Index: netscape/jk_nsapi_plugin.c
===
--- netscape/jk_nsapi_plugin.c (revision 562051)
+++ netscape/jk_nsapi_plugin.c (working copy)
@@ -382,10 +382,14 @@
}
else {
if ((result == JK_CLIENT_ERROR) (is_error ==
JK_HTTP_OK)) {
+rc = REQ_EXIT;
+protocol_status(sn, rq, is_error, NULL);
jk_log(logger, JK_LOG_INFO,
service() failed because client aborted
connection);
}
else {
+rc = REQ_ABORTED;
+protocol_status(sn, rq, is_error, NULL);
jk_log(logger, JK_LOG_ERROR,
service() failed with http error %d,
is_error);
}
nsapi and shm
--
For Netware nsapi now has a build dependency on shm although it doesn't
use it. More generally, we need to check which way we should use shm for
nsapi on which platform. I think the nsapi and general platforms
considerations should not be done before 1.2.25, but everything else
looks OK to me.
Regards,
Rainer
Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
Author: rjung
Date: Thu Aug 2 05:10:48 2007
New Revision: 562090
URL: http://svn.apache.org/viewvc?view=revrev=562090
Log:
Revert the quickfix r562022. It looks like we found the real problem
with r562085.
Perfect. The fix makes login working once again.
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.25
Rainer Jung wrote: Apache Tomcat Connectors 1.2.25 is: [X] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r571006 - /tomcat/connectors/trunk/ajp/
[EMAIL PROTECTED] wrote: Author: markt Date: Wed Aug 29 18:14:11 2007 New Revision: 571006 URL: http://svn.apache.org/viewvc?rev=571006view=rev Log: Remove source for mod_proxy_ajp that moved to httpd some time ago. Why the hell did you do that? You could copy it to some sandbox or something, since there is lots of usable code in there like console mode httpd API client for testing modules, etc. In any case you should ask the community before doing something like that. Please revert. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r571006 - /tomcat/connectors/trunk/ajp/
William A. Rowe, Jr. wrote: Mladen Turk wrote: You could copy it to some sandbox or something, since there is lots of usable code in there like console mode httpd API client for testing modules, etc. It's trivial to svn cp -r 571005 https://svn.apache.org/repos/asf/tomcat/connectors/trunk/ajp/ OK. so I'm sure Mark meant well, even if he didn't notice there were non-module utilities hiding within that tree. Right. Deleting entire trees from SVN should at least be preceded by some note of intention. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r571175 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp_common.c xdocs/miscellaneous/changelog.xml
[EMAIL PROTECTED] wrote: Match header names exactly against pre defined constants. p += 6; -if (memcmp(p, CHARSET, 7) == 0) +if (strcmp(p, CHARSET) == 0) Someone would say that this is over engineering :) memcmp *is always* faster then strcmp I don't get it, what's the point? Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r571175 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp_common.c xdocs/miscellaneous/changelog.xml
Mladen Turk wrote: [EMAIL PROTECTED] wrote: Match header names exactly against pre defined constants. p += 6; -if (memcmp(p, CHARSET, 7) == 0) +if (strcmp(p, CHARSET) == 0) Someone would say that this is over engineering :) memcmp *is always* faster then strcmp I don't get it, what's the point? Oops. It makes sense for things like HTTP_CHARSET_FOO I should think twice before sending reply :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r571175 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp_common.c xdocs/miscellaneous/changelog.xml
Rainer Jung wrote: No problem, better safe than sorry. Right. It seems I always forget the ingenuity of the users that wish to extent the http spec :) However, I think that we can still use the memcmp with xxx\0. That would still be faster then figuring out the EOL with strcmp? Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r571175 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp_common.c xdocs/miscellaneous/changelog.xml
Rainer Jung wrote: Yes Mladen, I know. But we never really use len :) I know, that we can do it with memcmp, but then you, me or someone else has to add a couple of if(len=...) before each memcmp(). Go ahead if you like to. Look, we have a local header[16] on which we copy toupper, and there is no chance for overflow. Like said, we can test for xxx\0 and that'll be fine. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r571175 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp_common.c xdocs/miscellaneous/changelog.xml
Rainer Jung wrote:
+/* Always do memcmp including the final \0-termination character.
+ */
switch (header[0]) {
case 'A':
-if (memcmp(p, CCEPT, 5) == 0) {
+if (memcmp(p, CCEPT, 6) == 0) {
Right, but like said this should be a
if (memcmp(p, CCEPT\0, 6) == 0) {
memcmp compares bytes.
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connectors cleanup
Mark Thomas wrote: Hi, Following on from my previous over eager attempt to clean up the duplicate code in connectors I would like to propose the following - remove connectors/trunk/ajp/CHANGES - remove connectors/trunk/ajp/proxy - move connectors/trunk/ajp/ajplib to connectors/trunk/ajplib Thoughts? I propose we create connectors/sanbox and move the trunk/ajp/* code in there. ajp/proxy code can be removed of course. Later if we choose to use the existing code from ajplib as base for JK3 we can either put it inside trunk/jk3 or inside trunk/ajplib if we choose to have independent protocol library. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Draft for September 2007 Board report
Hi, We need to file the board report by next week for a board meeting on September 19th. Here is my draft, so please fill in the gaps, since it's my first one :) Thanks, Mladen Apache Tomcat Board Report, September 2007 Summary -- The project continues to be active on a number of fronts. There are no issues requiring Board attention at this time. Releases - We cut a number of releases incorporating all our active branches. Tomcat 5.5.25 is going to be released in few days. Tomcat 6, the current production branch, had one releases this past quarter: 6.0.14, which is the latest stable Tomcat at this time. Finally, the Tomcat connectors, mainly mod_jk, has a couple of releases as well: 1.2.24 and 1.2.25. However we had to revoke the 1.2.24 release because of serious regression that sliped trough the testing phase. Security The Tomcat security site (http://tomcat.apache.org/security.html) has been getting more love and attention. It now contains the vast majority of known issues and fixes for all Tomcat branches. We've been working closely with security issue reports and the Apache Security committee on quickly replying to issues, resolving them, and coordinating public disclosures. There exist few open security issues at the moment. The fixes are already in SVN, and most of them are already incorporated with 6.0.14 and 5.5.25 releases. Development --- There is ongoing discussion about the purpose of the current code inside Tomcat 6 trunk, and the majority of developers have agreed to put the trunk into the sandbox. Community - After last quarter's new committers and PMC members, there were no changes the committership nor PMC membership this time. Mladen Turk was elected as new PMC Chair and voted by the ASF Board. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r572181 - in /tomcat/connectors/trunk/jk/native/common: jk_ajp12_worker.c jk_ajp_common.c jk_jni_worker.c jk_status.c
[EMAIL PROTECTED] wrote: Author: rjung Date: Sun Sep 2 15:50:40 2007 New Revision: 572181 URL: http://svn.apache.org/viewvc?rev=572181view=rev Log: - Document return codes of the service() method for all worker types (lb still missing). Below is for jk_ajp_common.c: - Document return codes of ajp_send_request() and ajp_get_reply(). - Fix log message typo - Don't use the recovery_options for idempotent GET and HEAD in case we already sent the headers. - We don't need to handle JK_FATAL_ERROR for ajp_process_callback() in ajp_get_reply(). - Handle JK_INTERNAL_ERROR instead of JK_SERVER_ERROR for ajp_process_callback() in ajp_get_reply(). - Add some logging for unexpected default case in return code handling. - Move complete handling of return codes of ajp_send_request() in front of return code handling for ajp_get_reply() in service(). - Some XXXs still open: return codes, is_error and op-recoverable for unexpected cases. We still need a better design for returning enough information from service() of a member to an lb, such that the lb can decide about recovery and if the member should be put in error state. Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c tomcat/connectors/trunk/jk/native/common/jk_jni_worker.c tomcat/connectors/trunk/jk/native/common/jk_status.c Huh, this is one huge single commit :( I must say it's really hard to follow something like that, and now I see that I'll for sure never do again something like that by myself. Can we in the future try to make the commits that a single-topic related? I know it's additional hassle, but lot less then the one when someone really tries to understand the patch. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r572181 - in /tomcat/connectors/trunk/jk/native/common: jk_ajp12_worker.c jk_ajp_common.c jk_jni_worker.c jk_status.c
Rainer Jung wrote: Hi Mladen, I'm fine with rolling back and committing in steps. No need to do that. Let's just take more care in the future. It'll be much easier to follow the commits thought. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connectors cleanup
Mark Thomas wrote: Mladen Turk wrote: I propose we create connectors/sanbox and move the trunk/ajp/* code in there. ajp/proxy code can be removed of course. Could we just move it to tomcat/sandbox as that already exists? We need connectors/sandbox anyway, so IMHO it's a good initial reason. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Make released versions RTC
Henri Gomez wrote: Well what's the consensus on Java projects, like Xerces, Xalan or Lucene ? It doesn't mater how other project do things. It's irrelevant. We had CTR policy till now and it was working. Now we have a new situation with different developers POVs, and cause of that, this requires a different set of rules. Do we need it? Yes, if we wish to survive as a project. It's pain in the ass, I know, but IMHO it's also the only way to get some sense in this chaos. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Make released versions RTC
Yoav Shapira wrote: Hi, On 9/6/07, Mladen Turk [EMAIL PROTECTED] wrote: Do we need it? Yes, if we wish to survive as a project. It's pain in the ass, I know, but IMHO it's also the only way to get some sense in this chaos. I disagree. I think the current CTR policy has worked just fine and can continue to work jsut fine. If you read my post I was careful enough to not mention the RTC policy. All I was saying is that current CTR caused too many problems, because trunk was our stable branch, and disagreement on API caused drastic things like putting trunk to sandbox etc. All that could be prevented if we had trunk with CTR and stable branch with RTC policy (or something like, that would give more stability to the stable branch). It's obvious that Filip and Remy have two different views on the subject, and all of us are influenced by that. Jean-Frederic, myself, and some other folks think this has to stop, and the easiest way is to comply to some rules that are already in place within different ASF projects. This won't prevent the security issues, cause those have priority and don't need to comply to the RTC (or something like) policy. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Make released versions RTC
Remy Maucherat wrote: To give an idea, tis could mean: - API changing patches (any protected or above signature change) - code changes in the critical path (for example, code which gets executed on each HTTP request) Fine. - any other commit for which a committer asks for the RTC procedure should be rollbacked if it hinders concurrent work, and go through the RTC procedure This looks like a conditional veto that can be voted over. Perfect! IIUC it means that instead veto one asks for a vote (+3 votes), right? Looks like RTC on demand, that would require some sort of lazy consensus. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Old CVS repository of Tomcat
Beat Fluri wrote: Hi, As a member of the Software Engineering group of the University Zurich, Switzerland, I'm investigating the evolution of software systems. For this, I'd like to use Tomcat as a case study. Unfortunately, our tools are limited to CVS and not yet fully adapted to Subversion. Is there a possibility to get an old version of the former CVS repository of Tomcat? I would very appreciate to get Tomcat as a case study. Think not. It has nothing to do with Tomcat but as ASF at large. I'd suggest you upgrade your tool to SVN Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml
Bill Barker wrote: Now, I'd prefer that TC is just the Servlet/JSP container that it is meant to be, and not try to add on proprietary features. But that is just me ;). You are not the only one ;) Seems we have lost the clear vision of the project somewhere in the flame wars. It has become a common rule rather then a exception that code gets committed without any prior discussion. Although this particular patch might be useful, bringing it inside in the middle of the branch lifetime is something unacceptable without prior discussion, notifying users about TODO long before the actual release having that feature will appear. From a user PoV this makes each Tomcat release as *surprise* with a question WTF changed from the last version. Tomcat6 is now at version 6.0.14 and who can tell what 6.0.15 will look alike? Not to mention the 6.0.20 :) This simply has to stop. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml
Filip Hanik - Dev Lists wrote: Mladen Turk wrote: This simply has to stop. taking trunk away, this turn of events is expected. I wish everyone would have thought of that before we got caught up in the personal, and not what is important, trunk debate. I did, as well others did (I hope) I'll vote +1 for bringing trunk back any time when I see your TODO list. Sorry but without that Tomcat6 is not Tomact6 but rather your personal (and anyone else) playground. As a commiter you have the privilege to direct development, but also the responsibility to appreciate other commiters opinions. For example, if I would like to commit something I might very well step on someone else toe just because there is no TODO listing what you or anyone else is currently working on, what the next release will look alike and what features it'll have. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review model take 2
+1 as well. Seems we have come to some sort of conclusion. (At least the proposal holds the majority of votes) I'll left this tread for a day or two and then create an official proposal draft we can vote on. If thats accepted, I'll create needed documents like STATUS, ROADMAP containing that draft as header. I can also create a xml that can be added to the t.a.org (updating http://tomcat.apache.org/getinvolved.html perhaps?) Regards, Mladen Remy Maucherat wrote: Hi, Another more precise draft. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Export Notification Requirements
William A. Rowe, Jr. wrote: Hey folks, as you provide the bindings to the JSSE, even though you don't ship the JSSE .jars - we still need Tomcat in compliance with the federal export notification policies. I know you did some work on this in the past, but please see http://www.apache.org/dev/crypto.html I suppose we would need the same for Native connectors that uses OpenSSL. Up till now we are using Irelands Heanet to host the binaries. Please advice what's needed to be done to get the ECCN numbers. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Export Notification Requirements
William A. Rowe, Jr. wrote: it's sort of a closed loop problem. Update the info, allow the usual one hour after updating from minotaur to sync, and then shoot out the notice referencing the list of notices sent :) Can we get an example email that needs to be send and an email address? The page you referred looks pretty confusing with lots of links ;) Think wee need to have both JSSE and OpenSSL referenced. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Export Notification Requirements
William A. Rowe, Jr. wrote: Mladen Turk wrote: William A. Rowe, Jr. wrote: it's sort of a closed loop problem. Update the info, allow the usual one hour after updating from minotaur to sync, and then shoot out the notice referencing the list of notices sent :) Can we get an example email that needs to be send and an email address? The page you referred looks pretty confusing with lots of links ;) Think wee need to have both JSSE and OpenSSL referenced. Please review the section Notify the U.S. Government of the Release and let me know of any suggested changes, or ask about the confusing paragraph so I can rewrite it. Argh. I was looking at the wrong location. I'll try running the tool. However, not sure what to do with JSSE and how to reference those. Is http://java.sun.com/javase/technologies/security/ enough? They tend to change the uri often ;) Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.25, JkEnvVar evaluated too many times
Ian Ward Comfort wrote: (I've heard this list is a good place to discuss mod_jk code; please redirect me and accept my apologies if it is not.) No, this is correct place :) containers. By adding some additional instrumentation to the code, I can see that each AJP packet is constructed with ((1 + 17) * 13) = 234 envvar attributes -- the whole set of attributes is appended 18 times in succession. (Often this overflows the default maximum packet size.) Can you use JkLogLevel debug and attach the packet dumps as well as the the config? Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tcnative-1 and windows vista pro 32 bits
Henri Gomez wrote: Here is the dump You should know by now that apache mailing doesn't allow large attachments, zip files, etc... :) Put a link somewhere Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VirtualHost inheritance (was Re: [Bug 43753] ...)
Ian Ward Comfort wrote: I don't know if this is intended behavior, or a bug in mod_jk, or even a bug in Apache, but something seems amiss. Thoughts? Your patch won't work. The real problem is in the initialization for vhosts where when there is *any* Jk directive the create_jk_config is called while where there isn't the clone_jk_config is called. clone_jk_config is bogus, and doesn't behave like it should (copy only the basic data and no mounts) Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VirtualHost inheritance (was Re: [Bug 43753] ...)
Ian Ward Comfort wrote: clone_jk_config is bogus, and doesn't behave like it should (copy only the basic data and no mounts) Was this function introduced since 1.2.25? Yes, I was talking about trunk not 1.2.25 Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
According to the release process, the 6.0.15 tag is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable Thumbs up for Linux, win32 and win64! Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r593943 - /tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
[EMAIL PROTECTED] wrote: Author: rjung Date: Sun Nov 11 11:22:23 2007 New Revision: 593943 URL: http://svn.apache.org/viewvc?rev=593943view=rev Log: Undo revision 593927. This produced a mem leak for vhosts with private JkMounts. No idea why. Because uw_map is now allocated *only* if uri_to_context is allocated. In other cases uw_map is pointer to the parent allocated uw_map. So if you free uw_map with uri_to_context equals NULL, you'll actually have a double free of the same pointer. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r593943 - /tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
Rainer Jung wrote: P.S.: I hope the other changes are fine with you? They look OK, but I'll double check, just in case ;) Cheers, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r596747 - /tomcat/connectors/trunk/jk/native/common/jk_util.c
Mladen Turk wrote: Rainer Jung wrote: But I'm open. If we remove the const, we also need to remove it for the log_fmt (got as compiler warning also there, but don't have the line number at hand). Which would you prefer? Do you see a problem with the const, like wrong compiler optimization or so? Yes, that's a problem. Something const should never be fed to a free. I don't see a problem if we have an char[] for each of them and simply do a strncpy instead having duality for the same thing. The other solution is to have a char* and always call free. When we need to assign const char* we call strdup(foo) Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r596761 - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/catalina/core/ java/org/apache/catalina/startup/ java/org/apache/tomcat/util/net/ res/
[EMAIL PROTECTED] wrote:
Author: jim
Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=596761r1=596760r2=596761view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Tue
Nov 20 10:19:00 2007
@@ -858,7 +858,7 @@
try {
// Need to create a connection to unlock the accept();
if (address == null) {
-s = new java.net.Socket(127.0.0.1, port);
+s = new
java.net.Socket(InetAddress.getByName(localhost).getHostAddress(), port);
Although fine related to the localhost address, this will need to get changed.
The problem is with IPV6 cause in case the bind address is IPV6 the
unlock should be s = new java.net.Socket(::1, port);
On some platforms APR doesn't listen on IPV4 and IPV6 like FreeBSD and Windows.
It's not something related to this patch but something related to the
concept itself.
The best approach for unlock IMO would be to use the actual bind address,
but again there is a problem with NULL for IPV4/IPV6 and the fact that
we'd need to figure out the IP for each of them (localhost).
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Monitor Configuration
RafaQuiM wrote: Hello, I'm having problems using the TomcatMonitor (tomcat4w.exe) when trying to access a WinXp net file from a Servlet due to the console uses the SYTEM user (user.name property) as credentials. Does anybody know how to configure tomcatMonitor in order to use the logged user? I've tried changing parameters in Log tag but no success. Those are only for running detached java.exe. Change the logon properties directly in Services control panel for the Tomcat service. BTW, this is dev list. You should use user list for such questions. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing process for JARs for Maven Central
On 12/16/2011 08:56 PM, Mark Thomas wrote: All, I know option 1 works ... Does anyone else have any requirements / views that would suggest one approach is better than the other? If it ain't broken don't fix it. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/17/2011 09:24 PM, Antonio Petrelli wrote: As requested here is a proposal to move to Maven. I simply cannot understand why some folks have almost religious fascination with Maven. I know many projects that have move from Ant to Maven and are now either switched back or gone to some other solution like Gradle or are in the active process of seeking the alternative. I won't support such a transition at this moment. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/19/2011 06:12 PM, Pid wrote: On 18/12/2011 08:37, Mladen Turk wrote: On 12/17/2011 09:24 PM, Antonio Petrelli wrote: As requested here is a proposal to move to Maven. I simply cannot understand why some folks have almost religious fascination with Maven. I know many projects that have move from Ant to Maven and are now either switched back or gone to some other solution like Gradle or are in the active process of seeking the alternative. I was wondering if someone would mention Gradle. If there's a build tool shootout to be had, Gradle should get fair consideration. Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. E.g I know that Hibernate switched from Maven to Gradle just because maven But then we are back at original question. What's the benefit and do we have a problem that cannot be done using existing technology? Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. Amount of work we invest in build.xml is negligible compared to the rest of the codebase, and I expect maven will provide such environment. If not, meaning we would need a couple of developers hacking pom's all the time, then a big -1. Cheers -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/19/2011 07:47 PM, David Jencks wrote: Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. And that relates to this thread in exactly which way? You guys did that for Geronimo, fine, great, super. Here we speak that we should replace entire Tomcat build system with maven, meaning, multiple arches, creating windows installer, etc. I don't see any of those in Geronimo. All I'm saying, if you can do it, you're welcome. I'd like to see 'ant release' using 'mvn release' before someone breaks trunk. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/19/2011 08:58 PM, Romain Manni-Bucau wrote: There is a big part of tomcat which doesn't need maven because it doesn't need to be standard (the installers are a great example). Installer is just ant exec task with some filtering for getting the versions correctly. We have multiple release artifacts using different compressors having different line endings, so I suppose that would stay with ant as well. I spoke about the common part which is today not obvious because of the false modularity of the project. So it would be ant + maven I suppose. Fine, who's gonna do it and maintain? Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/19/2011 09:13 PM, Romain Manni-Bucau wrote: I don't know if it is because i used more maven than ant but when i checked out tomcat the first time i wondered where was modules (corresponding to jars). OK, this is the first thing I can agree with you. But It has nothing to do with toolkit used. Repository reorganization to match the .jars we produce could be done with or without maven. Also producing jars is just one part of release process. I'm afraid that amount of tasks that either cannot be done by maven, or it would require a huge effort and bunch of custom mojo's is just not worth the effort. But like I said (hate to repeat myself). Anyone is welcome to volunteer and propose a working solution that won't require more work on release tools when making a release compared to the existing system. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/19/2011 09:13 PM, Romain Manni-Bucau wrote: because developers can't know both? Since it seems you are familiar with maven, what is your opinion about maven ant tasks? Seems to me it offers full power of Ant, almost seamless transition, with the option to use maven deploy and dependency tasks where appropriate. Since those tasks look like any other ant task think it could be easily digested by this community. OTOH, we'd still have some dependency issues with JDT, daemon native, tomcat native, so it would be only partial solution, but given that it would effectively behave like extension to our download task I can live with the extra complexity. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/21/2011 09:34 PM, Olivier Lamy wrote: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. We must at least create 7.1.x branch for such a crucial change. Otherwise no one will be able to apply custom patches to the exiting code base. BTW, Oliver, it looks really nice! Have couple of suggestion, but we need to solve #1 first. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/21/2011 10:24 PM, Mark Thomas wrote: On 21/12/2011 21:21, Mladen Turk wrote: On 12/21/2011 09:34 PM, Olivier Lamy wrote: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. We must at least create 7.1.x branch for such a crucial change. I'm not sure we need a new branch if the end result is going to be the same. Well, we would screw anyone doing derivative work, that's for sure. Also any distribution packaging tomcat will have serious problems as well since almost all of them use package dependencies instead download or maven tasks. Eg, take a look at https://github.com/vanaf/tomcat7-fedora/blob/master/tomcat.spec OpenSuse is almost the same (they add some Geronimo dependencies however) In essence no packages will be able to change the version unless he rewrites the .spec or debian files from scratch thought. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/21/2011 11:01 PM, Mark Thomas wrote: On 21/12/2011 21:57, Mladen Turk wrote: In essence no packages will be able to change the version unless he rewrites the .spec or debian files from scratch thought. Ouch. That is argument for only doing this in trunk, if we do it at all. Right. Up till now all linux distributions were using tomcatX, so yes, Tomcat8 (trunk) is the logical target. Still need to figure out how to merge patches if we go that way. If they do not span across new 'modules' it should be just making sure they are executed using 'patch -pX' so that correct number of directory entries is stripped from patch header. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket progress report
On 01/24/2012 10:15 PM, Mark Thomas wrote: I have made some further headway with this and the latest patch is on people.a.o [1]. How that relates to Servlet spec 3.1? Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SPDY support
On 02/15/2012 04:53 AM, Costin Manolache wrote: Uploaded another take. For non-SSL ( JIO, and apr without ssl ) - SPDY just kicks in on all connections, this is just a short-cut for testing. I could also define a SpdyProtocol and set it directly on the connector - but seems too much overhead for something that is testing/experimental. If we are going to consider this as AJP alternative (++1) then the SSL would definitely be handy (doesn't have to be TLS in that case, although some contemporary JVMs might support it) One of the major problems why users choose https over ajp for server-server communication is that (viable or not) So I'm not sure how SPDY is 'customizable' for allowing different transport layers. eg. can it use SSLv23 instead TLSv1 Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.26
On 02/17/2012 09:00 PM, Mark Thomas wrote: The proposed 7.0.26 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 7.0.26 Stable Looks good ... nothing much to say :) Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1291760 - in /tomcat/native/branches/1.1.x: native/src/address.c xdocs/miscellaneous/changelog.xml
On 02/21/2012 03:06 PM, Konstantin Kolinko wrote:
2012/2/21mt...@apache.org:
@@ -58,6 +70,13 @@ TCN_IMPLEMENT_CALL(jlong, Address, info)
sl = sa;
}
}
+if (sp) {
+/* Set the provided scope id
+ * APR lack the api for setting this directly so lets presume
+ * the sin6_scope_id is present everywhere
+ */
+sl-sa.sin6.sin6_scope_id = scope_id;
Maybe guard the above with #if APR_HAVE_IPV6 , like the first code
fragment in this patch?
Check the full code not just patch. It is inside APR_HAVE_IPV6
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1291760 - in /tomcat/native/branches/1.1.x: native/src/address.c xdocs/miscellaneous/changelog.xml
On 02/21/2012 03:06 PM, Konstantin Kolinko wrote: 2012/2/21mt...@apache.org: I wonder when this change will be ported to native/trunk. (Just wondering. No real interest though). We currently have only 1.x release which is from this branch. Trunk will be 2.x and will require apr-2.x I plan to add support for scope_id directly inside APR so trunk will have different code. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Release Tomcat Native 1.1.23
Hi, We have couple of bugs fixed and its been quite a while since 1.1.22. There is also few trivial bugs and patches in BZ which I plan to solve. I volunteer as RM for 1.1.23. Objections, comments? Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Release Tomcat Native 1.1.23
On 02/21/2012 09:56 PM, Costin Manolache wrote:
On Tue, Feb 21, 2012 at 12:51 PM, Rainer Jungrainer.j...@kippdata.dewrote:
On 21.02.2012 21:30, Costin Manolache wrote:
Is this going to be from head ? How can I get the NPN ( sslext.c )
included
?
Mladen is aiming for 1.1.23, so he will be releasing from the 1.1.x branch.
What's the process for backporting ? The main change is adding a file, so
it should be pretty safe.
Not sure if that code is safe and I doubt it'll compile on all platforms,
E.g
TCN_IMPLEMENT_CALL(jint, SSLExt, setSessionData)(TCN_STDARGS, jlong tcsock,
jbyteArray buf, jint len)
{
unsigned char bytes[len];
^^^
This is not valid C code, although some compiler might allow it.
You would need to use malloc for that buffer since the 'len' is not known in
advance.
BTW, what's the purpose of this code? Seems it requires java API as well, so
not sure if that's present in all tomcat versions 1.1.23 is supposed to run.
However if not used I don't care ;)
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Release Tomcat Native 1.1.23
On 02/22/2012 06:17 AM, Costin Manolache wrote: Mladen: please let me know if you want to further review the change or should I merge it to the branch. Well I personally would not merge that into 1.1.x branch. It would be a bit weird to have 1.1.22 as is, and 1.1.23 with whole bunch of new features and API's. That's not why we introduced branches at the first place. I also noticed there are few other diffs - in particular the 'interrupt' stuff in poll, few others. Any plans to merge them too ? Nope. Not to the 1.1.x branch What's the plan with the trunk ? We can release 1.2.0 from trunk. I see no problem with that. It requires apr-1.4.x so this might be a solution for that sslext code instead porting that back to 1.1.x We can require 1.2.x for tomcat8 and actually use that new API's without worrying on backward compatibility. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1292127 - /tomcat/native/trunk/native/src/sslext.c
On 02/22/2012 05:52 AM, cos...@apache.org wrote:
Author: costin
+ if (len TCN_BUFFER_SZ) {
+ return -1;
+ }
Suppose that the len is presumed to always be shorter then 8K.
char * requestedTicket = apr_pcalloc(tcssl-pool, len);
suppose this can be be just
jbyte *requestedTicket = apr_pcalloc(tcssl-pool, len);
so that you don't need to cast later to jbyte*.
+ if (len TCN_BUFFER_SZ) {
+ return -1;
+ }
should be 'if (len TCN_BUFFER_SZ)'
Could you arrange the code style of this file.
I mean it uses tabs instead spaces, doesn't have spaces between operators,
C++ comments and so on.
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Release Tomcat Native 1.1.23
On 02/22/2012 03:54 PM, Costin Manolache wrote: On Tue, Feb 21, 2012 at 11:11 PM, Mladen Turkmt...@apache.org wrote: Well I personally would not merge that into 1.1.x branch. It would be a bit weird to have 1.1.22 as is, and 1.1.23 with whole bunch of new features and API's. That's not why we introduced branches at the first place. That's right, I agree. OK, so 1.1.x stays as is. I see no problem with that. It requires apr-1.4.x so this might be a solution for that sslext code instead porting that back to 1.1.x sslext works best with openssl 1.0.1 beta 2 ( i.e. latest ) - to get npn working with older ssl it needs a patch ( nodejs, chrome do this ). But it compiles and just lacks the npn feature without the patch. So for me a 1.2.x with recent apr and openssl would be best. Cool, lets then cleanup the code in trunk and go for 1.2.x release after we cut 1.1.23. OK? 1.1.x would be in feature freeze state after we release 1.2.x. I'd like we make 1.2.x mandatory for tomcat8 together with removing all the code that checks for missing API. And finally after APR-2.0 gets released we can create 1.2.x branch and make trunk as 2.0.x since with APR-2 abi will change. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Release Tomcat Native 1.1.23
On 02/22/2012 05:47 PM, Costin Manolache wrote: On Wed, Feb 22, 2012 at 8:13 AM, Mladen Turkmt...@apache.org wrote: One thing I would appreciate help with: I would like to have an option to statically link openssl and apr into the tc-native .so - I mean use openssl.a, apr.a. You mean for unixes? The solution would be to create stub libssl.so and libcrypto.so so that libtcnative don't carry their SONAME and link to system so.x... Static linkage is not a good idea I'm afraid. The reason is to avoid the system libraries which will probably have the wrong version. Right. Having stubs, libtcnative will always link to libssl.so which is usually symlink on any system. At runtime we can check for SSL_version and fail in case it has wrong ABI. However, not sure why you wish to do that. Many distros already provide tomcat-native so there's no real point for doing that, especially since we should not distribute unix binaries. Regards. -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Release Tomcat Native 1.1.23
On 02/22/2012 07:22 PM, Costin Manolache wrote: On Wed, Feb 22, 2012 at 9:12 AM, Mladen Turkmt...@apache.org wrote: However, not sure why you wish to do that. Many distros already provide tomcat-native so there's no real point for doing that, especially since we should not distribute unix binaries. Yes, distros provide tomcat-native, apr and openssl - with the 'stable' releases. I'm trying to provide a way for people to build libtcnative-2.so so it can be installed on those systems along with the existing apr, openssl and libtcnative-1, without requiring the installation of 2 versions of openssl, apr. Right if its --with-apr-static --with-openssl-static it could be a valid solution for someone that needs such specific deployments. It seems to work for me on linux ( using cmake ) - I get a tcnative.so with all the openssl/apr code linked in, without dependencies to libapr.so ( no SONAME ). No need for cmake. This can be done with gnu tools. I'll enable that when I catch some time. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1292891 - /tomcat/trunk/bin/daemon.sh
On 02/23/2012 08:00 PM, Konstantin Kolinko wrote: 2012/2/23ma...@apache.org: Maybe: while [ -n $1 ] (though both variants should work work) Some solaris shells misbehave on -n. do - case $o in + case $o=1 in What the above line is about? Was it supposed to be: case $1 in Right, Mark probably made a typo while copying the code form 7.0.x Fixed that (hope mark won't mind :) Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Release Tomcat Native 1.1.23
On 02/22/2012 07:22 PM, Costin Manolache wrote: On Wed, Feb 22, 2012 at 9:12 AM, Mladen Turkmt...@apache.org wrote: I'm trying to provide a way for people to build libtcnative-2.so so it can be installed on those systems along with the existing apr, openssl and libtcnative-1, without requiring the installation of 2 versions of openssl, apr. Just committed a brief howto inside native/BUILDING See the last paragraph and check if it works for you. No need for cmake and stuff. The only needed thing is to comment or remove two lines from libapr-1.la file before building tomcat-native. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Native components builds on Gump
On 02/24/2012 10:07 AM, Konstantin Kolinko wrote: Hi! Thanks to Stefan Bodewig work to resolve issue with expat configuration on Gump, APR now builds successfully there, after failing for more than 1 year. So projects that depend on APR and/or HTTPD now have a chance to be built, after being in Prerequisite Failed state for long time. One of such modules is tomcat-connectors-native with project jakarta-tomcat-jk-native. Maybe someone can take a look at what is going on there? It is currently failing during make: http://vmgump.apache.org/gump/public/tomcat-connectors-native/jakarta-tomcat-jk-native/index.html [[[ mod_jk.c: In function ___init_ws_service___: mod_jk.c:787: error: ___conn_rec___ has no member named ___remote_ip___ mod_jk.c:788: error: ___conn_rec___ has no member named ___remote_addr___ mod_jk.c:1104: error: ___conn_rec___ has no member named ___remote_ip___ mod_jk.c:1104: error: ___conn_rec___ has no member named ___remote_ip___ make[1]: *** [mod_jk.lo] Error 1 make[1]: Leaving directory `/srv/gump/public/workspace/tomcat-connectors-native/native/apache-2.0' make: *** [all-recursive] Error 1 Wrong httpd headers been included. BTW, not sure if that makes sense at all. It's just one platform and one webserver. We have much wider targets (same for tomcat-native) Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Release Tomcat Native 1.1.23
On 02/24/2012 11:12 AM, Henri Gomez wrote: I just notice this 'release' Did you release a source tarball ? Nope, will tag later today or over the weekend (depends on weather conditions :) Cheers -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1293119 - in /tomcat/native/branches/1.1.x: native/configure.in native/include/ssl_private.h native/src/sslutils.c xdocs/miscellaneous/changelog.xml
On 02/24/2012 06:31 PM, Felix Schumacher wrote: Am Freitag, den 24.02.2012, 07:43 + schrieb mt...@apache.org: +AC_ARG_ENABLE(ocsp, +[AS_HELP_STRING([--enable-openssl],[Turn on OpenSSL OCSP verification support])], I think the help string should read --enable-ocsp. Right. Good catch! Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
tomcat-native 1.1.23 test run r1293352
Hi, I have made available soon to be 1.1.23 release at http://people.apache.org/~mturk/native/r1293352/ So please test before I make tag. Notice -- There is one change in distribution layout. There is no more binaries/win32/ with individual files. Instead there is binaries/tomcat-native-$version-win32-bin.zip with the layout that can directly expand inside tomcat home. It was just too many files user need to download (as well as we during the build time) and IMHO its safer to ship .zip file instead .dll or .exe directly. It also carries LICENSE and NOTICE files (not sure about KEYS) cause its always better to use one from www.apache.org/dist Modifying tomcat build.xml should be quite simple to use that single file instead downloading multiple .dll's so if OK, I'll modify that after the 1.1.23 release. Comments? Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat-native 1.1.23 test run r1293352
On 02/24/2012 07:15 PM, Mladen Turk wrote: Hi, I have made available soon to be 1.1.23 release at http://people.apache.org/~mturk/native/r1293352/ Please use: http://people.apache.org/~mturk/native/r1293383/ Inside binaries there is now win32-bin.zip and win32-ocsp.zip with the latest having OCSP compiled in (still experimental) The versions in r1293352 had OCSP compiled in so not for production. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat-native 1.1.23 test run r1293352
On 02/26/2012 03:39 PM, Rainer Jung wrote: On 24.02.2012 20:33, Mladen Turk wrote: On 02/24/2012 07:15 PM, Mladen Turk wrote: Hi, I have made available soon to be 1.1.23 release at http://people.apache.org/~mturk/native/r1293352/ Please use: http://people.apache.org/~mturk/native/r1293383/ Inside binaries there is now win32-bin.zip and win32-ocsp.zip with the latest having OCSP compiled in (still experimental) The versions in r1293352 had OCSP compiled in so not for production. Are the versions of APR and OpenSSL given in jni/native/srclib/VERSIONS the ones you were using? Yes. Plan to make that always in sync in the future. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat-native 1.1.23 test run r1293352
On 02/26/2012 04:19 PM, Rainer Jung wrote: Hi Mladen, On 24.02.2012 20:33, Mladen Turk wrote: On 02/24/2012 07:15 PM, Mladen Turk wrote: Hi, I have made available soon to be 1.1.23 release at http://people.apache.org/~mturk/native/r1293352/ Please use: http://people.apache.org/~mturk/native/r1293383/ The xdocs folder and the jni release script are excluded from the src distro. Is that intentional? Yes. It contains generated docs from xdocs. jni release is for making those files from SVN, so no purpose in .zip Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat-native 1.1.23 test run r1293352
On 02/24/2012 08:33 PM, Mladen Turk wrote: Please use: http://people.apache.org/~mturk/native/r1293383/ Inside binaries there is now win32-bin.zip and win32-ocsp.zip with the latest having OCSP compiled in (still experimental) The versions in r1293352 had OCSP compiled in so not for production. I'll leave that cut till tomorrow for any additional overview. If no other comments received I'll create 1.1.23 about 12:00 GMT tomorrow. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1293202 - /tomcat/native/branches/1.1.x/jnirelease.sh
On 02/26/2012 04:58 PM, Rainer Jung wrote:
On 24.02.2012 13:09, mt...@apache.org wrote:
JKJNISVN=$SVNBASE/${JKJNIEXT}
if [ x$JKJNIEXT = xtrunk ]; then
- JKJNIVER=`svn info ${JKJNISVN} | awk '$1 == Revision: {print $2}'`
-elif [ $USE_BRANCH -eq 1 ]; then
- JKJNIBRANCH=${JKJNIEXT}
- JKJNISVN=$SVNBASE/branches/${JKJNIBRANCH}
- JKJNIVER=${JKJNIBRANCH}-`svn info ${JKJNISVN} | awk '$1 == Revision: {print
$2}'`
+ i=`svn info`
+ JKJNIVER=`echo $i | awk '$1 == Revision: {print $2}'`
+ JKJNISVN=`echo $i | awk '$1 == URL: {print $2}'`
Just in case you didn't notice: before you could run the script without having a
workspace checked out. Now this needs a local workspace to run svn info on
it. Before it ran the info on the URL computed.
Yes I did that intentionally to simplify the release script.
Note that layouts in trunk and 1.1.x branch are already different so you
cannot release arbitrary tag/branch with it.
This one is specific for 1.1.x branch.
For trunk all branch mechanism should be removed as well because
the premise of branches is that they are different so you will
at least need to run jnirelease.sh from the target branch.
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1294273 - /tomcat/native/branches/1.1.x/README.txt
On 02/27/2012 08:19 PM, Konstantin Kolinko wrote: 2012/2/27mt...@apache.org: Author: mturk Date: Mon Feb 27 18:56:02 2012 New Revision: 1294273 URL: http://svn.apache.org/viewvc?rev=1294273view=rev Log: Make some sense out of README. Removed ASL header and added Crypto notice Why are you removing the ASL header? Is the file not for redistribution? It is. Files for redistribution do not have to contain ASL header. See: http://apache.org/legal/src-headers.html#faq-exceptions Further more it has 'Licensing' section so no need to duplicate the content. Note for example that RUNNING.txt, BUILDING.txt and RELEASE-NOTES files in Tomcat proper have the ASL header. It does not make them less readable. IMHO it does make them harder to read and especially if you try to run some markup over them. However since both RUNNING and BUILDING are actually documentation files they should have the ASL header. For RELEASE-NOTES not sure, since this info is not something 'creative' but rather pure statistical data. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[VOTE] Release Apache Tomcat Native 1.1.23
Version 1.1.23 is both bugfix release with couple of additional features that does not change ABI (namely OCSP and pkcs12 support). The proposed release artefacts can be found at [1], and the build was done using tag [2]. Please vote. The vote will be open for at least 72 hours. Apache Tomcat Native 1.1.23 should be: [+1] Released [-1] Not released because ... [1] http://people.apache.org/~mturk/native/1.1.23 [2] https://svn.apache.org/repos/asf/tomcat/native/tags/TOMCAT_NATIVE_1_1_23 Regard -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Taglibs Parent POM 1
On 02/27/2012 12:33 AM, Jeremy Boynes wrote: OK. Artefacts re-staged at https://repository.apache.org/content/repositories/orgapachetomcat-084/ +1 Signatures and content OK. Although not sure why you have LICENSE and LICENSE.txt as well as NOTICE and NOTICE.txt with the same content (well, the only difference is that .txt files are missing trailing new lines). I could understand if they were LF/CRL-LF, but as they are currently it makes no sense. You should probably fix that in future releases. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Taglibs Parent POM 1
On 02/28/2012 08:57 PM, sebb wrote: On 28 February 2012 16:43, Mladen Turkmt...@apache.org wrote: Although not sure why you have LICENSE and LICENSE.txt as well as NOTICE and NOTICE.txt with the same content That is probably caused by the Apache POM, which tries to be helpful by adding the NL for you. Right, that should be the cause. We had to disable that part in Commons, because we don't use the same naming convention (and the AP does not allow for the names to be changed). Whatever... Think that this should be easy to solve. Just rm extra files if maven will add them automatically and the content is satisfactory. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[RESULT] Was: [VOTE] Release Apache Tomcat Native 1.1.23
With my implicit +1 we 4 +1's (Henri, Filip, Jean-Frederic and I) and no other votes. I declare vote as passed. On 02/28/2012 03:39 PM, Mladen Turk wrote: Version 1.1.23 is both bugfix release with couple of additional features that does not change ABI (namely OCSP and pkcs12 support). The proposed release artefacts can be found at [1], and the build was done using tag [2]. Please vote. The vote will be open for at least 72 hours. Apache Tomcat Native 1.1.23 should be: [+1] Released [-1] Not released because ... [1] http://people.apache.org/~mturk/native/1.1.23 [2] https://svn.apache.org/repos/asf/tomcat/native/tags/TOMCAT_NATIVE_1_1_23 Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[ANN] Apache Tomcat Native 1.1.23 released
The Apache Tomcat team announces the immediate availability of Apache Tomcat Native 1.1.23 stable. Please refer to the change log for the list of changes: http://tomcat.apache.org/native-doc/miscellaneous/changelog.html Downloads: http://tomcat.apache.org/download-native.cgi Please allow up to 24 hours for your local mirror to sync with the Apache distribution site. Note that with this release we changed the Windows binaries packaging. Instead standalone .dll files we now have a single tomcat-native-1.1.23-win32-bin.zip file containing libraries for both 32 and 64 bit JVM's. It can be found inside download binaries directory. Thank you, -- The Apache Tomcat Team - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1296630 - in /tomcat/jk/trunk: native/common/jk_util.c xdocs/miscellaneous/changelog.xml
On 03/03/2012 03:41 PM, rj...@apache.org wrote: Author: rjung Date: Sat Mar 3 14:41:12 2012 New Revision: 1296630 URL: http://svn.apache.org/viewvc?rev=1296630view=rev Log: BZ 52793: Fix default value of forwarded worker activation state. Think we've been holding 1.2.33 for a quite time. I plan to tag that next week. It's been enough time for testing last time I gave intent to TR 1.2.33 Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
