Re: Move to Nexus with no community discussion. WTF?
On 12/16/2011 11:02 PM, Mark Thomas wrote: The good news is that Jean-Frederic has indicated via private e-mail that he will be fixing the build scripts to use Nexus tomorrow. I would like to see him confirm that on this list but I have no reason to doubt his word. A quick read of [2] suggests that it should be do-able in that timeframe. I am working on it. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52351] New: tomcat6 started but web page stopped automatically
https://issues.apache.org/bugzilla/show_bug.cgi?id=52351 Bug #: 52351 Summary: tomcat6 started but web page stopped automatically Product: Tomcat 6 Version: 6.0.24 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: kalingara...@sourcetrace.com Classification: Unclassified Hi, We are using tomcat6.0.24 and java 1.6.0_24 in our ubuntu production server. we are created two multiple instance.1.is wconsole.war file and another one is transation.war file. The first web console is working fine in first instace but the 2nt instance have the trancation file. Its frequently down the trancesation console but service is running.we are tunned the memory as to minimum 1024 to maximum 2048 memory but its not working Please tell me the correct log analyser opensource tool. Our server is xeon server and RAM is 8GB. Please let us know the correct solution for this,Please give the tips for this We are expecting your answer. Thanks kalingarjan -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52351] tomcat6 started but web page stopped automatically
https://issues.apache.org/bugzilla/show_bug.cgi?id=52351 Konstantin Kolinko changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Konstantin Kolinko 2011-12-17 11:08:59 UTC --- RTFM. Bugzilla is wrong place for your question. Ask on the @users list. http://tomcat.apache.org/bugreport.html#Bugzilla_is_not_a_support_forum -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: 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 Dec 17, 2011, at 6:44 AM, sebb wrote: > 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. Only via the release plugin and not following the documented process at the time. Adding GUI steps and more mysterious software *decreases* control. > > 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. Which the simple rsync setup that tomcat and some Commons holdouts still use does in a much simpler and more transparent way. > >> 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. Thats what I meant above. Phil > >> 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 > - 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
2011/12/16 Mark Thomas > There are currently two options for publishing JARs to Maven Central: > 1. scp+rsync via people.a.o > 2. Nexus > In my experience in Tiles releases, the only problem we had with scp + simple copy (we did not use rsync) is that this process breaks Maven metadata. I try to explain myself. If you release to a staging directory, the Maven metadata (containg info about previous releases) are not there, so they are created from scratch. So, after releasing in the staging directory and voting, the copy method simply overwrite the old metadata with the new one (remember, *without the old versions*). So in the end, we needed to use the Maven stage plugin (deprecated), that: * downloads the staged artifacts; * reuploads them to the final destination. Inside Nexus, you simply "promote" the staged repository, without the problem of downloading and uploading again. Antonio
Re: Publishing process for JARs for Maven Central
On 17/12/2011 18:08, Antonio Petrelli wrote: > 2011/12/16 Mark Thomas > >> There are currently two options for publishing JARs to Maven Central: >> 1. scp+rsync via people.a.o >> 2. Nexus >> > > In my experience in Tiles releases, the only problem we had with scp + > simple copy (we did not use rsync) is that this process breaks Maven > metadata. > I try to explain myself. > If you release to a staging directory, the Maven metadata (containg info > about previous releases) are not there, so they are created from scratch. > So, after releasing in the staging directory and voting, the copy method > simply overwrite the old metadata with the new one (remember, *without the > old versions*). > So in the end, we needed to use the Maven stage plugin (deprecated), that: > * downloads the staged artifacts; > * reuploads them to the final destination. That is not an issue. Tomcat doesn't release to a staging repo first. The Maven artefact release is only done after the release vote has passed. If you look at the Tomcat 7 metadata you'll see that all versions are present. > Inside Nexus, you simply "promote" the staged repository, without the > problem of downloading and uploading again. That is not a problem with the scp+rsync process used by the Tomcat project. Mark - 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
2011/12/17 Mark Thomas > On 17/12/2011 18:08, Antonio Petrelli wrote: > > 2011/12/16 Mark Thomas > > > >> There are currently two options for publishing JARs to Maven Central: > >> 1. scp+rsync via people.a.o > >> 2. Nexus > >> > > > > In my experience in Tiles releases, the only problem we had with scp + > > simple copy (we did not use rsync) is that this process breaks Maven > > metadata. > > I try to explain myself. > > If you release to a staging directory, the Maven metadata (containg info > > about previous releases) are not there, so they are created from scratch. > > So, after releasing in the staging directory and voting, the copy method > > simply overwrite the old metadata with the new one (remember, *without > the > > old versions*). > > So in the end, we needed to use the Maven stage plugin (deprecated), > that: > > * downloads the staged artifacts; > > * reuploads them to the final destination. > > That is not an issue. > > Tomcat doesn't release to a staging repo first. The Maven artefact > release is only done after the release vote has passed. If you look at > the Tomcat 7 metadata you'll see that all versions are present. > > > Inside Nexus, you simply "promote" the staged repository, without the > > problem of downloading and uploading again. > > That is not a problem with the scp+rsync process used by the Tomcat > project. > Ok then interprete my words as: now you can use a staging repository. This way, artifacts may be tested *before* they are released. Antonio
Re: Publishing process for JARs for Maven Central
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. Mark - 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 16/12/2011 19:56, 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 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? More info from [1]. 1 means running a single script (after the release vote has passed) 2 means running a single script (before or after the release vote) and then a couple of clicks in Nexus to promote the JARs once the release vote passes. Nexus pros: The Maven artefacts can be available sooner since we can upload them while the release vote is running. Nexus cons: What was a single step to release the Maven JARs is now multiple steps. I think I am still neutral on this. Jean-Frederic, what was your motivation for moving Tomcat to Nexus? Mark [1] https://issues.apache.org/jira/browse/INFRA-4162 - 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
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) Antonio
Re: Publishing process for JARs for Maven Central
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. Mark - 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
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 . 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
Re: Publishing process for JARs for Maven Central
On 17/12/2011 18:42, 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 . > 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. Personally, I am of the view "If it ain't broke, don't fix it". If there was something we would gain by switching to Maven then I'd be interested but given we have an established build process with Ant that a number of committers are familiar with and that I'm not aware of any benefits of moving to Maven then I don't see any compelling reason to switch. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1215557 - in /tomcat/tc6.0.x/trunk/res/maven: README.txt mvn-pub.xml mvn.properties.default
Author: jfclere
Date: Sat Dec 17 19:02:31 2011
New Revision: 1215557
URL: http://svn.apache.org/viewvc?rev=1215557&view=rev
Log:
Fix the deploy-release task.
Once done you should have an entry in
https://repository.apache.org/index.html#stagingRepositories
Check it and click Close.
Once the release is voted just click Release.
If any wrong just click Drop.
Added:
tomcat/tc6.0.x/trunk/res/maven/README.txt
Modified:
tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml
tomcat/tc6.0.x/trunk/res/maven/mvn.properties.default
Added: tomcat/tc6.0.x/trunk/res/maven/README.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/maven/README.txt?rev=1215557&view=auto
==
--- tomcat/tc6.0.x/trunk/res/maven/README.txt (added)
+++ tomcat/tc6.0.x/trunk/res/maven/README.txt Sat Dec 17 19:02:31 2011
@@ -0,0 +1,6 @@
+To release do the following:
+1 - copy mvn.properties.default to mvn.propertie and adjust it.
+2 - ant -f mvn-pub.xml deploy-release
+that step creates a staging in
https://repository.apache.org/index.html#stagingRepositories
+3 - test it and do the vote process
+4 - in https://repository.apache.org/index.html#stagingRepositories close it
and then promote it.
Modified: tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml?rev=1215557&r1=1215556&r2=1215557&view=diff
==
--- tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml (original)
+++ tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml Sat Dec 17 19:02:31 2011
@@ -68,6 +68,29 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -90,13 +113,14 @@
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+maven.password=
maven.scp.username=fhanik
maven.scp.privateKey=${user.home}/.ssh/id_dsa
maven.scp.passphrase=
@@ -44,8 +46,8 @@ maven.release.repo.url=scp://people.apac
maven.release.repo.repositoryId=tomcat-staging
maven.release.deploy.version=${tomcat.version}
-#Maven release properties for the main ASF repo
-maven.asf.release.repo.url=scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository
+#Maven release properties for the main ASF repo (staging in nexus)
+maven.asf.release.repo.url=https://repository.apache.org/service/local/staging/deploy/maven2
maven.asf.release.repo.repositoryId=apache.releases
maven.asf.release.deploy.version=${tomcat.version}
-
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
2011/12/17 Mark Thomas > On 17/12/2011 18:42, 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 . > > 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. > > Personally, I am of the view "If it ain't broke, don't fix it". If there > was something we would gain by switching to Maven then I'd be interested > but given we have an established build process with Ant that a number of > committers are familiar with and that I'm not aware of any benefits of > moving to Maven then I don't see any compelling reason to switch. > Using Maven has several benefits (standardization of structure, lots of reusable plugins, supported by major IDEs), but, somehow, they still don't convince hardcode Ant believers. I prefer speaking with facts and I love doing Maven reconstructions. Since Apache lets us use Git, though in a read-only way, and since I use and love Tomcat, I think that it's worth a try. Antonio
Re: Publishing process for JARs for Maven Central
On 17/12/2011 19:10, Antonio Petrelli wrote: > 2011/12/17 Mark Thomas >> Personally, I am of the view "If it ain't broke, don't fix it". If there >> was something we would gain by switching to Maven then I'd be interested >> but given we have an established build process with Ant that a number of >> committers are familiar with and that I'm not aware of any benefits of >> moving to Maven then I don't see any compelling reason to switch. >> > > Using Maven has several benefits (standardization of structure, lots of > reusable plugins, supported by major IDEs), Those are features, not benefits. If you can demonstrate how switching to Maven will be better, then I am all ears. So far Maven just looks different rather than better with the disadvantage (for me at least) that Maven is unfamiliar whereas Ant is familiar. There needs to be an incentive to go up the Maven learning curve and I haven't seen one yet. > I prefer speaking with facts and I love doing Maven reconstructions. > Since Apache lets us use Git, though in a read-only way, and since I use > and love Tomcat, I think that it's worth a try. You are, of course, free to take a look at this. It might be more productive to try and make the case for Maven before doing that work. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
As requested here is a proposal to move to Maven. 2011/12/17 Mark Thomas > > Using Maven has several benefits (standardization of structure, lots of > > reusable plugins, supported by major IDEs), > > Those are features, not benefits. > The standardization of structure is not a feature, but a constraint. When you use Maven *the right way* you ought to follow a well standardized structure. > You are, of course, free to take a look at this. It might be more > productive to try and make the case for Maven before doing that work 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. 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. 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) 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. 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. 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Antonio
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
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. > 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. The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. 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. > 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? > 4. POMs are (almost) universal. Projects of the same kind have almost the > same content.. How does this benefit the Tomcat community? > 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? > 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). 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.). Mark - 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)
I'll try to keep it short because I really don't want to spend time re-beating this dead horse. The last time I looked a couple years ago the jars constructed out of the single source tree could not be compiled separately in any order. I was told this wasn't a problem, at which point I realized discussion was useless. Maven prevents problems like this through the project structure. If this situation is not a problem to the tomcat community, then the other possible benefits of using maven are not likely to be interesting either. thanks david jencks On Dec 17, 2011, at 12:48 PM, Mark Thomas wrote: > 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. > >> 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. The dependencies are known and > we have checks in place (via Checkstyle) to ensure that unwanted > dependencies are not added. 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. > >> 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? > >> 4. POMs are (almost) universal. Projects of the same kind have almost the >> same content.. > > How does this benefit the Tomcat community? > >> 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? > >> 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). > > 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.). > > 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: Publishing process for JARs for Maven Central
2011/12/17 Antonio Petrelli : > If you release to a staging directory, the Maven metadata (containg info > about previous releases) are not there, so they are created from scratch. > So, after releasing in the staging directory and voting, the copy method > simply overwrite the old metadata with the new one (remember, *without the > old versions*). > So in the end, we needed to use the Maven stage plugin (deprecated), that: > * downloads the staged artifacts; > * reuploads them to the final destination. > Mark, the above issue mentioned by Antonio is what I think we already encountered with broken maven-metadata.xml. That is https://issues.apache.org/bugzilla/show_bug.cgi?id=52124 More detailed description is in https://issues.sonatype.org/browse/MVNCENTRAL-139 Mark, when you do 7.0 releases, do you scp the maven-metadata.xml file? Do you have all previous releases of 7.0 in your local repository (so that the file is built correctly)? If Nexus allows to prepare new releases without the need to keep old releases around, I am +1 for it. Best regards, Konstantin Kolinko - 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/12/2011 21:43, Konstantin Kolinko wrote: > 2011/12/17 Antonio Petrelli : >> If you release to a staging directory, the Maven metadata (containg info >> about previous releases) are not there, so they are created from scratch. >> So, after releasing in the staging directory and voting, the copy method >> simply overwrite the old metadata with the new one (remember, *without the >> old versions*). >> So in the end, we needed to use the Maven stage plugin (deprecated), that: >> * downloads the staged artifacts; >> * reuploads them to the final destination. >> > > Mark, the above issue mentioned by Antonio is what I think we already > encountered with broken maven-metadata.xml. That is > > https://issues.apache.org/bugzilla/show_bug.cgi?id=52124 > > More detailed description is in > https://issues.sonatype.org/browse/MVNCENTRAL-139 That was a broken Tomcat 6 build process. Tomcat 7 doesn't have that problem (and now, neither does 6). Granted using Nexus would have avoided that issue but it has taken 5 years (since the 6.0.0 tag) for someone to complain. That suggests to me the issue is minor. > Mark, when you do 7.0 releases, do you scp the maven-metadata.xml file? I assume that the file gets correctly generated automatically. > Do you have all previous releases of 7.0 in your local repository (so > that the file is built correctly)? No. I have 7.0.11 - 7.0.23 (mainly because I haven't cleaned it out in a while). It looks like the build process grabs a copy of the metadata from the remote repo, updates it to add the new version and then uploads the updated file. > If Nexus allows to prepare new releases without the need to keep old > releases around, I am +1 for it. As far as I can tell, Nexus and the scp+rsync process are the same in this regard. Mark - 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 17/12/2011 21:12, David Jencks wrote: > I'll try to keep it short because I really don't want to spend time > re-beating this dead horse. > > The last time I looked a couple years ago the jars constructed out of > the single source tree could not be compiled separately in any order. > I was told this wasn't a problem, at which point I realized > discussion was useless. I just did a check with JarAnalyzer and we still have circular dependency issues with catalina.jar, catalina-ha.jar and catalina-tribes.jar I haven't looked in the archives for the previous discussion and I can't remember what my views were then - probably completely opposite to now :). I wouldn't class it as a problem (I am happy to live with this) but I'm happy to take a look to see if there is an easy fix and apply the fix in that case. > Maven prevents problems like this through the project structure. If > this situation is not a problem to the tomcat community, then the > other possible benefits of using maven are not likely to be > interesting either. The dependencies we really care about are monitored via Checkstyle. If I fix the above issue, I'll add some additional checks so we don't recreate the issue. Mark > > thanks david jencks > > On Dec 17, 2011, at 12:48 PM, Mark Thomas wrote: > >> 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. >> >>> 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. The dependencies >> are known and we have checks in place (via Checkstyle) to ensure >> that unwanted dependencies are not added. 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. >> >>> 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? >> >>> 4. POMs are (almost) universal. Projects of the same kind have >>> almost the same content.. >> >> How does this benefit the Tomcat community? >> >>> 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? >> >>> 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). >> >> 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.). >> >> 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: svn commit: r1215557 - in /tomcat/tc6.0.x/trunk/res/maven: README.txt mvn-pub.xml mvn.properties.default
2011/12/17 :
> Author: jfclere
> Date: Sat Dec 17 19:02:31 2011
> New Revision: 1215557
>
> URL: http://svn.apache.org/viewvc?rev=1215557&view=rev
> Log:
> Fix the deploy-release task.
> Once done you should have an entry in
> https://repository.apache.org/index.html#stagingRepositories
> Check it and click Close.
> Once the release is voted just click Release.
> If any wrong just click Drop.
>
> Added:
> tomcat/tc6.0.x/trunk/res/maven/README.txt
> Modified:
> tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml
> tomcat/tc6.0.x/trunk/res/maven/mvn.properties.default
>
> Added: tomcat/tc6.0.x/trunk/res/maven/README.txt
> URL:
> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/maven/README.txt?rev=1215557&view=auto
> ==
> --- tomcat/tc6.0.x/trunk/res/maven/README.txt (added)
> +++ tomcat/tc6.0.x/trunk/res/maven/README.txt Sat Dec 17 19:02:31 2011
> @@ -0,0 +1,6 @@
> +To release do the following:
> +1 - copy mvn.properties.default to mvn.propertie and adjust it.
> +2 - ant -f mvn-pub.xml deploy-release
> + that step creates a staging in
> https://repository.apache.org/index.html#stagingRepositories
> +3 - test it and do the vote process
> +4 - in https://repository.apache.org/index.html#stagingRepositories close it
> and then promote it.
Note that
1) there is also a big comment at the top of mvn-pub.xml.
2) ASL header is needed? Nobody checks it in 6.0 but in thunk
checkstyle would complain on such a file, I think.
>
> Modified: tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml
(...)
Looks good.
> --- tomcat/tc6.0.x/trunk/res/maven/mvn.properties.default (original)
> +++ tomcat/tc6.0.x/trunk/res/maven/mvn.properties.default Sat Dec 17 19:02:31
> 2011
> @@ -23,6 +23,8 @@
> tomcat.version=6.0.20
Can update the above sometime :)
>
> #Maven properties
> +maven.username=
> +maven.password=
Regarding plaintext passwords in config files:
There is simple workaround: use Ant task.
1. Remove maven.password from maven.properties.default
2. Add
Probably that goes into init-maven so that it executes only once.
As docs say
[[[
Since Apache Ant 1.6, will not prompt for input if a property
should be set by the task that has already been set in the project
(and the task wouldn't have any effect).
]]]
> maven.scp.username=fhanik
> maven.scp.privateKey=${user.home}/.ssh/id_dsa
> maven.scp.passphrase=
> @@ -44,8 +46,8 @@ maven.release.repo.url=scp://people.apac
> maven.release.repo.repositoryId=tomcat-staging
> maven.release.deploy.version=${tomcat.version}
>
> -#Maven release properties for the main ASF repo
> -maven.asf.release.repo.url=scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository
> +#Maven release properties for the main ASF repo (staging in nexus)
> +maven.asf.release.repo.url=https://repository.apache.org/service/local/staging/deploy/maven2
> maven.asf.release.repo.repositoryId=apache.releases
> maven.asf.release.deploy.version=${tomcat.version}
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1220292 - in /tomcat/trunk/java/javax/servlet: ServletRequestWrapper.java ServletResponseWrapper.java annotation/HandlesTypes.java
Author: markt
Date: Sat Dec 17 22:51:29 2011
New Revision: 1220292
URL: http://svn.apache.org/viewvc?rev=1220292&view=rev
Log:
Servlet 3.1 generics additions
Modified:
tomcat/trunk/java/javax/servlet/ServletRequestWrapper.java
tomcat/trunk/java/javax/servlet/ServletResponseWrapper.java
tomcat/trunk/java/javax/servlet/annotation/HandlesTypes.java
Modified: tomcat/trunk/java/javax/servlet/ServletRequestWrapper.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/ServletRequestWrapper.java?rev=1220292&r1=1220291&r2=1220292&view=diff
==
--- tomcat/trunk/java/javax/servlet/ServletRequestWrapper.java (original)
+++ tomcat/trunk/java/javax/servlet/ServletRequestWrapper.java Sat Dec 17
22:51:29 2011
@@ -430,9 +430,7 @@ public class ServletRequestWrapper imple
* @param wrappedType
* @since Servlet 3.0 TODO SERVLET3 - Add comments
*/
-@SuppressWarnings("unchecked")
-// Spec API does not use generics
-public boolean isWrapperFor(@SuppressWarnings("rawtypes") Class
wrappedType) {
+public boolean isWrapperFor(Class wrappedType) {
if (wrappedType.isAssignableFrom(request.getClass())) {
return true;
}
Modified: tomcat/trunk/java/javax/servlet/ServletResponseWrapper.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/ServletResponseWrapper.java?rev=1220292&r1=1220291&r2=1220292&view=diff
==
--- tomcat/trunk/java/javax/servlet/ServletResponseWrapper.java (original)
+++ tomcat/trunk/java/javax/servlet/ServletResponseWrapper.java Sat Dec 17
22:51:29 2011
@@ -224,9 +224,7 @@ public class ServletResponseWrapper impl
* @param wrappedType
* @since Servlet 3.0 TODO SERVLET3 - Add comments
*/
-@SuppressWarnings("unchecked")
-// Spec API does not use generics
-public boolean isWrapperFor(@SuppressWarnings("rawtypes") Class
wrappedType) {
+public boolean isWrapperFor(Class wrappedType) {
if (wrappedType.isAssignableFrom(response.getClass())) {
return true;
}
Modified: tomcat/trunk/java/javax/servlet/annotation/HandlesTypes.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/annotation/HandlesTypes.java?rev=1220292&r1=1220291&r2=1220292&view=diff
==
--- tomcat/trunk/java/javax/servlet/annotation/HandlesTypes.java (original)
+++ tomcat/trunk/java/javax/servlet/annotation/HandlesTypes.java Sat Dec 17
22:51:29 2011
@@ -29,12 +29,11 @@ import java.lang.annotation.Target;
*/
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
-@SuppressWarnings("rawtypes") // Spec API does not use generics
public @interface HandlesTypes {
/**
* @return array of classes
*/
-Class[] value();
+Class[] value();
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1220293 - in /tomcat/trunk: java/org/apache/catalina/startup/Catalina.java java/org/apache/catalina/startup/LocalStrings.properties res/checkstyle/org-import-control.xml
Author: markt
Date: Sat Dec 17 22:52:18 2011
New Revision: 1220293
URL: http://svn.apache.org/viewvc?rev=1220293&view=rev
Log:
Fix cyclic JAR dependency and add check to ensure it doesn't return
Modified:
tomcat/trunk/java/org/apache/catalina/startup/Catalina.java
tomcat/trunk/java/org/apache/catalina/startup/LocalStrings.properties
tomcat/trunk/res/checkstyle/org-import-control.xml
Modified: tomcat/trunk/java/org/apache/catalina/startup/Catalina.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/Catalina.java?rev=1220293&r1=1220292&r2=1220293&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/Catalina.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/Catalina.java Sat Dec 17
22:52:18 2011
@@ -22,6 +22,7 @@ import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
+import java.lang.reflect.Constructor;
import java.net.Socket;
import java.util.ArrayList;
import java.util.HashMap;
@@ -34,13 +35,13 @@ import org.apache.catalina.LifecycleExce
import org.apache.catalina.LifecycleState;
import org.apache.catalina.Server;
import org.apache.catalina.core.StandardServer;
-import org.apache.catalina.ha.ClusterRuleSet;
import org.apache.catalina.security.SecurityConfig;
import org.apache.juli.ClassLoaderLogManager;
import org.apache.tomcat.util.ExceptionUtils;
import org.apache.tomcat.util.IntrospectionUtils;
import org.apache.tomcat.util.digester.Digester;
import org.apache.tomcat.util.digester.Rule;
+import org.apache.tomcat.util.digester.RuleSet;
import org.apache.tomcat.util.log.SystemLogHandler;
import org.apache.tomcat.util.res.StringManager;
import org.xml.sax.Attributes;
@@ -372,13 +373,13 @@ public class Catalina {
digester.addRuleSet(new EngineRuleSet("Server/Service/"));
digester.addRuleSet(new HostRuleSet("Server/Service/Engine/"));
digester.addRuleSet(new ContextRuleSet("Server/Service/Engine/Host/"));
-digester.addRuleSet(new
ClusterRuleSet("Server/Service/Engine/Host/Cluster/"));
+addClusterRuleSet(digester, "Server/Service/Engine/Host/Cluster/");
digester.addRuleSet(new
NamingRuleSet("Server/Service/Engine/Host/Context/"));
// When the 'engine' is found, set the parentClassLoader.
digester.addRule("Server/Service/Engine",
new SetParentClassLoaderRule(parentClassLoader));
-digester.addRuleSet(new
ClusterRuleSet("Server/Service/Engine/Cluster/"));
+addClusterRuleSet(digester, "Server/Service/Engine/Cluster/");
long t2=System.currentTimeMillis();
if (log.isDebugEnabled()) {
@@ -388,6 +389,27 @@ public class Catalina {
}
+/**
+ * Cluster support is optional. The JARs may have been removed.
+ */
+private void addClusterRuleSet(Digester digester, String prefix) {
+Class clazz = null;
+Constructor constructor = null;
+try {
+clazz = Class.forName("org.apache.catalina.ha.ClusterRuleSet");
+constructor = clazz.getConstructor(String.class);
+RuleSet ruleSet = (RuleSet) constructor.newInstance(prefix);
+digester.addRuleSet(ruleSet);
+} catch (Exception e) {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("catalina.noCluster",
+e.getClass().getName() + ": " + e.getMessage()), e);
+} else if (log.isInfoEnabled()) {
+log.info(sm.getString("catalina.noCluster",
+e.getClass().getName() + ": " + e.getMessage()));
+}
+}
+}
/**
* Create and configure the Digester we will be using for shutdown.
Modified: tomcat/trunk/java/org/apache/catalina/startup/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/LocalStrings.properties?rev=1220293&r1=1220292&r2=1220293&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/startup/LocalStrings.properties Sat
Dec 17 22:52:18 2011
@@ -14,6 +14,7 @@
# limitations under the License.
catalina.configFail=Unable to load server configuration from [{0}]
+catalina.noCluster=Cluster RuleSet not found due to [{0}]. Cluster
configuration disabled.
catalina.shutdownHookFail=The shutdown hook experienced an error while trying
to stop the server
catalina.stopServer=No shutdown port configured. Shut down server through OS
signal. Server not shut down.
contextConfig.altDDNotFound=alt-dd file {0} not found
Modified: tomcat/trunk/res/checkstyle/org-import-control.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/res/checkstyle/org-import-control.xml?rev=1220293&r1=12
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 17/12/2011 21:59, Mark Thomas wrote: > On 17/12/2011 21:12, David Jencks wrote: >> I'll try to keep it short because I really don't want to spend time >> re-beating this dead horse. >> >> The last time I looked a couple years ago the jars constructed out of >> the single source tree could not be compiled separately in any order. >> I was told this wasn't a problem, at which point I realized >> discussion was useless. > > I just did a check with JarAnalyzer and we still have circular > dependency issues with catalina.jar, catalina-ha.jar and catalina-tribes.jar These have been fixed in trunk and I'll port it to 7.0.x shortly. It looks like a recent clean-up change of mine introduced this so 7.0.x should have been buildable jar by jar for most of its life. There are some other dependencies I want to look into and I may have further commits to clean-up the dependencies shortly. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1220294 - /tomcat/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
Author: markt
Date: Sat Dec 17 22:52:54 2011
New Revision: 1220294
URL: http://svn.apache.org/viewvc?rev=1220294&view=rev
Log:
Fix startup failure when running with a SecurityManager
Modified:
tomcat/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
Modified: tomcat/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/security/SecurityClassLoad.java?rev=1220294&r1=1220293&r2=1220294&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/security/SecurityClassLoad.java Sat
Dec 17 22:52:54 2011
@@ -131,7 +131,6 @@ public final class SecurityClassLoad {
private static final void loadUtilPackage(ClassLoader loader)
throws Exception {
final String basePackage = "org.apache.catalina.util.";
-loader.loadClass(basePackage + "Enumerator");
loader.loadClass(basePackage + "ParameterMap");
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1220295 - /tomcat/trunk/conf/catalina.policy
Author: markt
Date: Sat Dec 17 22:53:20 2011
New Revision: 1220295
URL: http://svn.apache.org/viewvc?rev=1220295&view=rev
Log:
Add properties required by new logging helper when running under a
SecurityManager
Modified:
tomcat/trunk/conf/catalina.policy
Modified: tomcat/trunk/conf/catalina.policy
URL:
http://svn.apache.org/viewvc/tomcat/trunk/conf/catalina.policy?rev=1220295&r1=1220294&r2=1220295&view=diff
==
--- tomcat/trunk/conf/catalina.policy (original)
+++ tomcat/trunk/conf/catalina.policy Sat Dec 17 22:53:20 2011
@@ -85,6 +85,10 @@ grant codeBase "file:${catalina.home}/bi
permission java.util.PropertyPermission
"java.util.logging.config.class", "read";
permission java.util.PropertyPermission
"java.util.logging.config.file", "read";
permission java.util.PropertyPermission "catalina.base", "read";
+permission java.util.PropertyPermission
+ "org.apache.juli.logging.UserDataHelper.CONFIG", "read";
+permission java.util.PropertyPermission
+ "org.apache.juli.logging.UserDataHelper.SUPPRESSION_TIME", "read";
// Note: To enable per context logging configuration, permit read
access to
// the appropriate file. Be sure that the logging configuration is
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1220296 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/startup/Catalina.java java/org/apache/catalina/startup/LocalStrings.properties res/checkstyle/org-import-control.xml
Author: markt Date: Sat Dec 17 22:53:51 2011 New Revision: 1220296 URL: http://svn.apache.org/viewvc?rev=1220296&view=rev Log: Fix cyclic JAR dependency and add check to ensure it doesn't return Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/Catalina.java tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/LocalStrings.properties tomcat/tc7.0.x/trunk/res/checkstyle/org-import-control.xml Propchange: tomcat/tc7.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Sat Dec 17 22:53:51 2011 @@ -1 +1 @@ -/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,1157908,1157939,1158155,1158160,1158176,1158195,1158198-1158199,1158227,1158331,1158334-1158335,1158426,1160347,1160592,1160611,1160619,1160626,1160639,1160652,1160720-1160721,1160772,1160774,1160776,1161303,1161310,1161322,1161339,1161486,1161540,1161549,1161584,1162082,1162149,1162169,1162721,1162769,1162836,1162932,1163630,1164419,1164438,1164469,1164480,1164567,1165234,1165247-1165248,1165253,1165273,1165282,1165309,1165331,1165338,1165347,1165360-1165361,1165367-1165368,1165602,1165608,1165677,1165693,1165721,1165723,1165728,1165730,1165738,1165746,1165765,1165777,1165918,1165921,1166077,1166150-1166151,1166290,1166366,1166620,1166686,1166693,1166752,1166757,1167368,1167394,1169447,1170647,1171692,1172233-1172234,1172236,1172269,1172278,1172282,1172556,1172610,1172664,1172689,1172711,1173020-1173021,1173082,1173088,1173090,1173096 ,1173241,1173256,1173288,117,1173342,1173461,1173614,1173630,1173659,1173722,1174061,1174239,1174322,1174325,1174329-1174330,1174337-1174339,1174343,1174353,1174799,1174882,1174884,1174983,1175155,1175158,1175167,1175182,1175190,1175201,1175272,1175275,1175283,1175582,1175589-1175590,1175594,1175602,1175613,1175633,1175690,1175713,1175798,1175889,1175896,1175907,1176584,1176590,1176799,1177050,1177060,1177125,1177152,1177160,1177245,1177850,1177862,1177978,1178209,1178228,1178233,1178449,1178542,1178681,1178684,1178721,1179268,1179274,1180261,1180865,1180891,1180894,1180907,1181028,1181123,1181125,1181136,1181291,1181743,1182796,1183078,1183105,1183142,1183328,1183339-1183340,1183492-1183494,1183605,1184917,1184919,1185018,1185020,1185200,1185588,1185626,1185756,1185758,1186011,1186042-1186045,1186104,1186123,1186137,1186153,1186254,1186257,1186377-1186379,1186479-1186480,1186712,1186743,1186750,1186763,1186890-1186892,1186894,1186949,1187018,1187027-1187028,1187381,1187 753,1187755,1187775,1187801,1187806,1187809,1187827,1188301,1188303-1188305,1188399,1188822,1188930-1188931,1189116,1189129,1189183,1189240,1189256,1189386,1189413-1189414,1189477,1189685,1189805,1189857,1189864,1189882,1190034,1190185,1190279,1190339,1190371,1190388-1190389,1190474,1190481,1194915,1195222-1195223,1195531,1195899,1195905,1195943,1195949,1195953,1195955,1195965,1195968,1196175,1196212,1196223,1196304-1196305,1196735,1196825,1196827,1197158,1197261,1197263,1197299-1197300,1197305,1197339-1197340,1197343,1197382,1197386-1197387,1197480,1197578,1198497,1198528,1198552,1198602,1198604,1198607,1198622,1198640,1198696,1198707,1199418,1199432,1199436,1199513,1199529,1199980,116,1200056,1200089,1200106-1200107,1200263,1200316,1200320,1200398-1200399,1200445-1200446,1200555,1200627,1200696,1200725,1200937,1200941,1201069,1201087,1201180,1201235-1201237,1201508,1201521,1201542,1201545-1201546,1201548,1201555-1201556,1201568,1201576,1201608,1201921-1201922,1201931,1 202035,1202039,1202271,1202565,1202578,1202705,1202828,1202860,1203047-1203052,1203078,1203091,1203253,1203278,1204182,1204856,1204867,1204936,1204938,1204982,1205033,1205065,1205082,1205097,1205112,1206200,1207692,1208046,1208073,1208096,1208114,1208145,1208772,1209194,1209277-1209278,1209686-1209731,1210894,1212091,1212095,1212099,1212118,1213469,1213906,1214853,1214855,1214864,1215115,1215118-1215119,1215121 +/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,1157908,1157939,1158155,1158160,1158176,1158195,1158198-1158199,1158227,1158331,1158334-1158335,1158426,1160347,1160592,1160611,1160619,1160626,1160639,1160652,1160720-1160721,1160772,1160774,1160776,1161303,1161310,1161322,1161339,1161486,1161540,1161549,1161584,1162082,1162149,1162169,1162721,1162769,1162836,1162932,1163630,1164419,1164438,1164469,1164480,1164567,1165234,1165247-1165248,1165253,1165273,1165282,1165309,1165331,1165338,1165347,1165360-1165361,1165367-1165368,1165602,1165608,1165677,1165693,1165721,1165723,1165728,1165730,1165738,1165746,1165765,1165777,1165918,1165921,1166077,1166150-1166151,1166290,1166366,1166620,1166686,1166693,1166752,1166757,1167368,1167394,1169447,1170647,1171692,1172233-1172234,1172236,1172269,1172278,1172282,1172556,1172610,1172664,1172689,11727
svn commit: r1220297 - in /tomcat/tc7.0.x/trunk: ./ conf/catalina.policy
Author: markt Date: Sat Dec 17 22:55:28 2011 New Revision: 1220297 URL: http://svn.apache.org/viewvc?rev=1220297&view=rev Log: Add properties required by new logging helper when running under a SecurityManager Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/conf/catalina.policy Propchange: tomcat/tc7.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Sat Dec 17 22:55:28 2011 @@ -1 +1 @@ -/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,1157908,1157939,1158155,1158160,1158176,1158195,1158198-1158199,1158227,1158331,1158334-1158335,1158426,1160347,1160592,1160611,1160619,1160626,1160639,1160652,1160720-1160721,1160772,1160774,1160776,1161303,1161310,1161322,1161339,1161486,1161540,1161549,1161584,1162082,1162149,1162169,1162721,1162769,1162836,1162932,1163630,1164419,1164438,1164469,1164480,1164567,1165234,1165247-1165248,1165253,1165273,1165282,1165309,1165331,1165338,1165347,1165360-1165361,1165367-1165368,1165602,1165608,1165677,1165693,1165721,1165723,1165728,1165730,1165738,1165746,1165765,1165777,1165918,1165921,1166077,1166150-1166151,1166290,1166366,1166620,1166686,1166693,1166752,1166757,1167368,1167394,1169447,1170647,1171692,1172233-1172234,1172236,1172269,1172278,1172282,1172556,1172610,1172664,1172689,1172711,1173020-1173021,1173082,1173088,1173090,1173096 ,1173241,1173256,1173288,117,1173342,1173461,1173614,1173630,1173659,1173722,1174061,1174239,1174322,1174325,1174329-1174330,1174337-1174339,1174343,1174353,1174799,1174882,1174884,1174983,1175155,1175158,1175167,1175182,1175190,1175201,1175272,1175275,1175283,1175582,1175589-1175590,1175594,1175602,1175613,1175633,1175690,1175713,1175798,1175889,1175896,1175907,1176584,1176590,1176799,1177050,1177060,1177125,1177152,1177160,1177245,1177850,1177862,1177978,1178209,1178228,1178233,1178449,1178542,1178681,1178684,1178721,1179268,1179274,1180261,1180865,1180891,1180894,1180907,1181028,1181123,1181125,1181136,1181291,1181743,1182796,1183078,1183105,1183142,1183328,1183339-1183340,1183492-1183494,1183605,1184917,1184919,1185018,1185020,1185200,1185588,1185626,1185756,1185758,1186011,1186042-1186045,1186104,1186123,1186137,1186153,1186254,1186257,1186377-1186379,1186479-1186480,1186712,1186743,1186750,1186763,1186890-1186892,1186894,1186949,1187018,1187027-1187028,1187381,1187 753,1187755,1187775,1187801,1187806,1187809,1187827,1188301,1188303-1188305,1188399,1188822,1188930-1188931,1189116,1189129,1189183,1189240,1189256,1189386,1189413-1189414,1189477,1189685,1189805,1189857,1189864,1189882,1190034,1190185,1190279,1190339,1190371,1190388-1190389,1190474,1190481,1194915,1195222-1195223,1195531,1195899,1195905,1195943,1195949,1195953,1195955,1195965,1195968,1196175,1196212,1196223,1196304-1196305,1196735,1196825,1196827,1197158,1197261,1197263,1197299-1197300,1197305,1197339-1197340,1197343,1197382,1197386-1197387,1197480,1197578,1198497,1198528,1198552,1198602,1198604,1198607,1198622,1198640,1198696,1198707,1199418,1199432,1199436,1199513,1199529,1199980,116,1200056,1200089,1200106-1200107,1200263,1200316,1200320,1200398-1200399,1200445-1200446,1200555,1200627,1200696,1200725,1200937,1200941,1201069,1201087,1201180,1201235-1201237,1201508,1201521,1201542,1201545-1201546,1201548,1201555-1201556,1201568,1201576,1201608,1201921-1201922,1201931,1 202035,1202039,1202271,1202565,1202578,1202705,1202828,1202860,1203047-1203052,1203078,1203091,1203253,1203278,1204182,1204856,1204867,1204936,1204938,1204982,1205033,1205065,1205082,1205097,1205112,1206200,1207692,1208046,1208073,1208096,1208114,1208145,1208772,1209194,1209277-1209278,1209686-1209731,1210894,1212091,1212095,1212099,1212118,1213469,1213906,1214853,1214855,1214864,1215115,1215118-1215119,1215121,1220293 +/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,1157908,1157939,1158155,1158160,1158176,1158195,1158198-1158199,1158227,1158331,1158334-1158335,1158426,1160347,1160592,1160611,1160619,1160626,1160639,1160652,1160720-1160721,1160772,1160774,1160776,1161303,1161310,1161322,1161339,1161486,1161540,1161549,1161584,1162082,1162149,1162169,1162721,1162769,1162836,1162932,1163630,1164419,1164438,1164469,1164480,1164567,1165234,1165247-1165248,1165253,1165273,1165282,1165309,1165331,1165338,1165347,1165360-1165361,1165367-1165368,1165602,1165608,1165677,1165693,1165721,1165723,1165728,1165730,1165738,1165746,1165765,1165777,1165918,1165921,1166077,1166150-1166151,1166290,1166366,1166620,1166686,1166693,1166752,1166757,1167368,1167394,1169447,1170647,1171692,1172233-1172234,1172236,1172269,1172278,1172282,1172556,1172610,1172664,1172689,1172711,1173020-1173021,1173082,1173088,1173090,1173096 ,1173241,1173256,1173288,117,1173342,1173461,1173614,1173630,1173659,1173722,1174061,117423
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
I forgot to mention that geronimo has been re-releasing several versions of tomcat built with maven. We have a script to set up a maven multi module project structure and distribute the tomcat source code from tomcat svn into the maven projects. This stuff is under https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-archetype with e.g an example of what you get from the script under https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-7.0.19 thanks david jencks On Dec 17, 2011, at 1:12 PM, David Jencks wrote: > I'll try to keep it short because I really don't want to spend time > re-beating this dead horse. > > The last time I looked a couple years ago the jars constructed out of the > single source tree could not be compiled separately in any order. I was told > this wasn't a problem, at which point I realized discussion was useless. > > Maven prevents problems like this through the project structure. If this > situation is not a problem to the tomcat community, then the other possible > benefits of using maven are not likely to be interesting either. > > thanks > david jencks > > On Dec 17, 2011, at 12:48 PM, Mark Thomas wrote: > >> 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. >> >>> 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. The dependencies are known and >> we have checks in place (via Checkstyle) to ensure that unwanted >> dependencies are not added. 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. >> >>> 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? >> >>> 4. POMs are (almost) universal. Projects of the same kind have almost the >>> same content.. >> >> How does this benefit the Tomcat community? >> >>> 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? >> >>> 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). >> >> 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.). >> >> 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
[jira] [Commented] (MTOMCAT-108) THe httpsPort flag starts another http thread not an https thread
[ https://issues.apache.org/jira/browse/MTOMCAT-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13171763#comment-13171763 ] Brad Giaccio commented on MTOMCAT-108: -- @Oliver 1. Sorry about the formatting I tried to follow what you had, as odd as it looked. If you can't take it as is then I'll have to fix it on Monday. 2. As for the obfuscate stuff, its most definitely breakable but at least 'protects' it from prying eyes. In the environment I'll be using this having plain texts passwords is a deal breaker and will mean I can't install my software, so please please keep it. If there is anything else I can do let me know > THe httpsPort flag starts another http thread not an https thread > - > > Key: MTOMCAT-108 > URL: https://issues.apache.org/jira/browse/MTOMCAT-108 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat7 >Affects Versions: 2.0 > Environment: MAc OSX 10.6.8 >Reporter: Keith Corbin >Assignee: Olivier Lamy > Fix For: 2.0 > > Attachments: https.patch > > > WHen you run the executable war the httpsPort flag starts an http protocol > listener thread on the port listed not an https protocol listener. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-tc7.0.x-test (in module tomcat-7.0.x) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-tc7.0.x-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-tc7.0.x-test : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property tomcat-dbcp-src.jar. -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property tomcat-dbcp.home. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-7.0.x/output/build/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-test.html Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 mins 58 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-18122011.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-18122011-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-18122011-native-src.tar.gz -Dexamples.sources.skip=true -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps -Djdt.jar=/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-18122011.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-src.jar -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x -Dcommons-dbcp.home=/srv/gump/public/worksp ace/commons-dbcp-1.x -Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-18122011.jar test [Working Directory: /srv/gump/public/workspace/tomcat-7.0.x] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-7.0.x/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/servlet-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/outp ut/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-util.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-7. 0.x/tomcat-deps/tomcat-dbcp-18122011.jar:/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-18122011.jar:/srv/gump/public/workspace/junit/dist/junit-18122011.jar
Bug report for Taglibs [2011/12/18]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |38193|Ass|Enh|2006-01-09|[RDC] BuiltIn Grammar support for Field | |38600|Ass|Enh|2006-02-10|[RDC] Enable RDCs to be used in X+V markup (X+RDC)| |42413|New|Enh|2007-05-14|[PATCH] Log Taglib enhancements | |46052|New|Nor|2008-10-21|SetLocaleSupport is slow to initialize when many l| |48333|New|Enh|2009-12-02|TLD generator | |50825|New|Nor|2011-02-24|Site still has links to Jakarta for mailing lists | |51234|New|Nor|2011-05-20|NumberFormatException in fmt:formatNumber tag | |51382|New|Blk|2011-06-15|Link to download pages are broken | +-+---+---+--+--+ | Total8 bugs | +---+ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Bug report for Tomcat 6 [2011/12/18]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |41679|New|Enh|2007-02-22|SemaphoreValve should be able to filter on url pat| |41883|Ass|Enh|2007-03-18|use abstract wrapper instead of plain X509Certific| |43001|New|Enh|2007-07-30|JspC lacks setMappedFile and setDie for use in Ant| |43400|New|Enh|2007-09-14|enum support for tag libs | |43548|Opn|Enh|2007-10-04|xml schema for tomcat-users.xml | |43682|New|Enh|2007-10-23|JULI: web-inf/classes/logging.properties to suppor| |43742|New|Enh|2007-10-30|.tag compiles performed one at a time -- extremel| |43979|New|Enh|2007-11-27|Add abstraction for Java and Classfile output | |44199|New|Enh|2008-01-10|expose current backlog queue size | |44225|New|Enh|2008-01-14|SSL connector tries to load the private keystore f| |44264|New|Enh|2008-01-18|Clustering - Support for disabling multicasting an| |44284|New|Enh|2008-01-23|Support java.lang.Iterable in c:forEach tag | |44294|New|Enh|2008-01-25|Support for EL functions with varargs | |44312|New|Enh|2008-01-28|Warn when overwritting docBase of the default Host| |44645|New|Enh|2008-03-20|[Patch] JNDIRealm - Doesn't support JNDI "java.nam| |44787|New|Enh|2008-04-09|provide more error context on "java.lang.IllegalSt| |44818|New|Enh|2008-04-13|tomcat hangs with GET when content-length is defin| |45014|New|Enh|2008-05-15|Request and Response classes should have wrappers | |45282|New|Enh|2008-06-25|NioReceiver doesn't close cleanly, leaving sockets| |45283|Opn|Enh|2008-06-25|Provide a JSR196 implementation | |45428|New|Enh|2008-07-18|warn if the tomcat stop doesn't complete | |45832|New|Enh|2008-09-18|add DIGEST authentication support to Ant tasks| |45878|New|Enh|2008-09-24|Generated jars do not contain proper manifests or | |45879|Opn|Enh|2008-09-24|Windows installer fails to install NOTICE and RELE| |45931|Opn|Enh|2008-10-01|trimSpaces incorrectly modifies output| |45995|New|Enh|2008-10-13|RFE - MIME type extension not case sensitive | |46173|New|Enh|2008-11-09|Small patch for manager app: Setting an optional c| |46263|New|Enh|2008-11-21|Tomcat reloading of context does not update contex| |46284|New|Enh|2008-11-24|Add flag to DeltaManager that blocks processing cl| |46350|New|Enh|2008-12-05|Maven repository should contain source bundles| |46497|New|Enh|2009-01-08|Install Tomcat Deployer/ANT on Windows Platform | |46655|New|Enh|2009-02-03|keystore's password handler | |46727|New|Enh|2009-02-17|DefaultServlet - serving multiple encodings | |46902|New|Enh|2009-03-24|LoginValve to bypass restrictions of j_security_ch| |47214|New|Enh|2009-05-17|Inner classes that are explicitly referenced - sho| |47230|New|Enh|2009-05-21|Include sample cert attributes for SSL connectors | |47242|New|Enh|2009-05-22|request for AJP command line client | |47281|New|Enh|2009-05-28|Efficiency of the JDBCStore | |47407|New|Enh|2009-06-23|HttpSessionListener doesn't operate in the session| |47467|New|Enh|2009-07-02|Deployment of the war file by URL when contextpath| |47785|Opn|Enh|2009-09-04|Cluster MBean not registered | |47834|New|Enh|2009-09-14|TldConfig throws Exception when exploring unpacked| |47919|New|Enh|2009-09-30|Log Tomcat & Java environment variables in additio| |48543|New|Enh|2010-01-14|[Patch] More flexibility in specifying -Dcatalina.| |48600|Opn|Enh|2010-01-22|Performance issue with tags | |48672|New|Enh|2010-02-03|Tomcat Virtual Host Manager (/host-manager) have b| |48674|New|Enh|2010-02-03|Tomcat Virtual Host Manager application doesn't pe| |48743|New|Enh|2010-02-15|Make the SLEEP variable in catalina.sh settable fr| |48899|New|Enh|2010-03-12|Guess URI charset should solve lot of problems| |48922|New|Enh|2010-03-16|org.apache.catalina.connector.Request clone static| |48928|New|Enh|2010-03-17|An alternative solution to preloading classes when| |49161|
Bug report for Tomcat Connectors [2011/12/18]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |34526|Opn|Nor|2005-04-19|Truncated content in decompressed requests from mo| |35959|Opn|Enh|2005-08-01|mod_jk not independant of UseCanonicalName| |43303|New|Enh|2007-09-04|Versioning under Windows not reported by many conn| |43968|Inf|Enh|2007-11-26|[patch] support ipv6 with mod_jk | |44290|Inf|Nor|2008-01-24|mod_jk/1.2.26: retry is not useful for an importan| |44349|Inf|Maj|2008-02-04|mod_jk/1.2.26 module does not read worker.status.s| |44379|New|Enh|2008-02-07|convert the output of strftime into UTF-8 | |44454|New|Nor|2008-02-19|busy count reported in mod_jk inflated, causes inc| |44571|New|Enh|2008-03-10|Limits busy per worker to a threshold | |45063|New|Nor|2008-05-22|JK-1.2.26 IIS ISAPI filter issue when running diff| |45313|New|Nor|2008-06-30|mod_jk 1.2.26 & apache 2.2.9 static compiled on so| |46337|New|Nor|2008-12-04|real worker name is wrong | |46676|New|Enh|2009-02-09|Configurable test request for Watchdog thread | |46767|New|Enh|2009-02-25|mod_jk to send DECLINED in case no fail-over tomca| |47327|New|Enh|2009-06-07|remote_user not logged in apache logfile | |47617|Inf|Enh|2009-07-31|include time spent doing ajp_get_endpoint() in err| |47678|New|Cri|2009-08-11|Unable to allocate shared memory when using isapi_| |47714|New|Cri|2009-08-20|Reponse mixed between users | |47750|New|Maj|2009-08-27|Loss of worker settings when changing via jkstatus| |47795|New|Maj|2009-09-07|service sticky_session not being set correctly wit| |47840|Inf|Min|2009-09-14|A broken worker name is written in the log file. | |48191|New|Maj|2009-11-13|Problem with mod_jk 1.2.28 - Can not render up the| |48460|New|Nor|2009-12-30|mod_proxy_ajp document has three misleading portio| |48490|New|Nor|2010-01-05|Changing a node to stopped in uriworkermap.propert| |48513|New|Enh|2010-01-09|IIS Quick setup instructions | |48564|New|Nor|2010-01-18|Unable to turn off retries for LB worker | |48830|New|Nor|2010-03-01|IIS shutdown blocked in endpoint service when serv| |48891|Opn|Enh|2010-03-11|Missing EOL-style settings in tomcat/jk/trunk | |49035|New|Maj|2010-04-01|data lost when post a multipart/form-data form| |49063|New|Enh|2010-04-07|Please add JkStripSession status in jk-status work| |49135|New|Enh|2010-04-16|SPDY Connector for The Tomcat | |49469|New|Enh|2010-06-19|Workers status page has negative number of connect| |49732|Opn|Nor|2010-08-10|reply_timeout can't wait forever. | |49822|New|Enh|2010-08-25|Add hash lb worker method | |49903|New|Enh|2010-09-09|Make workers file reloadable | |50186|New|Nor|2010-10-31|Wrong documentation of connection_pool_timeout / c| |50511|Inf|Nor|2010-12-22|WARNING about Internal Dummy Connection of Apache | |51235|Inf|Maj|2011-05-20|Access Violation in httpd.exe originating in mod_j| |51767|New|Maj|2011-09-06|isapi_redirect intermittently crashes iis worker p| |52074|New|Maj|2011-10-23|PATH_INFO not passed from IIS7 to Tomcat7 | |52270|New|Cri|2011-12-01|isapi rediderctor hangs IIS 7.5 APP POOL | |52286|New|Maj|2011-12-05|isapi 1.2.32 fails to reload after worker processe| |52334|New|Maj|2011-12-14|recover_time is not properly used | +-+---+---+--+--+ | Total 43 bugs | +---+ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Bug report for Tomcat 7 [2011/12/18]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |10021|New|Enh|2002-06-19|Include upgrade option in installer | |16579|New|Enh|2003-01-30|documentation page layout/style breaks wrapping to| |18500|New|Enh|2003-03-30|Host aliases to match by regular expression | |48358|Opn|Enh|2009-12-09|JSP-unloading reloaded| |48550|Inf|Enh|2010-01-14|Update examples and default server.xml to use UTF-| |48892|New|Enh|2010-03-11|Use URIEncoding from server.xml for decoding post | |49395|New|Enh|2010-06-06|manager.findLeaks : display the date when the leak| |49589|New|Enh|2010-07-12|Tag handlers with constant attribute values are al| |49785|New|Enh|2010-08-19|Enabling TLS for JNDIRealm| |49821|New|Enh|2010-08-25|Tomcat CLI| |50019|New|Enh|2010-09-28|Adding JNDI "lookup-name" support In XML and Resou| |50175|New|Enh|2010-10-28|Enhance memory leak detection by selectively apply| |50234|New|Enh|2010-11-08|JspC use servlet 3.0 features | |50504|New|Enh|2010-12-21|Allow setting query string character set trough re| |50670|New|Enh|2011-01-27|Tribes | RpcChannel | Add option to specify extern| |51181|New|Enh|2011-05-10|Add support for Web Sockets | |51195|New|Enh|2011-05-13|"Find leaks" reports a false positive memory/class| |51334|New|Enh|2011-06-07|Web SSO support based on WS-Federation Passive Req| |51408|Opn|Enh|2011-06-21|String.getBytes() and new String(byte[]) use defau| |51423|Inf|Enh|2011-06-23|[Patch] to add a path and a version parameters to | |51463|New|Enh|2011-07-01|Tomcat.setBaseDir (package org.apache.catalina.st| |51496|New|Enh|2011-07-11|NSIS - Warn that duplicate service name will resul| |51497|New|Enh|2011-07-11|Use canonical IPv6 text representation in logs| |51500|New|Enh|2011-07-12|NSIS - Allow configuration of more service propert| |51526|New|Enh|2011-07-18|Process web application context config with embedd| |51587|New|Enh|2011-07-29|Implement status and uptime commands | |51717|New|Enh|2011-08-24|Provide a way to disable EL cache | |51953|New|Enh|2011-10-04|Proposal: netmask filtering valve and filter | |52092|New|Enh|2011-10-26|Please make AsyncFileHandler and OneLineFormatter | |52134|New|Enh|2011-11-04|HostConfig#deployDirectories Deploys Every Directo| |52213|New|Nor|2011-11-18|Field "org.apache.catalina.tribes.transport.bio.ut| |52234|New|Nor|2011-11-23|More documentation of embedding, please? | |52235|New|Enh|2011-11-23|Please do a bit of SEO tuning for the web site| |52236|New|Enh|2011-11-23|Idea: support 'overlays' shaped like Maven overlay| |52243|New|Trv|2011-11-25|Documentation of Service-Installer missing one inf| |52245|New|Enh|2011-11-25|Add detection of EL Jar to WebappClassLoader | |52263|New|Nor|2011-11-29|static membership cluster fails to establish membe| |52303|New|Min|2011-12-08|NonLoginAuthenticator does not honour session time| |52316|New|Nor|2011-12-09|AccessLog does not log size for files sent with se| |52323|New|Enh|2011-12-13|Cobertura test code coverage support for build.xml| |52326|New|Min|2011-12-13|Lower log level for failed class loading | |52328|New|Reg|2011-12-14|Massive garbage production observed when using the| +-+---+---+--+--+ | Total 42 bugs | +---+ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Bug report for Tomcat 5 [2011/12/18]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |28039|Opn|Enh|2004-03-30|Cluster Support for SingleSignOn | |38216|Inf|Enh|2006-01-10|Extend Jmxproxy to allow call of MBean Operations | |40728|New|Enh|2006-10-11|Catalina MBeans use non-serializable classes | |40766|New|Enh|2006-10-16|Using an unsecure jsessionid with mod_proxy_ajp ov| |40881|Opn|Enh|2006-11-02|Unable to receive message through TCP channel -> | |41007|Opn|Enh|2006-11-20|Can't define customized 503 error page| |41697|Ver|Enh|2007-02-25|make visible in debug output if charset from brows| |43866|New|Enh|2007-11-14|add support for session attribute propagation with| |43925|Opn|Enh|2007-11-21|org.apache.jasper.runtime.BodyContentImpl causing | |44216|New|Enh|2008-01-11|Don't reuse session ID even if emptySessionPath=tr| |44904|New|Enh|2008-04-29|Provide warning message when DataSource's maxActiv| |52335|New|Nor|2011-12-15|Tomcat escapes all the \% in Template Text as %. | +-+---+---+--+--+ | Total 12 bugs | +---+ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Bug report for Tomcat Native [2011/12/18]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |45392|New|Nor|2008-07-14|No OCSP support for client SSL verification | |46179|Opn|Maj|2008-11-10|apr ssl client authentication | |48655|Inf|Nor|2010-02-02|Active multipart downloads prevent tomcat shutdown| |49038|Inf|Nor|2010-04-02|Crash in tcnative | |51477|Opn|Enh|2011-07-05|Support all protocol combinations in SSLProtocol o| |51655|New|Nor|2011-08-12|Index page does not say what native does | |51813|New|Cri|2011-09-14|Tomcat randomly crashes with [libtcnative-1.so.1+0| |52119|New|Nor|2011-11-01|Add Diablo JDK to default JDK location search path| |52153|New|Maj|2011-11-08|periodic JVM crash (access violation) on buffer fl| |52231|New|Nor|2011-11-23|Ant Tasks need to reflect changes in manager comma| |52319|New|Maj|2011-12-12|Tomcat 6 crashes with [libapr-1.so.0+0x196da] sig| +-+---+---+--+--+ | Total 11 bugs | +---+ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Bug report for Tomcat Modules [2011/12/18]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |48240|New|Nor|2009-11-19|Tomcat-Lite missing @Override markers | |48268|New|Nor|2009-11-23|Patch to fix generics in tomcat-lite | |48861|New|Nor|2010-03-04|Files without AL headers | |49685|New|Nor|2010-08-02|Unsafe synchronization in class ManagedBean | |49686|New|Nor|2010-08-02|Using an instance lock to protect static shared da| |49953|Opn|Nor|2010-09-17|Missing @Override annotations | |50565|New|Min|2011-01-10|Static variables should be accessed in a static wa| |50566|New|Nor|2011-01-10|Duplicate assignment to connection variable | |50571|Inf|Nor|2011-01-11|Tomcat 7 JDBC connection pool exception enhancemen| |50660|New|Min|2011-01-26|Improve validationQuery error handling| |50860|New|Nor|2011-03-03|In case of invalid or empty slqQuery connection ar| |50864|New|Nor|2011-03-03|Reconfigure pool on the fly using JMX | |51198|New|Nor|2011-05-13|Trunk Version : Performance enhancement in Connect| |51237|New|Nor|2011-05-20|SlowQueryReport interceptor does not log anything | |51388|New|Enh|2011-06-16|SlowQueryReport should respect Statement.getQueryT| |51582|New|Maj|2011-07-29|NPE in SlowQueryReport| |51595|New|Nor|2011-08-01|org.apache.tomcat.jdbc.pool.jmx.ConnectionPool sho| |51879|New|Enh|2011-09-22|Improve access to Native Connection Methods | |51893|New|Nor|2011-09-26|JMX notification/Exception for empty/exhausted con| |52002|New|Nor|2011-10-10|Pool re-opens and re-issues closed connection | |52024|New|Enh|2011-10-13|Custom interceptor to support automatic failover o| |52066|New|Nor|2011-10-20|ConnectionPool.borrowConnection swallows interrupt| |52318|New|Cri|2011-12-11|Version in POM is conflicted with Version in MANIF| |52327|New|Nor|2011-12-14|DataSourceProxy is not thread-safe| +-+---+---+--+--+ | Total 24 bugs | +---+ - 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 12/17/2011 07:27 PM, Mark Thomas wrote: Jean-Frederic, what was your motivation for moving Tomcat to Nexus? 1 - The good thing in Nexus is that we can check the result of our "deploy-release" and drop is we screw it (multi upload can fail and we don't know when the mirroring stars). 2 - Users using maven can test easy the jar in staging Nexus repository. 3 - I was looking to fix BZ 52124 a clean way. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
