[Taglibs] Is anyone looking after taglibs?
The Jakarta TLP is about to retire to the attic; however the taglibs site still refers to non-existent jakarta pages for the downloads. A bug [1] was raised for this for this some while ago, but there appears to be no-one interested in fixing the issue. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51382 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Proposal: use tomcat-version-number in server.xml element?
On 2 December 2011 17:35, Christopher Schultz wrote: > Filip, > > On 12/2/11 12:26 PM, Filip Hanik - Dev Lists wrote: >> Chris, this would be your [cue] to rethink the solution one step further >> down the line. >> Not too long ago, I add in a property validator. Tomcat used to silently >> ignored invalid attributes, so misspellings such as >> >> >> >> This used to run with default values, with zero logging. This has been >> addressed for the most part. >> but there are still [loopholes], particularly with values and elements > > Definitely. I'll see if I can take a look at the validator to see how it > might be extended to look for certain things. > > I just cringe whenever I see someone who has a element in their > server.xml or "debug" attributes all over their elements. The former may > require a different strategy, but the latter should already be handled > by your validator (which really sounds like a complainer :) > > Tomcat already uses commons-digester to read its configuration files, so > it should be trivial to add some rules to look for specific, definitely > BAD things (like anywhere, for instance). > > IIRC, Tomcat has hard-coded digester rules for just about everything. > Does anyone know if that was an intentional design decision or just what > happened at the time? Digester may have more elegant ways of doing the > same things these days (like XML configuration)... and that would make > it easier for me to add something like this: just a one-liner in the > configuration for each known-bad element/property instead of modifying > the code. What about implementing something like Java does for deprecated code? That is, if the checking algorithm notices anything odd in the configuration, log a _single_ message to say the config looks wrong. The message should say how to generate more verbose logging (and possibly stricter checking), e.g. via a System property or marker file, or even via a command-line option. [Asking them to edit the xml file would likely be counter-productive...!] If it was found that even basic checking caused a slowdown in startup, then just log a message saying how to run the checks. == May I suggest that any warning messages generated by the checking algorithm have a unique code for each error type; if it is reasonably short (cf. Http's 404 etc. or VMS's RMS-FNF) it might make debugging on the user list easier. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Nexus with no community discussion. WTF?
On 16 December 2011 16:15, Mark Thomas wrote: > On 16/12/2011 16:06, Antonio Petrelli wrote: >> Please Mark calm down. > > No, I will not calm down. The release process has been changed without > prior discussion and on top of that it is now broken for Maven > artefacts. That is not acceptable. > >> Being possible to deploy to Nexus does not mean that the project is >> configured to do that. > > Exactly. Tomcat has been using scp+rsync via people.a.o for several > years. That process has been broken by the switch to Nexus. > >> To enable this, you need to configure the needed POM >> metadata (SCM, website) and let the master POM of Tomcat be child of the >> Apache Master pom. >> Even if you have done this steps, if you are not using the Maven release >> plugin, it does not work. AFAICT you should be able to (temporarily, for >> good) deploy to people.a.o. > > The whole point is that we can no longer release via people.a.o because > of the switch to Nexus. It has been made quite clear that a project can > use either Nexus or people.a.o but not both. For Tomcat to use Nexus, > the Tomcat release scripts need to be updated and they have not been. That's not how Nexus is being used in Commons - but I don't know what has been set up here, so perhaps the following is not applicable: Nexus (as used by Commons/HttpClient) intercepts uploads to the Maven distribution repo on people. Instead of Maven artifacts being automatically synched with Maven Central, Nexus stores them in a staging repo. This must be checked and closed to new updates; it's then available to the general public to as part of the VOTE. If the vote succeeds, the staging repo can be released, otherwise it is dropped. Once released, the artifacts make their way to Maven Central as before. Nexus does *not* change the process for non-Maven artifacts (which are the main Tomcat release mechanism). However once enabled for a project, the protection on the maven distribution repo is changed so only Nexus can update it. The benefit is that it is impossible to accidentally release Maven artifacts using "mvn deploy" or whatever; and there is staging area which can be used for votes. It also checks sigs and generates hashes if necessary. It guarantees that the voted on artifacts are the ones that are released. The disadvantage is that one has to login to Nexus twice: to close the staging area, and then to release or drop it at the end of the vote. But this does not change how non-Maven artifacts are released. >> Antonio >> >> P.S. Your project is a mess to be a Maven project. If you *really* want to >> move to Maven you need to do a major reconstruction of the directory >> structure. > > There are no plans to move Tomcat to use Maven for building. This is > purely about providing the Tomcat JARs as Maven artefacts in Maven > Central for others to use as they wish. > > Mark > >> >> 2011/12/16 Mark Thomas >> >>> On 16/12/2011 15:43, jean-frederic clere wrote: On 12/16/2011 04:20 PM, Mark Thomas wrote: > It appears that Maven artefact publishing has been moved from people.a.o > (that all the release scripts are written to use) to using Nexus. See >>> [1] > > I have a number of issues with this: > > 1. There was zero discussion of this on the dev list. > > 2. Maven publishing for snapshots, release candidates and releases is > now broken as the release scripts have not been updated as it appears is > required. [2] > > Jean-Frederic, please explain ASAP what on earth is going on here. > Decisions such as this must happen on list *before* they are actioned. I understood it only affects the release process... >>> >>> So what? Releasing software is why this community exists. Any changes to >>> that process need to be agreed by the community first. >>> If that is wrong that I screwed it, Sorry >>> >>> Before this change, we could release artefacts to Maven Central. >>> >>> After this change, we are unable to release artefacts to Maven Central >>> since that part of the release process now needs re-writing. >>> >>> That is not acceptable. If there were an security issue that required an >>> immediate release Maven users at best would get the artefacts late or at >>> worst not at all. >>> >>> An apology is a good start but the stuff you have just broken needs >>> fixing. At the moment, I see two possible fixes. >>> >>> 1. Update the release scripts so we can release artefacts to Maven using >>> the new process. >>> 2. Revert the change to use Nexus and return to scp+rsync. >>> >>> If you don't do 1. (pretty much immediately), I intend to request that >>> the infra team does 2. >>> >>> Mark >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >>> >> > > > - > To unsubs
Re: Publishing process for JARs for Maven Central
On 16 December 2011 23:45, Yoav Shapira wrote: > On Fri, Dec 16, 2011 at 2:56 PM, Mark Thomas wrote: >> All, >> >> There are currently two options for publishing JARs to Maven Central: >> 1. scp+rsync via people.a.o >> 2. Nexus > > I don't have a strong preference between them. Is there a difference > between the two approaches in how fast the JARs are available for > download? AFAIK it's the same. AIUI the artifacts are still deployed to the same distribution area. Nexus copies them across when the RM releases the staging repo, rather than the RM doing the copy directly. BTW, Nexus takes care of maintaining the Maven metadata. It also checks that the signature is valid and uses a public key (I think this is done on Close) I think it also creates hashes if required. See http://www.apache.org/dev/publishing-maven-artifacts.html and linked docs for some more info on Nexus. > Yoav > >> >> Personally, my only requirements are: >> a) that the JARs reach Maven Central >> b) publishing is as simple as running a single script >> >> I don't particularly care about the details. As long as all I have to do >> is run a script and the JARs end up in Maven Central I'm happy. I know >> option 1 works and I assume 2 will work the same way. Therefore I have >> no preference for either approach. >> >> Does anyone else have any requirements / views that would suggest one >> approach is better than the other? >> >> Mark >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On 17 December 2011 05:19, Phil Steitz wrote: > On 12/16/11 12:56 PM, Mark Thomas wrote: >> All, >> >> There are currently two options for publishing JARs to Maven Central: >> 1. scp+rsync via people.a.o >> 2. Nexus >> >> Personally, my only requirements are: >> a) that the JARs reach Maven Central >> b) publishing is as simple as running a single script > > I would be very interested to know if anyone has figured out a way > to fully script Nexus. AFAIK, Nexus requires that you use the GUI I think that's the main advantage or Nexus - makes it difficult to accidentally release files. This happened at least once in Commons before we started using Nexus. AIUI there is a REST interface which could be scripted if one could find the docs. But I think it would negate one of the main benefits if this allowed releases to be published to Maven Central automatically. > and also (sic) store credentials in a plaintext file. Maybe someone AFAIK that's not true - or at least if it is, that's due to using Maven deploy, rather than Nexus, which is not directly involved in the upload. > has figured out a way around this. I would be very interested to You can store the master password on a USB stick for Maven to use. Or you could use something like a TrueCrypt container file. > learn this so we can improve the not-quite-functional process that > we have been fumbling with in Commons [1]. FWIW, my NSHO is that if > you have a working script that produces good artifacts that can be > scpd to central, there is no reason to bring in proprietary > software, plaintext credential files or GUI steps. > > Phil > [1] http://wiki.apache.org/commons/UsingNexus >> >> I don't particularly care about the details. As long as all I have to do >> is run a script and the JARs end up in Maven Central I'm happy. I know >> option 1 works and I assume 2 will work the same way. Therefore I have >> no preference for either approach. >> >> Does anyone else have any requirements / views that would suggest one >> approach is better than the other? >> >> Mark >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On 18 December 2011 18:03, Phil Steitz wrote: > On 12/17/11 11:42 AM, Antonio Petrelli wrote: >> 2011/12/17 Mark Thomas >> >>> On 17/12/2011 18:35, Antonio Petrelli wrote: 2011/12/17 Mark Thomas > On 17/12/2011 18:14, Antonio Petrelli wrote: >> Ok then interprete my words as: now you can use a staging repository. >> This way, artifacts may be tested *before* they are released. > The scp+rsync process also has a staging repository (and using that did > not cause any meta-data issues). > > The JARs are the standard Tomcat JARs. The Maven release process just > adds the metadata files and moves the JARs + metadata around. Since the > JARs are already tested as part of the Tomcat release process, we never > had a need to use the staging repository and I don't see that changing. > > There is also a snapshot repository and we did use that early on in the > Tomcat 7 development process (before the first release) mainly because > one user who was doing a lot of testing was using Maven and the snapshot > repository was the easiest way to get them the latest build. We stopped > using the snapshot repository some time ago. I can't remember if it was > after the first release or after the first stable release. > > Ok then using Nexus makes sense only if you are going to use Maven for >>> all the release process (it's a matter of two commands and a Nexus stage promotion). I think that now you should change the subject into: why should you >>> switch to pure Maven build process? :-D (Joking, but not too much) >>> Yeah, that isn't going to happen :) >>> >>> I've seen way to much pain and grief with Maven on the Commons list to >>> ever want to even think about converting the Tomcat build process to Maven. >>> >> Commons? That's strange, they are only libraries. Probably they never had >> a Maven wizard like me . > > We have several maven committers on the PMC and have been using > maven since the 1.x days. > > One thing we have learned is that maven builds require regular care > and feeding. We are on version 23 of the Commons Parent pom. One That's partly due to Maven, but quite a few of those changes are due to new requirements, and updated plugins etc. Having a shared parent pom means more attention has to be paid to it and less to the component poms. So I don't think that's an entirely fair statistic. But I do agree that fixing Maven issues is generally a lot harder than fixing Ant issues. > statistic that I have often thought would be interesting to look at > is how much time (maybe proxied by number of metadata commits) is > spent maintaining maven vs Ant builds. I wonder if on net maven > saves time? The tomcat Ant build has been relatively stable > compared to the maven projects I know. Could be I am wrong, but I > bet tomcat has overall spent less time fussing with its build than > the average ASF maven project. In Commons, our success getting to > periods of stability (we are between stable points now) has depended > on having multiple deeply maven-knowledgeable people prepared to do > the work to keep component builds up to date with maven, > ASF/Sonatype infrastructure and plugin changes. If there are several > tomcat committers willing to step up to do this, then I am sure you > can get it to work. Otherwise, you are likely better off staying > with Ant. I'm inclined to agree here. I think Commons is somewhat different as it has many small components independently released. Maven enforces some conventions which mean the build processes tend to be similar across projects. Ant is more flexible and it would take a fair amount of work to ensure that all Commons components used standardised Ant build targets. Also Common components are libraries that are often consumed by other Maven projects. Tomcat is mainly a stand-alone download. I don't particularly like Maven - there's far too much built-in magic, which is not always properly explained - but it does have benefits in standardisation and (some aspects of its) dependency management. > Phil >> Seriously, if I have the time, I could fork Tomcat 7 from GitHub to try if >> I can change this situation. I already did it for Velocity (using SVN). The >> only difficulty is the website. >> >> Antonio >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 19 December 2011 08:36, Antonio Petrelli wrote: > 2011/12/17 Mark Thomas > >> On 17/12/2011 20:24, Antonio Petrelli wrote: >> > Ok, let's do it again :-D >> > 1. Standardization. Maven strongly encourages to use a standardized >> > structure. The source should go into src/main/java, the resources in >> > src/main/resources etc. You can change it, but this is discouraged. With >> > Ant you always do things differently for different projects. >> >> What benefit is this to the Tomcat community? I see a change, but no >> benefit. >> > > So standardization is no benefit? Do you mean that an external developer, > that sees a common project structure that can start working on it easily, > is not a benefit? > > >> > 2. Modularization. Separation between modules is strong, i.e. one jar-one >> > source directory. In the case of Tomcat, there is a big big trouble: one >> > single big source directory. Separating them will be one of the most >> > important step to do. >> >> Why is that an issue? Switching to a single source tree was one of the >> best changes we ever made. It has been much easier to manage than the >> multiple source trees we had in the past. > > > Sincerely, this is the worst thing that you have made. Do you think that > having a single source tree and letting Ant script reconstruct in some > non-obvious way the jars, is a benefit? > > >> The dependencies are known and >> we have checks in place (via Checkstyle) to ensure that unwanted >> dependencies are not added. > > > Checkstyle checks unwanted *imports* not dependencies. > > >> Again, what is the benefit here to the >> Tomcat community? There has been some interest but very little activity >> towards greater modularity. If there was more interest in increasing >> modularity then there might be a case for this but given Tomcat's remit >> of implementing the Servlet and JSP specs there is very little that >> could be made modular / optional. Jasper and EL are already optional >> (well, they can be removed) and pretty much everything else is required >> by the Servlet spec. >> > > Real modularity means: one source directory -> one jar. In other cases, it > is not obvious. > > >> >> > 3. Metadata-driven process. The build process is driven by metadata >> (where >> > the source is? where should I deploy it?) and not by commands (compile >> the >> > source that is in that point, deploy it in that repository) >> >> Again, how does this benefit the Tomcat community? >> > > The benefit is that the pom.xml is similar to other projects. After you see > a kind of project, you see almost them all. > > >> >> > 4. POMs are (almost) universal. Projects of the same kind have almost the >> > same content.. >> >> How does this benefit the Tomcat community? >> > > See above. > > >> > 5. Plug-ins do generically what pieces of Ant's script do specifically. >> For >> > example take the Maven assembly plugin: via a descriptor you obtain a zip >> > file to distribute. >> >> That sounds like just a different way of doing things. What is the benefit? >> > > You don't need to maintain a build script, but only use a plugin. Most of > the time, it's just the matter of including it. > > >> > 6. When all the metadata is in place, the release process is a matter of >> > launching: >> > mvn release:prepare >> > and >> > mvn release:perform >> >> Right now the release process is: >> ant release >> followed by scp / ftp / 'take your pick' the files to the right place >> and that could be added to the script if we really wanted to (but no-one >> has felt the need to scratch that itch). >> > > Does "ant release" tag automatically and prepare for the next snapshot? AIUI, the Maven release plugin temporarily changes the trunk SVN to drop the -SNAPSHOT suffix, merely in order to create the new tag. This means that concurrent builds (e.g. in a CI) may pick up what appears to be a release version, when in fact it is not. For me, that is broken (and unsafe) behaviour, as it requires additional measures to perform it safely. > >> In summary, I see a lot of differences but no benefits. Changing to >> Maven would mean big changes along with some disruption. For the >> community to make those changes and accept that disruption there needs >> to be something in return. So far, I haven't seen anything that I would >> class as a benefit to the community (e.g. faster build process, simpler >> releases, fewer bugs, etc.). >> > > You see features where I see benefits of the features, asking the same > question again and again shows your hate, and probably you hate me too, > because I love Maven. > No problem, you'll lose at some point :-D > > Antonio > >> >> Mark >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.o
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 19 December 2011 14:16, Antonio Petrelli wrote: > 2011/12/19 sebb > >> On 19 December 2011 08:36, Antonio Petrelli >> wrote: >> > 2011/12/17 Mark Thomas >> > >> >> On 17/12/2011 20:24, Antonio Petrelli wrote: >> >> > Ok, let's do it again :-D >> >> > 1. Standardization. Maven strongly encourages to use a standardized >> >> > structure. The source should go into src/main/java, the resources in >> >> > src/main/resources etc. You can change it, but this is discouraged. >> With >> >> > Ant you always do things differently for different projects. >> >> >> >> What benefit is this to the Tomcat community? I see a change, but no >> >> benefit. >> >> >> > >> > So standardization is no benefit? Do you mean that an external developer, >> > that sees a common project structure that can start working on it easily, >> > is not a benefit? >> > >> > >> >> > 2. Modularization. Separation between modules is strong, i.e. one >> jar-one >> >> > source directory. In the case of Tomcat, there is a big big trouble: >> one >> >> > single big source directory. Separating them will be one of the most >> >> > important step to do. >> >> >> >> Why is that an issue? Switching to a single source tree was one of the >> >> best changes we ever made. It has been much easier to manage than the >> >> multiple source trees we had in the past. >> > >> > >> > Sincerely, this is the worst thing that you have made. Do you think that >> > having a single source tree and letting Ant script reconstruct in some >> > non-obvious way the jars, is a benefit? >> > >> > >> >> The dependencies are known and >> >> we have checks in place (via Checkstyle) to ensure that unwanted >> >> dependencies are not added. >> > >> > >> > Checkstyle checks unwanted *imports* not dependencies. >> > >> > >> >> Again, what is the benefit here to the >> >> Tomcat community? There has been some interest but very little activity >> >> towards greater modularity. If there was more interest in increasing >> >> modularity then there might be a case for this but given Tomcat's remit >> >> of implementing the Servlet and JSP specs there is very little that >> >> could be made modular / optional. Jasper and EL are already optional >> >> (well, they can be removed) and pretty much everything else is required >> >> by the Servlet spec. >> >> >> > >> > Real modularity means: one source directory -> one jar. In other cases, >> it >> > is not obvious. >> > >> > >> >> >> >> > 3. Metadata-driven process. The build process is driven by metadata >> >> (where >> >> > the source is? where should I deploy it?) and not by commands (compile >> >> the >> >> > source that is in that point, deploy it in that repository) >> >> >> >> Again, how does this benefit the Tomcat community? >> >> >> > >> > The benefit is that the pom.xml is similar to other projects. After you >> see >> > a kind of project, you see almost them all. >> > >> > >> >> >> >> > 4. POMs are (almost) universal. Projects of the same kind have almost >> the >> >> > same content.. >> >> >> >> How does this benefit the Tomcat community? >> >> >> > >> > See above. >> > >> > >> >> > 5. Plug-ins do generically what pieces of Ant's script do >> specifically. >> >> For >> >> > example take the Maven assembly plugin: via a descriptor you obtain a >> zip >> >> > file to distribute. >> >> >> >> That sounds like just a different way of doing things. What is the >> benefit? >> >> >> > >> > You don't need to maintain a build script, but only use a plugin. Most of >> > the time, it's just the matter of including it. >> > >> > >> >> > 6. When all the metadata is in place, the release process is a matter >> of >> >> > launching: >> >> > mvn release:prepare >> >> > and >> >> > mvn release:perform >> >> >> >> Right now the release
[RFI] How do you package and upload Tomcat jars to Maven?
Some users are asking for JMeter jars to be uploaded to Maven Central. At present, we use Ant to build JMeter, so it would be useful to be able to just package up the jars and deploy them without needing to maintain dummy Maven poms. I can see that Tomcat7 jars are in Maven, but as far as I can tell they are not uploaded using Maven. I've had a quick look at the Tomcat 7 trunk, but cannot see how the Maven jars are created / prepared for deployment. Could anyone explain how you do the upload please? Thanks! - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [RFI] How do you package and upload Tomcat jars to Maven?
On 13 January 2012 14:26, Mark Thomas wrote: > On 13/01/2012 13:41, Olivier Lamy wrote: >> Hello, >> Have a look here: >> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/res/maven/ Thanks, that's what I needed. Perhaps consider adding a reference to this at the end of /BUILDING.txt? > +1 and I am planning some enhancements to those scripts so pass-phrases > etc are promoted for rather than having to be in a properties file. I > was planning on doing that when I do the next release. I'd probably use Putty, which has the Pageant agent; not sure if there is an equivalent for non-Windows systems. > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Nexus release problem
On 16 January 2012 09:43, Mark Thomas wrote: > It appears there is a problem with the Nexus release process. Prior to > the switch to Nexus, the Maven metedata contained all previous releases > [1]. Post the switch to Nexus, none of the previous releases appear in > the metadata [2]. > > The switch to Nexus has, therefore, introduced the very bug to the > Tomcat 7.0.x series that the switch to Nexus was meant to avoid [3]. > > Given that we go have the prior metadata, how do we get Nexus to use it? AIUI, Nexus is supposed to maintain the metadata, so I would raise a JIRA INFRA bug against Nexus to get this resolved. > Mark > > > [1] > http://repo2.maven.org/maven2/org/apache/tomcat/tomcat-catalina/maven-metadata.xml > [2] > https://repository.apache.org/service/local/repositories/orgapachetomcat-078/content/org/apache/tomcat/tomcat-catalina/maven-metadata.xml > [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=52124 > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Nexus release problems
On 16 January 2012 10:53, Konstantin Kolinko wrote: > 2012/1/16 Mark Thomas : >> On 16/01/2012 09:43, Mark Thomas wrote: >>> It appears there is a problem with the Nexus release process. Prior to >>> the switch to Nexus, the Maven metedata contained all previous releases >>> [1]. Post the switch to Nexus, none of the previous releases appear in >>> the metadata [2]. >>> >>> The switch to Nexus has, therefore, introduced the very bug to the >>> Tomcat 7.0.x series that the switch to Nexus was meant to avoid [3]. >>> >>> Given that we go have the prior metadata, how do we get Nexus to use it? >>> >>> [1] > http://repo2.maven.org/maven2/org/apache/tomcat/tomcat-catalina/maven-metadata.xml >>> [2] > https://repository.apache.org/service/local/repositories/orgapachetomcat-078/content/org/apache/tomcat/tomcat-catalina/maven-metadata.xml >>> [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=52124 > > There is no error in that. The metadata is only for > "orgapachetomcat-078" repository that contains this only release and > nothing else. > > I do not know an easy way to find similar current repositories in > other projects. Just searched markmail.org for recent VOTE threads > mentioning repository.apache.org. > > Here are two examples > https://repository.apache.org/content/repositories/orgapacherave-015/ > https://repository.apache.org/content/repositories/maven-060/ > > (from the following threads: > http://markmail.org/thread/qt5pwg3xdxpapyc5 > http://markmail.org/thread/jaa3fi4djn6kflic > ) > >> >> Oh, and if there is a way to get Nexus not to create .md5 and .sha1 >> files for the .asc signatures that would be nice but not essential since >> the scp+rsync had the same problem. >> > > I think that it is not possible to avoid creating them. I thought I had raised a bug against Nexus for that, but cannot find it at present. Likewise, Maven should not create them. [They are only small, but they are a nuisance when visually scanning the directory listing] > I've read on dev@commons that it is possible to delete them (more below). > > I think that Maven may need those files just to autocheck integrity of > asc files downloaded from remote servers. So I think it is better to > keep them. AFAIK that's not necessary. > > Regarding the procedure to delete those files I just did some search: > Some [1] say that you delete them "before closing staging area". > Others [2] (an older thread but seems more reliable) say that only > after closing it. It used to be possible to delete spurious files in both open and closed staging areas. It's no longer possible to delete files in the open state; I've raised a bug for this: https://issues.apache.org/jira/browse/INFRA-4312 > [1] http://markmail.org/message/tebuldnggk3pepky > [2] http://markmail.org/thread/uqjxxvpgztrlg362 > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.24
On 16 January 2012 13:02, Mark Thomas wrote: > On 16/01/2012 12:23, Olivier Lamy wrote: >> I think it's here (thanks) >> But you need to close it (tru the ui) in order we can consume >> artifacts from this staged repository. > > OK. Closed. Normally Nexus sends messages to a mailing list when staging repos are closed, dropped or released. But I've not noticed any relating to Tomcat - where are they being sent? > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 52489] Enhancement request for code signing of war files
On 19 January 2012 14:51, wrote: > https://issues.apache.org/bugzilla/show_bug.cgi?id=52489 > > Sebb changed: > > What |Removed |Added > > Summary|Enhancement request for |Enhancement request for > |codesigning of war files |code signing of war files FYI: codesigning was ambiguous: code signing or co-designing? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 52543] Exception
On 27 January 2012 13:38, wrote: > https://issues.apache.org/bugzilla/show_bug.cgi?id=52543 > > Pid changed: > > What |Removed |Added > > Status|NEW |RESOLVED > Resolution| |INVALID > > --- Comment #1 from Pid 2012-01-27 13:38:11 UTC --- > Bugzilla is not a support forum. Please join the Tomcat Users mailing list and > ask your question there. In this case, AFAICT the Exception is deep in Tomcat code. It looks to be an error that should not happen, regardless of what the application is doing. Or at least, if the application is doing something wrong, the exception is not helpful. IMO, not (directly) a user error - seems unfair to close as such. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket progress report
On 29 January 2012 10:19, Mark Thomas wrote: > On 29/01/2012 01:20, Costin Manolache wrote: >> On Fri, Jan 27, 2012 at 3:09 PM, Mark Thomas wrote: >> >> Not complaining - it's great to add this feature, please commit it - but >> I'm wondering >> if a lighter interface wouldn't be better. From looking at the >> implementation, it seems >> after the upgrade it keeps the InputBuffer/OutputBuffer ( and the whole >> Request / Processor / etc tree ). > > I agree there is certainly scope to do that. My initial focus has been > on functionality and minimal changes to existing code - hence the > current approach. > > I'm not overly keen on the additional overhead myself and can see > several ways to reduce it. Output is easier than input since we know the > output buffers are clear on upgrade. Input is a little trickier since > there may be some data in the input buffer and that would need to be > drained before switching to the lighter weight approach. > > I think this is something to look at once the implementation is more > feature complete. Whatever we do, I'd like to keep the following aims in > mind: > - minimal endpoint specific code > - minimal changes to what we have now > - keep the generic upgrade and the protocol specific parts separate > >> Would it be possible for example to release the Request, like it's done >> after request, >> in keep-alive, and use a lighter parser/callback on the socket ? I think >> one of the use cases >> for websockets is to support a _lot_ of open connections. > > That is certainly one approach. It will be easier to explore options > when we have a wider range of examples to work / test with. > >> Also the interface may be simpler without InputStreams. > > I thought long and hard about that. Looking around, some implementations > are message based, some are stream based. There are good arguments for > both. Unfortunately the WebSocket protocol is a messages based protocol > with no maximum message length. A message is one or more frames and a > frame is up to 2^63 bytes. While most usages will be small(ish) messages > that can be buffered without undue overhead, any application that wants > larger messages needs to use a stream based interface to be able to > scale. That is why I went for both. May I suggest that such design decisions are documented in the code and/or package Javadoc? > Thanks for the feedback. Much appreciated. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Apache Tomcat Maven plugin 2.0-beta-1
On 26 January 2012 18:05, Olivier Lamy wrote: > Hi, > > I'd like to release the Apache Tomcat Maven plugin 2.0-beta-1. > > The staging repository is available here: > https://repository.apache.org/content/repositories/orgapachetomcat-142/ > The documentation site is available here: > http://tomcat.apache.org/maven-plugin-2.0-beta-1/ Looks nice and clean, however: There's no feather/link to the ASF in the heading. The About page does not have an Overview as to what the plugin does; it launches straight into the list of changes for the release The License link MUST point to http://www.apache.org/licenses/; it should not point to a local copy of the license. It would be better if there was a license link at top-level, it's not as easy to find where it is, though it would not harm to have both. > Changelog: http://tomcat.apache.org/maven-plugin-2.0-beta-1/jira-report.html > > Guide to test a staged release maven plugin: > http://maven.apache.org/guides/development/guide-testing-releases.html > . > > [+1] > [ 0] > [-1] > > Here my +1 > > Thanks > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Apache Tomcat Maven plugin 2.0-beta-1
On 1 February 2012 11:13, Olivier Lamy wrote: > Hello, > Thanks for those suggestions ! > 2012/2/1 sebb : >> On 26 January 2012 18:05, Olivier Lamy wrote: >>> Hi, >>> >>> I'd like to release the Apache Tomcat Maven plugin 2.0-beta-1. >>> >>> The staging repository is available here: >>> https://repository.apache.org/content/repositories/orgapachetomcat-142/ >>> The documentation site is available here: >>> http://tomcat.apache.org/maven-plugin-2.0-beta-1/ >> >> Looks nice and clean, however: >> >> There's no feather/link to the ASF in the heading. > Agree and fixed in trunk. >> The About page does not have an Overview as to what the plugin does; >> it launches straight into the list of changes for the release > This page http://tomcat.apache.org/maven-plugin-2.0-beta-1/ is not an > enough summary of what the plugins (tomcat6/7) does ? There are brief details, but they are buried amongst details of the recent changes. The overview needs to come before the changes, and be clearly identified as such, for example: >>> *Apache Tomcat Maven Plugin* This is the new home for the Tomcat Maven Plugin (previously hosted at Codehaus). The Tomcat Maven Plugin provides goals to manipulate WAR projects within the Apache Tomcat servlet container. Or to run your war project in an embeded Apache Tomcat. The run goal give you the opportunity to develop quickly your application without any huge install to do manually. More details and features: see documentation. *Recent Changes* Version 2.0-beta-1 has the following new features: etc. <<< >> >> The License link MUST point to http://www.apache.org/licenses/; it >> should not point to a local copy of the license. > fixed too in trunk >> It would be better if there was a license link at top-level, it's not >> as easy to find where it is, though it would not harm to have both. > fixed too in trunk >> >>> Changelog: http://tomcat.apache.org/maven-plugin-2.0-beta-1/jira-report.html >>> >>> Guide to test a staged release maven plugin: >>> http://maven.apache.org/guides/development/guide-testing-releases.html >>> . >>> >>> [+1] >>> [ 0] >>> [-1] >>> >>> Here my +1 >>> >>> Thanks >>> -- >>> Olivier Lamy >>> Talend: http://coders.talend.com >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Apache Tomcat Maven plugin 2.0-beta-1
On 1 February 2012 10:14, Olivier Lamy wrote: > Hello, > As the others currently provided tomcat maven artifacts, adding those > in the download section doesn't have (IMHO) sense. > Because to be able to consume it within a maven build, users will have > to install it locally respecting the maven repository format layout. > So when the vote passed the files available in the staging repository > https://repository.apache.org/content/repositories/orgapachetomcat-142/ > will be sync to http://repo.maven.apache.org/maven2/org/apache/tomcat/ > . > > What we can do at least is to add in the ASF download system the > source archive. See files *-source-release.zip* in > https://repository.apache.org/content/repositories/orgapachetomcat-142/org/apache/tomcat/maven/tomcat-maven-plugin/2.0-beta-1/ > > At least with the file named > tomcat-maven-plugin-2.0-beta-1-source-release.zip you can rebuild the > plugins. > > Makes sense ? Apache Commons also releases code which is mainly consumed by Maven users. All the components are released to the Apache mirrors (as source and binary archives) as well as to Maven Central (as jars, with additional src and javadoc jars). Same as Tomcat itself, really. > 2012/1/31 Konstantin Kolinko : >> 2012/1/26 Olivier Lamy : >>> Hi, >>> >>> I'd like to release the Apache Tomcat Maven plugin 2.0-beta-1. >>> >>> The staging repository is available here: >>> https://repository.apache.org/content/repositories/orgapachetomcat-142/ >>> The documentation site is available here: >>> http://tomcat.apache.org/maven-plugin-2.0-beta-1/ >>> >>> Changelog: http://tomcat.apache.org/maven-plugin-2.0-beta-1/jira-report.html >>> >>> Guide to test a staged release maven plugin: >>> http://maven.apache.org/guides/development/guide-testing-releases.html >>> . >>> >>> [+1] >>> [ 0] >>> [-1] >>> >> >> Where are downloadable artifacts that will be placed to the ASF mirror >> system? >> >> Best regards, >> Konstantin Kolinko >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Apache Tomcat Maven plugin 2.0-beta-1
On 1 February 2012 11:56, Olivier Lamy wrote: > 2012/2/1 sebb : >> On 1 February 2012 10:14, Olivier Lamy wrote: >>> Hello, >>> As the others currently provided tomcat maven artifacts, adding those >>> in the download section doesn't have (IMHO) sense. >>> Because to be able to consume it within a maven build, users will have >>> to install it locally respecting the maven repository format layout. >>> So when the vote passed the files available in the staging repository >>> https://repository.apache.org/content/repositories/orgapachetomcat-142/ >>> will be sync to http://repo.maven.apache.org/maven2/org/apache/tomcat/ >>> . >>> >>> What we can do at least is to add in the ASF download system the >>> source archive. See files *-source-release.zip* in >>> https://repository.apache.org/content/repositories/orgapachetomcat-142/org/apache/tomcat/maven/tomcat-maven-plugin/2.0-beta-1/ >>> >>> At least with the file named >>> tomcat-maven-plugin-2.0-beta-1-source-release.zip you can rebuild the >>> plugins. >>> >>> Makes sense ? >> >> Apache Commons also releases code which is mainly consumed by Maven users. >> All the components are released to the Apache mirrors (as source and >> binary archives) as well as to Maven Central (as jars, with additional >> src and javadoc jars). >> Same as Tomcat itself, really. > > For commons it's artifacts/jars which can be consume "manually" but > AFAIK consuming "manually" maven plugins jars doesn't have sense IMHO. The ASF releases source - from which it must be possible to build the plugin. That's not generally easy or even possible from the jars that are released to Maven Central. > If the case of a Maven plugin, I can put the jars in something like > http://apache.multidist.com/tomcat/maven-plugin/ but so how will you > use it ? installing manually using mvn install: ? You don't; you use the copies in Maven Central. > And If I go here : http://apache.multidist.com/tomcat/tomcat-7/v7.0.25/bin/ > I don't see maven artifacts which are available here: > http://repo.maven.apache.org/maven2/org/apache/tomcat/tomcat-api/7.0.25/ Exactly. Tomcat (as Commons) releases are made to *both* the mirrors *and* Maven Central. The ASF mirrors are for source and binary archives. The Maven Central repo is used for the binary jars, along with pom and accompanying source/javadoc jars. > or here > http://repo.maven.apache.org/maven2/org/apache/tomcat/embed/tomcat-embed-core/7.0.25/ > etc... > > > > >> >>> 2012/1/31 Konstantin Kolinko : >>>> 2012/1/26 Olivier Lamy : >>>>> Hi, >>>>> >>>>> I'd like to release the Apache Tomcat Maven plugin 2.0-beta-1. >>>>> >>>>> The staging repository is available here: >>>>> https://repository.apache.org/content/repositories/orgapachetomcat-142/ >>>>> The documentation site is available here: >>>>> http://tomcat.apache.org/maven-plugin-2.0-beta-1/ >>>>> >>>>> Changelog: >>>>> http://tomcat.apache.org/maven-plugin-2.0-beta-1/jira-report.html >>>>> >>>>> Guide to test a staged release maven plugin: >>>>> http://maven.apache.org/guides/development/guide-testing-releases.html >>>>> . >>>>> >>>>> [+1] >>>>> [ 0] >>>>> [-1] >>>>> >>>> >>>> Where are downloadable artifacts that will be placed to the ASF mirror >>>> system? >>>> >>>> Best regards, >>>> Konstantin Kolinko >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>>> >>> >>> >>> >>> -- >>> Olivier Lamy >>> Talend: http://coders.talend.com >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Apache Tomcat Maven plugin 2.0-beta-1
On 1 February 2012 13:33, Olivier Lamy wrote: > 2012/2/1 Mark Thomas : >> On 01/02/2012 13:01, sebb wrote: >>> On 1 February 2012 11:56, Olivier Lamy wrote: >>>> 2012/2/1 sebb : >>>>> On 1 February 2012 10:14, Olivier Lamy wrote: >>>>>> Hello, >>>>>> As the others currently provided tomcat maven artifacts, adding those >>>>>> in the download section doesn't have (IMHO) sense. >>>>>> Because to be able to consume it within a maven build, users will have >>>>>> to install it locally respecting the maven repository format layout. >>>>>> So when the vote passed the files available in the staging repository >>>>>> https://repository.apache.org/content/repositories/orgapachetomcat-142/ >>>>>> will be sync to http://repo.maven.apache.org/maven2/org/apache/tomcat/ >>>>>> . >>>>>> >>>>>> What we can do at least is to add in the ASF download system the >>>>>> source archive. See files *-source-release.zip* in >>>>>> https://repository.apache.org/content/repositories/orgapachetomcat-142/org/apache/tomcat/maven/tomcat-maven-plugin/2.0-beta-1/ >>>>>> >>>>>> At least with the file named >>>>>> tomcat-maven-plugin-2.0-beta-1-source-release.zip you can rebuild the >>>>>> plugins. >>>>>> >>>>>> Makes sense ? >>>>> >>>>> Apache Commons also releases code which is mainly consumed by Maven users. >>>>> All the components are released to the Apache mirrors (as source and >>>>> binary archives) as well as to Maven Central (as jars, with additional >>>>> src and javadoc jars). >>>>> Same as Tomcat itself, really. >>>> >>>> For commons it's artifacts/jars which can be consume "manually" but >>>> AFAIK consuming "manually" maven plugins jars doesn't have sense IMHO. >>> >>> The ASF releases source - from which it must be possible to build the >>> plugin. >>> That's not generally easy or even possible from the jars that are >>> released to Maven Central. >>> >>>> If the case of a Maven plugin, I can put the jars in something like >>>> http://apache.multidist.com/tomcat/maven-plugin/ but so how will you >>>> use it ? installing manually using mvn install: ? >>> >>> You don't; you use the copies in Maven Central. >>> >>>> And If I go here : http://apache.multidist.com/tomcat/tomcat-7/v7.0.25/bin/ >>>> I don't see maven artifacts which are available here: >>>> http://repo.maven.apache.org/maven2/org/apache/tomcat/tomcat-api/7.0.25/ >>> >>> Exactly. >>> >>> Tomcat (as Commons) releases are made to *both* the mirrors *and* Maven >>> Central. >>> >>> The ASF mirrors are for source and binary archives. >>> The Maven Central repo is used for the binary jars, along with pom and >>> accompanying source/javadoc jars. >> >> +1 >> >> The primary/master/whatever Tomcat release is the source that we voted >> on. It comes in two formats .zip and .tar.gz. Everything else (the >> binaries, the Maven artefacts, the docs) is (and can be by anyone who >> cares to) derived from that source release. >> >> Every Apache release *must* have a source form from which everything >> else may be derived. Without that, the release is invalid. > > Yup I proposed to add > https://repository.apache.org/content/repositories/orgapachetomcat-142/org/apache/tomcat/maven/tomcat-maven-plugin/2.0-beta-1/tomcat-maven-plugin-2.0-beta-1-source-release.zip > > In http://www.apache.org/dist/tomcat/maven-plugin/ ? Not forgetting the corresponding .asc/.md5/.sha1 as well. [But you can & should omit the .asc.md5 and .asc.sha1 files which are useless] >> >> Mark >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1241356 - in /tomcat/trunk/java/org/apache/tomcat/jni: Poll.java SSL.java SSLExt.java
On 7 February 2012 06:13, wrote: > Author: costin > Date: Tue Feb 7 06:13:36 2012 > New Revision: 1241356 > > URL: http://svn.apache.org/viewvc?rev=1241356&view=rev > Log: > Add the new ssl methods from tomcat-native ( and few poll methods that seemed > to be missing ). > > APR connector will not work unless you recompile tomcat-native ! ( it is ok > to use the current version of > openssl, but npn methods will not work ) > > > Added: > tomcat/trunk/java/org/apache/tomcat/jni/SSLExt.java EOL? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1243508 - in /tomcat/site/trunk: docs/tools.html xdocs/tools.xml
On 13 February 2012 13:50, wrote: > Author: kkolinko > Date: Mon Feb 13 13:50:43 2012 > New Revision: 1243508 > > URL: http://svn.apache.org/viewvc?rev=1243508&view=rev > Log: > Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52652 > Correct typos in tools.html > > s/licence/license/ seems to be GB vs UK. IDE hilights "licence" as > misspelled, event though m dictionary knows this word. [GB vs US?] In the UK, different spellings are used for the noun (licence) and the verb (license). "Get your licence from the licensing authority". See for example the Ofcom website [1] Similarly for practice/practise. However, the US seems to use license for both noun and verb. [1] http://licensing.ofcom.org.uk/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat web site UI update
On 15 February 2012 20:04, Jeremy Brown wrote: >>That is a comment that the layout needs to be >>cleaner (a comment I agree with). > > I agree too. I tried to create a cleaner layout and I posted a mockup for > all to see and voice their opinions. > > https://s3.amazonaws.com/jjbosstracker/TomcatMockup.jpg Looks good. There's no obvious link to the Tomcat License - this is a problem with the existing site, but perhaps could be fixed at the same time. > I'll leave it to Mark, Konstantin, Wesley and whomever else to let me know > when it is reasonable to move forward. > > Cheers, Jeremy > > > > On Tue, Feb 14, 2012 at 11:40 AM, Mark Thomas wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 14/02/2012 16:21, Christopher Schultz wrote: >> > Mark, >> > >> > On 2/13/12 5:28 PM, Mark Thomas wrote: >> >> On 13/02/2012 20:11, Christopher Schultz wrote: >> >>> >> >>> IIRC, Pid did a bunch of work toward that end and it was >> >>> ultimately vetoed >> >> >> >> Reference please. That is not my recollection at all. >> > >> > Markmail remembers: >> > >> > http://markmail.org/message/og235cbvrdluiejg >> >> That isn't a veto. That is a comment that the layout needs to be >> cleaner (a comment I agree with). From a style point of view it is a >> big improvement. >> >> Mark >> >> > >> >> My recollection was that pid started down this road but hasn't >> >> found the time to finish it, or at least get it to a state where >> >> enough was complete that it could be committed. >> > >> > Konstantin liked it for the ROOT webapp, but not the Tomcat main >> > site. Same with Wesley Acheson. >> > >> > -chris >> > >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.9 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iQIcBAEBAgAGBQJPOpx3AAoJEBDAHFovYFnnxEIP/Rvhm+UYlVq5enUzWlPbLmWC >> ZPXcduolPXTVwU2jpIZpSw020677h92kq3dWFL7JSlKNhuHK2C/fS0iI9YYY0Xp/ >> L9qYf7fvzSvzka7wUFJxFXLwPX6uoDAFwFtr+KSBmus3S206elkCCtILB/z06itA >> VE31NVqOmXqLq7ZrqsE+4oxzqdkiJV1Cl1uKfR+O0LRJJ39Yl5+LyjThRDWdandC >> JoWDnJhz/rAWC473X4NWh9q0LXK04uiufvHN3qtq1tbjl2YQ2tkEdcgJilXXCOF/ >> NgcnvBlWw5R6o9w2Hm7X5xu6YAi8FS1sdWZ5QAihMud23pxT4KCUlK7DSzz2v3Yt >> vWXEWpbaOD7kFa2c1Wj8dxED4q9ZB8UZZfBkCpG/AGXA1W1DrygPOePkRCNMzBSe >> L7JWBU5CBJ6avlSnEFMXZIgXg/iVf0bGJUSZr+nL9auoDmJwyN46/HyDeK9ucWyn >> O6TTzCFgCrcI01k7sVt3vrmtX2/JcvF2O0XMGRYTD/6trFWg96eA7NeOab7Rq90S >> S6HcEFWGgM52/SibK49yc1J1oQvwNFHzZ2FNINMLBHRI4FjnbLbwxqF8IcZtKs+5 >> YlbpiiXz+9LIUS8negOTTStXJFqmGaauYMZmIDf7JxFfxozCCQsayifzn+62STrX >> bx3sI4uobJxVqoNNe++B >> =F97+ >> -END PGP SIGNATURE- >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1292891 - /tomcat/trunk/bin/daemon.sh
On 23 February 2012 19:00, Konstantin Kolinko wrote:
> 2012/2/23 :
>> Author: markt
>> Date: Thu Feb 23 18:44:02 2012
>> New Revision: 1292891
>>
>> URL: http://svn.apache.org/viewvc?rev=1292891&view=rev
>> Log:
>> Fix BZ52750. Correctly parse command options
>> Port of r1292878 from 7.0.x
>>
>> Modified:
>> tomcat/trunk/bin/daemon.sh (contents, props changed)
>>
>> Modified: tomcat/trunk/bin/daemon.sh
>> URL:
>> http://svn.apache.org/viewvc/tomcat/trunk/bin/daemon.sh?rev=1292891&r1=1292890&r2=1292891&view=diff
>> ==
>> --- tomcat/trunk/bin/daemon.sh (original)
>> +++ tomcat/trunk/bin/daemon.sh Thu Feb 23 18:44:02 2012
>> @@ -34,9 +34,9 @@ while [ -h "$ARG0" ]; do
>> done
>> DIRNAME="`dirname $ARG0`"
>> PROGRAM="`basename $ARG0`"
>> -for o
>> +while [ ".$1" != . ]
>
> Maybe:
> while [ -n "$1" ]
> (though both variants should work work)
>
>> do
>> - case "$o" in
>> + case "$o=1" in
>
> What the above line is about?
I wondered the same myself;
it so happens that the "=" key is next to the "Backspace" key, so I
suspect the intention was to delete the "o" ...
> Was it supposed to be:
> case "$1" in
>
>> --java-home )
>> JAVA_HOME="$2"
>> shift; shift;
>>
>> Propchange: tomcat/trunk/bin/daemon.sh
>> ('svn:executable' removed)
>>
>
> 231 echo "Unkown command: \`$1'"
>
> Unknown
>
> 232 echo "Usage: $PROGRAM ( commands ... )"
>
> $PROGRAM [--options] ( commands ... )
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Taglibs Parent POM 1
On 26 February 2012 23:33, Jeremy Boynes wrote: > OK. Artefacts re-staged at > https://repository.apache.org/content/repositories/orgapachetomcat-084/ Looks a bit odd to have orgapachetomcat above yet the Maven package is org.apache.taglibs ? But perhaps that's just a feature of Nexus. Using o.a.taglibs looks like the TLP name is taglibs - is that likely to cause a problem in future? > > Thanks > Jeremy > > On Feb 26, 2012, at 3:00 PM, Olivier Lamy wrote: > >> 2012/2/26 Jeremy Boynes : >>> I do but I can't as it seems I signed with the wrong key - a subkey that is >>> not recognized. >>> >>> Can I just delete the subkey from my keyring and re-run release:perform? >> Yup. >> Just delete the current staging repository. >> If you still have the target/checkout directory locally, run: mvn >> deploy -Papache-release >> >> >>> >>> On Feb 26, 2012, at 11:20 AM, Olivier Lamy wrote: >>> Hello Jeremy, I think you must first close the repository in the "Staging repositories" entry menu. After that the url (https://repository.apache.org/content/repositories/orgapachetomcat-068/) will be available. 2012/2/25 Jeremy Boynes : > The proposed Apache Taglibs Parent POM v1 release is now available for > voting. > > This contains Maven project metadata for building and releasing the > actual Taglibs project files. > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-068/ > > The svn tag is: > https://svn.apache.org/repos/asf/tomcat/taglibs/taglibs-parent/tags/taglibs-parent-1/ > > The proposed v1 release is: > [ ] Broken - do not release > [ ] Stable - go ahead and release as v1 Stable > > Cheers > Jeremy > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >> >> >> >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Taglibs Parent POM 1
On 28 February 2012 16:43, Mladen Turk wrote: > On 02/27/2012 12:33 AM, Jeremy Boynes wrote: >> >> OK. Artefacts re-staged at >> https://repository.apache.org/content/repositories/orgapachetomcat-084/ >> > > +1 > Signatures and content OK. > > Although not sure why you have LICENSE and LICENSE.txt as well > as NOTICE and NOTICE.txt with the same content > (well, the only difference is that .txt files are missing > trailing new lines). > > I could understand if they were LF/CRL-LF, but as they are currently > it makes no sense. > You should probably fix that in future releases. > That is probably caused by the Apache POM, which tries to be helpful by adding the N&L for you. We had to disable that part in Commons, because we don't use the same naming convention (and the AP does not allow for the names to be changed). > Regards > -- > ^TM > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Taglibs Parent POM 1
On 29 February 2012 05:11, Konstantin Kolinko wrote: > 2012/2/29 Jeremy Boynes : >> Removed from svn. A dry run of the next release shows they are automatically >> added to the source bundle. >> > > 1. Where it takes those files from? Is their content correct. > > Besides extra blank lines before and after the text in NOTICE file, I'd forgotten about that - that's one reason why we don't use the auto-generated N&L files in Commons. [In a previous Maven release, IIRC the NOTICE file had even more extraneous text] Personally, I think it's a big mistake for the Apache Parent to generate these files automatically. They only apply to projects with no 3rd party dependencies or code. IMO the N&L files are too important to be auto-generated. Also, by using the auto-generated copies, SVN is left without any N&L files at the head of the tree. I would urge taglibs to use local copies of N&L files which can be properly maintained in SVN, and ignore the auto-generated ones. > there is small difference: > NOTICE: > Copyright 2000-2012 The Apache Software Foundation > NOTICE.txt: > Copyright 2009-2012 The Apache Software Foundation > > Is in pom.xml correct (2000) ? > > > 2. Looking at site.xml in source bundle and current site at > http://tomcat.apache.org/taglibs/ > > - I do not see a link to http://www.apache.org/licenses/ > - I do not see a link to http://tomcat.apache.org/security.html > > 3. commons-skin dependency says v.2. I see that there is v.3 at Maven > Central. > > > [x] +1 to go, but I think v2 will be needed before we release any of > the taglibs. > > It is hard to judge without looking at a site generated from this parent pom. > > Best regards, > Konstantin Kolinko > > >> On Feb 28, 2012, at 12:12 PM, Mladen Turk wrote: >> >>> On 02/28/2012 08:57 PM, sebb wrote: >>>> On 28 February 2012 16:43, Mladen Turk wrote: >>>>> >>>>> Although not sure why you have LICENSE and LICENSE.txt as well >>>>> as NOTICE and NOTICE.txt with the same content >>>> >>>> That is probably caused by the Apache POM, which tries to be helpful >>>> by adding the N&L for you. >>>> >>> >>> Right, that should be the cause. >>> >>>> We had to disable that part in Commons, because we don't use the same >>>> naming convention (and the AP does not allow for the names to be >>>> changed). >>>> >>> >>> Whatever... Think that this should be easy to solve. >>> Just rm extra files if maven will add them automatically >>> and the content is satisfactory. >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1294943 - in /tomcat/taglibs/taglibs-parent/trunk: LICENSE.txt NOTICE.txt
On 29 February 2012 02:19, wrote: > Author: jboynes > Date: Wed Feb 29 02:19:53 2012 > New Revision: 1294943 > > URL: http://svn.apache.org/viewvc?rev=1294943&view=rev > Log: > remove LICENCE.txt and NOTICE.txt as they are automatically added by Maven > release process -1 I think that's the wrong solutiion; see my comments on the dev list thread. > Removed: > tomcat/taglibs/taglibs-parent/trunk/LICENSE.txt > tomcat/taglibs/taglibs-parent/trunk/NOTICE.txt > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Taglibs Parent POM 1
On 29 February 2012 18:07, Jeremy Boynes wrote: > Reverted r1294943. > > Do you know how this was addressed in Commons? Yes, see commons-parent pom http://repo1.maven.org/maven2/org/apache/commons/commons-parent/23/commons-parent-23.pom search for NOTICE > Any patches? :) > > On Feb 29, 2012, at 9:14 AM, sebb wrote: > >> On 29 February 2012 05:11, Konstantin Kolinko wrote: >>> 2012/2/29 Jeremy Boynes : >>>> Removed from svn. A dry run of the next release shows they are >>>> automatically added to the source bundle. >>>> >>> >>> 1. Where it takes those files from? Is their content correct. >>> >>> Besides extra blank lines before and after the text in NOTICE file, >> >> I'd forgotten about that - that's one reason why we don't use the >> auto-generated N&L files in Commons. >> [In a previous Maven release, IIRC the NOTICE file had even more >> extraneous text] >> >> Personally, I think it's a big mistake for the Apache Parent to >> generate these files automatically. >> They only apply to projects with no 3rd party dependencies or code. >> IMO the N&L files are too important to be auto-generated. >> >> Also, by using the auto-generated copies, SVN is left without any N&L >> files at the head of the tree. >> >> I would urge taglibs to use local copies of N&L files which can be >> properly maintained in SVN, and ignore the auto-generated ones. >> >>> there is small difference: >>> NOTICE: >>> Copyright 2000-2012 The Apache Software Foundation >>> NOTICE.txt: >>> Copyright 2009-2012 The Apache Software Foundation >>> >>> Is in pom.xml correct (2000) ? >>> >>> >>> 2. Looking at site.xml in source bundle and current site at >>> http://tomcat.apache.org/taglibs/ >>> >>> - I do not see a link to http://www.apache.org/licenses/ >>> - I do not see a link to http://tomcat.apache.org/security.html >>> >>> 3. commons-skin dependency says v.2. I see that there is v.3 at Maven >>> Central. >>> >>> >>> [x] +1 to go, but I think v2 will be needed before we release any of >>> the taglibs. >>> >>> It is hard to judge without looking at a site generated from this parent >>> pom. >>> >>> Best regards, >>> Konstantin Kolinko >>> >>> >>>> On Feb 28, 2012, at 12:12 PM, Mladen Turk wrote: >>>> >>>>> On 02/28/2012 08:57 PM, sebb wrote: >>>>>> On 28 February 2012 16:43, Mladen Turk wrote: >>>>>>> >>>>>>> Although not sure why you have LICENSE and LICENSE.txt as well >>>>>>> as NOTICE and NOTICE.txt with the same content >>>>>> >>>>>> That is probably caused by the Apache POM, which tries to be helpful >>>>>> by adding the N&L for you. >>>>>> >>>>> >>>>> Right, that should be the cause. >>>>> >>>>>> We had to disable that part in Commons, because we don't use the same >>>>>> naming convention (and the AP does not allow for the names to be >>>>>> changed). >>>>>> >>>>> >>>>> Whatever... Think that this should be easy to solve. >>>>> Just rm extra files if maven will add them automatically >>>>> and the content is satisfactory. >>>>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Taglibs Parent POM 1
On 29 February 2012 19:15, Olivier Lamy wrote: > Perso, I prefer using something which read pom and generate > automatically N&L from metadatas rather than maintaining those files > manually (for me manually means you always missed to add/modify :-) ) > (but sure it's my POV) AFAICT that just moves the work from maintaining the N&L to creating and maintaining the metadata. It also means that the N&L files are not present in SVN (unless they are checked in after generation). > BTW Did you create any issues for that ? > > 2012/2/29 sebb : >> On 29 February 2012 05:11, Konstantin Kolinko wrote: >>> 2012/2/29 Jeremy Boynes : >>>> Removed from svn. A dry run of the next release shows they are >>>> automatically added to the source bundle. >>>> >>> >>> 1. Where it takes those files from? Is their content correct. >>> >>> Besides extra blank lines before and after the text in NOTICE file, >> >> I'd forgotten about that - that's one reason why we don't use the >> auto-generated N&L files in Commons. >> [In a previous Maven release, IIRC the NOTICE file had even more >> extraneous text] >> >> Personally, I think it's a big mistake for the Apache Parent to >> generate these files automatically. >> They only apply to projects with no 3rd party dependencies or code. >> IMO the N&L files are too important to be auto-generated. >> >> Also, by using the auto-generated copies, SVN is left without any N&L >> files at the head of the tree. >> >> I would urge taglibs to use local copies of N&L files which can be >> properly maintained in SVN, and ignore the auto-generated ones. >> >>> there is small difference: >>> NOTICE: >>> Copyright 2000-2012 The Apache Software Foundation >>> NOTICE.txt: >>> Copyright 2009-2012 The Apache Software Foundation >>> >>> Is in pom.xml correct (2000) ? >>> >>> >>> 2. Looking at site.xml in source bundle and current site at >>> http://tomcat.apache.org/taglibs/ >>> >>> - I do not see a link to http://www.apache.org/licenses/ >>> - I do not see a link to http://tomcat.apache.org/security.html >>> >>> 3. commons-skin dependency says v.2. I see that there is v.3 at Maven >>> Central. >>> >>> >>> [x] +1 to go, but I think v2 will be needed before we release any of >>> the taglibs. >>> >>> It is hard to judge without looking at a site generated from this parent >>> pom. >>> >>> Best regards, >>> Konstantin Kolinko >>> >>> >>>> On Feb 28, 2012, at 12:12 PM, Mladen Turk wrote: >>>> >>>>> On 02/28/2012 08:57 PM, sebb wrote: >>>>>> On 28 February 2012 16:43, Mladen Turk wrote: >>>>>>> >>>>>>> Although not sure why you have LICENSE and LICENSE.txt as well >>>>>>> as NOTICE and NOTICE.txt with the same content >>>>>> >>>>>> That is probably caused by the Apache POM, which tries to be helpful >>>>>> by adding the N&L for you. >>>>>> >>>>> >>>>> Right, that should be the cause. >>>>> >>>>>> We had to disable that part in Commons, because we don't use the same >>>>>> naming convention (and the AP does not allow for the names to be >>>>>> changed). >>>>>> >>>>> >>>>> Whatever... Think that this should be easy to solve. >>>>> Just rm extra files if maven will add them automatically >>>>> and the content is satisfactory. >>>>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1295724 - in /tomcat/trunk/webapps/examples/WEB-INF: classes/websocket/EchoMessage.java web.xml
On 1 March 2012 18:27, wrote:
> Author: fhanik
> Date: Thu Mar 1 18:27:56 2012
> New Revision: 1295724
>
> URL: http://svn.apache.org/viewvc?rev=1295724&view=rev
> Log:
> Allow the examples to configure the buffer on the fly
>
> Modified:
> tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
> tomcat/trunk/webapps/examples/WEB-INF/web.xml
>
> Modified:
> tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java?rev=1295724&r1=1295723&r2=1295724&view=diff
> ==
> --- tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
> (original)
> +++ tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
> Thu Mar 1 18:27:56 2012
> @@ -20,6 +20,8 @@ import java.io.IOException;
> import java.nio.ByteBuffer;
> import java.nio.CharBuffer;
>
> +import javax.servlet.ServletException;
> +
> import org.apache.catalina.websocket.MessageInbound;
> import org.apache.catalina.websocket.StreamInbound;
> import org.apache.catalina.websocket.WebSocketServlet;
> @@ -28,13 +30,40 @@ import org.apache.catalina.websocket.Web
> public class EchoMessage extends WebSocketServlet {
>
> private static final long serialVersionUID = 1L;
> + private volatile int byteBufSize;
> + private volatile int charBufSize;
> +
> + @Override
> + public void init() throws ServletException {
> + super.init();
> + byteBufSize = getInitParameterIntValue("byteBufferMaxSize", 2097152);
> + charBufSize = getInitParameterIntValue("charBufferMaxSize", 2097152);
Value does not agree with below.
Is that intended?
> + }
> +
> + public int getInitParameterIntValue(String name, int defaultValue) {
> + String val = this.getInitParameter(name);
> + int result = defaultValue;
> + try {
> + result = Integer.parseInt(val);
> + }catch (Exception x) {
> + }
> + return result;
> + }
> +
> +
>
> @Override
> protected StreamInbound createWebSocketInbound(String subProtocol) {
> - return new EchoMessageInbound();
> + return new EchoMessageInbound(byteBufSize,charBufSize);
> }
>
> private static final class EchoMessageInbound extends MessageInbound {
> +
> + public EchoMessageInbound(int byteBufferMaxSize, int
> charBufferMaxSize) {
> + super();
> + setByteBufferMaxSize(byteBufferMaxSize);
> + setCharBufferMaxSize(charBufferMaxSize);
> + }
>
> @Override
> protected void onBinaryMessage(ByteBuffer message) throws IOException
> {
>
> Modified: tomcat/trunk/webapps/examples/WEB-INF/web.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/web.xml?rev=1295724&r1=1295723&r2=1295724&view=diff
> ==
> --- tomcat/trunk/webapps/examples/WEB-INF/web.xml (original)
> +++ tomcat/trunk/webapps/examples/WEB-INF/web.xml Thu Mar 1 18:27:56 2012
> @@ -359,6 +359,8 @@
>
> wsEchoMessage
> websocket.EchoMessage
> +
> byteBufferMaxSize20971520
> +
> charBufferMaxSize20971520
Value does not agree with above.
Is that intended?
>
>
> wsEchoMessage
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: License/Notice Files
On 4 March 2012 03:44, Jeremy Boynes wrote: > On Feb 29, 2012, at 11:37 AM, sebb wrote: > >> On 29 February 2012 19:15, Olivier Lamy wrote: >>> Perso, I prefer using something which read pom and generate >>> automatically N&L from metadatas rather than maintaining those files >>> manually (for me manually means you always missed to add/modify :-) ) >>> (but sure it's my POV) >> >> AFAICT that just moves the work from maintaining the N&L to creating >> and maintaining the metadata. >> >> It also means that the N&L files are not present in SVN (unless they >> are checked in after generation). > > My preference here is also to have them generated. We want the metadata in > the project descriptor to be valid anyway, and maintaining the templates for > LICENSE and NOTICE would be handled by maintainers of the Apache resources. > We don't have any dependencies requiring a notice, and if we do this should > be covered with append-resources. > > The files wouldn't be in SVN but will be in the distributed archives. Having > this done automatically rather than by configuring each archiver will be > easier to keep straight. I think just about every project has N&L files at the top-level of SVN. [If they don't, perhaps they should] Not sure it is an absolute requirement (unlike in archives and jars) but it is helpful for 3rd parties who browse the SVN tree. > -- > Jeremy > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: License/Notice Files
On 18 March 2012 16:05, Jeremy Boynes wrote: > It looks like the source assembly that packages the source distributions will > prefer files in the project over files from the remote resources bundle. So > is we rename LICENSE.txt to just LICENSE there will only be one copy and it > will be the one from this project. I'm going to do that for the files in the > root of each trunk so that they will be in the top level of anything checked > out from SVN, and remove the ones further down the directory tree leaving it > to the plugin to add them to each distribution. If in the future we add > dependencies with notice requirements we can add that to the particular > module at that time. OK, great. > On Mar 4, 2012, at 5:40 PM, sebb wrote: > >> On 4 March 2012 03:44, Jeremy Boynes wrote: >>> On Feb 29, 2012, at 11:37 AM, sebb wrote: >>> >>>> On 29 February 2012 19:15, Olivier Lamy wrote: >>>>> Perso, I prefer using something which read pom and generate >>>>> automatically N&L from metadatas rather than maintaining those files >>>>> manually (for me manually means you always missed to add/modify :-) ) >>>>> (but sure it's my POV) >>>> >>>> AFAICT that just moves the work from maintaining the N&L to creating >>>> and maintaining the metadata. >>>> >>>> It also means that the N&L files are not present in SVN (unless they >>>> are checked in after generation). >>> >>> My preference here is also to have them generated. We want the metadata in >>> the project descriptor to be valid anyway, and maintaining the templates >>> for LICENSE and NOTICE would be handled by maintainers of the Apache >>> resources. We don't have any dependencies requiring a notice, and if we do >>> this should be covered with append-resources. >>> >>> The files wouldn't be in SVN but will be in the distributed archives. >>> Having this done automatically rather than by configuring each archiver >>> will be easier to keep straight. >> >> I think just about every project has N&L files at the top-level of SVN. >> [If they don't, perhaps they should] >> >> Not sure it is an absolute requirement (unlike in archives and jars) >> but it is helpful for 3rd parties who browse the SVN tree. >> >>> -- >>> Jeremy >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Taglibs Parent POM 2
On 24 March 2012 14:45, Jeremy Boynes wrote: > The proposed 2 release of Apache Taglibs Parent POM is now available for > voting. > > This release addresses issues found during the 1 release process including > duplicate LICENSE files and poor site configuration. > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-107/ > > and SVN tag is: > http://svn.apache.org/repos/asf/tomcat/taglibs/taglibs-parent/tags/taglibs-parent-2/ NOTICE says Copyright 2009-2012 pom.xml has 2000 These are inconsistent. > Please vote on whether Apache Taglibs Parent 2 should be: > [+1] Released, or > [-1] Not released because ... > > Thanks > Jeremy > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs build #2 failed due to Hudson error
On 31 March 2012 03:23, Jeremy Boynes wrote: > From the log: > https://builds.apache.org/job/taglib-standard/2/consoleText > > Parsing POMs > ERROR: Failed to parse POMs > hudson.util.IOException2: remote file operation failed: > /home/jenkins/jenkins-slave/workspace/taglib-standard at > hudson.remoting.Channel@1c4071a9:ubuntu3 > at hudson.FilePath.act(FilePath.java:828) > at hudson.FilePath.act(FilePath.java:814) > at > hudson.maven.MavenModuleSetBuild$RunnerImpl.parsePoms(MavenModuleSetBuild.java:914) > at > hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:658) > at > hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:473) > at hudson.model.Run.run(Run.java:1410) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) > Caused by: java.io.FileNotFoundException: > /tmp/hudson-remoting6347775300781058040/META-INF/plexus/components.xml (No > such file or directory) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:194) > at java.io.FileOutputStream.(FileOutputStream.java:145) > at > hudson.remoting.RemoteClassLoader.makeResource(RemoteClassLoader.java:270) > at > hudson.remoting.RemoteClassLoader.findResources(RemoteClassLoader.java:237) > at java.lang.ClassLoader.getResources(ClassLoader.java:1040) > at java.lang.ClassLoader.getResources(ClassLoader.java:1036) > at > hudson.maven.MavenUtil$MaskingClassLoader.getResources(MavenUtil.java:291) > at hudson.maven.MavenUtil.createEmbedder(MavenUtil.java:199) > at > hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1218) > at > hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1049) > at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154) > at hudson.remoting.UserRequest.perform(UserRequest.java:118) > at hudson.remoting.UserRequest.perform(UserRequest.java:48) > at hudson.remoting.Request$2.run(Request.java:287) > at > hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > > Resubmitting the build worked fine. What causes this type of problem? Jenkins bug or problem with Jenkins hosts. > Thanks > Jeremy > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1336516 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/net/AbstractEndpoint.java webapps/docs/changelog.xml
On 10 May 2012 08:50, wrote:
> Author: rjung
> Date: Thu May 10 07:50:29 2012
> New Revision: 1336516
>
> URL: http://svn.apache.org/viewvc?rev=1336516&view=rev
> Log:
> Add public method to retrieve the current connectionCount
> from an endpoint.
>
> It will also show up in the ThreadPool MBean.
>
> Backport of r1336515 from trunk.
>
> Modified:
> tomcat/tc7.0.x/trunk/ (props changed)
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
> tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
>
> Propchange: tomcat/tc7.0.x/trunk/
> --
> Merged /tomcat/trunk:r1336515
>
> Modified:
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
> URL:
> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java?rev=1336516&r1=1336515&r2=1336516&view=diff
> ==
> ---
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
> (original)
> +++
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
> Thu May 10 07:50:29 2012
> @@ -173,6 +173,14 @@ public abstract class AbstractEndpoint {
> }
>
> public int getMaxConnections() { return this.maxConnections; }
> +
Javadoc?
In particular, it would help if the condition under which -1 is
returned were documented. ...
> + public long getConnectionCount() {
> + if (connectionLimitLatch != null) {
> + return connectionLimitLatch.getCount();
> + }
> + return -1;
> + }
> +
> /**
> * External Executor based thread pool.
> */
>
> Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1336516&r1=1336515&r2=1336516&view=diff
> ==
> --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
> +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Thu May 10 07:50:29 2012
> @@ -121,6 +121,11 @@
> The new default value will never go above 2 regardless of
> available processors. (fhanik)
>
> +
> + Allow to retrieve the current connectionCount
> + via getter from the endpoint and as JMX attribute of the ThreadPool
> + mbean. (rjung)
> +
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Connectors 1.2.36
On 9 May 2012 15:25, Mladen Turk wrote: > Hi, > > Apache Tomcat Connectors 1.2.36 release candidate is ready > for vote at [1]. This version solves shared memorz regression(s) > found in released version 1.2.35 and allows )again= compiling > against old httpd 1.3.x. > > > The VOTE will remain open for at least 48 hours. Just curious - why only 48 hours? The normal rule is a minimum of 72 hours. > The Apache Tomcat Connectors 1.2.36 is > [ ] Stable, go ahead and release > [ ] Broken because of ... > > > > [1] http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.36/ > > > Regards > -- > ^TM > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: native connector tool chain
On 21 May 2012 21:01, Mark Thomas wrote: > On 21/05/2012 17:52, Mladen Turk wrote: >> On 05/21/2012 02:05 PM, Mark Thomas wrote: >>> I am trying to build the 1.1.x native connector from trunk so I can test >>> the changes I plan to make to support per socket time outs. I can build >>> using dynamic linking but not statically. What tool chain are folks >>> currently using to build the native connector binaries we currently ship? >>> >>> My current issue relates to statically linking to OpenSSL. I get the >>> same failure with 1.0.c, 0.9.8x and 0.9.8k. I am using: >>> - Visual Studio 6 + SP6 >>> - Win 2003 r2 Platform SDK >>> - OpenSSL binaries from http://slproweb.com/products/Win32OpenSSL.html >> >> If those binaries were not compiled with VS6 you can't statically link >> them. When I build binaries I build both of those (and apr) with the >> same compiler. >> >> Yeah, it's not trivial task. > > :) Got it working! > > For the benefit of the archives, I ended up using: Maybe this info should also be saved somewhere in SVN? > - Visual Studio 6 + SP6 > - Win 2003 r2 Platform SDK > - OpenSSL source bundle 0.9.x > - APR 1.4.x src (I used the 1.4.6 tag) > - native source (I used the 1.1.x branch) > > OpenSSL 1.x will not work with the VS6 tool chain. > > My aim is to build the 64-bit APR/native DLL. 32-bit should be pretty similar. > > Stage 1: OpenSSL build > This is pretty close to the OpenSSL docs INSTALL.W64 > - Set up the environment to build with the Platform SDK > %PLATFORM_SDK_HOME%\SetEnv.Cmd /X64 /RETAIL > - Follow the OpenSSL build instructions > perl Configure VC-WIN64A > ms\do_win64a > nmake -f ms\nt.mak > > The *.lib files you'll need are in the out32 directory. > > Stage 2: Start VS6 in x64 mode > You'll need a batch file that looks something like this: > call "C:\Program Files\PlatformSDK\SetEnv.Cmd" /X64 /RETAIL > start "" "C:\Program Files (x86)\Microsoft Visual > Studio\Common\MSDev98\Bin\MSDEV.EXE" /useenv > > Stage 3: Open the workspace > Depending on where APR is, you'll need to specify paths to the projects > > Stage 4: Build APR > Make sure you can build the "apr x64" Release target > You may need to tweak src and library paths. > > Stage 5: Create a tcnative x64 target > Copy the Win32 release configuration and name it x64 Release > Add /machine:AMD64 to the link options (you can't remove the I368 option - > just make sure you add the new one after it) > Tweak the src and library paths as required. > > For both stage 4 and 5 you may need to add additional standard libraries. > Google the linking error you get to figure out which. > > HTH, > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat Native 1.1.24 released
On 14 June 2012 15:58, Mladen Turk wrote: > The Apache Tomcat team announces the immediate availability of Apache > Tomcat Native 1.1.24 stable. Please include a brief synopsis (1 or 2 sentences) of the purpose of the TLP/Product in all announcements sent outside the TLP mailing lists. The developers and users will (presumably) know what the product is about, but others are unlikely to know. S. P.S. Just about every other TLP includes this information, including HTTD... > Please refer to the change log for the list of changes: > http://tomcat.apache.org/native-doc/miscellaneous/changelog.html > > Downloads: > http://tomcat.apache.org/download-native.cgi > > Thank you, > -- > The Apache Tomcat Team > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.28
On 15 June 2012 10:14, Mark Thomas wrote: > The proposed Apache Tomcat 7.0.28 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.28/ The NOTICE file for the source archive includes references to Nullsoft and Eclipse which AFAICT are not actually present in the archive. AFAIK, the NOTICE file should only be for required notices. The way I look at this is: if Tomcat were released as source only (no binaries) would the entries in NOTICE be required? > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-243/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_28/ > > The proposed 7.0.27 release is: > [ ] Broken - do not release > [ ] Stable - go ahead and release as 7.0.28 Stable > > Cheers, > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1360729 - in /tomcat/trunk: ./ modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ res/dbcp/
Do these patches need to be fed back to Commons DBCP? Or do they only apply to the version embedded by Tomcat? On 14 July 2012 21:47, Rainer Jung wrote: > On 14.07.2012 22:25, Filip Hanik Mailing Lists wrote: >> >> I know, it's the same patch for DBCP as for DBCP2. > > > Roger that. > > >> we can fix it, not urgent though > > > No hurry, maybe we'll be on DBCP2 until the first TC 8 release. > > Rainer > > >> - Original Message - >>> >>> From: "Rainer Jung" >>> To: dev@tomcat.apache.org >>> Sent: Friday, July 13, 2012 3:47:27 AM >>> Subject: Re: svn commit: r1360729 - in /tomcat/trunk: ./ >>> modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ >>> res/dbcp/ >>> >>> On 12.07.2012 17:38, fha...@apache.org wrote: Author: fhanik Date: Thu Jul 12 15:38:28 2012 New Revision: 1360729 URL: http://svn.apache.org/viewvc?rev=1360729&view=rev Log: Configure Tomcat trunk to build with Java 7. This includes adding a patch to the Commons-DBCP code from res/dbcp Added: tomcat/trunk/res/dbcp/ tomcat/trunk/res/dbcp/dbcp-java-7.patch (with props) >>> >>> >>> Just an info: when compiling TC trunk with Java 7 and ant 1.8.2 a few >>> minutes ago, many of the offsets when applying the patch were quite >>> big: >>> >>>[copy] Copying 68 files to >>> /shared/build/dev/tomcat/deps/tomcat8-deps/tomcat8-deps/dbcp >>> [patch] patching file >>> src/java/org/apache/commons/dbcp/DelegatingCallableStatement.java >>> [patch] Hunk #1 succeeded at 660 (offset -114 lines). >>> [patch] patching file >>> src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java >>> [patch] patching file >>> src/java/org/apache/commons/dbcp/DelegatingResultSet.java >>> [patch] Hunk #1 succeeded at 1078 (offset -196 lines). >>> [patch] patching file >>> src/java/org/apache/commons/dbcp/PoolingDataSource.java >>> [patch] Hunk #1 succeeded at 437 (offset -52 lines). >>> [patch] patching file >>> src/java/org/apache/commons/dbcp/DelegatingConnection.java >>> [patch] Hunk #1 succeeded at 678 (offset -126 lines). >>> [patch] patching file >>> src/java/org/apache/commons/dbcp/PoolingDriver.java >>> [patch] Hunk #1 succeeded at 496 (offset -5 lines). >>> [patch] patching file >>> src/java/org/apache/commons/dbcp/DelegatingStatement.java >>> [patch] Hunk #1 succeeded at 385 (offset -144 lines). >>> [patch] patching file >>> src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java >>> [patch] Hunk #1 succeeded at 1206 (offset -171 lines). >>> [patch] patching file >>> src/java/org/apache/commons/dbcp/BasicDataSource.java >>> [patch] Hunk #1 succeeded at 28 with fuzz 1. >>> [patch] Hunk #2 succeeded at 1580 (offset -221 lines). >>> [patch] patching file >>> src/java/org/apache/commons/dbcp/datasources/InstanceKeyDataSource.java >>> [patch] Hunk #1 succeeded at 887 (offset -1 lines). >>> >>> Compilation for everything including DBCP works though. >>> >>> Regards, >>> >>> Rainer > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1360729 - in /tomcat/trunk: ./ modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ res/dbcp/
On 15 July 2012 20:54, Mark Thomas wrote: > On 15/07/2012 20:49, Filip Hanik Mailing Lists wrote: >> not sure if they want to make Java 7 minimum requirement I'd forgotten that DBCP stands for the Don't Be Compatible Project ... > > That will need a discussion on the commons dev list. If no-one brings it > up sooner, I'll bring it up once Pool2 is sorted as work will naturally > move to dbcp2 at that point. > > Mark > >> >> - Original Message - >>> From: "sebb" >>> To: "Tomcat Developers List" >>> Sent: Saturday, July 14, 2012 8:04:42 PM >>> Subject: Re: svn commit: r1360729 - in /tomcat/trunk: ./ >>> modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ >>> res/dbcp/ >>> >>> Do these patches need to be fed back to Commons DBCP? >>> >>> Or do they only apply to the version embedded by Tomcat? >>> >>> On 14 July 2012 21:47, Rainer Jung wrote: >>>> On 14.07.2012 22:25, Filip Hanik Mailing Lists wrote: >>>>> >>>>> I know, it's the same patch for DBCP as for DBCP2. >>>> >>>> >>>> Roger that. >>>> >>>> >>>>> we can fix it, not urgent though >>>> >>>> >>>> No hurry, maybe we'll be on DBCP2 until the first TC 8 release. >>>> >>>> Rainer >>>> >>>> >>>>> - Original Message - >>>>>> >>>>>> From: "Rainer Jung" >>>>>> To: dev@tomcat.apache.org >>>>>> Sent: Friday, July 13, 2012 3:47:27 AM >>>>>> Subject: Re: svn commit: r1360729 - in /tomcat/trunk: ./ >>>>>> modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ >>>>>> res/dbcp/ >>>>>> >>>>>> On 12.07.2012 17:38, fha...@apache.org wrote: >>>>>>> >>>>>>> Author: fhanik >>>>>>> Date: Thu Jul 12 15:38:28 2012 >>>>>>> New Revision: 1360729 >>>>>>> >>>>>>> URL: http://svn.apache.org/viewvc?rev=1360729&view=rev >>>>>>> Log: >>>>>>> Configure Tomcat trunk to build with Java 7. >>>>>>> This includes adding a patch to the Commons-DBCP code from >>>>>>> res/dbcp >>>>>>> >>>>>>> >>>>>>> Added: >>>>>>> tomcat/trunk/res/dbcp/ >>>>>>> tomcat/trunk/res/dbcp/dbcp-java-7.patch (with props) >>>>>> >>>>>> >>>>>> Just an info: when compiling TC trunk with Java 7 and ant 1.8.2 a >>>>>> few >>>>>> minutes ago, many of the offsets when applying the patch were >>>>>> quite >>>>>> big: >>>>>> >>>>>>[copy] Copying 68 files to >>>>>> /shared/build/dev/tomcat/deps/tomcat8-deps/tomcat8-deps/dbcp >>>>>> [patch] patching file >>>>>> src/java/org/apache/commons/dbcp/DelegatingCallableStatement.java >>>>>> [patch] Hunk #1 succeeded at 660 (offset -114 lines). >>>>>> [patch] patching file >>>>>> src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java >>>>>> [patch] patching file >>>>>> src/java/org/apache/commons/dbcp/DelegatingResultSet.java >>>>>> [patch] Hunk #1 succeeded at 1078 (offset -196 lines). >>>>>> [patch] patching file >>>>>> src/java/org/apache/commons/dbcp/PoolingDataSource.java >>>>>> [patch] Hunk #1 succeeded at 437 (offset -52 lines). >>>>>> [patch] patching file >>>>>> src/java/org/apache/commons/dbcp/DelegatingConnection.java >>>>>> [patch] Hunk #1 succeeded at 678 (offset -126 lines). >>>>>> [patch] patching file >>>>>> src/java/org/apache/commons/dbcp/PoolingDriver.java >>>>>> [patch] Hunk #1 succeeded at 496 (offset -5 lines). >>>>>> [patch] patching file >>>>>> src/java/org/apache/commons/dbcp/DelegatingStatement.java >>>>>> [patch] Hunk #1 succeeded at 385 (offset -144 lines). >>>>>> [patch] patching file >>>>>> sr
Re: svn commit: r1358055 - in /tomcat/trunk: java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/coyote/ java/org/apache/coyote/ajp/ java/org/apache/coyote/http11/ java/
On 6 July 2012 07:53, wrote:
> Author: fhanik
> Date: Fri Jul 6 06:53:52 2012
> New Revision: 1358055
>
> URL: http://svn.apache.org/viewvc?rev=1358055&view=rev
> Log:
> implement rev 1 of async/non blocking writes
>
> @@ -146,8 +226,12 @@ public class InternalNioOutputBuffer ext
> * @throws IOException
> * TODO Fix non blocking write properly
> */
> +int total = 0;
The field is misplaced; it should not be between the Javadoc and the method.
> private synchronized int writeToSocket(ByteBuffer bytebuffer, boolean
> block, boolean flip) throws IOException {
> -if ( flip ) bytebuffer.flip();
> +if ( flip ) {
> +bytebuffer.flip();
> +flipped = true;
> +}
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1364419 - /tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
On 22 July 2012 20:55, wrote:
> Author: markt
> Date: Sun Jul 22 19:55:50 2012
> New Revision: 1364419
>
> URL: http://svn.apache.org/viewvc?rev=1364419&view=rev
> Log:
> Fingbugs: Fix possible NPE
>
> Modified:
>
> tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
>
> Modified:
> tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java?rev=1364419&r1=1364418&r2=1364419&view=diff
> ==
> ---
> tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
> (original)
> +++
> tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
> Sun Jul 22 19:55:50 2012
> @@ -122,13 +122,14 @@ public class TcpPingInterceptor extends
> }
>
> protected void sendPing() {
> -if (failureDetector.get()!=null) {
> -//we have a reference to the failure detector
> -//piggy back on that dude
> +if (failureDetector.get() != null) {
> +// We have a reference to the failure detector
> +// Piggy back on it
> failureDetector.get().checkMembers(true);
If it's necessary to pre-fetch staticMembers just once (as below) is
it not also necessary to pre-fetch failureDetector (above) ?
They are both WeakReference fields, so surely both can return null at any time?
> -}else {
> -if (staticOnly && staticMembers.get()!=null) {
> -sendPingMessage(staticMembers.get().getMembers());
> +} else {
> +StaticMembershipInterceptor smi = staticMembers.get();
> +if (staticOnly && smi != null) {
> +sendPingMessage(smi.getMembers());
> } else {
> sendPingMessage(getMembers());
> }
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-maven-plugin] Is it only for Maven 3 and later? (was: svn commit r1367640)
On 1 August 2012 19:39, Konstantin Kolinko wrote: > 2012/7/31 : >> Author: olamy >> Date: Tue Jul 31 16:01:20 2012 >> New Revision: 1367640 >> >> URL: http://svn.apache.org/viewvc?rev=1367640&view=rev >> Log: >> [MTOMCAT-157] use new Maven Plugins annotations. done for tomcat6 mojos. >> >> Modified: >> tomcat/maven-plugin/trunk/pom.xml >>(...) > >> >> +org.apache.maven.plugin-tools >> +maven-plugin-annotations >> +3.1 >> +compile >> + > > Hi! > > Just to confirm: > > is tomcat-maven-plugin currently designed for Apache Maven 3 and later only? If so, can the required maven dependency be added to the pom please? > There is a project on Jenkins "TomcatMavenPlugin-mvn2.x" [1] that is > in the failed state for many months (and it nags me with an e-mail > every time it builds). > > If maven 2 is not supported, then maybe it is now time to remove this > project from Jenkins? > > [1] https://builds.apache.org/job/TomcatMavenPlugin-mvn2.x/ > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1358055 - in /tomcat/trunk: java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/coyote/ java/org/apache/coyote/ajp/ java/org/apache/coyote/http11/ java/
On 6 July 2012 07:53, wrote:
> Author: fhanik
> Date: Fri Jul 6 06:53:52 2012
> New Revision: 1358055
>
> URL: http://svn.apache.org/viewvc?rev=1358055&view=rev
> Log:
> implement rev 1 of async/non blocking writes
>
>
> Modified:
> tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java?rev=1358055&r1=1358054&r2=1358055&view=diff
> ==
> --- tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
> (original)
> +++ tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
> Fri Jul 6 06:53:52 2012
> @@ -146,8 +226,12 @@ public class InternalNioOutputBuffer ext
> * @throws IOException
> * TODO Fix non blocking write properly
> */
> +int total = 0;
The above is in the wrong place; it should either be before the
Javadoc or after the private method body, not between them.
> private synchronized int writeToSocket(ByteBuffer bytebuffer, boolean
> block, boolean flip) throws IOException {
> -if ( flip ) bytebuffer.flip();
> +if ( flip ) {
> +bytebuffer.flip();
> +flipped = true;
> +}
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Re-factoring TLD parsing
On 16 August 2012 23:44, Christopher Schultz wrote: > All, > > The first item in the TOMCAT-NEXT.txt is this: > > 1. Refactor the TLD parsing. TLDs are currently parsed twice. Once by > Catalina looking for listeners and once by Jasper. > > I had a conversation in Vancouver with David Blevins about the scourge > of JAR-scanning in general (in that case, we were discussing > annotation-processing) and I suggested that a generic JAR scanner could > be built that would simply scan JARs and emit events like "found > annotation" or "found JAR" or "found file" or whatever. > > I don't know enough about how Catalina and Jasper each handle these > things, but would such a scanning component be helpful to them? If both > components (Catalina and Jasper, other components) could register event > handlers with the scanner, the number of times each JAR would be scanned > would be limited to 1. > > Perhaps this strategy could be extended to TLD processing as well: the > scanner could be configured to send TLD-specific notifications (or maybe > just have a TLD-specific listener registered with the scanner that > generates events like "read TLD component" or what have you). > > I guess the question is whether each component (Catalina, Jasper, > whatever add-ons might be interested in similar information) can cleanly > register their interest in receiving notification of these kinds of > events. Is there a convenient place where components hosted by Catalina > could naturally register for these kinds of events (or even request that > a JAR scan occur)? What about timing? If the components start up independently, there could be issues with knowing when all interested parties have declared themselves and when it is safe to start the scan. Equally, one component may require the information before another registers. > Is this kind of thing overkill, or does it sound like it would be a > truly useful utility? > > Thanks, > -chris > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Re-factoring TLD parsing
On 17 August 2012 05:00, Christopher Schultz wrote: > Sebb, > > On 8/16/12 7:11 PM, sebb wrote: >> On 16 August 2012 23:44, Christopher Schultz >> wrote: >>> >>> I had a conversation in Vancouver with David Blevins about the scourge >>> of JAR-scanning in general (in that case, we were discussing >>> annotation-processing) and I suggested that a generic JAR scanner could >>> be built that would simply scan JARs and emit events like "found >>> annotation" or "found JAR" or "found file" or whatever. >> >> What about timing? >> If the components start up independently, there could be issues with >> knowing when all interested parties have declared themselves and when >> it is safe to start the scan. Equally, one component may require the >> information before another registers. > > Obviously, timing can be an issue. If the scan is already done and the > events haven't been stored somewhere, the scan needs to be re-done. At > that point, it's no worse than the situation as it stands, today. The > components that can benefit from this idea can, while others will not > suffer any worse than they already do. Provided that the scan only does what is needed by that component. If the scanner performs multiple types of scan each time, some of that work will be wasted. So the components would need to be able to register for specific scan types. The scanner would also need to keep track of which scan types are outstanding requests. Obviously if the scanner can cache the info, this would not apply. > -chris > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1397522 - in /tomcat/trunk/java/javax/net: ./ websocket/ websocket/annotations/ websocket/extensions/
On 12 October 2012 13:39, Mark Thomas wrote: > On 12/10/2012 13:24, Martin Grigorov wrote: > > Please use quoting, particularly when you have a few short comments on a > very large e-mail. Without quoting, your comments were more effort to find. > >>> Added: tomcat/trunk/java/javax/net/websocket/HandshakeRequest.java >>> URL: >>> http://svn.apache.org/viewvc/tomcat/trunk/java/javax/net/websocket/HandshakeRequest.java?rev=1397522&view=auto > > > >>> +Object getSession(); >> >> ^^ >> Shouldn't this return a Session instead ? > > No. That is an HTTP Session object and Object is used to avoid a > dependency on the Servlet spec. I'll add some Javadoc. (I can't just > copy the RI's Javadoc because of licensing). > > >>> Added: tomcat/trunk/java/javax/net/websocket/Session.java >>> URL: >>> http://svn.apache.org/viewvc/tomcat/trunk/java/javax/net/websocket/Session.java?rev=1397522&view=auto > > > >>> +RemoteEndpoint getRemote(); >>> + >>> +RemoteEndpoint getRemoteL(Class c); >> >> Is there a typo in the method name ? Is the 'L' needed ? > > That is what the spec currently says. It looks like a typo. I've raised > it with the EG. In which case it might help to comment this in the code, so people reading the source are aware? > Thanks for the review. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r784083 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/core/ java/org/apache/naming/resources/ webapps/docs/config/
On 12/06/2009, ma...@apache.org wrote:
> Author: markt
> Date: Fri Jun 12 11:38:29 2009
> New Revision: 784083
>
> URL: http://svn.apache.org/viewvc?rev=784083&view=rev
> Log:
> Implement alias resources. Key features:
> - configured at the context level in the same way as the other resource
> related attributes
> - maps paths to directories or WAR files (single files not supported)
>
> Implementation notes:
> - Correct results for getRealPath() required this to be pushed down to the
> BaseDirContext as the short-cuts previously used needed to take account of
> any aliases. This in turn meant an addition to the Context interface
> - Thanks to Tim F. The configuration format is all his idea
>
> Modified:
> tomcat/trunk/java/org/apache/catalina/Context.java
> tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
> tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
> tomcat/trunk/java/org/apache/catalina/core/mbeans-descriptors.xml
> tomcat/trunk/java/org/apache/naming/resources/BaseDirContext.java
> tomcat/trunk/java/org/apache/naming/resources/FileDirContext.java
> tomcat/trunk/java/org/apache/naming/resources/LocalStrings.properties
> tomcat/trunk/java/org/apache/naming/resources/VirtualDirContext.java
> tomcat/trunk/java/org/apache/naming/resources/WARDirContext.java
> tomcat/trunk/webapps/docs/config/context.xml
>
> Modified: tomcat/trunk/java/org/apache/catalina/Context.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/Context.java?rev=784083&r1=784082&r2=784083&view=diff
>
> ==
> --- tomcat/trunk/java/org/apache/catalina/Context.java (original)
> +++ tomcat/trunk/java/org/apache/catalina/Context.java Fri Jun 12 11:38:29
> 2009
> @@ -1073,6 +1073,13 @@
> */
> public void setTldNamespaceAware(boolean tldNamespaceAware);
>
> +/**
> + * Return the real path for a given virtual path, if possible; otherwise
> + * return null.
> + *
> + * @param path The path to the desired resource
> + */
> +public String getRealPath(String path);
>
> }
>
>
> Modified: tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java?rev=784083&r1=784082&r2=784083&view=diff
>
> ==
> --- tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
> (original)
> +++ tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java Fri
> Jun 12 11:38:29 2009
> @@ -371,17 +371,7 @@
> * @param path The path to the desired resource
> */
> public String getRealPath(String path) {
> -
> -if (!context.isFilesystemBased())
> -return null;
> -
> -if (path == null) {
> -return null;
> -}
> -
> -File file = new File(basePath, path);
> -return (file.getAbsolutePath());
> -
> +return context.getRealPath(path);
> }
>
>
>
> Modified: tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardContext.java?rev=784083&r1=784082&r2=784083&view=diff
>
> ==
> --- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
> (original)
> +++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Fri Jun
> 12 11:38:29 2009
> @@ -670,6 +670,12 @@
>
>
> /**
> + * List of resource aliases.
> + */
> +protected String aliases = null;
>
This should be private, as there are public get/set methods.
> +
> +/**
> * Non proxied resources.
> */
> private DirContext webappResources = null;
> @@ -848,6 +854,25 @@
>
>
> /**
> + * Return the list of resource aliases.
> + */
> +public String getAliases() {
> +return this.aliases;
> +}
> +
> +
> +/**
> + * Set the current alias configuration. The list of aliases should be
> of the
> + * form "/aliasPath1=docBase1,/aliasPath2=docBase2" where aliasPathN
> must
> + * include a leading '/' and docBaseN must be an absolute path to
> either a
> + * .war file or a directory.
> + */
> +public void setAliases(String aliases) {
> +this.aliases = aliases;
> +}
> +
> +
> +/**
> * Return the "follow standard delegation model" flag used to configure
> * our ClassLoader.
> */
> @@ -1908,6 +1933,7 @@
> ((BaseDirContext) resources).setCacheMaxSize(getCacheMaxSize());
> ((BaseDirContext) resources).setCacheObjectMaxSize(
> getCacheObjectMaxSize());
> +((BaseDirContext) resources).setAliase
Re: [VOTE] Release JDBC Pool module v1.0.3
On 15/06/2009, Filip Hanik - Dev Lists wrote: > Sebb, thanks for the feedback. > > sebb wrote: > > > Apart from the problems with N&L files etc that have already been > > mentioned, I found the following: > > > > == > > > > The changelog.html file refers to Tomcat JDBC Connection Pool > > *v1.0.5-beta* which looks wrong. > > > > > fixed. > > > == > > > > The documentation for the Interceptors appears to be incorrect. > > > > For example: > > > > The code sample: > > > jdbcInterceptors="ConnectionState;StatementFinalizer(useWeakReferences=true,useEquals=true)" > > implies that StatementFinalizer has a property useWeakReferences, but > > that does not appear to be the case - and it is not documented in any > > sections below. > > > > > fixed. > > > Also SlowQueryReport does not have a threshold attribute. > > > > > sure does. it inherits it. > > > There may be other inconsistencies; I did not check it all > > > > The Copyright years in the html files are wrong. > > > > > fixed > > > == > > > > As to the source: > > > > There does not appear to be a build file or any test cases so it's not > > easy to check if the code works as intended. I was able to build the > > POJO sample, and it worked against Apache Derby after making the > > necessary changes. However this does not constitute a thorough test. > > > > > Added in docs and references to the build file. > > > > There are some threading issues, e.g. the ConnectionPool.closed > > boolean field is accessed by multiple threads, but is not synchronized > > or volatile. This will probably work most of the time, but is not > > guaranteed to work. > > > > > yes, although calling close multiple times would be a programmer error. Not sure how calling close() multiple times relates to the threading bug (anyway, the code already guards against multiple calls from the same thread). The "closed" field is checked in the PoolCleaner thread. AFAICT, the close() method that sets the "closed" field will be called in a different thread from the pool cleaner. > > It's confusing to have two classes called ConnectionPool (or is this > > required by JMX/MBean?) > > > > > There is a naming convention between the MBean interface and the MBean > itself. > Doesn't have to be ConnectionPool, it just ended up being that way. > > Thanks for taking a look. > The rest is personal preferences in coding. And some ol' dogs like me, > don't like to learn new tricks, only fix bugs. I disagree that these are all personal coding preferences. For example, Javadoc errors are errors. > Filip > > > Likewise, the class name > org.apache.tomcat.jdbc.pool.DataSource > > shadows the simple name of the implemented interface > > javax.sql.DataSource. This can cause confusion. > > > > == > > > > There are some dubious coding practices, e.g. > > > > The method Statement#close() throws SQLException, yet the code catches > > and ignores Exception (e.g. in StatementFinalizer). > > > > The fields: > > > > > interceptor.AbstractCreateStatementInterceptor.statements > and > > > interceptor.AbstractCreateStatementInterceptor.executes > > > > are both public arrays, which anyone can overwrite. > > > > == > > > > The code uses generics, but there are some instances of raw types being > used. > > Also a few unnecessary casts, and some unchecked casts. > > > > There are a lot of Javadoc errors, and quite a few unused imports. > > > > The visibility of fields seems to be generally too permissive; it's > > much harder to test and maintain code that has lots of non-private > > variables. Some of the classes have public getters and setters yet the > > fields they operate on are not private. > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release JDBC Pool module v1.0.4
On 15/06/2009, Filip Hanik - Dev Lists wrote: > Cleaned up and fixed. > > The release is located here: > http://people.apache.org/~fhanik/jdbc-pool/v1.0.4/ NOTICE file is incorrect, it should read: >>> Apache Tomcat JDBC Pool Copyright 2008-2009 The Apache Software Foundation This product includes software developed by The Apache Software Foundation (http://www.apache.org/). <<< [e.g. See http://www.apache.org/dev/release.html#notice-required] This assumes that JDBC Pool was first released in 2008; if not adjust accordingly. Two java files (ResultSet and TestException) don't have AL headers. The jar files don't have NOTICE or LICENSE files. Releases must consist of a source archive; binary archives are optional. The source archive must contain all the items needed to build and test the binary archive, see: http://www.apache.org/dev/release.html#what-must-every-release-contain Therefore the source archive needs to contain the test code. It's not essential, but it's helpful if the jar MANIFEST.MF files contain the following: Built-By: Implementation-Title: Implementation-Vendor: The Apache Software Foundation Implementation-Vendor-Id: org.apache Implementation-Version: Specification-Title: Specification-Vendor: The Apache Software Foundation Specification-Version: X-Compile-Target-JDK: X-Compile-Source-JDK: It might be useful to include the Javadoc in the binary archive. The build.xml defines compile.source=1.5, however some of the classes require 1.6, for example SlowQueryReport uses the generic form of OpenType which was only introduced in 1.6. The build file relies on the following files for testing, however there is no indication where these are to be obtained: c3p0-0.9.1.2.jar mysql-connector-java-5.0.7-bin.jar The test file DefaultTestCase does not define any test cases, so it would help some IDEs if it were marked abstract. The ResultSet and Statement test classes in the test driver directory won't compile when using Eclipse, because Eclipse generates an error for @Override tags applied to methods only defined in interfaces. It's not clear whether this is an Eclipse bug or a Sun Java bug, but it does not really add much to use @Override for interface methods, so perhaps these tags could be removed. > > [ ] STABLE - I couldn't find any bugs > [ ] BETA - I found some bugs but not critical > [X] BROKEN - I found some show stoppers Incorrect NOTICE file, missing N&L files Incorrect packging. > > > Any comments ? See above. > Thanks, > Filip > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 4.1.40
The copyright year in the NOTICE files in the binary archive is still 2008; surely it should be 2009? The connectors/NOTICE file in the source archive is wrong. There are no NOTICE files for the jasper and servletapi directory sub-trees. It would be better to have a single N&L file at the top of the directory structure, but failing that, each sub-tree needs the proper N&L files. The binary tgz and zip archives agree with each other. The source tgz and zip archives are different. The binary files (*.exe and *.bin) are corrupted in the tgz archive. Also there are additional EOLs at the end of many source files in the tgz archive. There seems to be a bug in the packaging of the source files in the tar.gz format. The apache-tomcat-4.1.40.exe fails for me when trying to install a Full release on WinXP: It starts by saying it has found a Java development kit, but later on fails with the message: Couldn't find a Java development kit on this computer. Please download one from http://java.sun.com/ The last line in the installer dialogue is "Created uninstaller: ..." There seem to be a lot of files missing from the installation compared with the binary zip archive, but that is probably due to the premature failure of the installation. IMO the release is broken. On 16/06/2009, Mark Thomas wrote: > The candidates source tarball and derived binaries are available here: > http://tomcat.apache.org/dev/dist/apache-tomcat-4.1.40/ > > According to the release process, the 4.0.40 tag is: > [ ] Broken > [ ] Alpha > [ ] Beta > [ ] Stable > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r785164 - /tomcat/container/branches/tc4.1.x/build.xml
On 16/06/2009, ma...@apache.org wrote:
> Author: markt
> Date: Tue Jun 16 11:17:26 2009
> New Revision: 785164
>
> URL: http://svn.apache.org/viewvc?rev=785164&view=rev
> Log:
> Update exclusion list for EOL filtering
>
> Modified:
> tomcat/container/branches/tc4.1.x/build.xml
>
> Modified: tomcat/container/branches/tc4.1.x/build.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/build.xml?rev=785164&r1=785163&r2=785164&view=diff
>
> ==
> --- tomcat/container/branches/tc4.1.x/build.xml (original)
> +++ tomcat/container/branches/tc4.1.x/build.xml Tue Jun 16 11:17:26 2009
> @@ -438,7 +438,7 @@
>
>
>- excludes="**/*.jar,**/*.gif,**/*.bmp,**/*.jpg,**/*.ico" eol="lf"/>
> +
> excludes="**/*.jar,**/*.gif,**/*.bmp,**/*.jpg,**/*.ico,**/*.war,**/*.exe,**/*.pdf,**/*.bin,**/*.dia"
> eol="lf"/>
>
>
> name="${final-src.name}/${jtc.project}/jk/native/buildconf.sh" />
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r785164 - /tomcat/container/branches/tc4.1.x/build.xml
On 16/06/2009, Mark Thomas wrote:
> sebb wrote:
> > On 16/06/2009, ma...@apache.org wrote:
> >> Author: markt
> >> Date: Tue Jun 16 11:17:26 2009
> >> New Revision: 785164
> >>
> >> URL: http://svn.apache.org/viewvc?rev=785164&view=rev
> >> Log:
> >> Update exclusion list for EOL filtering
> >>
> >> Modified:
> >> tomcat/container/branches/tc4.1.x/build.xml
> >>
> >> Modified: tomcat/container/branches/tc4.1.x/build.xml
> >> URL:
> http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/build.xml?rev=785164&r1=785163&r2=785164&view=diff
> >>
> ==
> >> --- tomcat/container/branches/tc4.1.x/build.xml (original)
> >> +++ tomcat/container/branches/tc4.1.x/build.xml Tue Jun 16 11:17:26 2009
> >> @@ -438,7 +438,7 @@
> >>
> >>
> >>>
> > If you add
> >
> > fixlast="false"
>
>
> I know. I'm already working on that but as a separate commit. Got
> distracted half way through. Will be committed shortly.
OK, NP.
> Mark
>
>
> >
> > that will prevent spurious additional EOLs and make it easier to
> > compare archives.
> >
> >> - excludes="**/*.jar,**/*.gif,**/*.bmp,**/*.jpg,**/*.ico" eol="lf"/>
> >> +
> excludes="**/*.jar,**/*.gif,**/*.bmp,**/*.jpg,**/*.ico,**/*.war,**/*.exe,**/*.pdf,**/*.bin,**/*.dia"
> eol="lf"/>
> >>
> >>
> >> name="${final-src.name}/${jtc.project}/jk/native/buildconf.sh" />
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] [CANCELLED] Release build 4.1.40
On 16/06/2009, Mark Thomas wrote: > Mark Thomas wrote: > > The candidates source tarball and derived binaries are available here: > > http://tomcat.apache.org/dev/dist/apache-tomcat-4.1.40/ > > > > According to the release process, the 4.0.40 tag is: > > [ ] Broken > > [ ] Alpha > > [ ] Beta > > [ ] Stable > > > There were enough issues to re-roll the release. For the record, I tried > and failed on several machines to recreate the problem sebb saw so I can > only assume it was a local JVM issue. I've just realised that it might be due to trying to install without Admin privileges; I'll try another install shortly. There's another issue I forgot to mention - the file RELEASE-NOTES-4.1.txt is buried in the container directory; it would be better if it were at the top-level. > I'll re-tag shortly and send out a new vote once the files are all in place. If you create a 4.1.20-RCn tag, you can keep going until the release passes, and then create the GA tag from whatever passes. > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] [CANCELLED] Release build 4.1.40
On 16/06/2009, Mark Thomas wrote: > sebb wrote: > > On 16/06/2009, Mark Thomas wrote: > >> Mark Thomas wrote: > >> > The candidates source tarball and derived binaries are available here: > >> > http://tomcat.apache.org/dev/dist/apache-tomcat-4.1.40/ > >> > > >> > According to the release process, the 4.0.40 tag is: > >> > [ ] Broken > >> > [ ] Alpha > >> > [ ] Beta > >> > [ ] Stable > >> > >> > >> There were enough issues to re-roll the release. For the record, I tried > >> and failed on several machines to recreate the problem sebb saw so I can > >> only assume it was a local JVM issue. > > > > I've just realised that it might be due to trying to install without > > Admin privileges; I'll try another install shortly. > > > That might explain things. I wonder if there is anything more graceful we can > do > in the installer in that case? Something for trunk though, not for 4.1.x. That was it. The error message ideally needs fixing, but I agree it's not worth it for 4.1.20 > > > There's another issue I forgot to mention - the file > > RELEASE-NOTES-4.1.txt is buried in the container directory; it would > > be better if it were at the top-level. > > > Probably, although the folks that use 4.1.x (the few there are) are used to > where it is. > > > > If you create a 4.1.20-RCn tag, you can keep going until the release > > passes, and then create the GA tag from whatever passes. > > > That would be neater. Something to keep in mind That way, tags are immutable. > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release JDBC Pool module v1.0.4
On 16/06/2009, Filip Hanik - Dev Lists wrote: > Sebb, I can't find anything that is broken. All your concerns seem invalid > to me. Please revisit, especially the NOTICE files. > Filip > > sebb wrote: > > > On 15/06/2009, Filip Hanik - Dev Lists wrote: > > > > > > > Cleaned up and fixed. > > > > > > The release is located here: > > > http://people.apache.org/~fhanik/jdbc-pool/v1.0.4/ > > > > > > > > > > NOTICE file is incorrect, it should read: > > > > Apache Tomcat JDBC Pool > > Copyright 2008-2009 The Apache Software Foundation > > > > This product includes software developed by > > The Apache Software Foundation (http://www.apache.org/). > > <<< > > > > [e.g. See > http://www.apache.org/dev/release.html#notice-required] > > > > This assumes that JDBC Pool was first released in 2008; if not adjust > > accordingly. > > > > > that date is correct. The code started in 2008 So why does the NOTICE file say this? Copyright 1999-2009 The Apache Software Foundation It is also missing the following required paragraph: This product includes software developed by The Apache Software Foundation (http://www.apache.org/). > > Two java files (ResultSet and TestException) don't have AL headers. > > > > > These don't ship with the release Nevertheless, they need AL headers. > > The jar files don't have NOTICE or LICENSE files. > > > > > Same as Tomcat, only .tar.gz and .zip have it. Two wrongs don't make a right. > > > Releases must consist of a source archive; binary archives are optional. > > The source archive must contain all the items needed to build and test > > the binary archive, see: > > > > > http://www.apache.org/dev/release.html#what-must-every-release-contain > > > > Therefore the source archive needs to contain the test code. > > > > > no they don't. > "test" in this case may as well be "try it out", ie, test the code itself, > not run the test suite. We never ship our test suites. Again, as others have pointed out, this is not the practice elsewhere in ASF projects. > > It's not essential, but it's helpful if the jar MANIFEST.MF files > > contain the following: > > > > Built-By: > > Implementation-Title: > > Implementation-Vendor: The Apache Software Foundation > > Implementation-Vendor-Id: org.apache > > Implementation-Version: > > Specification-Title: > > Specification-Vendor: The Apache Software Foundation > > Specification-Version: > > > > X-Compile-Target-JDK: > > X-Compile-Source-JDK: > > > > It might be useful to include the Javadoc in the binary archive. > > > > The build.xml defines compile.source=1.5, however some of the classes > > require 1.6, for example SlowQueryReport uses the generic form of > > OpenType which was only introduced in 1.6. > > > > > not part of the release It's in the archives you published. E.g. in apache-tomcat-jdbc-1.0.4.zip/tomcat-jdbc-src.jar > > The build file relies on the following files for testing, however > > there is no indication where these are to be obtained: > > > > c3p0-0.9.1.2.jar > > mysql-connector-java-5.0.7-bin.jar > > > > > not part of the release. The build file is a required part of the release. > > The test file DefaultTestCase does not define any test cases, so it > > would help some IDEs if it were marked abstract. > > > > > not part of the release > > > The ResultSet and Statement test classes in the test driver directory > > won't compile when using Eclipse, because Eclipse generates an error > > for @Override tags applied to methods only defined in interfaces. It's > > not clear whether this is an Eclipse bug or a Sun Java bug, but it > > does not really add much to use @Override for interface methods, so > > perhaps these tags could be removed. > > > > > not part of the release > > > > > > > > > > [ ] STABLE - I couldn't find any bugs > > > [ ] BETA - I found some bugs but not critical > > > [X] BROKEN - I found some show stoppers > > > > > > > > > > Incorrect NOTICE file, missing N&L files > > Incorrect packging. > > > > > > > > > > > > > > > Any comments ? > > > > > > > > > > See above. > > > > > > > > > Thanks, > > > Filip > > > > > > > > > > - > > > To unsubscribe, e-mail: > dev-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release JDBC Pool module v1.0.4
On 17/06/2009, Filip Hanik - Dev Lists wrote: > sebb wrote: > > > On 16/06/2009, Filip Hanik - Dev Lists wrote: > > > > > > > Sebb, I can't find anything that is broken. All your concerns seem > invalid > > > to me. > > > > > > > > > > Please revisit, especially the NOTICE files. > > > > > no need The NOTICE file included in the file apache-tomcat-jdbc-1.0.4.zip is wrong, as I keep trying to point out. > > > > > > > Filip > > > > > > sebb wrote: > > > > > > > > > > > > > On 15/06/2009, Filip Hanik - Dev Lists wrote: > > > > > > > > > > > > > > > > > > > > > Cleaned up and fixed. > > > > > > > > > > The release is located here: > > > > > http://people.apache.org/~fhanik/jdbc-pool/v1.0.4/ > > > > > > > > > > > > > > > > > > > > > > > > NOTICE file is incorrect, it should read: > > > > > > > > Apache Tomcat JDBC Pool > > > > Copyright 2008-2009 The Apache Software Foundation > > > > > > > > This product includes software developed by > > > > The Apache Software Foundation (http://www.apache.org/). > > > > <<< > > > > > > > > [e.g. See > > > > > > > > > > > http://www.apache.org/dev/release.html#notice-required] > > > > > > > > > > This assumes that JDBC Pool was first released in 2008; if not adjust > > > > accordingly. > > > > > > > > > > > > > > > > > > > that date is correct. The code started in 2008 > > > > > > > > > > So why does the NOTICE file say this? > > > > > > Copyright 1999-2009 The Apache Software Foundation > > > > > > It is also missing the following required paragraph: > > > > This product includes software developed by > > The Apache Software Foundation (http://www.apache.org/). > > > > > cause other files, in the SVN tree may come from earlier times. OK, but you said it dated from 2008. > > > > > > > > > > > Two java files (ResultSet and TestException) don't have AL headers. > > > > > > > > > > > > > > > > > > > These don't ship with the release > > > > > > > > > > Nevertheless, they need AL headers. > > > > > Has nothing to do with the release itself, hence you can't say the release > is broken. > > > > > > > > > > > > The jar files don't have NOTICE or LICENSE files. > > > > > > > > > > > > > > > > > > > Same as Tomcat, only .tar.gz and .zip have it. > > > > > > > > > > Two wrongs don't make a right. > > > > > You still don't get it. NOTICE and LICENSE are for the release. the .jar > file themselves don't constitute the release, only the entire package does. > you may want to verify this with folks who know :) > > > > > > > > > > > Releases must consist of a source archive; binary archives are > optional. > > > > The source archive must contain all the items needed to build and test > > > > the binary archive, see: > > > > > > > > > > > > > > > > > > > > http://www.apache.org/dev/release.html#what-must-every-release-contain > > > > > > > > > > Therefore the source archive needs to contain the test code. > > > > > > > > > > > > > > > > > > > no they don't. > > > "test" in this case may as well be "try it out", ie, test the code > itself, > > > not run the test suite. We never ship our test suites. > > > > > > > > > > Again, as others have pointed out, this is not the practice elsewhere > > in ASF projects. > > > > > still not a valid concern. > > > > > > > > > > > > It's not essential, but it's helpful if the jar MANIFEST.MF files > > > > contain the following: > > > > > > > > Built-By: > > > > Implementation-Title: > > > > Implementation-Vendor: The Apache Software Foundation > > > > Implementation-Vendor-Id: org.apache > > > > Implementati
Re: svn commit: r785952 - in /tomcat/trunk/test/org/apache/catalina/valves: ./ Benchmarks.java
On 18/06/2009, Mark Thomas wrote: > Tim Funk wrote: > > I think this needs to be volatile ? > > In (GetDateBenchmarkTest) > >> +private long currentMillis = 0; > > > > Same for (in TimeDateElementBenchmarkTest) > >> +private Date currentDate = null; > > > > Of course - since the test is single threaded - it doesn't really matter. > > > The test should be multi-threaded unless I got something badly wrong. I'll > double check. > > Making those volatile gets them closer to the real code. I doubt it will > make a > difference but worth changing to be sure. You never know with these things. The field GetDateBenchmarkTest.currentDate is set in a synch. block in doSynch(), but for the return it is fetched outside the synch. block - so it could potentially be changed by another thread. Also if the synch. block is not entered, the thread might not see the correct version of the field as there is no synch. on the read. Similarly in TimeDateElementBenchmarkTest.getDateSync() - although the field is volatile, it is set in the synch. block but fetched for the return outside the block. If it is intended to allow currentDate to be updated by another thread before the return, then the field needs to be volatile. Otherwise the return value needs to be established in the synch. block. > Mark > > > > > > -Tim > > > > ma...@apache.org wrote: > >> Author: markt > >> Date: Thu Jun 18 08:32:29 2009 > >> New Revision: 785952 > >> > >> URL: http://svn.apache.org/viewvc?rev=785952&view=rev > >> Log: > >> Add some micro-benchmarks that enable the differences between the Sync > >> and ThreadLocal approach to be compared > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r785952 - in /tomcat/trunk/test/org/apache/catalina/valves: ./ Benchmarks.java
On 18/06/2009, sebb wrote: > On 18/06/2009, Mark Thomas wrote: > > Tim Funk wrote: > > > I think this needs to be volatile ? > > > In (GetDateBenchmarkTest) > > >> +private long currentMillis = 0; > > > > > > Same for (in TimeDateElementBenchmarkTest) > > >> +private Date currentDate = null; > > > > > > Of course - since the test is single threaded - it doesn't really > matter. > > > > > > The test should be multi-threaded unless I got something badly wrong. I'll > > double check. > > > > Making those volatile gets them closer to the real code. I doubt it will > make a > > difference but worth changing to be sure. You never know with these > things. > > > The field GetDateBenchmarkTest.currentDate is set in a synch. block in > doSynch(), but for the return it is fetched outside the synch. block - > so it could potentially be changed by another thread. Also if the > synch. block is not entered, the thread might not see the correct > version of the field as there is no synch. on the read. > > Similarly in TimeDateElementBenchmarkTest.getDateSync() - although the > field is volatile, it is set in the synch. block but fetched for the > return outside the block. > > If it is intended to allow currentDate to be updated by another thread > before the return, then the field needs to be volatile. Otherwise the > return value needs to be established in the synch. block. > Oops, forgot to mention - there are only 5 threads in the test; it might be useful to try tests with increasing numbers of threads to see if the relative numbers change. > > Mark > > > > > > > > > > -Tim > > > > > > ma...@apache.org wrote: > > >> Author: markt > > >> Date: Thu Jun 18 08:32:29 2009 > > >> New Revision: 785952 > > >> > > >> URL: http://svn.apache.org/viewvc?rev=785952&view=rev > > >> Log: > > >> Add some micro-benchmarks that enable the differences between the Sync > > >> and ThreadLocal approach to be compared > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release JDBC Pool module v1.0.4
On 19/06/2009, Filip Hanik - Dev Lists wrote: > So now that we've clarified that NOTICE and LICENSE covers the entire > release as an entity, No idea what you mean by that, but anyway: As I have written several times before, the NOTICE file is incorrect. This applies to the version in the SVN tag JDBC_POOL_1_0_4 as well as the version in the archives. Please read: http://www.apache.org/dev/release.html#notice-required IMO, the proposed release does not meet the ASF requirements because: - incorrect NOTICE file - no pure source release (which is what is supposed to be voted on) - no test code in the release > my vote > [X] STABLE - I couldn't find any bugs > Filip > > > Filip Hanik - Dev Lists wrote: > > > Cleaned up and fixed. > > > > The release is located here: > > http://people.apache.org/~fhanik/jdbc-pool/v1.0.4/ > > > > > > [ ] STABLE - I couldn't find any bugs > > [ ] BETA - I found some bugs but not critical > > [ ] BROKEN - I found some show stoppers > > > > > > Any comments ? > > > > Thanks, > > Filip > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Duplicate code in AccessLogValve
Just spotted this duplicate code in AccessLogValve:
661:if (!dateStamp.equals(tsDate)) {
662:if (!dateStamp.equals(tsDate)) {
Not sure this double-checked looking offers any benefit ;-)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Duplicate code in AccessLogValve
On 19/06/2009, sebb wrote:
> Just spotted this duplicate code in AccessLogValve:
>
> 661:if (!dateStamp.equals(tsDate)) {
> 662:if (!dateStamp.equals(tsDate)) {
>
> Not sure this double-checked looking offers any benefit ;-)
>
Line 767 is also no longer needed, as currentMillis is now volatile:
765:if ((systime - currentMillis) > 1000) {
766:synchronized (this) {
767:if ((systime - currentMillis) > 1000) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Duplicate code in AccessLogValve
On 19/06/2009, Xie Xiaodong wrote:
> No, I think line767 is still needed. You could turn to the last part of this
> article for reference: "
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html";.
Oops, my bad.
The code would still work, but it would sometimes create a new Date
unecessarily.
>
>
> 2009/6/19 sebb
>
>
> > On 19/06/2009, sebb wrote:
> > > Just spotted this duplicate code in AccessLogValve:
> > >
> > > 661:if (!dateStamp.equals(tsDate)) {
> > > 662:if (!dateStamp.equals(tsDate)) {
> > >
> > > Not sure this double-checked looking offers any benefit ;-)
> > >
> >
> > Line 767 is also no longer needed, as currentMillis is now volatile:
> >
> > 765:if ((systime - currentMillis) > 1000) {
> > 766:synchronized (this) {
> > 767:if ((systime - currentMillis) > 1000) {
> >
>
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>
>
> --
> Sincerely yours and Best Regards,
>
> Xie Xiaodong
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r786532 - /tomcat/trunk/modules/jdbc-pool/NOTICE
On 19/06/2009, fha...@apache.org wrote: > Author: fhanik > Date: Fri Jun 19 15:05:04 2009 > New Revision: 786532 > > URL: http://svn.apache.org/viewvc?rev=786532&view=rev > Log: > Correct per sebb/markt Sorry, but this is still incorrect. The NOTICE is now: >>> This product includes software developed by The Apache Software Foundation (http://www.apache.org/) Apache Tomcat JDBC Pool Copyright 1999-2009 The Apache Software Foundation <<< whereas it should be: >>> Apache Tomcat JDBC Pool Copyright 2008-2009 The Apache Software Foundation This product includes software developed by The Apache Software Foundation (http://www.apache.org/) <<< as I wrote in my original e-mail. AFAIK the first copyright date needs to be the first year when the code was first released, rather than when it was first developed; JDBC Pool was surely not around in 1999? see also: http://www.apache.org/legal/src-headers.html#notice-text for the standard header. > Modified: > tomcat/trunk/modules/jdbc-pool/NOTICE > > Modified: tomcat/trunk/modules/jdbc-pool/NOTICE > URL: > http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/NOTICE?rev=786532&r1=786531&r2=786532&view=diff > > == > --- tomcat/trunk/modules/jdbc-pool/NOTICE (original) > +++ tomcat/trunk/modules/jdbc-pool/NOTICE Fri Jun 19 15:05:04 2009 > @@ -1,3 +1,3 @@ > +This product includes software developed by The Apache Software Foundation > (http://www.apache.org/) > Apache Tomcat JDBC Pool > Copyright 1999-2009 The Apache Software Foundation > -Copyright 2008-2009 Filip Hanik > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r786569 - /tomcat/trunk/modules/jdbc-pool/NOTICE
On 19/06/2009, fha...@apache.org wrote: > Author: fhanik > Date: Fri Jun 19 16:16:16 2009 > New Revision: 786569 > > URL: http://svn.apache.org/viewvc?rev=786569&view=rev > Log: > correction > > Modified: > tomcat/trunk/modules/jdbc-pool/NOTICE > > Modified: tomcat/trunk/modules/jdbc-pool/NOTICE > URL: > http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/NOTICE?rev=786569&r1=786568&r2=786569&view=diff > > == > --- tomcat/trunk/modules/jdbc-pool/NOTICE (original) > +++ tomcat/trunk/modules/jdbc-pool/NOTICE Fri Jun 19 16:16:16 2009 > @@ -1,3 +1,12 @@ > -This product includes software developed by The Apache Software Foundation > (http://www.apache.org/) > Apache Tomcat JDBC Pool > -Copyright 1999-2009 The Apache Software Foundation > +Copyright 2008-2009 The Apache Software Foundation > + > +This product includes software developed at > +The Apache Software Foundation (http://www.apache.org/). Good. > + > +Logging and JMX capabilities provided by the Apache Tomcat project. > +The original software and related information can be found at > +http://tomcat.apache.org > + > + The last paragraph is not necessary, as it is included in the following: "This product includes software developed at The Apache Software Foundation (http://www.apache.org/)." The NOTICE file is supposed to be a short as possible so please can you remove the last para? > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 4.1.40 - Take 2
On 16/06/2009, Mark Thomas wrote: > The (updated) candidates source tarball and derived binaries are > available here: > http://tomcat.apache.org/dev/dist/apache-tomcat-4.1.40/ > > According to the release process, the release based on the 4.0.40 tag is: Did you mean 4.1.40? Also, where can I find the tag? > [ ] Broken > [ ] Alpha > [ ] Beta > [ ] Stable > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 4.1.40 - Take 2
On 19/06/2009, Mark Thomas wrote: > sebb wrote: > > On 16/06/2009, Mark Thomas wrote: > >> The (updated) candidates source tarball and derived binaries are > >> available here: > >> http://tomcat.apache.org/dev/dist/apache-tomcat-4.1.40/ > >> > >> According to the release process, the release based on the 4.0.40 tag is: > > > > Did you mean 4.1.40? > > > Yes. > > > > Also, where can I find the tag? > > > It is actually 4 tags (the joys of the Tomcat 4 build process): > http://svn.apache.org/repos/asf/tomcat/connectors/tags/tc4.1.x/TOMCAT_4_1_40/ > http://svn.apache.org/repos/asf/tomcat/container/tags/tc4.1.x/TOMCAT_4_1_40/ > http://svn.apache.org/repos/asf/tomcat/jasper/tags/tc4.1.x/TOMCAT_4_1_40/ > > http://svn.apache.org/repos/asf/tomcat/servletapi/tags/servlet2.3-jsp1.2-tc4.x/TOMCAT_4_1_40/ > Thanks, I used the following SVN URLs + revisions: http://svn.apache.org/repos/asf/tomcat/connectors/tags/tc4.1.x/TOMCAT_4_1_40 Last Changed Rev: 784715 http://svn.apache.org/repos/asf/tomcat/container/tags/tc4.1.x/TOMCAT_4_1_40 Last Changed Rev: 785257 http://svn.apache.org/repos/asf/tomcat/jasper/tags/tc4.1.x/TOMCAT_4_1_40 Last Changed Rev: 784716 http://svn.apache.org/repos/asf/tomcat/servletapi/tags/servlet2.3-jsp1.2-tc4.x/TOMCAT_4_1_40 Last Changed Rev: 784717 The source archives mostly agree with the tags, however there are code changes in the following files: connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java connectors/util/java/org/apache/tomcat/util/buf/CharChunk.java connectors/util/java/org/apache/tomcat/util/http/ServerCookie.java [I can provide a diff listing if required] The tags really ought to agree with the source archive. Unfortunately, I think I have found another problem, which is that the README file needs to mention the TSU exception: http://www.apache.org/dev/crypto.html#inform [This presumably applies to all the later Tomcat versions as well] Sorry, I should have noticed this before as IMO it is a release blocker. There ought really to be NOTICE files alongside the LICENSE files in the jasper and servletapi SVN trees (SVN is a form of distribution). > Mark > > > > > >> [ ] Broken > >> [ ] Alpha > >> [ ] Beta > >> [ ] Stable > >> > >> Mark > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r786631 - /tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java
On 19/06/2009, kkoli...@apache.org wrote:
> Author: kkolinko
> Date: Fri Jun 19 18:57:59 2009
> New Revision: 786631
>
> URL: http://svn.apache.org/viewvc?rev=786631&view=rev
> Log:
> Add two more implementations for the second test.
> a) using a single ThreadLocal instead of multiple ones
> b) also using StringBuilder instead of StringBuffer
> Also, replaced class.getName() with class.getSimpleName() in the status
> message.
>
> Modified:
> tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java
>
> Modified: tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java?rev=786631&r1=786630&r2=786631&view=diff
>
> ==
> --- tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java (original)
> +++ tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java Fri Jun 19
> 18:57:59 2009
> @@ -135,8 +135,8 @@
>
> // note, that we can avoid (long -> Long) conversion
> private static class Struct {
> -long currentMillis = 0;
> -Date currentDate;
> +public long currentMillis = 0;
> +public Date currentDate;
> }
>
> private ThreadLocal currentStruct = new
> ThreadLocal() {
> @@ -165,7 +165,9 @@
> BenchmarkTest benchmark = new BenchmarkTest();
> Runnable[] tests = new Runnable[] {
> new TimeDateElementBenchmarkTest_Sync(),
> -new TimeDateElementBenchmarkTest_Local() };
> +new TimeDateElementBenchmarkTest_Local(),
> +new TimeDateElementBenchmarkTest_LocalStruct(),
> +new TimeDateElementBenchmarkTest_LocalStruct_SBuilder() };
> benchmark.doTest(5, tests);
> }
>
> @@ -285,13 +287,17 @@
> if (currentDateStringLocal.get() == null) {
> StringBuffer current = new StringBuffer(32);
> current.append('[');
> -
> current.append(dayFormatterLocal.get().format(currentDateLocal.get())); // Day
> +current.append(dayFormatterLocal.get().format(
> +currentDateLocal.get())); // Day
> current.append('/');
> -
> current.append(lookup(monthFormatterLocal.get().format(currentDateLocal.get(;
> // Month
> +current.append(lookup(monthFormatterLocal.get().format(
> +currentDateLocal.get(; // Month
> current.append('/');
> -
> current.append(yearFormatterLocal.get().format(currentDateLocal.get())); //
> Year
> +current.append(yearFormatterLocal.get().format(
> +currentDateLocal.get())); // Year
> current.append(':');
> -
> current.append(timeFormatterLocal.get().format(currentDateLocal.get())); //
> Time
> +current.append(timeFormatterLocal.get().format(
> +currentDateLocal.get())); // Time
> current.append(']');
> currentDateStringLocal.set(current.toString());
> }
> @@ -308,6 +314,122 @@
> }
> }
>
> +private static class TimeDateElementBenchmarkTest_LocalStruct extends
> +TimeDateElementBenchmarkTestBase implements Runnable {
> +
> +public String toString() {
> +return "single ThreadLocal";
> +}
> +
> +private static class Struct {
> +public String currentDateString;
> +public Date currentDate = new Date();
> +public SimpleDateFormat dayFormatter = new
> SimpleDateFormat("dd");
> +public SimpleDateFormat monthFormatter = new
> SimpleDateFormat("MM");
> +public SimpleDateFormat yearFormatter = new
> SimpleDateFormat("");
> +public SimpleDateFormat timeFormatter = new SimpleDateFormat(
> +"hh:mm:ss");
> +}
> +
> +private ThreadLocal structLocal = new ThreadLocal()
> {
> +protected Struct initialValue() {
> +return new Struct();
> +}
> +};
> +
> +public void run() {
> +printDate();
> +}
> +
> +public String printDate() {
> +getDateLocal();
> +Struct struct = structLocal.get();
> +if (struct.currentDateString == null) {
> +StringBuffer current = new StringBuffer(32);
> +current.append('[');
> +
> current.append(struct.dayFormatter.format(struct.currentDate)); // Day
> +current.append('/');
> +current.append(lookup(struct.monthFormatter
> +.format(struct.currentDate))); // Month
> +current.append('/');
Re: [VOTE] Release build 4.1.40 - Take 2
On 19/06/2009, Mark Thomas wrote: > sebb wrote: > > The source archives mostly agree with the tags, however there are code > > changes in the following files: > > > > connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java > > connectors/util/java/org/apache/tomcat/util/buf/CharChunk.java > > connectors/util/java/org/apache/tomcat/util/http/ServerCookie.java > > > That happens automatically as part of the build process and is expected. OK, I see. It would be better if the changes were made to temporary copies of the source files, but that's not essential given that the version is rather old. > > [I can provide a diff listing if required] > > > No need, I know exactly what has changed in those files. > > > > Unfortunately, I think I have found another problem, which is that the > > README file needs to mention the TSU exception: > > > > http://www.apache.org/dev/crypto.html#inform > > > > [This presumably applies to all the later Tomcat versions as well] > > > > Sorry, I should have noticed this before as IMO it is a release blocker. > > > Having read http://www.apache.org/dev/crypto.html#inform, it makes clear > that this requirement is self imposed. Therefore I > propose that we take a little bit of latitude and do the following > (assuming this gets the votes to pass) > - include the text in the announcement e-mail > - add the text to the README (post tag) > - put the updated README in the download directory (currently it just > includes the release notes) > > I think this meets the spirit of our self-imposed requirement without > needing to re-roll the release. I'm not 100% convinced. It might be an idea to ask this question on legal-discuss. > What I will do is update those read me files now, so the changes are in > place for the next releases. +1 > > > There ought really to be NOTICE files alongside the LICENSE files in > > the jasper and servletapi SVN trees (SVN is a form of distribution). > > > I think that is a grey area. I see where you are coming from but I don't > propose to do anything about this for the 4.1.40 release. Post the svn > re-org that will follow the final 4.1.x release, we can revisit that. OK, but if there is any need to re-roll the release I think the NOTICE files should be added to SVN. > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r786653 - /tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
On 19/06/2009, ma...@apache.org wrote:
> Author: markt
> Date: Fri Jun 19 20:21:53 2009
> New Revision: 786653
>
> URL: http://svn.apache.org/viewvc?rev=786653&view=rev
> Log:
> Switch to ThreadLocal where possible. This removes all the syncs apart from
> those related to accessing the log file.
>
> Modified:
> tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
>
> Modified: tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java?rev=786653&r1=786652&r2=786653&view=diff
>
> ==
> --- tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
> (original)
> +++ tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java Fri Jun
> 19 20:21:53 2009
> @@ -224,34 +224,6 @@
>
>
> /**
> - * A date formatter to format Dates into a day string in the format
> - * "dd".
> - */
> -private SimpleDateFormat dayFormatter = null;
> -
> -
> -/**
> - * A date formatter to format a Date into a month string in the format
> - * "MM".
> - */
> -private SimpleDateFormat monthFormatter = null;
> -
> -
> -/**
> - * A date formatter to format a Date into a year string in the format
> - * "".
> - */
> -private SimpleDateFormat yearFormatter = null;
> -
> -
> -/**
> - * A date formatter to format a Date into a time in the format
> - * "kk:mm:ss" (kk is a 24-hour representation of the hour).
> - */
> -private SimpleDateFormat timeFormatter = null;
> -
> -
> -/**
> * The system timezone.
> */
> private TimeZone timezone = null;
> @@ -281,9 +253,13 @@
> * The system time when we last updated the Date that this valve
> * uses for log lines.
> */
> -private volatile Date currentDate = null;
> -
> -private volatile long currentMillis = 0;
> +private ThreadLocal currentDate = new ThreadLocal() {
> +protected Date initialValue() {
> +return new Date();
> +}
> +};
> +private ThreadLocal currentDateString =
> +new ThreadLocal();
>
>
> /**
> @@ -760,15 +736,11 @@
> private Date getDate() {
> // Only create a new Date once per second, max.
> long systime = System.currentTimeMillis();
> -if ((systime - currentMillis) > 1000) {
> -synchronized (this) {
> -if ((systime - currentMillis) > 1000) {
> -currentDate = new Date(systime);
> -currentMillis = systime;
> -}
> -}
> +if ((systime - currentDate.get().getTime()) > 1000) {
> +currentDate.get().setTime(systime);
> +currentDateString.set(null);
> }
> -return currentDate;
> +return currentDate.get();
> }
>
>
> @@ -864,16 +836,7 @@
> fileDateFormat = "-MM-dd";
> fileDateFormatter = new SimpleDateFormat(fileDateFormat);
> fileDateFormatter.setTimeZone(timezone);
> -dayFormatter = new SimpleDateFormat("dd");
> -dayFormatter.setTimeZone(timezone);
> -monthFormatter = new SimpleDateFormat("MM");
> -monthFormatter.setTimeZone(timezone);
> -yearFormatter = new SimpleDateFormat("");
> -yearFormatter.setTimeZone(timezone);
> -timeFormatter = new SimpleDateFormat("HH:mm:ss");
> -timeFormatter.setTimeZone(timezone);
> -currentDate = new Date();
> -dateStamp = fileDateFormatter.format(currentDate);
> +dateStamp = fileDateFormatter.format(currentDate.get());
> open();
> }
>
> @@ -927,20 +890,21 @@
> */
> protected class LocalAddrElement implements AccessLogElement {
>
> -private String value = null;
> +private ThreadLocal value = new ThreadLocal() {
> +protected String initialValue() {
> +String init;
> +try {
> +init = InetAddress.getLocalHost().getHostAddress();
> +} catch (Throwable e) {
> +init = "127.0.0.1";
> +}
> +return init;
> +}
> +};
Surely the value will be the same for all threads?
In which case, it could be established as a static final field, thus
avoiding any need to synch or use threadLocal.
If you want avoid the overhead of calling the method in case it is not
used, one could use the Init On Demand Holder idiom.
> public void addElement(StringBuffer buf, Date date, Request request,
> Response response, long time) {
> -if (value == null) {
> -synchronized (this) {
> -try {
> -value = InetAddress.getLocalHos
Re: svn commit: r787211 - /tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java
On 22/06/2009, ma...@apache.org wrote:
> Author: markt
> Date: Mon Jun 22 11:58:07 2009
> New Revision: 787211
>
> URL: http://svn.apache.org/viewvc?rev=787211&view=rev
> Log:
> Fix a couple of Eclipse warnings
>
> Modified:
> tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java
>
> Modified: tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java?rev=787211&r1=787210&r2=787211&view=diff
>
> ==
> --- tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java (original)
> +++ tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java Mon Jun 22
> 11:58:07 2009
> @@ -88,8 +88,7 @@
> // You can customize the context by calling
> // its API
>
> -tomcat.addServlet(ctx, "myServlet",
> -new HelloWorld());
> +Tomcat.addServlet(ctx, "myServlet", new HelloWorld());
Looks a bit odd - are there really both "tomcat" and "Tomcat" objects/classes?
> ctx.addServletMapping("/", "myServlet");
>
> tomcat.start();
If so, is this the correct cat?
> @@ -103,9 +102,7 @@
> File appDir =
> new File(base + "output/build/webapps/examples");
> // app dir is relative to server home
> -StandardContext ctx =
> -tomcat.addWebapp(null, "/examples",
> -appDir.getAbsolutePath());
> +tomcat.addWebapp(null, "/examples", appDir.getAbsolutePath());
>
> tomcat.start();
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Please review JDBC Pool before vote
On 22/06/2009, Filip Hanik - Dev Lists wrote: > in the spirit of trying to get my poop right, > > http://people.apache.org/~fhanik/jdbc-pool/v1.0.5/ Looks a lot better. > the binary releases contain everything in individual jar files (including > source references for IDEs) However, there are no N & L files in the jars. As these are likely to be independently deployed, the L&N really ought to be present in the jars. > the source release is "as is" from our repo, with the ability to build by > using > ant download build That's much better, and the Ant build file generally works well. However, it's not easy finding out how to build and test the source release, as the information is buried in an XML file. I think there should be a README or BUILDING text file in the top-level directory which includes simple instructions to build and test. This should include details of Java version etc, and any other software that is required, e.g. database. Most of the required info is in the XML file; it could be moved into the text file. Some of the tests fail; I assume that is because I am not running MySQL, but this requirement does not appear to be described anywhere, and there are no details of what (if anything) needs to be set up in the MySQL database (logins, tables, etc.). The Ant "dist" target adds the build.properties file (if present) to the source archive; I don't think it should do this as it may contain host-specific information. > Filip > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release JDBC Pool module v1.0.5
On 24/06/2009, Filip Hanik - Dev Lists wrote: > Cleaned up and fixed. > > The release is located here: > http://people.apache.org/~fhanik/jdbc-pool/v1.0.5/ Exactly the same path names were used previously; I assume you are referring to the following versions of the files: apache-tomcat-jdbc-1.0.5-bin.tar.gz.md5:808cf400c4f7f4de7294b844c68108fa apache-tomcat-jdbc-1.0.5-bin.zip.md5:3f20849d6b0dbe29bb9707cd519c456c apache-tomcat-jdbc-1.0.5-src.tar.gz.md5:6a63d1e77c47c5d6385cf680dac4514c apache-tomcat-jdbc-1.0.5-src.zip.md5:7b4870d50e498a18014031589b8a88eb rather than the older ones: apache-tomcat-jdbc-1.0.5-bin.tar.gz.md5:b6081e6d34a8e9ecd70b505c90e73485 apache-tomcat-jdbc-1.0.5-bin.zip.md5:76cb2efd7ce7093d71e4a989e71d2874 apache-tomcat-jdbc-1.0.5-src.tar.gz.md5:d8d08870f3479080582d3261a4d1afe5 apache-tomcat-jdbc-1.0.5-src.zip.md5:cc6992ff33524f15052f9b72588b628f == The source and test source archives contain META-INF/MANIFEST.MF files which don't belong in a source archive. The binary archives contain MD5 hashes of all but one of the jars; again, these don't belong in the archives. The jars should contain NOTICE and LICENSE files. There's no easily accessible documentation on how to build and test the code. If someone is familiar with Ant, they can work out what the targets do, but the user should not have to do this. The ant script automatically downloads jars, some of which don't have Apache Licenses. In particular, the MySQL licence appears to be GPL, which is not compatible with the AL. AFAICT, this is specifically forbidden: http://www.apache.org/legal/3party.html#options-build-may2 The "ant test" target generates a few warnings, e.g. WARNING: Database connection pool evicter thread interval is set to lower than 1 second. Several of the tests fail. There's no documentation on what database needs to be set up in order to run the database tests so I don't know if these are due to failure to set up the database correctly or whether the test failures were nothing to do with the database. Ideally, the user should be given the option of running the JDBC tests against whatever database they prefer. If the tests require tables etc to be set up, these should either be done as part of the test setup, or there should be clear documentation on what data needs to be set up. > > [ ] STABLE - I couldn't find any bugs > [ ] BETA - I found some bugs but not critical > [ ] BROKEN - I found some show stoppers > > > Any comments ? > > Thanks, > Filip > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release JDBC Pool module v1.0.5
On 26/06/2009, Filip Hanik - Dev Lists wrote: > sebb wrote: > > > On 24/06/2009, Filip Hanik - Dev Lists wrote: > > > > > > > Cleaned up and fixed. > > > > > > The release is located here: > > > http://people.apache.org/~fhanik/jdbc-pool/v1.0.5/ > > > > > > > > > > Exactly the same path names were used previously; I assume you are > > referring to the following versions of the files: > > > > > apache-tomcat-jdbc-1.0.5-bin.tar.gz.md5:808cf400c4f7f4de7294b844c68108fa > > > apache-tomcat-jdbc-1.0.5-bin.zip.md5:3f20849d6b0dbe29bb9707cd519c456c > > > apache-tomcat-jdbc-1.0.5-src.tar.gz.md5:6a63d1e77c47c5d6385cf680dac4514c > > > apache-tomcat-jdbc-1.0.5-src.zip.md5:7b4870d50e498a18014031589b8a88eb > > > > rather than the older ones: > > > > > apache-tomcat-jdbc-1.0.5-bin.tar.gz.md5:b6081e6d34a8e9ecd70b505c90e73485 > > > apache-tomcat-jdbc-1.0.5-bin.zip.md5:76cb2efd7ce7093d71e4a989e71d2874 > > > apache-tomcat-jdbc-1.0.5-src.tar.gz.md5:d8d08870f3479080582d3261a4d1afe5 > > > apache-tomcat-jdbc-1.0.5-src.zip.md5:cc6992ff33524f15052f9b72588b628f > > > > == > > > > The source and test source archives contain META-INF/MANIFEST.MF files > > which don't belong in a source archive. > > > > > these are fine. > > > The binary archives contain MD5 hashes of all but one of the jars; > > again, these don't belong in the archives. > > > > The jars should contain NOTICE and LICENSE files. > > > > > no they should not. I think I've told you before, that NOTICE and LICENSE > files are for a release, not for individual files within a release. > > > There's no easily accessible documentation on how to build and test the > code. > > If someone is familiar with Ant, they can work out what the targets > > do, but the user should not have to do this. > > > > The ant script automatically downloads jars, some of which don't have > > Apache Licenses. In particular, the MySQL licence appears to be GPL, > > which is not compatible with the AL. > > > > > yes, I will remove this. > > > AFAICT, this is specifically forbidden: > > > > > http://www.apache.org/legal/3party.html#options-build-may2 > > > > The "ant test" target generates a few warnings, e.g. > > > > WARNING: Database connection pool evicter thread interval is set to > > lower than 1 second. > > > > Several of the tests fail. > > > > > I will remove all tests. It was a bad idea to include to begin with, since > they are not part of the release either. > > > There's no documentation on what database needs to be set up in order > > to run the database tests so I don't know if these are due to failure > > to set up the database correctly or whether the test failures were > > nothing to do with the database. > > > > > that will be solved when the tests go away In which case, how can reviewers test the code? That is not the solution either. It should be fairly easy to remove the dependency on MySQL and c3p0 - if not, then IMO the tests are too specific, as Tomcat DBCP should work with any JDBC provider. As an experiment, I tried using Derby instead of MySQL, and most of the tests worked. [I'm not yet sure why some tests failed. Unfortunately the output gives no clue to me.] I suggest changing the Ant test classpath to include whatever jars it finds in the include directory, and change the test code to pick up the database settings from build.properties Then all a tester has to do is put their JDBC jar in the directory and set up the database as required. > > > Ideally, the user should be given the option of running the JDBC tests > > against whatever database they prefer. If the tests require tables etc > > to be set up, these should either be done as part of the test setup, > > or there should be clear documentation on what data needs to be set > > up. > > > > > > > > > > > > [ ] STABLE - I couldn't find any bugs > > > [ ] BETA - I found some bugs but not critical > > > [ ] BROKEN - I found some show stoppers > > > > > > > > > Any comments ? > > > > > > Thanks, > > > Filip > > > > > > > - > > > To unsubscribe, e-mail: > dev-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release JDBC Pool module v1.0.5
On 26/06/2009, Filip Hanik - Dev Lists wrote: > sebb wrote: > > > On 26/06/2009, Filip Hanik - Dev Lists wrote: > > > > > > > sebb wrote: > > > > > > > > > > > > > On 24/06/2009, Filip Hanik - Dev Lists wrote: > > > > > > > > > > > > > > > > > > > > > Cleaned up and fixed. > > > > > > > > > > The release is located here: > > > > > http://people.apache.org/~fhanik/jdbc-pool/v1.0.5/ > > > > > > > > > > > > > > > > > > > > > > > > Exactly the same path names were used previously; I assume you are > > > > referring to the following versions of the files: > > > > > > > > > > > > > > > > > > > > apache-tomcat-jdbc-1.0.5-bin.tar.gz.md5:808cf400c4f7f4de7294b844c68108fa > > > > apache-tomcat-jdbc-1.0.5-bin.zip.md5:3f20849d6b0dbe29bb9707cd519c456c > > > > apache-tomcat-jdbc-1.0.5-src.tar.gz.md5:6a63d1e77c47c5d6385cf680dac4514c > > > > apache-tomcat-jdbc-1.0.5-src.zip.md5:7b4870d50e498a18014031589b8a88eb > > > > > > > > > > rather than the older ones: > > > > > > > > > > > > > > > > > > > > apache-tomcat-jdbc-1.0.5-bin.tar.gz.md5:b6081e6d34a8e9ecd70b505c90e73485 > > > > apache-tomcat-jdbc-1.0.5-bin.zip.md5:76cb2efd7ce7093d71e4a989e71d2874 > > > > apache-tomcat-jdbc-1.0.5-src.tar.gz.md5:d8d08870f3479080582d3261a4d1afe5 > > > > apache-tomcat-jdbc-1.0.5-src.zip.md5:cc6992ff33524f15052f9b72588b628f > > > > > > > > > > == > > > > > > > > The source and test source archives contain META-INF/MANIFEST.MF files > > > > which don't belong in a source archive. > > > > > > > > > > > > > > > > > > > these are fine. > > > > > > > > > > > > > The binary archives contain MD5 hashes of all but one of the jars; > > > > again, these don't belong in the archives. > > > > > > > > The jars should contain NOTICE and LICENSE files. > > > > > > > > > > > > > > > > > > > no they should not. I think I've told you before, that NOTICE and > LICENSE > > > files are for a release, not for individual files within a release. > > > > > > > > > > > > > There's no easily accessible documentation on how to build and test > the > > > > > > > > > > > code. > > > > > > > > > > If someone is familiar with Ant, they can work out what the targets > > > > do, but the user should not have to do this. > > > > > > > > The ant script automatically downloads jars, some of which don't have > > > > Apache Licenses. In particular, the MySQL licence appears to be GPL, > > > > which is not compatible with the AL. > > > > > > > > > > > > > > > > > > > yes, I will remove this. > > > > > > > > > > > > > AFAICT, this is specifically forbidden: > > > > > > > > > > > > > > > > > > > > http://www.apache.org/legal/3party.html#options-build-may2 > > > > > > > > > > The "ant test" target generates a few warnings, e.g. > > > > > > > > WARNING: Database connection pool evicter thread interval is set to > > > > lower than 1 second. > > > > > > > > Several of the tests fail. > > > > > > > > > > > > > > > > > > > I will remove all tests. It was a bad idea to include to begin with, > since > > > they are not part of the release either. > > > > > > > > > > > > > There's no documentation on what database needs to be set up in order > > > > to run the database tests so I don't know if these are due to failure > > > > to set up the database correctly or whether the test failures were > > > > nothing to do with the database. > > > > > > > > > > > > > > > > > > > that will be solved when the tests go away > > > > > > > > > > In which case, how can reviewers test the code? > > > > > you misunderstand "test the code". When you test a car, do yo
Re: [VOTE] Release JDBC Pool module v1.0.5
When testing with Derby on Java 1.6.0 I get the following error: [junit] Running org.apache.tomcat.jdbc.test.StarvationTest [junit] Testsuite: org.apache.tomcat.jdbc.test.StarvationTest [junit] AbandonedObjectPool is used (org.apache.tomcat.dbcp.dbcp.abandonedobjectp...@1d6096) [junit]LogAbandoned: true [junit]RemoveAbandoned: true [junit]RemoveAbandonedTimeout: 5 [junit] 26-Jun-2009 18:33:20 org.apache.tomcat.jdbc.pool.ConnectionPool$PoolCleaner [junit] WARNING: Database connection pool evicter thread interval is set to lower than 1 second. [junit] 26-Jun-2009 18:33:20 org.apache.tomcat.jdbc.pool.ConnectionPool init [junit] WARNING: minIdle is larger than maxActive, setting minIdle to: 1 [junit] 26-Jun-2009 18:33:26 org.apache.tomcat.jdbc.pool.ConnectionPool abandon [junit] WARNING: Connection has been abandoned pooledconnection[org.apache.derby.client.net.netconnectio...@7bd9f2]:java.lang.Exception [junit] at org.apache.tomcat.jdbc.pool.ConnectionPool.getThreadDump(ConnectionPool.java:781) [junit] at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:566) [junit] at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:459) [junit] at org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:138) [junit] at org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:96) [junit] at org.apache.tomcat.jdbc.test.StarvationTest.testConnectionStarvation(StarvationTest.java:77) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at junit.framework.TestCase.runTest(TestCase.java:164) [junit] at junit.framework.TestCase.runBare(TestCase.java:130) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:120) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:230) [junit] at junit.framework.TestSuite.run(TestSuite.java:225) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768) [junit] [junit] 26-Jun-2009 18:33:27 org.apache.tomcat.jdbc.pool.ConnectionPool$PoolCleaner [junit] WARNING: Database connection pool evicter thread interval is set to lower than 1 second. [junit] 26-Jun-2009 18:33:27 org.apache.tomcat.jdbc.pool.ConnectionPool init [junit] WARNING: minIdle is larger than maxActive, setting minIdle to: 1 [junit] 26-Jun-2009 18:33:32 org.apache.tomcat.jdbc.pool.ConnectionPool abandon [junit] WARNING: Connection has been abandoned pooledconnection[org.apache.derby.client.net.netconnectio...@50d89c]:java.lang.Exception [junit] at org.apache.tomcat.jdbc.pool.ConnectionPool.getThreadDump(ConnectionPool.java:781) [junit] at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:566) [junit] at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:459) [junit] at org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:138) [junit] at org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:96) [junit] at org.apache.tomcat.jdbc.test.StarvationTest.testFairConnectionStarvation(StarvationTest.java:98) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at junit.framework.TestCase.runTest(TestCase.java:164) [junit] at junit.framework.TestCase.runBare(TestCase.java:130) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:120) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:230) [junit] at junit.framework.TestSuite.run(TestSuite.java:225)
Re: svn commit: r788214 - /tomcat/current/tc5.5.x/STATUS.txt
On 27/06/2009, Xie Xiaodong wrote: > But how could ThreadLocal be shared among all AccessLogValve instances on > the same server? After all, each thread access ThreadLocal has its own. > > Another point, based on the java doc of ThreadLocal, maybe "private > ThreadLocal currentDateStruct" should be declared as > static? +1, that should ensure that it will be shared. Also it should be declared final. > > 2009/6/27 Konstantin Kolinko > > > > Mark Thomas wrote: > > >Konstantin Kolinko wrote: > > >> 2. struct.currentDateString is calculated in two different places > > >> I propose to encapsulate that code into AccessDateStruct > > >> > > >> 3. Invocation of getDate() in invoke() (the only place where getDate() > > >> is called): > > >> I think that getDate() also can be incapsulated into AccessDateStruct. > > >> Actually, I think of the following: > > >> 1) In invoke() there is already a variable that stores current time > > >> millis: "t2" > > >> I propose to replace that getDate() with > > >> AccessDateStruct.setDate(t2) that will perform the same job. > > >> 2) Change the signature of replace(..., Date, ..) method, and pass a > > >> reference to the AccessDateStruct instead of a Date. > > >> In the future the replace(..) methods of this class can be changed to > > >> accept a StringBuffer, instead of returning a String, but that can be > > >> another story. > > >> > > >> If AccessDateStruct is passed into the replace() method, > > >> timeTakenFormatter can be added to it as well. Maybe. > > >> > > >> 4. The log() method still creates a new Date() once in a second. > > >> The Date instance can be stored in some member variable and reused. It > > >> is in a synchronized block, so it will be safe. > > >> I do not like, that it is the same once-in-a-second synchronized > > >> block, that we already avoided once by using those ThreadLocals. > > >> Can be addressed separately, though. > > > > > > Thanks for this. I'll see about updating the patch. > > > > > > > One more thought: > > It would be better if the ThreadLocal is shared among all > > AccessLogValve instances on the same server. Otherwise, the count of > > threads will be multiplied by the count of AccessLogValve instances. > > > > That implies that the AccessDateStruct does not have any configurable > > parameters or any valve instance specific data. > > E.g., fileDateFormat is configurable, thus its formatter is not a > > candidate to be put there (and it is not there now). > > > > >> I do not like, that it is the same once-in-a-second synchronized > > >> block, that we already avoided > > I was not right writing this. We avoided sync around the formatters on > > every call, and that makes a difference. > > We already have sync in the writer on every call, so this sync > > once-in-a second won't be something noticeable. Though maybe it can be > > done once in 5/20/60 secs, but who cares. > > > > Best regards, > > Konstantin Kolinko > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > -- > Sincerely yours and Best Regards, > > Xie Xiaodong > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release JDBC Pool module v1.0.5
I've just realised that there is no Javadoc in any of the archives. The only documentation is in the form of a web-page, which is fine as far as it goes, but is really not enough for a general-purpose library. I would expect to see the Javadoc included in binary releases. On 24/06/2009, Filip Hanik - Dev Lists wrote: > Cleaned up and fixed. > > The release is located here: > http://people.apache.org/~fhanik/jdbc-pool/v1.0.5/ > > > [ ] STABLE - I couldn't find any bugs > [ ] BETA - I found some bugs but not critical > [ ] BROKEN - I found some show stoppers > > > Any comments ? > > Thanks, > Filip > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r789392 - in /tomcat/trunk/modules/jdbc-pool: ./ test/org/apache/tomcat/jdbc/test/
On 29/06/2009, fha...@apache.org wrote: > Author: fhanik > Date: Mon Jun 29 17:38:21 2009 > New Revision: 789392 > > URL: http://svn.apache.org/viewvc?rev=789392&view=rev > Log: > Remove all usage of GPL or LGPL downloads. +1, thanks. > Use H2 for test database (EPL1.0) as it can be downloaded and easily > embedded. Why not just leave it to the tester to decide which database to use? All they need to do is to provide the JDBC jar, and pass the details to the build.xml file. That way, the build file can be generic, allowing the code to be tested easily against many different databases if required. > Derby didn't work, too slow to populate test data with. Did you try embedded Derby? Just curious. > Add Javadoc per Sebb's suggestion. The source files need updating too, as the Javadoc there is rather sparse. > Add EPL and CPL to LICENSE since we use it in the unit test cases. > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r789392 - in /tomcat/trunk/modules/jdbc-pool: ./ test/org/apache/tomcat/jdbc/test/
On 29/06/2009, sebb wrote: > On 29/06/2009, fha...@apache.org wrote: > > Author: fhanik > > Date: Mon Jun 29 17:38:21 2009 > > New Revision: 789392 > > > > URL: http://svn.apache.org/viewvc?rev=789392&view=rev > > Log: > > Remove all usage of GPL or LGPL downloads. > > > +1, thanks. > > > > Use H2 for test database (EPL1.0) as it can be downloaded and easily > embedded. > > > Why not just leave it to the tester to decide which database to use? > > All they need to do is to provide the JDBC jar, and pass the details > to the build.xml file. > > That way, the build file can be generic, allowing the code to be > tested easily against many different databases if required. > > > > Derby didn't work, too slow to populate test data with. > > > Did you try embedded Derby? Just curious. > > > > Add Javadoc per Sebb's suggestion. > > > The source files need updating too, as the Javadoc there is rather sparse. > > > > Add EPL and CPL to LICENSE since we use it in the unit test cases. > > > Just realised: since H2 is not included with the release artifacts - nor stored in SVN - the EPL should not be included in LICENSE. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r789714 - in /tomcat: container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/FastAsyncSocketSender.java container/tc5.5.x/webapps/docs/changelog.xml current/tc5.5
On 30/06/2009, rj...@apache.org wrote:
> Author: rjung
> Date: Tue Jun 30 13:26:10 2009
> New Revision: 789714
>
> URL: http://svn.apache.org/viewvc?rev=789714&view=rev
> Log:
> Separate statistics counter lock in FastAsyncSocketSender
> from inherited DataSender lock to reduce blocking during
> failed node detection.
>
> Backport of http://svn.apache.org/viewvc?rev=759694&view=rev
> from OACC to tc5.5.x.
>
> Modified:
>
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/FastAsyncSocketSender.java
> tomcat/container/tc5.5.x/webapps/docs/changelog.xml
> tomcat/current/tc5.5.x/STATUS.txt
>
> Modified:
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/FastAsyncSocketSender.java
> URL:
> http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/FastAsyncSocketSender.java?rev=789714&r1=789713&r2=789714&view=diff
>
> ==
> ---
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/FastAsyncSocketSender.java
> (original)
> +++
> tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/tcp/FastAsyncSocketSender.java
> Tue Jun 30 13:26:10 2009
> @@ -91,6 +91,13 @@
>
> private int threadPriority = Thread.NORM_PRIORITY;;
>
> +/**
> + * Separate mutex for our local state.
> + * We keep the synchronization independent of the synchronization
> + * in the super class DataSender.
> + */
> +private Object mutex = new Object();
Should be final as well to indicate that it must never be changed and
to ensure safe publication across threads.
> // -
> Constructor
>
> /**
> @@ -353,7 +360,7 @@
> public void sendMessage(ClusterData data)
> throws java.io.IOException {
> queue.add(data.getUniqueId(), data);
> -synchronized (this) {
> +synchronized (mutex) {
> inQueueCounter++;
> if(queueThread != null)
> queueThread.incQueuedNrOfBytes(data.getMessage().length);
> @@ -455,15 +462,15 @@
> return queuedNrOfBytes;
> }
>
> -protected synchronized void setQueuedNrOfBytes(long
> queuedNrOfBytes) {
> +protected void setQueuedNrOfBytes(long queuedNrOfBytes) {
> this.queuedNrOfBytes = queuedNrOfBytes;
> }
>
> -protected synchronized void incQueuedNrOfBytes(long size) {
> +protected void incQueuedNrOfBytes(long size) {
> queuedNrOfBytes += size;
> }
>
> -protected synchronized void decQueuedNrOfBytes(long size) {
> +protected void decQueuedNrOfBytes(long size) {
> queuedNrOfBytes -= size;
> }
>
> @@ -561,8 +568,10 @@
> .getKey()), x);
> }
> } finally {
> -outQueueCounter++;
> -decQueuedNrOfBytes(messagesize);
> +synchronized (sender.mutex) {
> +outQueueCounter++;
> +decQueuedNrOfBytes(messagesize);
> +}
> }
> entry = entry.next();
> } while (keepRunning && entry != null);
>
> Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=789714&r1=789713&r2=789714&view=diff
>
> ==
> --- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
> +++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Tue Jun 30 13:26:10
> 2009
> @@ -195,6 +195,10 @@
>
>
>
> + Separate statistics counter lock in FastAsyncSocketSender from
> inherited
> + DataSender lock to reduce blocking during failed node detection.
> (rjung)
> +
> +
> Handle situation session ID rewriting on fail-over with parallel
> requests
> from the same client. (pero)
>
>
> Modified: tomcat/current/tc5.5.x/STATUS.txt
> URL:
> http://svn.apache.org/viewvc/tomcat/current/tc5.5.x/STATUS.txt?rev=789714&r1=789713&r2=789714&view=diff
>
> ==
> --- tomcat/current/tc5.5.x/STATUS.txt (original)
> +++ tomcat/current/tc5.5.x/STATUS.txt Tue Jun 30 13:26:10 2009
> @@ -33,17 +33,6 @@
>-1: markt (see https://issues.apache.org/bugzilla/show_bug.cgi?id=47308)
>kkolinko: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4686717
>
> -* Fix locking in cluster/tcp/FastAsyncSocketSender:
> - Locking in DataSender and the sub class FastAsyncSocketSender
> - uses the same lock, although the reasons for l
Re: svn commit: r789883 - in /tomcat/trunk/modules/jdbc-pool: build.properties.default build.xml
On 30/06/2009, fha...@apache.org wrote:
> Author: fhanik
> Date: Tue Jun 30 19:15:28 2009
> New Revision: 789883
>
> URL: http://svn.apache.org/viewvc?rev=789883&view=rev
> Log:
> Apply patch by sebb from
> https://issues.apache.org/bugzilla/show_bug.cgi?id=47458
> Store db properties in build.properties using a prefix of testdb
>
> Modified:
> tomcat/trunk/modules/jdbc-pool/build.properties.default
> tomcat/trunk/modules/jdbc-pool/build.xml
>
> Modified: tomcat/trunk/modules/jdbc-pool/build.properties.default
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/build.properties.default?rev=789883&r1=789882&r2=789883&view=diff
>
> ==
> --- tomcat/trunk/modules/jdbc-pool/build.properties.default (original)
> +++ tomcat/trunk/modules/jdbc-pool/build.properties.default Tue Jun 30
> 19:15:28 2009
> @@ -41,6 +41,27 @@
> compile.target=1.5
> compile.debug=true
>
> +# - Settings for Junit test database.
> +
> +# Common settings
> +testdb.username=root
> +testdb.password=password
> +
> +# H2
> +testdb.url=jdbc:h2x:~/.h2/test;QUERY_TIMEOUT=0;DB_CLOSE_ON_EXIT=FALSE
Oops, sorry, I was testing the code to ensure that the properties were
picked up OK, and accidentally left in an error:
":h2x:" should be ":h2:"
otherwise tests will fail.
> +testdb.driverClassName=org.h2.Driver
> +testdb.validationQuery=SELECT 1
> +
> +# MySQL
> +#testdb.url=jdbc:mysql://localhost:3306/mysql?autoReconnect=true
> +#testdb.driverClassName=com.mysql.jdbc.Driver
> +#testdb.validationQuery=SELECT 1
> +
> +# Derby
> +#testdb.url=jdbc:derby:derbyDB;create=true
> +#testdb.driverClassName=org.apache.derby.jdbc.EmbeddedDriver
> +#testdb.validationQuery=VALUES 1
> +
> # - JUnit Unit Test Suite, version 3.7 or later -
> junit.home=${base.path}/junit3.8.2
> junit.lib=${junit.home}
>
> Modified: tomcat/trunk/modules/jdbc-pool/build.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/build.xml?rev=789883&r1=789882&r2=789883&view=diff
>
> ==
> --- tomcat/trunk/modules/jdbc-pool/build.xml (original)
> +++ tomcat/trunk/modules/jdbc-pool/build.xml Tue Jun 30 19:15:28 2009
> @@ -367,10 +367,17 @@
>
>
>
> +
> +
> +
> +
> +
> +
>
>
> Creating test table for test purposes.
>
> +
>
>
>
> @@ -383,6 +390,7 @@
>
> Performance and fairness tests.
>
> +
>
>
>
> @@ -398,6 +406,7 @@
>
> Functional tests.
>
> +
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r790155 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/session/ catalina/src/share/org/apache/catalina/valves/ webapps/docs/ webapps/docs/config/
On 01/07/2009, ma...@apache.org wrote:
> Author: markt
> Date: Wed Jul 1 13:19:15 2009
> New Revision: 790155
>
> URL: http://svn.apache.org/viewvc?rev=790155&view=rev
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=43343
> Port of r656751, r778523, r778524, r784453 and r784602
> Because, unlike 6.0.x, accessCount is not atomic I made it volatile and
> sync'd the updates.
>
> Modified:
>
> tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java
>
> tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/StandardSession.java
>
> tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/PersistentValve.java
> tomcat/container/tc5.5.x/webapps/docs/changelog.xml
> tomcat/container/tc5.5.x/webapps/docs/config/manager.xml
>
> Modified:
> tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java
> URL:
> http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java?rev=790155&r1=790154&r2=790155&view=diff
>
> ==
> ---
> tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java
> (original)
> +++
> tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java
> Wed Jul 1 13:19:15 2009
> @@ -590,6 +590,23 @@
> public Session findSession(String id) throws IOException {
>
> Session session = super.findSession(id);
> +// OK, at this point, we're not sure if another thread is trying to
> +// remove the session or not so the only way around this is to lock
> it
> +// (or attempt to) and then try to get it by this session id again.
> If
> +// the other code ran swapOut, then we should get a null back during
> +// this run, and if not, we lock it out so we can access the session
> +// safely.
> +if(session != null) {
> +synchronized(session){
> +session = super.findSession(session.getIdInternal());
Not sure this will work correctly, as you are changing the lock in the
middle of a synch. block. This looks very much like another instance
of https://issues.apache.org/bugzilla/show_bug.cgi?id=46990
> +if(session != null){
> + // To keep any external calling code from messing up the
> + // concurrency.
> + session.access();
> + session.endAccess();
> +}
> +}
> +}
> if (session != null)
> return (session);
>
> @@ -797,6 +814,9 @@
> ((StandardSession)session).tellNew();
> add(session);
> ((StandardSession)session).activate();
> +// endAccess() to ensure timeouts happen correctly.
> +// access() to keep access count correct or it will end up negative
> +session.access();
> session.endAccess();
>
> return (session);
> @@ -1023,24 +1043,28 @@
> long timeNow = System.currentTimeMillis();
>
> // Swap out all sessions idle longer than maxIdleSwap
> -// FIXME: What's preventing us from mangling a session during
> -// a request?
> if (maxIdleSwap >= 0) {
> for (int i = 0; i < sessions.length; i++) {
> StandardSession session = (StandardSession) sessions[i];
> -if (!session.isValid())
> -continue;
> -int timeIdle = // Truncate, do not round up
> -(int) ((timeNow - session.getLastAccessedTime()) /
> 1000L);
> -if (timeIdle > maxIdleSwap && timeIdle > minIdleSwap) {
> -if (log.isDebugEnabled())
> -log.debug(sm.getString
> -("persistentManager.swapMaxIdle",
> - session.getIdInternal(), new
> Integer(timeIdle)));
> -try {
> -swapOut(session);
> -} catch (IOException e) {
> -; // This is logged in writeSession()
> +synchronized (session) {
> +if (!session.isValid())
> +continue;
> +int timeIdle = // Truncate, do not round up
> +(int) ((timeNow - session.getLastAccessedTime()) /
> 1000L);
> +if (timeIdle > maxIdleSwap && timeIdle > minIdleSwap) {
> +if (session.accessCount > 0) {
> +// Session is currently being accessed - skip it
> +continue;
> +}
> +if (log.isDebugEnabled())
> +
Re: svn commit: r790693 - /tomcat/trunk/modules/jdbc-pool/build.xml
On 02/07/2009, fha...@apache.org wrote: > Author: fhanik > Date: Thu Jul 2 17:35:26 2009 > New Revision: 790693 > > URL: http://svn.apache.org/viewvc?rev=790693&view=rev > Log: > break out javadoc into its own target > > Modified: > tomcat/trunk/modules/jdbc-pool/build.xml > > Modified: tomcat/trunk/modules/jdbc-pool/build.xml > URL: > http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/build.xml?rev=790693&r1=790692&r2=790693&view=diff > > == > --- tomcat/trunk/modules/jdbc-pool/build.xml (original) > +++ tomcat/trunk/modules/jdbc-pool/build.xml Thu Jul 2 17:35:26 2009 > @@ -85,6 +85,14 @@ > > > > + > + verbose="false"/> Needs classpath to avoid generating errors for 3rd party classes. > + > + > + > + > + > + > > > > @@ -98,8 +106,6 @@ > > > > - verbose="false"/> > - > > > > @@ -116,11 +122,6 @@ > > > > - > - > - > - > - > > > > @@ -187,7 +188,7 @@ > > > > - > + > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r790684 - /tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
On 02/07/2009, fha...@apache.org wrote:
> Author: fhanik
> Date: Thu Jul 2 17:08:50 2009
> New Revision: 790684
>
> URL: http://svn.apache.org/viewvc?rev=790684&view=rev
> Log:
> Add some doco, make shared variables volatile
>
> Modified:
>
> tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
>
> Modified:
> tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java?rev=790684&r1=790683&r2=790684&view=diff
>
> ==
> ---
> tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
> (original)
> +++
> tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
> Thu Jul 2 17:08:50 2009
> @@ -48,17 +48,28 @@
> */
>
> public class ConnectionPool {
> +/**
> + * Prefix type for JMX registration
> + */
> public static final String POOL_JMX_TYPE_PREFIX = "tomcat.jdbc:type=";
>
> -//logger
> +/**
> + * Logger
> + */
> protected static Log log = LogFactory.getLog(ConnectionPool.class);
>
>
> //===
> // INSTANCE/QUICK ACCESS VARIABLE
>
> //===
> +/**
> + * Carries the size of the pool, instead of relying on a queue
> implementation
> + * that usually iterates over to get an exact count
> + */
> private AtomicInteger size = new AtomicInteger(0);
> +
> /**
> * All the information about the connection pool
> + * These are the properties the pool got instantiated with
> */
> private PoolProperties poolProperties;
>
> @@ -76,12 +87,12 @@
> /**
> * The thread that is responsible for checking abandoned and idle threads
> */
> -private PoolCleaner poolCleaner;
> +private volatile PoolCleaner poolCleaner;
>
> /**
> * Pool closed flag
> */
> -private boolean closed = false;
> +private volatile boolean closed = false;
>
> /**
> * Since newProxyInstance performs the same operation, over and over
> @@ -95,7 +106,7 @@
> private ThreadPoolExecutor cancellator = new
> ThreadPoolExecutor(0,1,1000,TimeUnit.MILLISECONDS,new
> LinkedBlockingQueue());
>
> /**
> - * reference to mbean
> + * reference to the JMX mbean
> */
> protected org.apache.tomcat.jdbc.pool.jmx.ConnectionPool jmxPool = null;
>
> @@ -119,6 +130,14 @@
> }
>
>
> +/**
> + * Retrieves a Connection future. If a connection is not available, one
> can block using future.get()
> + * until a connection has become available.
> + * If a connection is not retrieved, the Future must be cancelled in
> order for the connection to be returned
> + * to the pool.
> + * @return
What does it return?
> + * @throws SQLException
> + */
> public Future getConnectionAsync() throws SQLException {
> if (idle instanceof FairBlockingQueue) {
> Future pcf =
> ((FairBlockingQueue)idle).pollAsync();
> @@ -130,7 +149,7 @@
>
> /**
> * Borrows a connection from the pool
> - * @return Connection - a java.sql.Connection reflection proxy,
> wrapping the underlying object.
> + * @return Connection - a
> java.sql.Connection/javax.sql.PooledConnection reflection proxy, wrapping the
> underlying object.
> * @throws SQLException
> */
> public Connection getConnection() throws SQLException {
> @@ -180,6 +199,10 @@
> return busy.size();
> }
>
> +/**
> + * Returns the number of idle connections
> + * @return
Ditto
> + */
> public int getIdle() {
> return idle.size();
> }
> @@ -197,7 +220,11 @@
>
> //===
>
>
> +/**
> + * configures a pooled connection as a proxy
> + */
> protected Connection setupConnection(PooledConnection con) throws
> SQLException {
> +//fetch previous interceptor proxy
> JdbcInterceptor handler = con.getHandler();
> if (handler==null) {
> //build the proxy handler
> @@ -252,6 +279,10 @@
> return proxyClassConstructor;
> }
>
> +/**
> + * If the connection pool gets garbage collected, lets make sure we
> clean up
> + * and close all the connections
> + */
> @Override
> protected void finalize() throws Throwable {
> close(true);
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Re: JDBC-POOL release candidate
On 14/07/2009, Filip Hanik - Dev Lists wrote: > think it should be all in order now > > http://people.apache.org/~fhanik/jdbc-pool/v1.0.6/ Eclipse and Findbugs show the following warnings for the non-test code: Description ResourcePathTypeLocation Class is a raw type. References to generic type Class should be parameterized ConnectionPool.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 302 Class is a raw type. References to generic type Class should be parameterized PoolProperties.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 735 Class is a raw type. References to generic type Class should be parameterized ProxyConnection.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 72 Constructor is a raw type. References to generic type Constructor should be parameterized ConnectionPool.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 105 Constructor is a raw type. References to generic type Constructor should be parameterized ConnectionPool.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 299 FairBlockingQueue is a raw type. References to generic type FairBlockingQueue should be parameterized ConnectionPool.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 148 FairBlockingQueue.ItemFuture is a raw type. References to generic type FairBlockingQueue.ItemFuture should be parameterized FairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 173 FairBlockingQueue.ItemFuture is a raw type. References to generic type FairBlockingQueue.ItemFuture should be parameterized FairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 177 Hashtable is a raw type. References to generic type Hashtable should be parameterized DataSourceFactory.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 177 Iterator is a raw type. References to generic type Iterator should be parameterizedDataSourceProxy.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 441 Iterator is a raw type. References to generic type Iterator should be parameterizedFairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 293 Javadoc: Duplicate tag for return typePooledConnection.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 295 Javadoc: UnsupportedOperation cannot be resolved to a typeFairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 254 Javadoc: UnsupportedOperation cannot be resolved to a typeFairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 262 Javadoc: UnsupportedOperation cannot be resolved to a typeFairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 303 Javadoc: UnsupportedOperation cannot be resolved to a typeFairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 312 Javadoc: UnsupportedOperation cannot be resolved to a typeFairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 327 Javadoc: UnsupportedOperation cannot be resolved to a typeFairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 335 Javadoc: UnsupportedOperation cannot be resolved to a typeFairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 343 Javadoc: UnsupportedOperation cannot be resolved to a typeFairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 351 Javadoc: UnsupportedOperation cannot be resolved to a typeFairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 359 Javadoc: UnsupportedOperation cannot be resolved to a typeFairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 367 Javadoc: UnsupportedOperation cannot be resolved to a typeFairBlockingQueue.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 375 Null comparison always yields false: The variable con cannot be null at this locationConnectionPool.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 823 Null comparison always yields false: The variable con cannot be null at this locationConnectionPool.java /tomcat-jdbc-pool_1_0_6/java/org/apache/tomcat/jdbc/poolJava Problem line 861
Re: [PROPOSAL] Remove SVN keywords from JavaDoc
On 07/07/2009, Mark Thomas wrote: > Konstantin Kolinko wrote: > > As was written early in this my thread: > > > http://www.nabble.com/Coding-Guidelines%2C-encodings%2C-keywords-td23662661.html > > (http://markmail.org/thread/d6dsgrsfvnuzclt7) > > > > there are problems with Subversion $Date$ keyword: > > 1. It uses localized names for the month and the day of the week > > 2. It writes those localized strings using UTF-8, while our sources > > are ISO-8859-1 > > 3. The time that is printed is in local timezone > > > > There are two possible solutions (besides ignoring the issue): > > a) Use $Id:$ keyword instead > > b) Remove the keyword > > > > For the java sources, I propose the simpler one of the above: > > > > I propose to remove *all* SVN keywords from our *.java sources, where they > are > > used in JavaDoc comments. > > That includes the following four keywords: Author Date Id Revision > > > > As it is a documentation change, I won't propose a patch, but go C-T-R. > > > > What are your opinions? > > If there are any objections to such a change, please write so. > > > I'm happy getting rid of all of them. The only times I have used them > there have been equally quick, equally effective ways of finding out the > information I was after (usually Tomcat version). +1 Apart from encoding issues, any SVN keywords that can vary between users (e.g. Header, Date) are a nuisance when comparing source files (e.g. tag checkout against source archive) as they generate spurious differences. > Mark > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r794798 - in /tomcat/trunk/java/org/apache/catalina/filters: Constants.java FilterBase.java LocalStrings.properties LocalStrings_es.properties LocalStrings_fr.properties RemoteAddrFi
On 16/07/2009, ma...@apache.org wrote:
> Author: markt
> Date: Thu Jul 16 19:34:49 2009
> New Revision: 794798
>
> URL: http://svn.apache.org/viewvc?rev=794798&view=rev
> Log:
> More GSOC work from Xie Xiadong
> Initial implementation of RemoteHost and RemoteAddr filters.
>
> Added:
> tomcat/trunk/java/org/apache/catalina/filters/Constants.java (with
> props)
> tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java (with
> props)
> tomcat/trunk/java/org/apache/catalina/filters/LocalStrings.properties
> (with props)
> tomcat/trunk/java/org/apache/catalina/filters/LocalStrings_es.properties
> (with props)
> tomcat/trunk/java/org/apache/catalina/filters/LocalStrings_fr.properties
> (with props)
> tomcat/trunk/java/org/apache/catalina/filters/RemoteAddrFilter.java
> (with props)
> tomcat/trunk/java/org/apache/catalina/filters/RemoteHostFilter.java
> (with props)
> tomcat/trunk/java/org/apache/catalina/filters/RequestFilter.java (with
> props)
>
> Added: tomcat/trunk/java/org/apache/catalina/filters/Constants.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/Constants.java?rev=794798&view=auto
>
> ==
> --- tomcat/trunk/java/org/apache/catalina/filters/Constants.java (added)
> +++ tomcat/trunk/java/org/apache/catalina/filters/Constants.java Thu Jul 16
> 19:34:49 2009
> @@ -0,0 +1,34 @@
> +/*
> + * 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.filters;
> +
> +
> +/**
> + * Manifest constants for this Java package.
> + *
> + *
> + * @author Craig R. McClanahan
Is that really true?
Likewise later on.
[IMO, @author tags should be omitted anyway, or perhaps use @author ASF]
> + * @version $Revision$ $Date$
> + */
> +
> +public final class Constants {
> +
> +public static final String Package = "org.apache.catalina.filters";
> +
> +}
>
> Propchange: tomcat/trunk/java/org/apache/catalina/filters/Constants.java
>
> --
> svn:eol-style = native
>
> Propchange: tomcat/trunk/java/org/apache/catalina/filters/Constants.java
>
> --
> svn:keywords = Date Author Id Revision
>
> Added: tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java?rev=794798&view=auto
>
> ==
> --- tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java (added)
> +++ tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java Thu Jul 16
> 19:34:49 2009
> @@ -0,0 +1,92 @@
> +/*
> + * 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.filters;
> +
> +import java.util.Enumeration;
> +
> +import javax.servlet.Filter;
> +import javax.servlet.FilterConfig;
> +import javax.servlet.ServletException;
> +import javax.servlet.ServletRequest;
> +import javax.servlet.ServletResponse;
> +import javax.servlet.http.HttpServletRequest;
> +import javax.servlet.http.HttpServletResponse;
> +
> +import org.apache.juli.logging.Log;
>
Re: JDBC-POOL release candidate
On 14/07/2009, Filip Hanik - Dev Lists wrote: > think it should be all in order now > > http://people.apache.org/~fhanik/jdbc-pool/v1.0.6/ There are some differences between the source archives and the SVN tag: In SVN, but not in source archive: .classpath .project sign.sh doc\package.xsl resources\MANIFEST.MF The 1st 3 files are OK to omit, but the others should surely be in the source archive? The Ant build fails with: build: BUILD FAILED build.xml:127: Manifest file: output/resources/MANIFEST.MF does not exist. In source archive, but not in SVN: java\META-INF\MANIFEST.MF java\org\apache\tomcat\jdbc\pool\PoolConfiguration.java test\META-INF\MANIFEST.MF The missing Java file really should be in the SVN tag. Not sure the MF files belong in a source archive. There is at least one outstanding Bug for JDBC-POOL which could be resolved: https://issues.apache.org/bugzilla/show_bug.cgi?id=47452 This would help with debugging the following test failures: [echo] Functional tests. [junit] Running org.apache.tomcat.jdbc.test.AbandonPercentageTest [junit] Tests run: 4, Failures: 1, Errors: 0, Time elapsed: 18.078 sec [junit] Test org.apache.tomcat.jdbc.test.AbandonPercentageTest FAILED [junit] Running org.apache.tomcat.jdbc.test.TestConcurrency [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 237.703 sec [junit] Test org.apache.tomcat.jdbc.test.TestConcurrency FAILED > If everyone thinks it looks ok, then I will put up for a vote in a few days > > Filip > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r796739 - /tomcat/trunk/java/org/apache/catalina/connector/AsyncContextImpl.java
On 22/07/2009, ma...@apache.org wrote:
> Author: markt
> Date: Wed Jul 22 14:29:09 2009
> New Revision: 796739
>
> URL: http://svn.apache.org/viewvc?rev=796739&view=rev
> Log:
> Restore the @Overrides. Eclipse on my Mac wasn't configured right. Sorry for
> the noise.
The build.properties.default file has
compile.source=1.5
compile.target=1.5
I get errors such as
[javac] Compiling 1029 source files
[javac]
tomcat-trunk\java\org\apache\catalina\connector\AsyncContextImpl.java:66:
method does not override a method from
its superclass
[javac] @Override
when compiling with
java version "1.5.0_18"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_18-b02)
Java HotSpot(TM) Client VM (build 1.5.0_18-b02, mixed mode, sharing)
Microsoft Windows XP [Version 5.1.2600]
So IMO either the minimum Java version needs to be updated to Java
1.6, or the @Override markers should be reserved for actual overrides,
rather than implementations.
> Modified:
> tomcat/trunk/java/org/apache/catalina/connector/AsyncContextImpl.java
>
> Modified:
> tomcat/trunk/java/org/apache/catalina/connector/AsyncContextImpl.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/AsyncContextImpl.java?rev=796739&r1=796738&r2=796739&view=diff
>
> ==
> --- tomcat/trunk/java/org/apache/catalina/connector/AsyncContextImpl.java
> (original)
> +++ tomcat/trunk/java/org/apache/catalina/connector/AsyncContextImpl.java
> Wed Jul 22 14:29:09 2009
> @@ -63,21 +63,25 @@
> this.request = request;
> }
>
> +@Override
> public void complete() {
> // TODO SERVLET3 - async
> doInternalComplete(false);
> }
>
> +@Override
> public void dispatch() {
> HttpServletRequest sr = (HttpServletRequest)getServletRequest();
> String path = sr.getRequestURI();
> dispatch(path);
> }
>
> +@Override
> public void dispatch(String path) {
> dispatch(request.getServletContext(),path);
> }
>
> +@Override
> public void dispatch(ServletContext context, String path) {
> // TODO SERVLET3 - async
> if (state.compareAndSet(AsyncState.STARTED, AsyncState.DISPATCHING)
> ||
> @@ -113,14 +117,17 @@
> }
> }
>
> +@Override
> public ServletRequest getRequest() {
> return getServletRequest();
> }
>
> +@Override
> public ServletResponse getResponse() {
> return getServletResponse();
> }
>
> +@Override
> public void start(final Runnable run) {
> if (state.compareAndSet(AsyncState.STARTED, AsyncState.DISPATCHING)
> ||
> state.compareAndSet(AsyncState.DISPATCHED,
> AsyncState.DISPATCHING)) {
> @@ -195,6 +202,7 @@
> this.servletResponse = servletResponse;
> }
>
> +@Override
> public boolean hasOriginalRequestAndResponse() {
> return hasOriginalRequestAndResponse;
> }
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r796739 - /tomcat/trunk/java/org/apache/catalina/connector/AsyncContextImpl.java
On 23/07/2009, Mark Thomas wrote:
> Filip Hanik - Dev Lists wrote:
> > Correct, servlet 3.0 requires minimum 1.6
> > so we don't have to build down to 1.5 anymore
> >
> > Filip
>
>
> I think sebb needs to do an svn up. build.properties.default has specified 1.6
> for over 6 months.
I have been doing "svn up", but just realised that I had an old
build.properties file.
Sorry for the noise.
BTW, I just noticed that build.xml comments state:
However, there is no such file I could find, so perhaps the comment
needs to be removed?
> Mark
>
>
> >
> > On 07/22/2009 10:48 AM, sebb wrote:
> >> On 22/07/2009, ma...@apache.org wrote:
> >>
> >>> Author: markt
> >>> Date: Wed Jul 22 14:29:09 2009
> >>> New Revision: 796739
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=796739&view=rev
> >>> Log:
> >>> Restore the @Overrides. Eclipse on my Mac wasn't configured right.
> >>> Sorry for the noise.
> >>>
> >>
> >> The build.properties.default file has
> >>
> >> compile.source=1.5
> >> compile.target=1.5
> >>
> >> I get errors such as
> >>
> >> [javac] Compiling 1029 source files
> >> [javac]
> >> tomcat-trunk\java\org\apache\catalina\connector\AsyncContextImpl.java:66:
> >> method does not override a method from
> >> its superclass
> >> [javac] @Override
> >>
> >> when compiling with
> >>
> >> java version "1.5.0_18"
> >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_18-b02)
> >> Java HotSpot(TM) Client VM (build 1.5.0_18-b02, mixed mode, sharing)
> >>
> >> Microsoft Windows XP [Version 5.1.2600]
> >>
> >> So IMO either the minimum Java version needs to be updated to Java
> >> 1.6, or the @Override markers should be reserved for actual overrides,
> >> rather than implementations.
> >>
> >>
> >>> Modified:
> >>>
> >>> tomcat/trunk/java/org/apache/catalina/connector/AsyncContextImpl.java
> >>>
> >>> Modified:
> >>> tomcat/trunk/java/org/apache/catalina/connector/AsyncContextImpl.java
> >>> URL:
> >>>
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/AsyncContextImpl.java?rev=796739&r1=796738&r2=796739&view=diff
> >>>
> >>>
> >>>
> ==
> >>>
> >>> ---
> >>> tomcat/trunk/java/org/apache/catalina/connector/AsyncContextImpl.java
> >>> (original)
> >>> +++
> >>> tomcat/trunk/java/org/apache/catalina/connector/AsyncContextImpl.java
> >>> Wed Jul 22 14:29:09 2009
> >>> @@ -63,21 +63,25 @@
> >>> this.request = request;
> >>> }
> >>>
> >>> +@Override
> >>> public void complete() {
> >>> // TODO SERVLET3 - async
> >>> doInternalComplete(false);
> >>> }
> >>>
> >>> +@Override
> >>> public void dispatch() {
> >>> HttpServletRequest sr =
> >>> (HttpServletRequest)getServletRequest();
> >>> String path = sr.getRequestURI();
> >>> dispatch(path);
> >>> }
> >>>
> >>> +@Override
> >>> public void dispatch(String path) {
> >>> dispatch(request.getServletContext(),path);
> >>> }
> >>>
> >>> +@Override
> >>> public void dispatch(ServletContext context, String path) {
> >>> // TODO SERVLET3 - async
> >>> if (state.compareAndSet(AsyncState.STARTED,
> >>> AsyncState.DISPATCHING) ||
> >>> @@ -113,14 +117,17 @@
> >>> }
> >>> }
> >>>
> >>> +@Override
> >>> public ServletRequest getRequest() {
> >>> return getServletRequest();
> >>> }
> >>>
> >>> +@Override
> >>> public ServletResponse getResponse() {
> >>> return getServletResponse();
> >>> }
> >>>
Re: svn commit: r797151 - /tomcat/trunk/build.xml
On 23/07/2009, ma...@apache.org wrote: > Author: markt > Date: Thu Jul 23 17:15:55 2009 > New Revision: 797151 > > URL: http://svn.apache.org/viewvc?rev=797151&view=rev > Log: > Correct the file name > > Modified: > tomcat/trunk/build.xml > > Modified: tomcat/trunk/build.xml > URL: > http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=797151&r1=797150&r2=797151&view=diff > > == > --- tomcat/trunk/build.xml (original) > +++ tomcat/trunk/build.xml Thu Jul 23 17:15:55 2009 > @@ -20,7 +20,7 @@ > > > > - > + > AFAICT there's no *need* to customise any values, so may I suggest: s/for all/for/ s/you must/you may need to/ > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r797151 - /tomcat/trunk/build.xml
On 24/07/2009, Rainer Jung wrote: > On 23.07.2009 20:43, sebb wrote: > > On 23/07/2009, ma...@apache.org wrote: > >> Author: markt > >> Date: Thu Jul 23 17:15:55 2009 > >> New Revision: 797151 > >> > >> URL: http://svn.apache.org/viewvc?rev=797151&view=rev > >> Log: > >> Correct the file name > >> > >> Modified: > >> tomcat/trunk/build.xml > >> > >> Modified: tomcat/trunk/build.xml > >> URL: > http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=797151&r1=797150&r2=797151&view=diff > >> > == > >> --- tomcat/trunk/build.xml (original) > >> +++ tomcat/trunk/build.xml Thu Jul 23 17:15:55 2009 > >> @@ -20,7 +20,7 @@ > >> > >> > >> > >> - > >> + > >> > > > > AFAICT there's no *need* to customise any values, so may I suggest: > > > > s/for all/for/ > > s/you must/you may need to/ > > > I fixed the file name in the other two build files also, and made the > text more explicit. I hope everyone is satisfied ... +1 > See: https://svn.apache.org/viewcvs.cgi?view=rev&rev=797425 That's much clearer; thanks! > Regards, > > > Rainer > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r797529 - in /tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test: AbandonPercentageTest.java BorrowWaitTest.java DefaultTestCase.java TestConcurrency.java
On 24/07/2009, fha...@apache.org wrote:
> Author: fhanik
> Date: Fri Jul 24 15:25:17 2009
> New Revision: 797529
>
> URL: http://svn.apache.org/viewvc?rev=797529&view=rev
> Log:
> update test cases
>
> Modified:
>
> tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/AbandonPercentageTest.java
>
> tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/BorrowWaitTest.java
>
> tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/DefaultTestCase.java
>
> tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/TestConcurrency.java
>
> Modified:
> tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/AbandonPercentageTest.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/AbandonPercentageTest.java?rev=797529&r1=797528&r2=797529&view=diff
>
> ==
> ---
> tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/AbandonPercentageTest.java
> (original)
> +++
> tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/AbandonPercentageTest.java
> Fri Jul 24 15:25:17 2009
> @@ -38,7 +38,6 @@
> this.datasource.getPoolProperties().setRemoveAbandoned(true);
> this.datasource.getPoolProperties().setRemoveAbandonedTimeout(1);
> Connection con = datasource.getConnection();
> -long start = System.currentTimeMillis();
> assertEquals("Number of connections active/busy should be
> 1",1,datasource.getPool().getActive());
> Thread.sleep(2000);
> assertEquals("Number of connections active/busy should be
> 0",0,datasource.getPool().getActive());
> @@ -56,7 +55,6 @@
> this.datasource.getPoolProperties().setRemoveAbandoned(true);
> this.datasource.getPoolProperties().setRemoveAbandonedTimeout(1);
> Connection con = datasource.getConnection();
> -long start = System.currentTimeMillis();
> assertEquals("Number of connections active/busy should be
> 1",1,datasource.getPool().getActive());
> Thread.sleep(2000);
> assertEquals("Number of connections active/busy should be
> 1",1,datasource.getPool().getActive());
> @@ -75,7 +73,6 @@
> this.datasource.getPoolProperties().setRemoveAbandonedTimeout(1);
>
> this.datasource.getPoolProperties().setJdbcInterceptors(ResetAbandonedTimer.class.getName());
> Connection con = datasource.getConnection();
> -long start = System.currentTimeMillis();
> assertEquals("Number of connections active/busy should be
> 1",1,datasource.getPool().getActive());
> for (int i=0; i<20; i++) {
> Thread.sleep(200);
> @@ -97,7 +94,6 @@
> this.datasource.getPoolProperties().setRemoveAbandonedTimeout(1);
> Connection[] con = new Connection[size];
> con[0] = datasource.getConnection();
> -long start = System.currentTimeMillis();
> assertEquals("Number of connections active/busy should be
> 1",1,datasource.getPool().getActive());
> for (int i=1; i<25; i++) {
> con[i] = datasource.getConnection();
>
> Modified:
> tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/BorrowWaitTest.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/BorrowWaitTest.java?rev=797529&r1=797528&r2=797529&view=diff
>
> ==
> ---
> tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/BorrowWaitTest.java
> (original)
> +++
> tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/BorrowWaitTest.java
> Fri Jul 24 15:25:17 2009
> @@ -32,10 +32,10 @@
> this.datasource.setMaxActive(1);
> this.datasource.setMaxWait(wait);
> Connection con = datasource.getConnection();
> -long start = System.currentTimeMillis();
> try {
> Connection con2 = datasource.getConnection();
> assertFalse("This should not happen, connection should be
> unavailable.",true);
> +con2.close();
> }catch (SQLException x) {
> long delta = System.currentTimeMillis();
> boolean inrange = Math.abs(wait-delta) < 1000;
>
> Modified:
> tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/DefaultTestCase.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/DefaultTestCase.java?rev=797529&r1=797528&r2=797529&view=diff
>
> ==
> ---
> tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/DefaultTestCase.java
> (original)
> +++
> tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/DefaultTestCase.java
> Fri Jul 24 15:25:17 2009
> @@ -52,6 +52,7
Re: svn commit: r797528 - in /tomcat/trunk/modules/jdbc-pool: doc/ java/org/apache/tomcat/jdbc/pool/
On 24/07/2009, fha...@apache.org wrote:
> Author: fhanik
> Date: Fri Jul 24 15:24:52 2009
> New Revision: 797528
>
> URL: http://svn.apache.org/viewvc?rev=797528&view=rev
> Log:
> Add in Linux special case for performance optimization around locking.
> Set default queue to be the fair one
> Remove unused code
>
>
> Modified:
> tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
>
> tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
>
> tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/DataSourceProxy.java
>
> tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/FairBlockingQueue.java
>
> tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/PoolConfiguration.java
>
> tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/PoolProperties.java
>
> Modified: tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml?rev=797528&r1=797527&r2=797528&view=diff
>
> ==
> --- tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml (original)
> +++ tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml Fri Jul 24 15:24:52 2009
> @@ -353,10 +353,16 @@
>
>(boolean) Set to true if you wish that calls to getConnection
> should be treated
> fairly in a true FIFO fashion. This uses the
> org.apache.tomcat.jdbc.pool.FairBlockingQueue
> - implementation for the list of the idle connections. The default
> value is false.
> + implementation for the list of the idle connections. The default
> value is true.
> This flag is required when you want to use asynchronous connection
> retrieval.
> - During performance tests, the fairQueue does very well on a multi
> core Solaris system,
> - but performs terribly on a Linux Fedora 11 system. On Linux we
> recommend setting this to false.
> + Setting this flag ensures that threads receive connections in the
> order they arrive.
> + During performance tests, there is a very large difference in how
> locks
> + and lock waiting is implemented. When fairQueue=true>
> + there is a decision making process based on what operating system
> the system is running.
> + If the system is running on Linux (property
> os.name=Linux.
> + To disable this Linux specific behavior and still use the fair
> queue, simply add the property
> +
> org.apache.tomcat.jdbc.pool.FairBlockingQueue.ignoreOS=true to
> your system properties
> + before the connection pool classes are loaded.
>
>
>
>
> Modified:
> tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java?rev=797528&r1=797527&r2=797528&view=diff
>
> ==
> ---
> tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
> (original)
> +++
> tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
> Fri Jul 24 15:24:52 2009
> @@ -148,6 +148,9 @@
> if (idle instanceof FairBlockingQueue) {
> Future pcf =
> ((FairBlockingQueue)idle).pollAsync();
> return new ConnectionFuture(pcf);
> +} else if (idle instanceof MultiLockFairBlockingQueue) {
> +Future pcf =
> ((MultiLockFairBlockingQueue)idle).pollAsync();
> +return new ConnectionFuture(pcf);
> } else {
> throw new SQLException("Connection pool is misconfigured,
> doesn't support async retrieval. Set the 'fair' property to 'true'");
> }
> @@ -306,21 +309,6 @@
> }
>
> /**
> - * If the connection pool gets garbage collected, lets make sure we
> clean up
> - * and close all the connections.
> - * {...@inheritdoc}
> - */
> -@Override
> -protected void finalize() throws Throwable {
> -//Runnable closer = new Runnable() {
> -//public void run() {
> -//close(true);
> -//}
> -//};
> -//this.cancellator.execute(closer);
> -}
> -
> -/**
> * Closes the pool and all disconnects all idle connections
> * Active connections will be closed upon the {...@link
> java.sql.Connection#close close} method is called
> * on the underlying connection instead of being returned to the pool
> @@ -381,6 +369,7 @@
> //make space for 10 extra in case we flow over a bit
> if (properties.isFairQueue()) {
> idle = new FairBlockingQueue();
> +//idle = new MultiLockFairBlockingQueue();
> } else {
> idle = new
> ArrayBlockingQueue
Re: 5.5.28 release candidate
On 24/07/2009, Filip Hanik - Dev Lists wrote: > http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.28/ There is no .zip version of apache-tomcat-5.5.28-fulldocs.tar.gz The source archives contain the file container/webapps/admin/images/Thumbs.db which does not belong in the archive. Also, the file container/modules/storeconfig-ha/test/conf/catalina.keystore is different in the .zip and .tar.gz versions of the archives. Looks like a packaging error - perhaps accidental EOL conversion? There are no NOTICE or LICENSE files in the top-level of the source archives. The binary archives contain the files bin/jsvc.tar.gz bin/tomcat-native.tar.gz which appears to be source code only. When the EXE is unpacked, there is no RELEASE-NOTES file in the top-level directory where one would expect to find it. The server.xml file in the EXE is different from the one in the bin file and appears to be an old version. Likewise, the file tomcat-users.xml looks wrong - it says that there is no user with the manager role, yet it contains the following entry: > I have not run the TCK on this yet > Plan on vote mid to late next week > > Filip > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: 5.5.28 release candidate
On 25/07/2009, Rainer Jung wrote: > On 25.07.2009 01:44, sebb wrote: > > On 24/07/2009, Filip Hanik - Dev Lists wrote: > > > Likewise, the file tomcat-users.xml looks wrong - it says that there > > is no user with the manager role, yet it contains the following entry: > > > > > > > IMHO this would be a release blocker. IMO the different server.xml files are a potential release blocker - the differences include changes to the names of parameters in the comments, so at least one of the files must have incorrect information. Extract from diff: - clusterName = a descriptive name for your cluster, can be anything + name = a descriptive name for your cluster, can be anything ... - mcastBindAddress = bind the multicast socket to a specific address + mcastBindAddr = bind the multicast socket to a specific address Note that neither of the versions of the file actually includes examples using name/clusterName or mcastBindAddress/mcastBindAddr, which also ought to be corrected. > Of course if it is only a packaging problem, we can still fix for 28. > > Regards, > > > Rainer > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
