Re: POJO Application Server for Tomcat
- Original Message - From: Yoav Shapira [EMAIL PROTECTED] To: Tomcat Developers List dev@tomcat.apache.org Sent: Tuesday, August 21, 2007 1:32 PM Subject: Re: POJO Application Server for Tomcat Hey, This thread is interesting stuff. I don't see myself using it, but it's cool to see your level of effort and the results. Are you actually using it for a production system? Is anyone else? Harbor is really something we did for ourselves, for internal use. Packaging it and putting it out there is only 1 week old its brand new, and the site does say use with caution. The momentum for this is actually coming from friends. When they saw us popping applications out of browsers just using Tomcat, they got more excited than we did. Dont think I've worked so hard in my life... spending hours showing people how to ban their supercan, which now seems to be the name for the informal course. So thats why we doing this, packaging it, giving it a site, mailing list etc... tired of visitors :) The 1 day old Mailing list can be found at http://coolharbor.100free.com/mailing_list.htm I'm also trying to get samples of things like mailing and dB pools up on to the site please be patient, its coming and its got a mailing list now so we dont have to bug the Tomcat guys anymore I thank Apache again. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] mod_jk for i5/OS / V5R4 mini
My trusted information sources concerning i5/OS (yes, such exist :) ) tell me, that it's quite common out there to not support R3 any more. On the other hand: if we really get enough benefit from dropping support during 1.2 now and not for the next major version, is unclear to me. This mainly is concerning you, because you are the one who maintains that part. I think it's obvious, that we should drop the V3 support for anything beyond 1.2.x, I'm not so sure about dropping it near the end of 1.2.x. Maybe we can let all those defines for 1.2.x in there, but include docs information, that we don't test any longer against V3 (use on your own risk) and only fully support V4. Regards, Rainer Henri Gomez wrote: Hi to all, We want to clean up a little the mod_jk code defines specific to i5/OS, and plan to make V5R4 OS as a minimum requirement. Since all i5 systems are now in V5R4 I couldn't test or build for V5R3 and previous release. Did there is i5/OS users with V5R3 and previous release ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug in B2C converter WAS: svn commit: r568307 - /tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java
Bill Barker wrote: Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Filip Hanik - Dev Lists wrote: Test Case and 5.5.x patch can be found here. http://people.apache.org/~fhanik/tomcat/b2c/ This is what is happening int cnt=conv.read( result, 0, BUFFER_SIZE ); is called with a while (true) statement, When the IntermediateInputStream.read returns -1, the above statement returns cnt==1. So to avoid calling conv.read, we must check to see if we have more bytes to read by implementing the available() method, to avoid the inputstream ever returning -1. It's possible, but I have a hard time understanding the issue. The issue is that InputStreamReader reads 8192 bytes from IntermediateInputStream on the first go. It then translates them into 2734 chars, but thinks that the last few bytes represent an incomplete char, so holds onto them. On the next call, IntermediateInputStream returns -1, so InputStreamReader outputs the last char as best it can (resulting in returning 1). Then the IntermediateInputStream buffer is reset, and it can continue on reading (but from the wrong position, resulting in corruption). Filip's patch is inelegant (better would be to use the ByteChunk sink), but other than my looking for a better way to do it, I can't come up with the required technical reason to porting the base of it to 5.5 (of course, I could care less what he does in his sandbox :). Some parts of the patch look weird, in particular, the: +import java.nio.CharBuffer; This I will -1 porting to 5.5. That branch of the connectors is shared by 3.3.x and 4.1.x, and it is already hard enough to get them to build on pre-1.4 JVMs. and so the pissing contest begins, just in a different area. ok, the so the only thing required for the fix is 1. available() call on the intermediate stream 2. make sure the B2CConverter uses while(available) instead of while(true) here is the 5.5 patch (had you actually taken a look at it) http://people.apache.org/~fhanik/tomcat/b2c/patch.txt nothing in there is 1.5-ish, hence I don't see your veto justified. if you want to veto it, you have to come up with a reason why this patch (see url) doesn't work and possibly a different fix, since its a significant bug, and we are tagging 5.5.25 on Friday Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug in B2C converter WAS: svn commit: r568307 - /tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java
Filip Hanik - Dev Lists wrote:
and so the pissing contest begins, just in a different area.
ok, the so the only thing required for the fix is
1. available() call on the intermediate stream
2. make sure the B2CConverter uses while(available) instead of while(true)
here is the 5.5 patch (had you actually taken a look at it)
http://people.apache.org/~fhanik/tomcat/b2c/patch.txt
nothing in there is 1.5-ish, hence I don't see your veto justified.
if you want to veto it, you have to come up with a reason why this patch
(see url) doesn't work
and possibly a different fix, since its a significant bug, and we are
tagging 5.5.25 on Friday
You do not seem to be able to read posts from other people. He does not
want NIO stuff in that branch, as it is used by other Tomcat versions.
This is a technical objection, so it is a valid veto.
If you'd like to revert and patch using simply this, then most likely he
would be happy:
Index: util/java/org/apache/tomcat/util/buf/B2CConverter.java
===
--- util/java/org/apache/tomcat/util/buf/B2CConverter.java (revision
568320)
+++ util/java/org/apache/tomcat/util/buf/B2CConverter.java (working copy)
@@ -82,7 +82,7 @@
{
try {
// read from the reader
-while( true ) { // conv.ready() ) {
+while( iis.available()0 ) { // conv.ready() ) {
int cnt=conv.read( result, 0, BUFFER_SIZE );
if( cnt = 0 ) {
// End of stream ! - we may be in a bad state
@@ -251,7 +251,12 @@
public final int read() throws IOException {
return (pos end ) ? (buf[pos++] 0xff) : -1;
}
+
+public int available() throws IOException {
+return end-pos;
+}
+
// Internal methods
void setBuffer( byte b[], int p, int l ) {
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug in B2C converter WAS: svn commit: r568307 - /tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
and so the pissing contest begins, just in a different area.
ok, the so the only thing required for the fix is
1. available() call on the intermediate stream
2. make sure the B2CConverter uses while(available) instead of
while(true)
here is the 5.5 patch (had you actually taken a look at it)
http://people.apache.org/~fhanik/tomcat/b2c/patch.txt
nothing in there is 1.5-ish, hence I don't see your veto justified.
if you want to veto it, you have to come up with a reason why this
patch (see url) doesn't work
and possibly a different fix, since its a significant bug, and we are
tagging 5.5.25 on Friday
You do not seem to be able to read posts from other people. He does
not want NIO stuff in that branch, as it is used by other Tomcat
versions. This is a technical objection, so it is a valid veto.
Where is the NIO stuff in the patch below, I've must have turned into a
complete idiot, cause I can't see it.
http://people.apache.org/~fhanik/tomcat/b2c/patch.txt
Am I really the one not reading posts correctly?
If you'd like to revert and patch using simply this, then most likely
he would be happy:
Index: util/java/org/apache/tomcat/util/buf/B2CConverter.java
===
--- util/java/org/apache/tomcat/util/buf/B2CConverter.java
(revision 568320)
+++ util/java/org/apache/tomcat/util/buf/B2CConverter.java(working
copy)
@@ -82,7 +82,7 @@
{
try {
// read from the reader
-while( true ) { // conv.ready() ) {
+while( iis.available()0 ) { // conv.ready() ) {
int cnt=conv.read( result, 0, BUFFER_SIZE );
if( cnt = 0 ) {
// End of stream ! - we may be in a bad state
@@ -251,7 +251,12 @@
public final int read() throws IOException {
return (pos end ) ? (buf[pos++] 0xff) : -1;
}
+
+public int available() throws IOException {
+return end-pos;
+}
+
// Internal methods
void setBuffer( byte b[], int p, int l ) {
Rémy
-
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] Send trunk to the sandbox
Mark Thomas wrote: Mark Thomas wrote: Bill Barker wrote: I'm so tired of this thread, so let's settle it once and for all. I'm backing Remy's suggestion to send the current trunk to the sandbox: [X] +1 Let's end the revolution [ ] +0 What revolution? [ ] -1 Viva the revolultion This applies to this proposal only. Other changes should be proposed in other threads. Expanding on what I said on private@ as I see no reason for it not to be part of the public discussion... I don't see a need for a separate 6.0.x and 6.1.x development at this point. I have yet to see a convincing technical argument that there is something sufficiently new and/or different to justify this overhead. There is enough work to do to maintain 4.1.x, 5.0.x (which we aren't doing a great job of and I am several months past my promise to do a security release for 5.0.x), 5.5.x and 6.0.x without adding yet an other branch. Simply, trunk should never have been called trunk, it is a branch. It should be moved to 6.0.x/branches/whatever In terms of moving forward, merge the changes in 'trunk' to 6.0.x. Ideally this should be done commit by commit or groups of related commits so we can discuss each of the additions if necessary. If any attract a veto or are viewed as too experimental etc they can stay in 6.0.x/branches/whatever until the issues are resolved or that feature is abandoned. My expectation is that 99% of what is in /trunk can move to 6.0.x/trunk with little or no debate. your points are completely valid, here is the thread for trunk http://marc.info/?l=tomcat-devm=117940240523993w=2 the idea, discussed in this thread, was to freeze 6.0 API all together, and continue with new changes in trunk, everyone was in agreement. and if comet was the culprit, that feature can be pulled out, I've must have said that 3 dozen times now. just the history of how we got to where we are at. At this point, I'm beat down by this argument, I'm getting vetoes on other areas just cause folks don't properly look over the patch submitted and are on a pure vendetta, it's too much of a personal head ache to fight that kind of attitude, that has no technical backup. do whatever you want, I'll tag along, my objections have been noted, that's good for now. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r568605 - /tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java
Author: fhanik
Date: Wed Aug 22 06:29:21 2007
New Revision: 568605
URL: http://svn.apache.org/viewvc?rev=568605view=rev
Log:
remove non needed methods, somehow they cause an itch, so lets get rid of the
itch
Modified:
tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java?rev=568605r1=568604r2=568605view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java Wed Aug 22
06:29:21 2007
@@ -22,7 +22,6 @@
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.UnsupportedEncodingException;
-import java.nio.CharBuffer;
/** Efficient conversion of bytes to character .
*
@@ -214,14 +213,6 @@
public final int read() throws IOException {
return super.read();
-}
-
-public final int read(CharBuffer cb) throws IOException {
-return super.read(cb);
-}
-
-public final int read(char[] cbuf) throws IOException {
-return super.read(cbuf);
}
/** Reset the buffer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
On Aug 21, 2007, at 8:54 PM, Yoav Shapira wrote: Hey, On 8/21/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Beyond withdrawing the silly vote, asking for the code you veto to be removed, and moving forward, don't you think you should hold a vote to make trunk R-T-C first? The latter is definitely a vote. (And I'd be -1 on it). input from other project members, of course. But I become concerned when only two people in a project even grok the technical implications of what is in their repository. I think that's stretching it a bit far. I, for one, grok the technical differences between Remy and Filip's approaches to Comet, but I just don't care about them. Either approach looks fine enough to me, and so as long as other work progresses I believe the Comet stuff will eventually be sorted out. Maybe now is that time. But please don't equate one pissing match with the entire rest of the committers not understanding what's going on. I'm guessing at least one or two other people share my stance above. IMO, code talks, bullshit walks. And I've been on both sides of the argument many times in many places. As Bill noted, there are lots of ways of skinning a cat. If person 1 comes up with a way, and implements it, then sure person 2 has the right to say that the implementation sucks and their way is better, but if it never gets beyond the talk phase, well... I can't see scrapping work 1 when work 2 isn't even in a debate mode. Vetoes are serious shit. They pack a lot of punch. They are not things to throw out willy nilly with no real technical justification other than some hand waving. Nor are they items to ignore simply because you don't like the person raising the veto. Re: naming of trunk/branches/sandbox/whatever. Trunk is designed to be the best guess of the *community's* idea on what the codebase will be looking like. It works best when it is free and easy with a c-t-r policy. Consider it, for lack of a better term, the community sandbox. Then, bits and pieces of it (patches and SVN revisions) get folded back into those areas that represent what will be released (usually branches). This is usually done via a r-t-c policy since you are now touching code that is directly in the release path. And personally, I think it's a damn shame that we don't see I owe you a beer more on the TC lists... Pissing matches are ok if, afterwards, you all meet, get together, have a few drinks and *get* pissed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r568631 - /tomcat/trunk/test/org/apache/catalina/tribes/test/membership/NamedNodes.java
Author: fhanik
Date: Wed Aug 22 07:43:08 2007
New Revision: 568631
URL: http://svn.apache.org/viewvc?rev=568631view=rev
Log:
Added example on how you can name nodes with existing system
Added:
tomcat/trunk/test/org/apache/catalina/tribes/test/membership/NamedNodes.java
Added:
tomcat/trunk/test/org/apache/catalina/tribes/test/membership/NamedNodes.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/tribes/test/membership/NamedNodes.java?rev=568631view=auto
==
---
tomcat/trunk/test/org/apache/catalina/tribes/test/membership/NamedNodes.java
(added)
+++
tomcat/trunk/test/org/apache/catalina/tribes/test/membership/NamedNodes.java
Wed Aug 22 07:43:08 2007
@@ -0,0 +1,54 @@
+package org.apache.catalina.tribes.test.membership;
+
+import org.apache.catalina.tribes.group.GroupChannel;
+import org.apache.catalina.tribes.membership.MemberImpl;
+import org.apache.catalina.tribes.MembershipListener;
+import org.apache.catalina.tribes.Member;
+import org.apache.catalina.tribes.Channel;
+
+public class NamedNodes implements MembershipListener{
+
+public void namedNodes() throws Exception {
+GroupChannel[] channels = new GroupChannel[3];
+for (int i=0; ichannels.length; i++) {
+channels[i] = new GroupChannel();
+//start the receiver, so that we can identify the local member
+channels[i].start(Channel.SND_RX_SEQ);
+MemberImpl member = (MemberImpl)channels[i].getLocalMember(false);
+String name = Member Nr-+(i+1);
+member.setPayload(name.getBytes(ASCII));
+channels[i].addMembershipListener(this);
+
channels[i].start(Channel.SND_TX_SEQ|Channel.MBR_RX_SEQ|Channel.MBR_TX_SEQ);
+ }
+ Thread.sleep(5000);
+ for (int i=0; ichannels.length; i++) {
+ channels[i].stop(Channel.DEFAULT);
+ Thread.sleep(1000);
+ }
+}
+
+public static void main(String[] args) throws Exception {
+NamedNodes nm = new NamedNodes();
+nm.namedNodes();
+}
+
+public void memberAdded(Member member) {
+try {
+String name = new String(member.getPayload(), ASCII);
+System.out.println(Node with name:+name+ just joined);
+}catch ( Exception x ) {
+x.printStackTrace();
+}
+}
+
+public void memberDisappeared(Member member) {
+try {
+String name = new String(member.getPayload(), ASCII);
+System.out.println(Node with name:+name+ just left);
+}catch ( Exception x ) {
+x.printStackTrace();
+}
+
+}
+
+}
\ No newline at end of file
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug in B2C converter WAS: svn commit: r568307 - /tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java
On Aug 22, 2007, at 9:32 AM, Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: and so the pissing contest begins, just in a different area. ok, the so the only thing required for the fix is 1. available() call on the intermediate stream 2. make sure the B2CConverter uses while(available) instead of while(true) here is the 5.5 patch (had you actually taken a look at it) http://people.apache.org/~fhanik/tomcat/b2c/patch.txt nothing in there is 1.5-ish, hence I don't see your veto justified. if you want to veto it, you have to come up with a reason why this patch (see url) doesn't work and possibly a different fix, since its a significant bug, and we are tagging 5.5.25 on Friday You do not seem to be able to read posts from other people. He does not want NIO stuff in that branch, as it is used by other Tomcat versions. This is a technical objection, so it is a valid veto. If you'd like to revert and patch using simply this, then most likely he would be happy: Umm... did anyone even LOOK at the patch that Filip suggested FOR BACKPORTING: http://people.apache.org/~fhanik/tomcat/b2c/patch.txt THAT is what he's proposing for 5.5... And it's EXACTLY what you specified. Geez. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
Jim Jagielski wrote: IMO, code talks, bullshit walks. And I've been on both sides of the argument many times in many places. Yeah right. So to summarize, we have 3 committers who are happy campers (2 of them which don't contribute much, as far as I know), and the rest of the committers are either do not care or are unhappy. Most also want a change in the development process, and as long as there's agreement on that and it respects the ASF principles, we should be able to do that. It's fairly obvious that vetoes which pack a lot of punch haven't been taken very seriously. The first reaction is to start arguing that the veto is not valid, and requalify technical reasons given as non technical. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
On Aug 22, 2007, at 10:47 AM, Remy Maucherat wrote: Jim Jagielski wrote: IMO, code talks, bullshit walks. And I've been on both sides of the argument many times in many places. Yeah right. And what do you mean by that? What is Yeah right about me claiming to at times being on the 'code talking' side and the 'bullshit walking' side? Or is this just a sample of your personal charm? So to summarize, we have 3 committers who are happy campers (2 of them which don't contribute much, as far as I know), and the rest of the committers are either do not care or are unhappy. Most also want a change in the development process, and as long as there's agreement on that and it respects the ASF principles, we should be able to do that. happy campers?? I have no idea what you mean. It's fairly obvious that vetoes which pack a lot of punch haven't been taken very seriously. The first reaction is to start arguing that the veto is not valid, and requalify technical reasons given as non technical. If others agree that your technical reasons are valid, then they are. If technical reasons are I would have done it this way instead then the issue falls into personal preference and not really technical, *objective* reasons. Unless, of course, one can show qualifiable reasons why the other way is more efficient, more secure, more maintainable, etc... you know, technical reasons. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
Remy Maucherat wrote: Yeah right. So to summarize, we have 3 committers who are happy campers (2 of them which don't contribute much, as far as I know), and the rest of the committers are either do not care or are unhappy. Most also want a change in the development process, and as long as there's agreement on that and it respects the ASF principles, we should be able to do that. Bah. In neither angry nor happy. My impression was trunk was going to be wacky new stuff which broke existing api's and configurations with 6.0. Much like 5.0 -- 5.5. In reality that didn't happen - we just got some comet changes. (I'm not saying this is good or bad - it's just and observation) Now we are in a technical debate between comet implementation between Remy and Filips designs. This has seemed to migrate into a personal attack in a subtle manner. Such is life when coding. Disagreements occur, feeling are hurt and email is the worst method of communicating an emotional topic since words are amplified. (Sometime on purpose, other times by accident). My hope is this too shall pass and all is good again. Personally - I am not very clueful on comet other than the basics. I'd love to get the clue - but I can't find and work related projects to justify the time. That leaves me out in the cold due to this conversation. I feel any vote by me would be a bad vote because of my ignorance on the topic. It seems others are in the same situation. All that being said - I'd love to see Remy and Filip agree on comet and remove trunk. It would be a shame to see either leave due to these disputes. -Tim (Away for training in Boston this week (Kendall Square)) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
On Aug 22, 2007, at 8:06 AM, [EMAIL PROTECTED] wrote: Remy Maucherat wrote: Yeah right. So to summarize, we have 3 committers who are happy campers (2 of them which don't contribute much, as far as I know), and the rest of the committers are either do not care or are unhappy. Most also want a change in the development process, and as long as there's agreement on that and it respects the ASF principles, we should be able to do that. Bah. In neither angry nor happy. My impression was trunk was going to be wacky new stuff which broke existing api's and configurations with 6.0. Much like 5.0 -- 5.5. In reality that didn't happen - we just got some comet changes. (I'm not saying this is good or bad - it's just and observation) While it's more fun to watch from the sidelines, I'm afraid I'll have to get involved here to point out that you are wrong about this. trunk contains an entirely new and incompatible with 6.0.x annotation processing framework which is in use in the Geronimo integration. Remy suggested and I agreed that it would not be appropriate for an api change of this magnitude to go in a 6.0.x revision. While Remy was certainly the committer most involved in applying these changes, IIRC there was some support from at least one other committer. In Geronimo we are anxiously awaiting an official tomcat release with these agreed upon api changes, so we tend to view the proposal eliminate trunk with some concern. thanks david jencks Now we are in a technical debate between comet implementation between Remy and Filips designs. This has seemed to migrate into a personal attack in a subtle manner. Such is life when coding. Disagreements occur, feeling are hurt and email is the worst method of communicating an emotional topic since words are amplified. (Sometime on purpose, other times by accident). My hope is this too shall pass and all is good again. Personally - I am not very clueful on comet other than the basics. I'd love to get the clue - but I can't find and work related projects to justify the time. That leaves me out in the cold due to this conversation. I feel any vote by me would be a bad vote because of my ignorance on the topic. It seems others are in the same situation. All that being said - I'd love to see Remy and Filip agree on comet and remove trunk. It would be a shame to see either leave due to these disputes. -Tim (Away for training in Boston this week (Kendall Square)) - 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] Send trunk to the sandbox
On Aug 22, 2007, at 11:43 AM, David Jencks wrote: While it's more fun to watch from the sidelines, I'm afraid I'll have to get involved here to point out that you are wrong about this. trunk contains an entirely new and incompatible with 6.0.x annotation processing framework which is in use in the Geronimo integration. Remy suggested and I agreed that it would not be appropriate for an api change of this magnitude to go in a 6.0.x revision. While Remy was certainly the committer most involved in applying these changes, IIRC there was some support from at least one other committer. In Geronimo we are anxiously awaiting an official tomcat release with these agreed upon api changes, so we tend to view the proposal eliminate trunk with some concern. All this really depends and hinges on what the current development community sees as the usage of trunk... For example, with httpd, trunk also contains incompatible changes from the current latest shipping release (2.2.x). But that's OK because trunk is actually what will be used as the basis for 2.4, where there are no API guarantees. BUT, and this is an important but, changes to the 2.2 branch are done via backports *from* trunk. 2.2 doesn't have it's own trunk, so to speak, but uses main trunk. This is all well and good if that process is understood and used by everyone... Seems to me, this is a main issue with this whole debate. What is trunk... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
On Aug 20, 2007, at 3:43 AM, Henri Gomez wrote: +0, could we see the pros and cons ? One con of moving trunk to sandbox, at least from an ASF-wide perspective, is that the annotation processing changes that Geronimo 2.0 relies on are currently only available in trunk. The development of this feature came about as the product of some excellent collaboration and cooperation between the Tomcat and Geronimo projects [1]. I would hate to slow down the progress we have made in that regard. Please take this into consideration as you decide upon the fate of trunk. Best wishes, Paul [1] http://www.nabble.com/Annotation-processing---Geronimo-injection- tf3459188.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r568702 - /tomcat/trunk/test/org/apache/catalina/tribes/test/membership/NamedNodes.java
Author: fhanik Date: Wed Aug 22 10:07:01 2007 New Revision: 568702 URL: http://svn.apache.org/viewvc?rev=568702view=rev Log: Added license header Modified: tomcat/trunk/test/org/apache/catalina/tribes/test/membership/NamedNodes.java Modified: tomcat/trunk/test/org/apache/catalina/tribes/test/membership/NamedNodes.java URL: http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/tribes/test/membership/NamedNodes.java?rev=568702r1=568701r2=568702view=diff == --- tomcat/trunk/test/org/apache/catalina/tribes/test/membership/NamedNodes.java (original) +++ tomcat/trunk/test/org/apache/catalina/tribes/test/membership/NamedNodes.java Wed Aug 22 10:07:01 2007 @@ -1,3 +1,19 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the License); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ package org.apache.catalina.tribes.test.membership; import org.apache.catalina.tribes.group.GroupChannel; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
Paul McMahan wrote: On Aug 20, 2007, at 3:43 AM, Henri Gomez wrote: +0, could we see the pros and cons ? One con of moving trunk to sandbox, at least from an ASF-wide perspective, is that the annotation processing changes that Geronimo 2.0 relies on are currently only available in trunk. The development of this feature came about as the product of some excellent collaboration and cooperation between the Tomcat and Geronimo projects [1]. I would hate to slow down the progress we have made in that regard. Please take this into consideration as you decide upon the fate of trunk. On that specific topic, I was thinking about maintaining a patchset. Regardless of what happens to the trunk branch, I don't think there will be a release based on this code anytime soon, and given the next specification is not too far away, I don't know if this new interface will be in a real release. We'll see what happens. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
Remy Maucherat wrote: Jim Jagielski wrote: IMO, code talks, bullshit walks. And I've been on both sides of the argument many times in many places. Yeah right. So to summarize, we have 3 committers who are happy campers (2 of them which don't contribute much, as far as I know), and the rest of the committers are either do not care or are unhappy. Most also want a change in the development process, and as long as there's agreement on that and it respects the ASF principles, we should be able to do that. It's fairly obvious that vetoes which pack a lot of punch haven't been taken very seriously. The first reaction is to start arguing that the veto is not valid, and requalify technical reasons given as non technical. you mean like the veto for the 5.5 B2C converter fix, where you and the person vetoing hadn't even looked at the patch before writing technical reasons you're kidding yourself at this point - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: Jim Jagielski wrote: IMO, code talks, bullshit walks. And I've been on both sides of the argument many times in many places. Yeah right. So to summarize, we have 3 committers who are happy campers (2 of them which don't contribute much, as far as I know), and the rest of the committers are either do not care or are unhappy. Most also want a change in the development process, and as long as there's agreement on that and it respects the ASF principles, we should be able to do that. It's fairly obvious that vetoes which pack a lot of punch haven't been taken very seriously. The first reaction is to start arguing that the veto is not valid, and requalify technical reasons given as non technical. you mean like the veto for the 5.5 B2C converter fix, where you and the person vetoing hadn't even looked at the patch before writing technical reasons you're kidding yourself at this point Of course :) He said he would veto if NIO APIs usage was introduced in Tomcat 5.5, and that seemed reasonable to me. If there is no NIO usage, there will be no veto, so again what is it you do not understand ? I see you also don't care about my reservations on the virtual CL hack. Any comment/discussion/collaboration on that issue ? The technical veto only thing does not make sense to me overall. If technical preference is not allowed, then I can simply overwrite your Comet API in your playground (trunk) with my interpretation of it, and you cannot do anything about it. I think ASF project management is broken :| Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: Jim Jagielski wrote: IMO, code talks, bullshit walks. And I've been on both sides of the argument many times in many places. Yeah right. So to summarize, we have 3 committers who are happy campers (2 of them which don't contribute much, as far as I know), and the rest of the committers are either do not care or are unhappy. Most also want a change in the development process, and as long as there's agreement on that and it respects the ASF principles, we should be able to do that. It's fairly obvious that vetoes which pack a lot of punch haven't been taken very seriously. The first reaction is to start arguing that the veto is not valid, and requalify technical reasons given as non technical. you mean like the veto for the 5.5 B2C converter fix, where you and the person vetoing hadn't even looked at the patch before writing technical reasons you're kidding yourself at this point Of course :) He said he would veto if NIO APIs usage was introduced in Tomcat 5.5, and that seemed reasonable to me. If there is no NIO usage, there will be no veto, so again what is it you do not understand ? both of you enforced the veto without ever looking at the real patch, so there was a veto thrown without justification. It should have never even been out there, and then dared to accuse me of not reading the posts, when in fact you hadn't read it yourself. I found the fact that you are trying to turn around that accusation here appalling. just go back and read your previous post on the matter... oh wait, I was the one not reading the post ;) must be my fault again. I see you also don't care about my reservations on the virtual CL hack. Any comment/discussion/collaboration on that issue ? feel free to start another thread on that topic,more appropriate than here, but i will comment you dislike it cause it is outside of the servlet spec, but the spec writers don't manage hundreds and even thousands of webapp/tomcat instances daily that have to deal with central repositories of approved licensed libraries. The virtual webapp loader is an optional component, and very useful to those large companies. The idea came from direct feedback from a few companies that needed those features. For folks, like yourself, that dislike those features, it is an optional component that needs to be configured, they will never even have to use it. Its not in the default configuration. As for portability, that wasn't the goal with the virtual webapp loader when it was added to the repository in the first place, I just made it more usable. I don't see any harm done with it, except that it now works, whereas before it really didn't. The technical veto only thing does not make sense to me overall. If technical preference is not allowed, then I can simply overwrite your Comet API in your playground (trunk) with my interpretation of it, and you cannot do anything about it. I think ASF project management is broken :| not broken at all, you're the one who refused a vote on the Comet API, then you try to overthrow it by throwing away trunk. had you just agreed to resolve the Comet issue instead of starting the trunk debate, it would have probably been resolved by now, and now of this would have been necessary. But it is what it is, do whatever you want with it, you seem so passionate about it that there is no limit to who you attack about it. I'm out of the trunk debate, what ever gets decided, I'll limp along. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug in B2C converter WAS: svn commit: r568307 - /tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java
Bill Barker wrote: Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Filip Hanik - Dev Lists wrote: Test Case and 5.5.x patch can be found here. http://people.apache.org/~fhanik/tomcat/b2c/ This is what is happening int cnt=conv.read( result, 0, BUFFER_SIZE ); is called with a while (true) statement, When the IntermediateInputStream.read returns -1, the above statement returns cnt==1. So to avoid calling conv.read, we must check to see if we have more bytes to read by implementing the available() method, to avoid the inputstream ever returning -1. It's possible, but I have a hard time understanding the issue. The issue is that InputStreamReader reads 8192 bytes from IntermediateInputStream on the first go. It then translates them into 2734 chars, but thinks that the last few bytes represent an incomplete char, so holds onto them. On the next call, IntermediateInputStream returns -1, so InputStreamReader outputs the last char as best it can (resulting in returning 1). Then the IntermediateInputStream buffer is reset, and it can continue on reading (but from the wrong position, resulting in corruption). Filip's patch is inelegant (better would be to use the ByteChunk sink), but other than my looking for a better way to do it, I can't come up with the required technical reason to porting the base of it to 5.5 (of course, I could care less what he does in his sandbox :). I've committed the fix to 5.5, if you find a more elegant way of solving the actual problem, feel free to revert it and commit another fix. I don't care about the how, as long as there is a fix that will be included in the tag 5.5.25 on Friday Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r568741 - /tomcat/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java
Author: fhanik
Date: Wed Aug 22 13:18:35 2007
New Revision: 568741
URL: http://svn.apache.org/viewvc?rev=568741view=rev
Log:
Log deserialization errors as error
log channellistener errors as warnings
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java
Modified: tomcat/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java?rev=568741r1=568740r2=568741view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java Wed
Aug 22 13:18:35 2007
@@ -248,7 +248,12 @@
if ( (msg.getOptions() SEND_OPTIONS_BYTE_MESSAGE) ==
SEND_OPTIONS_BYTE_MESSAGE ) {
fwd = new ByteMessage(msg.getMessage().getBytes());
} else {
-fwd =
XByteBuffer.deserialize(msg.getMessage().getBytesDirect(),0,msg.getMessage().getLength());
+try {
+fwd =
XByteBuffer.deserialize(msg.getMessage().getBytesDirect(), 0,
msg.getMessage().getLength());
+}catch (Exception sx) {
+log.error(Unable to deserialize message:+msg,sx);
+return;
+}
}
if ( Logs.MESSAGES.isTraceEnabled() ) {
Logs.MESSAGES.trace(GroupChannel - Receive Message: + new
UniqueId(msg.getUniqueId()) + is +fwd);
@@ -278,8 +283,10 @@
}
} catch ( Exception x ) {
-if ( log.isDebugEnabled() ) log.error(Unable to process
channel:IOException.,x);
-throw new RemoteProcessException(IOException:+x.getMessage(),x);
+//this could be the channel listener throwing an exception, we
should log it
+//as a warning.
+if ( log.isWarnEnabled() ) log.warn(Error receiving message:,x);
+throw new RemoteProcessException(Exception:+x.getMessage(),x);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r568742 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java
Author: fhanik
Date: Wed Aug 22 13:19:54 2007
New Revision: 568742
URL: http://svn.apache.org/viewvc?rev=568742view=rev
Log:
backport from trunk
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java?rev=568742r1=568741r2=568742view=diff
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java
Wed Aug 22 13:19:54 2007
@@ -248,7 +248,12 @@
if ( (msg.getOptions() SEND_OPTIONS_BYTE_MESSAGE) ==
SEND_OPTIONS_BYTE_MESSAGE ) {
fwd = new ByteMessage(msg.getMessage().getBytes());
} else {
-fwd =
XByteBuffer.deserialize(msg.getMessage().getBytesDirect(),0,msg.getMessage().getLength());
+try {
+fwd =
XByteBuffer.deserialize(msg.getMessage().getBytesDirect(), 0,
msg.getMessage().getLength());
+}catch (Exception sx) {
+log.error(Unable to deserialize message:+msg,sx);
+return;
+}
}
if ( Logs.MESSAGES.isTraceEnabled() ) {
Logs.MESSAGES.trace(GroupChannel - Receive Message: + new
UniqueId(msg.getUniqueId()) + is +fwd);
@@ -278,8 +283,10 @@
}
} catch ( Exception x ) {
-if ( log.isDebugEnabled() ) log.error(Unable to process
channel:IOException.,x);
-throw new RemoteProcessException(IOException:+x.getMessage(),x);
+//this could be the channel listener throwing an exception, we
should log it
+//as a warning.
+if ( log.isWarnEnabled() ) log.warn(Error receiving message:,x);
+throw new RemoteProcessException(Exception:+x.getMessage(),x);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43191] New: - compressableMimeType attribute ignored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=43191.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43191
Summary: compressableMimeType attribute ignored
Product: Tomcat 5
Version: 5.5.20
Platform: All
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Connector:HTTP
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I have set compression=on and compressableMimeType=text/html in server.xml.
It appears that the value of compressableMimeType is being ignored. My XML
responses are all coming back gzipped. If I switch to compression=off the
responses are not gzipped, but as soon as I turn it on, regardless of the value
of compressableMimeType, the XML responses are coming back gzipped.
A full Connector tag follows. Note that this is just an example -- I have tried
many values for compressableMimeType (that do NOT include text/xml) and the
responses are still compressed.
Connector port=7630 address=${jboss.bind.address}
maxThreads=20 minSpareThreads=4 maxSpareThreads=10 strategy=ms
maxHttpHeaderSize=8192
emptySessionPath=true enableLookups=false redirectPort=7643
acceptCount=16
connectionTimeout=2 disableUploadTimeout=true
compression=off
compressableMimeType=text/html,text/javascript,application/x-javascript,application/javascript
/
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] mod_jk for i5/OS / V5R4 mini
My trusted information sources concerning i5/OS (yes, such exist :) ) Sure :) tell me, that it's quite common out there to not support R3 any more. Well yes On the other hand: if we really get enough benefit from dropping support during 1.2 now and not for the next major version, is unclear to me. This mainly is concerning you, because you are the one who maintains that part. I maintain but since I didn't get access anymore to V5R3 or below, I couldn't guarantee anything. Also it will make the code cleaner (less #ifdef...) I think it's obvious, that we should drop the V3 support for anything beyond 1.2.x, I'm not so sure about dropping it near the end of 1.2.x. Safe decision... Maybe we can let all those defines for 1.2.x in there, but include docs information, that we don't test any longer against V3 (use on your own risk) and only fully support V4. A note shouldn't hurt. Did there is a date for 1.2.25 release ? Henri Gomez wrote: Hi to all, We want to clean up a little the mod_jk code defines specific to i5/OS, and plan to make V5R4 OS as a minimum requirement. Since all i5 systems are now in V5R4 I couldn't test or build for V5R3 and previous release. Did there is i5/OS users with V5R3 and previous release ? - 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: Bug in B2C converter WAS: svn commit: r568307 - /tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java
Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bill Barker wrote: Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Filip Hanik - Dev Lists wrote: Test Case and 5.5.x patch can be found here. http://people.apache.org/~fhanik/tomcat/b2c/ This is what is happening int cnt=conv.read( result, 0, BUFFER_SIZE ); is called with a while (true) statement, When the IntermediateInputStream.read returns -1, the above statement returns cnt==1. So to avoid calling conv.read, we must check to see if we have more bytes to read by implementing the available() method, to avoid the inputstream ever returning -1. It's possible, but I have a hard time understanding the issue. The issue is that InputStreamReader reads 8192 bytes from IntermediateInputStream on the first go. It then translates them into 2734 chars, but thinks that the last few bytes represent an incomplete char, so holds onto them. On the next call, IntermediateInputStream returns -1, so InputStreamReader outputs the last char as best it can (resulting in returning 1). Then the IntermediateInputStream buffer is reset, and it can continue on reading (but from the wrong position, resulting in corruption). Filip's patch is inelegant (better would be to use the ByteChunk sink), but other than my looking for a better way to do it, I can't come up with the required technical reason to porting the base of it to 5.5 (of course, I could care less what he does in his sandbox :). I've committed the fix to 5.5, if you find a more elegant way of solving the actual problem, feel free to revert it and commit another fix. I don't care about the how, as long as there is a fix that will be included in the tag 5.5.25 on Friday No problem. I can see how to do this better, but I'll wait until the weekend to commit (since it's not totally trivial, I don't want a one-day window for regression testing :). That way 5.5.25 can go out with your patch. It doesn't include the NIO dependancy (which was my only concern), so it works well enough for me for now. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
