Re: tomcat-oacc
Filip Hanik - Dev Lists schrieb: - Java 5 dispatcher: I mostly agree. I got lost in the code. The code I thought was responsible was transport/PooledSender.java which uses a fixed pool of threads without queueing. I overlooked somehow the Executor with queue in the Java 5 dispatcher. Nevertheless there's still some discrepancy, because we added some aspects to the queue in 5.5 which are gone now: oh, I didn't even realize this :) MessageDispatchInterceptor.java uses protected FastQueue queue = new FastQueue(); I'm talking about the Java 5 message dispatcher. As far as I can see it doesn't use FastQeueue and as far as the techical part of our discussion went, it probably also doesn't need to. I was focusing on the Java 5 dispatcher because it is the documented default (so I deduce it is recommended). Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat-oacc
Filip Hanik - Dev Lists schrieb: hi Rainer, so to tell the true tale, isn't the story... - You got customers on 5.5 using session replication Of course, and that helped in making the 5.5 cluster better. - Your customers want to move to Tomcat 6 I do hope so! I thought that's something we want all our users to do? But: I didn't do OACC because *anyone* asked me to. I reflected the actual situation and I still think it is a good idea. - You're not confident about the maturity of Tomcat 6's clustering codebase, mainly cause you haven't used it, even though it was originally developed in 2006. I would argue that the this doubt is mainly a lack of both usage and understanding Yes, as I said I'm not confident in its maturity. No, it mainly comes from the fact that it is pretty young. Yes, it was developped in 2006 but it first got delivered as default with TC 6. And TC 6 is getting wide adoption now - but not clustering! As I said, I'm talking about experience coming from users and I expect this to need another 6 to 12 months to grow. - So, to mitigate this, you'd like to use the ASF as the delivery vehicle for your custom code base to allow your customers to switch to Tomcat 6 So how should I interprete this statement? The terms "vehicle", "your codebase" and "your customers" make it a very insulting statement. At least I do feel insulted. But what are we talking about: - "your codebase": its our codebase. If we had to find a single person for this cluster codebase, then it would be your codebase. As everyone can see from yesterdays commit, the codebase is nearly identical from the TC 5.5 codebase. I don't want to have "my" codebase. I want us to cooperate for a strong shared Tomcat codebase. - "your customers": I get a lot of ideas from my customers, and yes they belomg to our community as well as yours. I try to be very cautious not to bring in very customer specific things into the Tomcat project. I was thinking about cluster users of TC 5.5 and how they could move forward and this is why I did port the TC 5.5 cluster. And yes, I know users who would profit from that. But the motivation for OACC is much more general. Migration concepts in the world of high availability need to be very solid. The Tomcat project (we) cancelled support for its existing cluster module from one major version to the next, without any early warning. That's not good practise in the HA world. So yes, I want to mitigate. I want to mitigate the fact, that we didn't do the right decisions with respect to cluster users when we dropped the existing cluster in TC 6. And I am very happy, that under the hood we didn't change the inhterfaces too much so that it is very simple to mitigate this. OACC was done in less than a day. - "vehicle": The official Tomcat project is the right place to offer OACC and to care about migration issues. We only started lately to act more properly with respect to deprecations and end of live announcements. This shows the necessary awareness for the needs of our users since Tomcat is now the leading servlet container and is ubiquitous. And I'm very open here about my motivation and plans. Most of us need to combine business work with our community work. And the ASF model allows this. The questions w.r.t. doing the work inside an ASF project are more like: does it lead to the right result for the community? Do we work together in good collaboration? Is our decision process open? And yes: w.r.t. meritocracy you are much in front of me. All in all I feel accused by the above formulation. I'm ok with you doing this for those folks in sandbox, I'd probably would recommend that we not put this as an official release to Tomcat, as I believe our small group would do much better focusing the effort against the current implementation. Putting into a release means we would spend resources in the bugs that arise from the port itself. The effort point is a valid point. For this reason I'm OK with clearly stating that OACC is a dead end. I already put some (probably not that harsh) statement in the release plan file I committed yesterday before our discussion even started. Concerning official module releases I have a differing opinion: - I will not suggest to bundle OACC additionally inside any other Tomcat release file but - I think it will be a strong statement from a responsibility point of view (a project asset), to provide OACC as an official separate release download. But at least for me it's to early to propose this, because I first want to get a clearer picture, of what will be included in OACC. At the moment it builds and works, but something we deliver needs to contain other parts. Not far away, but not finished yet. I do have some comments inline too Rainer Jung wrote: Although I think that a detailed technical discussion is not the right way to determine the usefulness of OACC, some comments: - monitoring: your
tcnative 1.1.3 and required openssl
Hi to all, While trying to build the latest tcnative on a SLES 10 box I got the following error : checking for OpenSSL library... using openssl from /usr/lib and /usr/include checking OpenSSL library version... Found OPENSSL_VERSION_NUMBER 0x0090801f Require OPENSSL_VERSION_NUMBER 0x0090701f or greater (0.9.7a) Require OPENSSL_VERSION_NUMBER 0x0090802f or greater (0.9.8a) not compatible It's strange since I got installed openssl 0.9.8a : openssl-devel-0.9.8a-18.15 openssl-0.9.8a-18.15 Regards
Re: tcnative 1.1.3 and required openssl
Henri Gomez wrote: Hi to all, While trying to build the latest tcnative on a SLES 10 box I got the following error : checking for OpenSSL library... using openssl from /usr/lib and /usr/include checking OpenSSL library version... Found OPENSSL_VERSION_NUMBER 0x0090801f Require OPENSSL_VERSION_NUMBER 0x0090701f or greater (0.9.7a) Require OPENSSL_VERSION_NUMBER 0x0090802f or greater (0.9.8a) not compatible 0x0090802f is 0.9.8b. I see no reason to require 0.9.8a. Cheers Jean-Frederic It's strange since I got installed openssl 0.9.8a : openssl-devel-0.9.8a-18.15 openssl-0.9.8a-18.15 Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tcnative 1.1.3 and required openssl
Require OPENSSL_VERSION_NUMBER 0x0090802f or greater (0.9.8a) tcnative require 0.9.8b mini ? 2008/3/27, jean-frederic clere <[EMAIL PROTECTED]>: > > Henri Gomez wrote: > > Hi to all, > > > > While trying to build the latest tcnative on a SLES 10 box I got the > > following error : > > > > checking for OpenSSL library... using openssl from /usr/lib and > /usr/include > > checking OpenSSL library version... > > > > Found OPENSSL_VERSION_NUMBER 0x0090801f > > Require OPENSSL_VERSION_NUMBER 0x0090701f or greater (0.9.7a) > > Require OPENSSL_VERSION_NUMBER 0x0090802f or greater (0.9.8a) > > > > not compatible > > > 0x0090802f is 0.9.8b. I see no reason to require 0.9.8a. > > Cheers > > Jean-Frederic > > > > > > It's strange since I got installed openssl 0.9.8a : > > > > openssl-devel-0.9.8a-18.15 > > openssl-0.9.8a-18.15 > > > > Regards > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
DO NOT REPLY [Bug 37458] Datarace on org.apache.catalina.loader. WebappClassLoader
https://issues.apache.org/bugzilla/show_bug.cgi?id=37458 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from Mark Thomas <[EMAIL PROTECTED]> 2008-03-27 06:40:02 PST --- Re-opening so I remember to look at this. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat-oacc
Rainer Jung wrote: Filip Hanik - Dev Lists schrieb: hi Rainer, so to tell the true tale, isn't the story... - You got customers on 5.5 using session replication Of course, and that helped in making the 5.5 cluster better. - Your customers want to move to Tomcat 6 I do hope so! I thought that's something we want all our users to do? But: I didn't do OACC because *anyone* asked me to. I reflected the actual situation and I still think it is a good idea. - You're not confident about the maturity of Tomcat 6's clustering codebase, mainly cause you haven't used it, even though it was originally developed in 2006. I would argue that the this doubt is mainly a lack of both usage and understanding Yes, as I said I'm not confident in its maturity. No, it mainly comes from the fact that it is pretty young. Yes, it was developped in 2006 but it first got delivered as default with TC 6. And TC 6 is getting wide adoption now - but not clustering! As I said, I'm talking about experience coming from users and I expect this to need another 6 to 12 months to grow. - So, to mitigate this, you'd like to use the ASF as the delivery vehicle for your custom code base to allow your customers to switch to Tomcat 6 So how should I interprete this statement? The terms "vehicle", "your codebase" and "your customers" make it a very insulting statement. At least I do feel insulted. Absolutely not. My sincere apologies if you feel that way. I really just wasn't feeling I was getting the whole story when you gave technical argument after technical argument without and claiming features were missing or removed, when in fact most of them are there and improved. even when it comes to documentation, TC6 is the first time there is a complete reference documentation for clustering setup. so please don't be insulted, instead be honest. don't make claims based on what you don't know, make them based on what you do know. Filip But what are we talking about: - "your codebase": its our codebase. If we had to find a single person for this cluster codebase, then it would be your codebase. As everyone can see from yesterdays commit, the codebase is nearly identical from the TC 5.5 codebase. I don't want to have "my" codebase. I want us to cooperate for a strong shared Tomcat codebase. - "your customers": I get a lot of ideas from my customers, and yes they belomg to our community as well as yours. I try to be very cautious not to bring in very customer specific things into the Tomcat project. I was thinking about cluster users of TC 5.5 and how they could move forward and this is why I did port the TC 5.5 cluster. And yes, I know users who would profit from that. But the motivation for OACC is much more general. Migration concepts in the world of high availability need to be very solid. The Tomcat project (we) cancelled support for its existing cluster module from one major version to the next, without any early warning. That's not good practise in the HA world. So yes, I want to mitigate. I want to mitigate the fact, that we didn't do the right decisions with respect to cluster users when we dropped the existing cluster in TC 6. And I am very happy, that under the hood we didn't change the inhterfaces too much so that it is very simple to mitigate this. OACC was done in less than a day. - "vehicle": The official Tomcat project is the right place to offer OACC and to care about migration issues. We only started lately to act more properly with respect to deprecations and end of live announcements. This shows the necessary awareness for the needs of our users since Tomcat is now the leading servlet container and is ubiquitous. And I'm very open here about my motivation and plans. Most of us need to combine business work with our community work. And the ASF model allows this. The questions w.r.t. doing the work inside an ASF project are more like: does it lead to the right result for the community? Do we work together in good collaboration? Is our decision process open? And yes: w.r.t. meritocracy you are much in front of me. All in all I feel accused by the above formulation. I'm ok with you doing this for those folks in sandbox, I'd probably would recommend that we not put this as an official release to Tomcat, as I believe our small group would do much better focusing the effort against the current implementation. Putting into a release means we would spend resources in the bugs that arise from the port itself. The effort point is a valid point. For this reason I'm OK with clearly stating that OACC is a dead end. I already put some (probably not that harsh) statement in the release plan file I committed yesterday before our discussion even started. Concerning official module releases I have a differing opinion: - I will not suggest to bundle OACC additionally inside any other Tomcat release file but - I think it will be a strong statement from a responsib
Re: tomcat-oacc
But what are we talking about: - "your codebase": its our codebase. If we had to find a single person for this cluster codebase, then it would be your codebase. As everyone can see from yesterdays commit, the codebase is nearly identical from the TC 5.5 codebase. I don't want to have "my" codebase. I want us to cooperate for a strong shared Tomcat codebase. - "your customers": I get a lot of ideas from my customers, and yes they belomg to our community as well as yours. I try to be very cautious not to bring in very customer specific things into the Tomcat project. I was thinking about cluster users of TC 5.5 and how they could move forward and this is why I did port the TC 5.5 cluster. And yes, I know users who would profit from that. But the motivation for OACC is much more general. Migration concepts in the world of high availability need to be very solid. The Tomcat project (we) cancelled support for its existing cluster module from one major version to the next, without any early warning. That's not good practise in the HA world. So yes, I want to mitigate. I want to mitigate the fact, that we didn't do the right decisions with respect to cluster users when we dropped the existing cluster in TC 6. And I am very happy, that under the hood we didn't change the inhterfaces too much so that it is very simple to mitigate this. OACC was done in less than a day. - "vehicle": The official Tomcat project is the right place to offer OACC and to care about migration issues. We only started lately to act more properly with respect to deprecations and end of live announcements. This shows the necessary awareness for the needs of our users since Tomcat is now the leading servlet container and is ubiquitous. And I'm very open here about my motivation and plans. Most of us need to combine business work with our community work. And the ASF model allows this. The questions w.r.t. doing the work inside an ASF project are more like: does it lead to the right result for the community? Do we work together in good collaboration? Is our decision process open? And yes: w.r.t. meritocracy you are much in front of me. All in all I feel accused by the above formulation. the answer to this all lies in the fact, that I didn't see an email on tomcat-dev about OACC creation, so if I missed it, my apologies, but I cant recall seeing one. If you didn't post it, then that would probably have been the correct route to take. I've done the mistake myself in past. Creating a project without notification, will make it "your" codebase Filip I'm ok with you doing this for those folks in sandbox, I'd probably would recommend that we not put this as an official release to Tomcat, as I believe our small group would do much better focusing the effort against the current implementation. Putting into a release means we would spend resources in the bugs that arise from the port itself. The effort point is a valid point. For this reason I'm OK with clearly stating that OACC is a dead end. I already put some (probably not that harsh) statement in the release plan file I committed yesterday before our discussion even started. Concerning official module releases I have a differing opinion: - I will not suggest to bundle OACC additionally inside any other Tomcat release file but - I think it will be a strong statement from a responsibility point of view (a project asset), to provide OACC as an official separate release download. But at least for me it's to early to propose this, because I first want to get a clearer picture, of what will be included in OACC. At the moment it builds and works, but something we deliver needs to contain other parts. Not far away, but not finished yet. I do have some comments inline too Rainer Jung wrote: Although I think that a detailed technical discussion is not the right way to determine the usefulness of OACC, some comments: - monitoring: your reference to trunk strengthens my argument about maturity of code. Taking trunk code instead of TC 5.5 code is the maximum opposite approach. - Java 5 dispatcher: I mostly agree. I got lost in the code. The code I thought was responsible was transport/PooledSender.java which uses a fixed pool of threads without queueing. I overlooked somehow the Executor with queue in the Java 5 dispatcher. Nevertheless there's still some discrepancy, because we added some aspects to the queue in 5.5 which are gone now: - lock fairness biased to the remover in order to reduce the likelyness of lock starvation the LinkedBlockingQueue implements a two-lock algorith to avoid lock contention around simultaneous puts and takes. Sounds very good, though Executor uses queue.offer() and offer() does need both of them. Neverteless I'm confident, that the j.u.concurrent queues and Executor are very efficient and stable. Using them may need some tuning, if my reasoning about primary and secondary func
Re: tomcat-oacc
+++ CUT +++ All in all I feel accused by the above formulation. the answer to this all lies in the fact, that I didn't see an email on tomcat-dev about OACC creation, so if I missed it, my apologies, but I cant recall seeing one. That is in sandbox. sandbox is supposed to be a play-ground for every committer, or has that changed? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r641908 - /tomcat/sandbox/tomcat-oacc/trunk/build.xml
Author: rjung Date: Thu Mar 27 10:25:34 2008 New Revision: 641908 URL: http://svn.apache.org/viewvc?rev=641908&view=rev Log: Prepare ant file for addition of docs sub directory. Modified: tomcat/sandbox/tomcat-oacc/trunk/build.xml Modified: tomcat/sandbox/tomcat-oacc/trunk/build.xml URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/build.xml?rev=641908&r1=641907&r2=641908&view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/build.xml (original) +++ tomcat/sandbox/tomcat-oacc/trunk/build.xml Thu Mar 27 10:25:34 2008 @@ -76,13 +76,23 @@ + - + + + + + + + + + + @@ -123,7 +133,7 @@ - @@ -147,16 +157,24 @@ + + + + + + + + - + - - @@ -165,13 +183,18 @@ - + - + + + + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r641910 - in /tomcat/sandbox/tomcat-oacc/trunk: docs/ images/
Author: rjung Date: Thu Mar 27 10:27:01 2008 New Revision: 641910 URL: http://svn.apache.org/viewvc?rev=641910&view=rev Log: Add directories for docs. Added: tomcat/sandbox/tomcat-oacc/trunk/docs/ tomcat/sandbox/tomcat-oacc/trunk/images/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r641912 - /tomcat/sandbox/tomcat-oacc/trunk/images/
Author: rjung Date: Thu Mar 27 10:28:01 2008 New Revision: 641912 URL: http://svn.apache.org/viewvc?rev=641912&view=rev Log: Throw away, we'll copy in all images from TC docs. Removed: tomcat/sandbox/tomcat-oacc/trunk/images/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r641913 - /tomcat/sandbox/tomcat-oacc/trunk/docs/images/
Author: rjung Date: Thu Mar 27 10:29:31 2008 New Revision: 641913 URL: http://svn.apache.org/viewvc?rev=641913&view=rev Log: Import docs images. Added: tomcat/sandbox/tomcat-oacc/trunk/docs/images/ - copied from r641912, tomcat/container/tc5.5.x/webapps/docs/images/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat-oacc
jean-frederic clere wrote: +++ CUT +++ All in all I feel accused by the above formulation. the answer to this all lies in the fact, that I didn't see an email on tomcat-dev about OACC creation, so if I missed it, my apologies, but I cant recall seeing one. That is in sandbox. sandbox is supposed to be a play-ground for every committer, or has that changed? when one wants it to be an official release, then it should probably be discussed. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r641921 - /tomcat/sandbox/tomcat-oacc/trunk/build.xml
Author: rjung Date: Thu Mar 27 10:40:14 2008 New Revision: 641921 URL: http://svn.apache.org/viewvc?rev=641921&view=rev Log: Fix ant script w.r.t. docs. Modified: tomcat/sandbox/tomcat-oacc/trunk/build.xml Modified: tomcat/sandbox/tomcat-oacc/trunk/build.xml URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/build.xml?rev=641921&r1=641920&r2=641921&view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/build.xml (original) +++ tomcat/sandbox/tomcat-oacc/trunk/build.xml Thu Mar 27 10:40:14 2008 @@ -91,7 +91,7 @@ - + @@ -180,6 +180,7 @@ + @@ -188,7 +189,7 @@ - + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat-oacc
Filip Hanik - Dev Lists wrote: jean-frederic clere wrote: +++ CUT +++ All in all I feel accused by the above formulation. the answer to this all lies in the fact, that I didn't see an email on tomcat-dev about OACC creation, so if I missed it, my apologies, but I cant recall seeing one. That is in sandbox. sandbox is supposed to be a play-ground for every committer, or has that changed? when one wants it to be an official release, then it should probably be discussed. Filip I'm trying to reply to today's mails in one mail to keep it easier to follow. Feeling insulted: Thanks for your answer. Fully accepted. I think it's better to talk about emotions when they come up. In advance notice about OACC: there was no. It was long in my head, but the work was actually done in one day. Was it a fault? Maybe. There are the obvious Pros and Cons. I decided to show what I wanted to talk about first, and then start a discussion, totally accepting, that the result might not be the one I wish. Of course I knew, that there is a big potential for conflict and I really was thinking about the subject for quite some time. At the end I think there is no real reason for a conflict, because it is just one more option. If the project decides not to offer this migration step, because the risk of lowering adoption for the better newer cluster is to high, I'm fine with that. Technical reasons: I really tried to carefully describe, that my motivation does *not* come from any known technical problems with the new cluster. I don't know of any, and the observations we discussed are actually minor points (apart from JMX :)) ). I agree, that we should simply work on those and they don't necessitate OACC. I'm really motivated by a very abstract argument: HA needs to work with the lowest possible risk. New code always carries an increased risk. If we have satisfied Tomcat cluster users which are not now starting a new project but are having HA applications (yes I mean really mission critical), at the moment they can only decide to be locked in with Tomcat 5.5 or jump to the new implementation. If they want to move to TC 6, that wish will mostly be driven by the web app developpers. The HA stuff is mainly under project control of the operations people. Offering a two step migration seemed to be a good thing to me. That's not talking about an existing customer, I get these ideas from my consulting experience. If OACC is to much work: then no. If we think that we can't get the story clear for our users: then no. But I think it is very little work, and I will accept any formulation about our recommendations. Formally for me it is only a sandbox right now. I added the original docs with some additions about the OACC situation and I need to add the tar and zip targets. Finally I have one patch for DeltaManager, which is also missing in TC 5.5 (and maybe HA/Tribes, I need to check). That's it. Then I would hope, that the project has a look at the stuff, and at the final wording in the docs (I might formulate even stronger than I did when I wrote the files yesterday). After that I would ask about existing formal limitations for placing downloads on t.a.o/dev/dist, or p.a.o. Finally I would like to start a discussion, if we think we should have it as an extras download, or not. Depending on the review, the discussion and the vote it will either get released, or simply stay in the sandbox. I'm totally aware of the fact, that this might happen. If you agree, we can postpone the OACC discussion for now. I don't plan to put more efforts into it than maybe another hour. And we'll resume the discussion in a few weeks, before we need to decide about releasing it or not. But if you like, we can start another discussion about the remaining minor HA/Tribes points. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat-oacc
It's a good initiative and sandbox is where experimental code should start. Gentlemen, don't feel insulted or whatever, to discuss code, reviewers should see it and that's why sandbox. I'm very happy to see new codes in sandbox these days like OACC or Tomcat-Lite, good ideas should be shared for reviews and positive/negative feebacks and suggestions. Regards 2008/3/27, Rainer Jung <[EMAIL PROTECTED]>: > > Filip Hanik - Dev Lists wrote: > > jean-frederic clere wrote: > >> +++ CUT +++ > >> > All in all I feel accused by the above formulation. > >>> the answer to this all lies in the fact, that I didn't see an email > >>> on tomcat-dev about OACC creation, so if I missed it, my apologies, > >>> but I cant recall seeing one. > >> > >> That is in sandbox. sandbox is supposed to be a play-ground for every > >> committer, or has that changed? > > when one wants it to be an official release, then it should probably be > > discussed. > > > > Filip > > > I'm trying to reply to today's mails in one mail to keep it easier to > follow. > > Feeling insulted: Thanks for your answer. Fully accepted. I think it's > better to talk about emotions when they come up. > > In advance notice about OACC: there was no. It was long in my head, but > the work was actually done in one day. Was it a fault? Maybe. There are > the obvious Pros and Cons. I decided to show what I wanted to talk about > first, and then start a discussion, totally accepting, that the result > might not be the one I wish. > > Of course I knew, that there is a big potential for conflict and I > really was thinking about the subject for quite some time. At the end I > think there is no real reason for a conflict, because it is just one > more option. If the project decides not to offer this migration step, > because the risk of lowering adoption for the better newer cluster is to > high, I'm fine with that. > > Technical reasons: I really tried to carefully describe, that my > motivation does *not* come from any known technical problems with the > new cluster. I don't know of any, and the observations we discussed are > actually minor points (apart from JMX :)) ). I agree, that we should > simply work on those and they don't necessitate OACC. > > I'm really motivated by a very abstract argument: HA needs to work with > the lowest possible risk. New code always carries an increased risk. If > we have satisfied Tomcat cluster users which are not now starting a new > project but are having HA applications (yes I mean really mission > critical), at the moment they can only decide to be locked in with > Tomcat 5.5 or jump to the new implementation. If they want to move to TC > 6, that wish will mostly be driven by the web app developpers. The HA > stuff is mainly under project control of the operations people. Offering > a two step migration seemed to be a good thing to me. That's not talking > about an existing customer, I get these ideas from my consulting > experience. > > If OACC is to much work: then no. > If we think that we can't get the story clear for our users: then no. > > But I think it is very little work, and I will accept any formulation > about our recommendations. > > Formally for me it is only a sandbox right now. I added the original > docs with some additions about the OACC situation and I need to add the > tar and zip targets. Finally I have one patch for DeltaManager, which is > also missing in TC 5.5 (and maybe HA/Tribes, I need to check). That's it. > > Then I would hope, that the project has a look at the stuff, and at the > final wording in the docs (I might formulate even stronger than I did > when I wrote the files yesterday). > > After that I would ask about existing formal limitations for placing > downloads on t.a.o/dev/dist, or p.a.o. > > Finally I would like to start a discussion, if we think we should have > it as an extras download, or not. > > Depending on the review, the discussion and the vote it will either get > released, or simply stay in the sandbox. I'm totally aware of the fact, > that this might happen. > > If you agree, we can postpone the OACC discussion for now. I don't plan > to put more efforts into it than maybe another hour. And we'll resume > the discussion in a few weeks, before we need to decide about releasing > it or not. > > But if you like, we can start another discussion about the remaining > minor HA/Tribes points. > > Regards, > > > Rainer > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
svn commit: r641970 - /tomcat/sandbox/tomcat-oacc/trunk/src/share/org/apache/catalina/cluster/tcp/SimpleTcpCluster.java
Author: rjung Date: Thu Mar 27 13:34:07 2008 New Revision: 641970 URL: http://svn.apache.org/viewvc?rev=641970&view=rev Log: Remove the remaining open porting question. Modified: tomcat/sandbox/tomcat-oacc/trunk/src/share/org/apache/catalina/cluster/tcp/SimpleTcpCluster.java Modified: tomcat/sandbox/tomcat-oacc/trunk/src/share/org/apache/catalina/cluster/tcp/SimpleTcpCluster.java URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/src/share/org/apache/catalina/cluster/tcp/SimpleTcpCluster.java?rev=641970&r1=641969&r2=641970&view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/src/share/org/apache/catalina/cluster/tcp/SimpleTcpCluster.java (original) +++ tomcat/sandbox/tomcat-oacc/trunk/src/share/org/apache/catalina/cluster/tcp/SimpleTcpCluster.java Thu Mar 27 13:34:07 2008 @@ -573,8 +573,6 @@ String clusterName = getManagerName(cmanager.getName(), manager); cmanager.setName(clusterName); cmanager.setCluster(this); -// XXX: TC6 cluster has: cmanager.setDefaultMode(false); -// XXX: Find out, which one is correct/better. cmanager.setDefaultMode(true); managers.put(clusterName, manager); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r641973 - in /tomcat/sandbox/tomcat-oacc/trunk/test: ./ src/share/org/apache/catalina/cluster/session/ src/share/org/apache/catalina/cluster/tcp/
Author: pero
Date: Thu Mar 27 13:38:44 2008
New Revision: 641973
URL: http://svn.apache.org/viewvc?rev=641973&view=rev
Log:
reactivate test cases
Modified:
tomcat/sandbox/tomcat-oacc/trunk/test/build.xml
tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/session/DeltaManagerTest.java
tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/session/DeltaSessionTest.java
tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/tcp/DataSenderTest.java
Modified: tomcat/sandbox/tomcat-oacc/trunk/test/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/test/build.xml?rev=641973&r1=641972&r2=641973&view=diff
==
--- tomcat/sandbox/tomcat-oacc/trunk/test/build.xml (original)
+++ tomcat/sandbox/tomcat-oacc/trunk/test/build.xml Thu Mar 27 13:38:44 2008
@@ -17,36 +17,31 @@
-->
-
-
+
+
-
+
-
+
-
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
@@ -75,7 +70,7 @@
-
+
@@ -83,13 +78,16 @@
+ Some tests logging Warnings or Errors, but this is
OK!
+---
+
-
+
-
+
Modified:
tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/session/DeltaManagerTest.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/session/DeltaManagerTest.java?rev=641973&r1=641972&r2=641973&view=diff
==
---
tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/session/DeltaManagerTest.java
(original)
+++
tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/session/DeltaManagerTest.java
Thu Mar 27 13:38:44 2008
@@ -23,6 +23,7 @@
import junit.framework.TestCase;
import org.apache.catalina.Session;
+import org.apache.catalina.core.StandardContext;
import org.apache.catalina.cluster.ClusterMessage;
import org.apache.catalina.cluster.Member;
import org.apache.catalina.cluster.mcast.McastMember;
@@ -48,6 +49,7 @@
public void testhandleGET_ALL_SESSIONS() throws Exception {
MockDeltaManager manager = new MockDeltaManager() ;
+manager.setContainer(new StandardContext());
Session session = manager.createSession(null,false);
assertEquals(session, manager.findSession(session.getId()));
for (int i = 0; i < 10; i++) {
Modified:
tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/session/DeltaSessionTest.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/session/DeltaSessionTest.java?rev=641973&r1=641972&r2=641973&view=diff
==
---
tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/session/DeltaSessionTest.java
(original)
+++
tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/session/DeltaSessionTest.java
Thu Mar 27 13:38:44 2008
@@ -53,6 +53,7 @@
manager.setMaxInactiveInterval(1);
MockSession session =
(MockSession)manager.createSession("hello",false);
session.setPrimarySession(false);
+session.setExpireTolerance(1);
try {
Thread.sleep(1000);
} catch (Exception sleep) {
Modified:
tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/tcp/DataSenderTest.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/tcp/DataSenderTest.java?rev=641973&r1=641972&r2=641973&view=diff
==
---
tomcat/sandbox/tomcat-oacc/trunk/test/src/share/org/apache/catalina/cluster/tcp/DataSenderTest.java
(original)
+++
tomcat/sandbox/tomcat-oac
svn commit: r641974 - /tomcat/sandbox/tomcat-oacc/trunk/build.xml
Author: pero
Date: Thu Mar 27 13:40:22 2008
New Revision: 641974
URL: http://svn.apache.org/viewvc?rev=641974&view=rev
Log:
fix javadoc target
Modified:
tomcat/sandbox/tomcat-oacc/trunk/build.xml
Modified: tomcat/sandbox/tomcat-oacc/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/build.xml?rev=641974&r1=641973&r2=641974&view=diff
==
--- tomcat/sandbox/tomcat-oacc/trunk/build.xml (original)
+++ tomcat/sandbox/tomcat-oacc/trunk/build.xml Thu Mar 27 13:40:22 2008
@@ -134,13 +134,13 @@
@@ -151,12 +151,6 @@
-
-
-
-
-
-
@@ -172,19 +166,17 @@
basedir="${oacc.build}/classes">
-
-
-
+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r641982 - in /tomcat/sandbox/tomcat-oacc/trunk: BUILDING.txt RELEASE-NOTES RUNNING.txt
Author: rjung
Date: Thu Mar 27 14:12:41 2008
New Revision: 641982
URL: http://svn.apache.org/viewvc?rev=641982&view=rev
Log:
Minor docs adjustment.
Modified:
tomcat/sandbox/tomcat-oacc/trunk/BUILDING.txt
tomcat/sandbox/tomcat-oacc/trunk/RELEASE-NOTES
tomcat/sandbox/tomcat-oacc/trunk/RUNNING.txt
Modified: tomcat/sandbox/tomcat-oacc/trunk/BUILDING.txt
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/BUILDING.txt?rev=641982&r1=641981&r2=641982&view=diff
==
--- tomcat/sandbox/tomcat-oacc/trunk/BUILDING.txt (original)
+++ tomcat/sandbox/tomcat-oacc/trunk/BUILDING.txt Thu Mar 27 14:12:41 2008
@@ -132,7 +132,8 @@
* The compiled classes will be placed into ${oacc.source}/build.
The jar files needed to install OACC will be placed into
- ${oacc.source}/dist.
+ ${oacc.source}/dist/lib, the docs will go into
+ ${oacc.source}/dist/docs.
(3) Updating sources
@@ -145,27 +146,44 @@
For a quick rebuild of only modified code you can use:
cd ${oacc.source}
-ant
+ant build-oacc
If you apply changes to the source and you want to make sure
that all classes get compiled correctly by ant, you can delete
the results of a previous compilation by
-ant build-clean
+ant clean
(5) Building the documentation
-The documentation can be easly built:
+The documentation gets automatically build by the default ant target.
+If you want to build it seperately, you can use
+
+cd ${oacc.source}
+ant build-docs
-cd ${tomcat.source}
-...
+or you go to the docs directory and do
-(6) Building the javadoc
-cd ${tomcat.source}
-...
+cd ${oacc.source}/docs
+ant
-(7) Building a oacc release:
+(6) Running the junit tests
+
+The path to your junit jar file must be set in your build.properties.
+For an example see build.properties.default.
+
+cd ${oacc.source}/test
+ant
+
+(7) Building the javadoc
+
+cd ${oacc.source}
+ant javadoc
+
+(8) Building a oacc release
+
+cd ${oacc.source}
+ant dist
-cd ${tomcat.source}
-...
+The dist target is also the default ant target.
Modified: tomcat/sandbox/tomcat-oacc/trunk/RELEASE-NOTES
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/RELEASE-NOTES?rev=641982&r1=641981&r2=641982&view=diff
==
--- tomcat/sandbox/tomcat-oacc/trunk/RELEASE-NOTES (original)
+++ tomcat/sandbox/tomcat-oacc/trunk/RELEASE-NOTES Thu Mar 27 14:12:41 2008
@@ -64,4 +64,4 @@
===
Viewing the Tomcat OACC Change Log:
===
-See changelog.html in the documentation directory.
+See changelog.html in the docs directory.
Modified: tomcat/sandbox/tomcat-oacc/trunk/RUNNING.txt
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/RUNNING.txt?rev=641982&r1=641981&r2=641982&view=diff
==
--- tomcat/sandbox/tomcat-oacc/trunk/RUNNING.txt (original)
+++ tomcat/sandbox/tomcat-oacc/trunk/RUNNING.txt Thu Mar 27 14:12:41 2008
@@ -77,6 +77,8 @@
use OACC. We don't support mixed use of OACC and Tomcat 6 default cluster
in the same Tomcat instance though.
+(2.6) Read the docs contained in $OACC_HOME/docs.
+
(3) Testing
(3.1) Start up Tomcat on all cluster nodes.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r641984 - in /tomcat/sandbox/tomcat-oacc/trunk: build.properties.default build.xml docs/build.xml test/build.xml
Author: rjung
Date: Thu Mar 27 14:16:08 2008
New Revision: 641984
URL: http://svn.apache.org/viewvc?rev=641984&view=rev
Log:
Build file adjustments.
Modified:
tomcat/sandbox/tomcat-oacc/trunk/build.properties.default
tomcat/sandbox/tomcat-oacc/trunk/build.xml
tomcat/sandbox/tomcat-oacc/trunk/docs/build.xml
tomcat/sandbox/tomcat-oacc/trunk/test/build.xml
Modified: tomcat/sandbox/tomcat-oacc/trunk/build.properties.default
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/build.properties.default?rev=641984&r1=641983&r2=641984&view=diff
==
--- tomcat/sandbox/tomcat-oacc/trunk/build.properties.default (original)
+++ tomcat/sandbox/tomcat-oacc/trunk/build.properties.default Thu Mar 27
14:16:08 2008
@@ -32,13 +32,17 @@
# path, we'll do that in build.xml automatically.
#
catalina.home=C:/Programme/apache-tomcat-6.0.14
-#catalina.home=../trunk/output/build
+#catalina.home=/usr/local/apache-tomcat-6.0.14
#
# We also need to know, where the tomcat-juli.jar is.
# This should be the full path including any sub directories.
#
-catalina.extras=C:/Programme/apache-tomcat-6.0.14/extras
-#catalina.extras=../trunk/output/extras
+catalina.extras=C:/Programme/apache-tomcat-6.0.14/bin
+#catalina.extras=/usr/local/apache-tomcat-6.0.14/bin
+
+# Only needed if you want to run the test suite
+junit.jar=C:/Programme/junit-4.4/junit-4.4.jar
+junit.jar=/usr/local/junit-4.4/junit-4.4.jar
compile.source=1.5
compile.target=1.5
Modified: tomcat/sandbox/tomcat-oacc/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/build.xml?rev=641984&r1=641983&r2=641984&view=diff
==
--- tomcat/sandbox/tomcat-oacc/trunk/build.xml (original)
+++ tomcat/sandbox/tomcat-oacc/trunk/build.xml Thu Mar 27 14:16:08 2008
@@ -162,12 +162,12 @@
-
-
@@ -176,7 +176,7 @@
-
+
Modified: tomcat/sandbox/tomcat-oacc/trunk/docs/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/docs/build.xml?rev=641984&r1=641983&r2=641984&view=diff
==
--- tomcat/sandbox/tomcat-oacc/trunk/docs/build.xml (original)
+++ tomcat/sandbox/tomcat-oacc/trunk/docs/build.xml Thu Mar 27 14:16:08 2008
@@ -20,9 +20,8 @@
-
+
-
Modified: tomcat/sandbox/tomcat-oacc/trunk/test/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/test/build.xml?rev=641984&r1=641983&r2=641984&view=diff
==
--- tomcat/sandbox/tomcat-oacc/trunk/test/build.xml (original)
+++ tomcat/sandbox/tomcat-oacc/trunk/test/build.xml Thu Mar 27 14:16:08 2008
@@ -16,7 +16,7 @@
limitations under the License.
-->
-
+
@@ -24,7 +24,6 @@
-
@@ -40,6 +39,7 @@
+
@@ -49,7 +49,7 @@
- This ant script implements some testcases to verify the
key functions of tomcat clustering module.
+ This ant script implements some testcases to verify the
key functions of tomcat OACC module.
You find this script at: ${ant.file}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44686] Migrating from Tomcat 5.0.28 to Tomcat 6.0.14
https://issues.apache.org/bugzilla/show_bug.cgi?id=44686 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-03-27 14:47:07 PST --- Using the code extract you provided as a basis for a .tagx file, I do not see this error. I suggest you test using a clean install of Tomcat 6 and make sure no TC5 elements sneak in. If you can re-produce this, please provide a minimal war (should be no more than a few hundred K, even with the jars for the tag libs) that demonstrates the issue. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44683] connection pool is not being kept alive by dbcp
https://issues.apache.org/bugzilla/show_bug.cgi?id=44683 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-03-27 15:47:22 PST --- This works for me with Tomcat 6.0.16 and the 5.1.6 connector. There must be something else wrong with your configuration. The best place to get help figuring out what the problem might be is the users list. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37458] Datarace on org.apache.catalina.loader. WebappClassLoader
https://issues.apache.org/bugzilla/show_bug.cgi?id=37458 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #6 from Mark Thomas <[EMAIL PROTECTED]> 2008-03-27 16:13:56 PST --- There are a couple of odd things about your stack trace. 1. For 5.5.23, line 1800 of WebappClassLoader doesn't call Package.isSealed(). It is around 30 lines later. 2. I don't understand why the NPE is thrown from within java.lang.Package. If pkg was null, I'd expect to see the NPE in WebappClassLoader 3. I have checked the source for 1.4, 1.5 and 1.6 and don't see how Package.isSealed() could throw a NPE. I have reviewed the patch you referred to and I do not see a code path by which this bug could re-appear. You may have found a new bug, in which case a new issue is in order, but the oddities above make me think that the root cause is more likely some other factor in your configuration. The best place to get help on this is the users list. Before posting please try a clean 5.5.26 build and also post the OS and JDK you are using. If the discussion there concludes there is a bug, please create a new issue to track it. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r642022 - in /tomcat/sandbox/tomcat-oacc/trunk/docs: changelog.xml index.xml project.xml
Author: rjung Date: Thu Mar 27 16:21:56 2008 New Revision: 642022 URL: http://svn.apache.org/viewvc?rev=642022&view=rev Log: Add javadocs to docs. Modified: tomcat/sandbox/tomcat-oacc/trunk/docs/changelog.xml tomcat/sandbox/tomcat-oacc/trunk/docs/index.xml tomcat/sandbox/tomcat-oacc/trunk/docs/project.xml Modified: tomcat/sandbox/tomcat-oacc/trunk/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/docs/changelog.xml?rev=642022&r1=642021&r2=642022&view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/docs/changelog.xml (original) +++ tomcat/sandbox/tomcat-oacc/trunk/docs/changelog.xml Thu Mar 27 16:21:56 2008 @@ -28,7 +28,7 @@ - + Modified: tomcat/sandbox/tomcat-oacc/trunk/docs/index.xml URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/docs/index.xml?rev=642022&r1=642021&r2=642022&view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/docs/index.xml (original) +++ tomcat/sandbox/tomcat-oacc/trunk/docs/index.xml Thu Mar 27 16:21:56 2008 @@ -69,6 +69,8 @@ Building from Source - Details the steps necessary to download Apache Tomcat OACC source code, and build a binary distribution from those sources. +API Docs +- Javadoc for OACC. Modified: tomcat/sandbox/tomcat-oacc/trunk/docs/project.xml URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/docs/project.xml?rev=642022&r1=642021&r2=642022&view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/docs/project.xml (original) +++ tomcat/sandbox/tomcat-oacc/trunk/docs/project.xml Thu Mar 27 16:21:56 2008 @@ -34,6 +34,7 @@ + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r642025 - in /tomcat/sandbox/tomcat-oacc/trunk: build.properties.default build.xml docs/build.xml test/build.xml
Author: rjung Date: Thu Mar 27 16:31:59 2008 New Revision: 642025 URL: http://svn.apache.org/viewvc?rev=642025&view=rev Log: Build procedure update: - add javadocs - let build.xml in sub dirs use vars from above - build release artefacts - use fixcrlf - fix file system permissions (chmod task) Modified: tomcat/sandbox/tomcat-oacc/trunk/build.properties.default tomcat/sandbox/tomcat-oacc/trunk/build.xml tomcat/sandbox/tomcat-oacc/trunk/docs/build.xml tomcat/sandbox/tomcat-oacc/trunk/test/build.xml Modified: tomcat/sandbox/tomcat-oacc/trunk/build.properties.default URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/build.properties.default?rev=642025&r1=642024&r2=642025&view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/build.properties.default (original) +++ tomcat/sandbox/tomcat-oacc/trunk/build.properties.default Thu Mar 27 16:31:59 2008 @@ -47,3 +47,10 @@ compile.source=1.5 compile.target=1.5 compile.debug=true + +version=6.0.17-dev + +oacc.output=output +oacc.build=output/build +oacc.dist=output/dist +oacc.release=output/release Modified: tomcat/sandbox/tomcat-oacc/trunk/build.xml URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/build.xml?rev=642025&r1=642024&r2=642025&view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/build.xml (original) +++ tomcat/sandbox/tomcat-oacc/trunk/build.xml Thu Mar 27 16:31:59 2008 @@ -24,10 +24,16 @@ - - + + + + + - + + + + @@ -35,7 +41,7 @@ - + @@ -78,13 +84,14 @@ + - + @@ -131,12 +138,13 @@ - - + + + + + @@ -173,21 +183,145 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Modified: tomcat/sandbox/tomcat-oacc/trunk/docs/build.xml URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/docs/build.xml?rev=642025&r1=642024&r2=642025&view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/docs/build.xml (original) +++ tomcat/sandbox/tomcat-oacc/trunk/docs/build.xml Thu Mar 27 16:31:59 2008 @@ -26,8 +26,8 @@ - - + + @@ -42,7 +42,8 @@ - + + Modified: tomcat/sandbox/tomcat-oacc/trunk/test/build.xml URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/test/build.xml?rev=642025&r1=642024&r2=642025&view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/test/build.xml (original) +++ tomcat/sandbox/tomcat-oacc/trunk/test/build.xml Thu Mar 27 16:31:59 2008 @@ -29,7 +29,7 @@ - + @@ -37,8 +37,8 @@ - - + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r642030 - /tomcat/sandbox/tomcat-oacc/trunk/BUILDING.txt
Author: rjung
Date: Thu Mar 27 16:46:29 2008
New Revision: 642030
URL: http://svn.apache.org/viewvc?rev=642030&view=rev
Log:
Sync doc with build procedure.
Modified:
tomcat/sandbox/tomcat-oacc/trunk/BUILDING.txt
Modified: tomcat/sandbox/tomcat-oacc/trunk/BUILDING.txt
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/BUILDING.txt?rev=642030&r1=642029&r2=642030&view=diff
==
--- tomcat/sandbox/tomcat-oacc/trunk/BUILDING.txt (original)
+++ tomcat/sandbox/tomcat-oacc/trunk/BUILDING.txt Thu Mar 27 16:46:29 2008
@@ -141,6 +141,7 @@
It is recommended that you regularly update the downloaded Tomcat OACC
sources using your SVN client.
+
(4) Rebuilds
For a quick rebuild of only modified code you can use:
@@ -168,6 +169,7 @@
cd ${oacc.source}/docs
ant
+
(6) Running the junit tests
The path to your junit jar file must be set in your build.properties.
@@ -176,14 +178,16 @@
cd ${oacc.source}/test
ant
+
(7) Building the javadoc
cd ${oacc.source}
ant javadoc
-(8) Building a oacc release
+
+(8) Building a OACC release
cd ${oacc.source}
-ant dist
+ant release
The dist target is also the default ant target.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44697] New: AccessValveLog doesn't escape URIs like HTTPd
https://issues.apache.org/bugzilla/show_bug.cgi?id=44697 Summary: AccessValveLog doesn't escape URIs like HTTPd Product: Tomcat 5 Version: 5.5.20 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Here's my Valve (ripped off from the Tomcat docs): When I do: curl 'http://localhost:8080/";' The quote shows up literally in the log. On httpd 2.2.3 I get a backslash escaped quote. I don't know what other naughty characters also mess up logging. 127.0.0.1 - - [27/Mar/2008:18:07:48 -0700] "GET /\" HTTP/1.1" 404 278 "-" "curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5" httpd again: curl -D - 'http://localhost/ HTTP/1.1"' 127.0.0.1 - - [27/Mar/2008:18:15:30 -0700] "GET / HTTP/1.1\" HTTP/1.1" 200 916 "-" "curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5" I believe this is major because I cannot parse the logs without also looking out for people injecting garbage to poison the logs. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 4.1.36 / .37 cant compile jsp on NetWare
Hi all, another user pointed out that Tomcat4 versions later than 4.1.34 dont work properly on NetWare; when you try to call any of the jsp examples, f.e. snoop.jsp, then you receive an HTTP Status 500: An error occurred at line: -1 in the jsp file: null full error report here: http://www.gknw.net/test/tomcat/Apache%20Tomcat-4_1_37%20-%20Error%20report.htm so it seems that Tomcat 4.1.36 / 4.1.37 are no longer able to compile jsp. The same user also reported that there was a change with the Ant version: TC 4.1.34 uses Ant 1.5, and TC 4.1.36 and later uses Ant 1.7. Indeed the issue can be fixed with only copying ant.jar from TC 4.1.34 over to TC 4.1.36 or 4.1.37; after that all works fine as usual. I googled for that error, and got tons back, however as usual nothing but same question and no solution; only that other recommended to upgrade JDK to 1.5 - and indeed some then reported back that it works. But when I look at the Ant page: http://ant.apache.org/manual/install.html#sysrequirements I can read there that Ant 1.7 requires JDK 1.3 only which is same as what the TC 4.1.x docs say; and the version I currently run on NetWare is: Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_13) Java HotSpot(TM) Client VM (build 1.4.2, mixed mode) We have also TC 5.0.x and even TC 5.5.x running on NetWare, so I wonder what here breaks with TC 4.1.37? I hope someone can give me some hints what's missing; my guess is that Ant 1.7 requires now some additional pieces with the classpath, whatever Thanks, Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
