svn commit: r816076 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: jfclere Date: Thu Sep 17 07:05:22 2009 New Revision: 816076 URL: http://svn.apache.org/viewvc?rev=816076&view=rev Log: My vote. Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=816076&r1=816075&r2=816076&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Sep 17 07:05:22 2009 @@ -319,7 +319,7 @@ Note: Patch cannot be applied until tc-native 1.1.17 has been released since it depends on a new native method http://svn.apache.org/viewvc?rev=815418&view=rev - +1: markt + +1: markt, jfclere -1: * Fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=47161 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47760] Ant deploy task's config attribute not working
https://issues.apache.org/bugzilla/show_bug.cgi?id=47760
--- Comment #2 from Uwe Günther 2009-09-17 08:53:26 PDT ---
I did a bit of investigation in this one.:
1) It seems to me this isn't a bug.
2) It seems to me you are mixing up two different deployment methods.
But let me explain it:
>From my point of view there is
a) a local deployment functionality and
b) a remote deployment functionality
In a) you can deploy a war file or a webapp directory to a local installed
tomcat with or without a context fragment. Note: You have here a hard
precondition: All files are local to the tomcat you want to deploy to.
In this case your ant target should look like this:
present:${present}
In b) you can only deploy a war file via HTTP PUT to your remote tomcat
installation via the manager servlet. In this case you have to put your context
fragment (pr.xml in your case) in META-INF/context.xml in your *.war file. You
have to do this because it is not possible to upload a config file (context
fragment aka context.xml) to a remote server via the manager webapp which gets
used by the deploy task.
In this case your ant target should look like this:
present:${present}
Note: In b) Your context fragment from build/pr.xml has to be in
${app.name}.war!/META-INF/context.xml. While the deployment it gets copied to
$CATALINA_BASE/conf/[engine]/[host]/[context].xml. In your case this would be
$CATALINA_BASE/conf/Catalina/localhost/pr.xml.
For more information you can consult the following two links:
If you lock in the execute methode of the AntDeploy Task your observations
become really obvious:
// line 182
if ((war == null) && (config != null)) {
sb.append("&config=");
sb.append(URLEncoder.encode(config, getCharset()));
}
if ((war == null) && (localWar != null)) {
sb.append("&war=");
sb.append(URLEncoder.encode(localWar, getCharset()));
}
// to 189
--
Kind Regards
Uwe Günther
--
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 47760] Ant deploy task's config attribute not working
https://issues.apache.org/bugzilla/show_bug.cgi?id=47760 Uwe Günther changed: What|Removed |Added CC||u...@cscc.de -- 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
svn commit: r816252 - /tomcat/trunk/java/org/apache/juli/FileHandler.java
Author: fhanik
Date: Thu Sep 17 16:07:13 2009
New Revision: 816252
URL: http://svn.apache.org/viewvc?rev=816252&view=rev
Log:
Enable the ability to disable the buffered writer. This does bunch of copying
when writing using an async thread there is no need for such a thing
Modified:
tomcat/trunk/java/org/apache/juli/FileHandler.java
Modified: tomcat/trunk/java/org/apache/juli/FileHandler.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/juli/FileHandler.java?rev=816252&r1=816251&r2=816252&view=diff
==
--- tomcat/trunk/java/org/apache/juli/FileHandler.java (original)
+++ tomcat/trunk/java/org/apache/juli/FileHandler.java Thu Sep 17 16:07:13 2009
@@ -292,11 +292,11 @@
String pathname = dir.getAbsolutePath() + File.separator +
prefix + date + suffix;
String encoding = getEncoding();
-OutputStream os = new BufferedOutputStream(new FileOutputStream(
-pathname, true),bufferSize);
+FileOutputStream fos = new FileOutputStream(pathname, true);
+OutputStream os = bufferSize>0?new
BufferedOutputStream(fos,bufferSize):fos;
writer = new PrintWriter(
(encoding != null) ? new OutputStreamWriter(os, encoding)
-: new OutputStreamWriter(os), true);
+ : new OutputStreamWriter(os), true);
writer.write(getFormatter().getHead(this));
} catch (Exception e) {
reportError(null, e, ErrorManager.OPEN_FAILURE);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r816254 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Author: markt
Date: Thu Sep 17 16:10:05 2009
New Revision: 816254
URL: http://svn.apache.org/viewvc?rev=816254&view=rev
Log:
Replace parseException instance field
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Modified: tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java?rev=816254&r1=816253&r2=816254&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Thu Sep 17
16:10:05 2009
@@ -115,12 +115,6 @@
/**
- * Any parse error which occurred while parsing XML descriptors.
- */
-protected SAXParseException parseException = null;
-
-
-/**
* Original docBase.
*/
protected String originalDocBase = null;
@@ -351,7 +345,8 @@
((StandardContext)
context).setReplaceWelcomeFiles(true);
}
webDigester.push(context);
-webDigester.setErrorHandler(new ContextErrorHandler());
+ContextErrorHandler errorHandler = new
ContextErrorHandler();
+webDigester.setErrorHandler(errorHandler);
if(log.isDebugEnabled()) {
log.debug("Parsing application web.xml file at " +
url.toExternalForm());
@@ -359,7 +354,7 @@
webDigester.parse(is);
-if (parseException != null) {
+if (errorHandler.getParseException() != null) {
ok = false;
}
} else {
@@ -376,7 +371,6 @@
ok = false;
} finally {
webDigester.reset();
-parseException = null;
try {
stream.close();
} catch (IOException e) {
@@ -688,9 +682,10 @@
digester.setClassLoader(this.getClass().getClassLoader());
digester.setUseContextClassLoader(false);
digester.push(context);
-digester.setErrorHandler(new ContextErrorHandler());
+ContextErrorHandler errorHandler = new ContextErrorHandler();
+digester.setErrorHandler(errorHandler);
digester.parse(source);
-if (parseException != null) {
+if (errorHandler.getParseException() != null) {
ok = false;
}
} catch (SAXParseException e) {
@@ -704,7 +699,6 @@
ok = false;
} finally {
digester.reset();
-parseException = null;
try {
if (stream != null) {
stream.close();
@@ -790,9 +784,10 @@
contextDigester.setUseContextClassLoader(false);
contextDigester.push(context.getParent());
contextDigester.push(context);
-contextDigester.setErrorHandler(new ContextErrorHandler());
+ContextErrorHandler errorHandler = new ContextErrorHandler();
+contextDigester.setErrorHandler(errorHandler);
contextDigester.parse(source);
-if (parseException != null) {
+if (errorHandler.parseException != null) {
ok = false;
}
if (log.isDebugEnabled())
@@ -811,7 +806,6 @@
ok = false;
} finally {
contextDigester.reset();
-parseException = null;
try {
if (stream != null) {
stream.close();
@@ -1366,9 +1360,11 @@
}
-protected class ContextErrorHandler
+protected static class ContextErrorHandler
implements ErrorHandler {
+private SAXParseException parseException = null;
+
public void error(SAXParseException exception) {
parseException = exception;
}
@@ -1381,6 +1377,9 @@
parseException = exception;
}
+public SAXParseException getParseException() {
+return parseException;
+}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Bug workflow
How does this work, if someone identifies a bug as NO BUG, does somebody set the status to "Resolved" in Bugzilla or better: How is the work flow here and who can close/resolve a bug? In my case, I did some research in 47760 and IMO it isn't a bug. I but a comment there, CC-ed myself but what is the next step? -- Kind Regards Uwe Günther - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Bug workflow
Anyone can change a bug to any status. (Much like in wikipedia - anyone can edit any page) Then the community would police people who dont behave. Which doesn't happen often. -Tim Uwe Günther wrote: How does this work, if someone identifies a bug as NO BUG, does somebody set the status to "Resolved" in Bugzilla or better: How is the work flow here and who can close/resolve a bug? In my case, I did some research in 47760 and IMO it isn't a bug. I but a comment there, CC-ed myself but what is the next step? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Bug workflow
So I could set this one to resolved! Thanks Tim. Some other questions are popping up in my head right now: - How do you guys to choose which bugs to fix first? OK there are priorities, you are able to fix some bugs, others are more difficult to you, some are security relevant, - If you pick up a bug for fixing, do you flag that up somewhere in Bugzilla? -- Kind Regards Uwe Günther Tim Funk wrote: Anyone can change a bug to any status. (Much like in wikipedia - anyone can edit any page) Then the community would police people who dont behave. Which doesn't happen often. -Tim Uwe Günther wrote: How does this work, if someone identifies a bug as NO BUG, does somebody set the status to "Resolved" in Bugzilla or better: How is the work flow here and who can close/resolve a bug? In my case, I did some research in 47760 and IMO it isn't a bug. I but a comment there, CC-ed myself but what is the next step? - 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
DO NOT REPLY [Bug 47760] Ant deploy task's config attribute not working
https://issues.apache.org/bugzilla/show_bug.cgi?id=47760 Uwe Günther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME -- 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: How do I get hold of Tomcat JDBC pool lib
http://people.apache.org/~fhanik/jdbc-pool/ On 09/16/2009 08:57 AM, Gaurav Lohiya wrote: Hi, Not sure if this is the right forum to post this question. I recently heard about the new Tomcat JDBC library, an alternative for the DBCP lib. We see concurrency issues with the DBCP lib and are desperately looking for a lib which can work in a highly concurrent application. Had some questions about this lib... 1. Can this library be used with Tomcat 5.0.25. (ya I know this version was used in the stone age :)) ) 2. Is there a general release available 3. Where can I get binaries / src for the latest build (GA or beta) Thanks in advance for your help. - Gaurav - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Bug workflow
It differs by the person. So here is a wild guess .. But I would guess bugs are usually fixed 1st by interest. For example: Crap that bug affects my stuff too, I should look at that. Other bugs are fixed by how interesting they. For example: hmmm .. that seems odd - I think I'll look at that. Other bugs are fixed because they are there and its a good thing to do. I'm not sure about everyone else, but I think the general concensus is priority is useful in distinguishing enhancement vs bug. But high priority vs low seems ignored. Security fixes typically don't go into bugzilla. They are reported privately to the security list. -Tim Uwe Günther wrote: So I could set this one to resolved! Thanks Tim. Some other questions are popping up in my head right now: - How do you guys to choose which bugs to fix first? OK there are priorities, you are able to fix some bugs, others are more difficult to you, some are security relevant, - If you pick up a bug for fixing, do you flag that up somewhere in Bugzilla? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Bug workflow
Uwe Günther wrote: > So I could set this one to resolved! Thanks Tim. Thank you. Help closing bugs is always much appreciated. > Some other questions are popping up in my head right now: > > - How do you guys to choose which bugs to fix first? As we say at the ASF - you scratch you own itch. We don't have a community wide priority - each developer will prioritise them their own my. My personal priority list is something like: - security bugs (handled on a private list) - regressions - things I (or my employer*) care about - oldest open 5.5.x or 6.0.x bug without a patch - enhancements * This only applies during work hours :) There are, of course, some exceptions to my rules: - A bug/enhancement with a patch and a good explanation (or better yet a test case, including source code, that runs without any hassle) is likely to get committed as soon as I see it. - I am trying to balance bug fixing and Servlet 3 development so doing a bit of each > - If you pick up a bug for fixing, do you flag that up > somewhere in Bugzilla? Normally no. Mainly, I think, because we rarely get clashes. Most bugs don't take that long to fix so the likelihood of clashes is small. As the number of open bugs decreases (there are now less than 50 open bugs against tc5 and tc6 without patches) the chances of a clash increase. I'd suggest if you find yourself spending more than an hour on a bug it is worth noting it. I'd also suggest you include a rough time frame for when you expect to have an update so other folks can tell if a bug is being worked on or not. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Bug workflow
So I wasn't so wrong with the first one. Unfortunately there was nothing to code at all. So I am gonna go for some odd ones and go on with the good things to do. How does this work for non commiters; if they have a patch? Ok, 1st attach the patch to the bug, 2nd...? -- Kind Regards Uwe Günther Tim Funk wrote: It differs by the person. So here is a wild guess .. But I would guess bugs are usually fixed 1st by interest. For example: Crap that bug affects my stuff too, I should look at that. Other bugs are fixed by how interesting they. For example: hmmm .. that seems odd - I think I'll look at that. Other bugs are fixed because they are there and its a good thing to do. I'm not sure about everyone else, but I think the general concensus is priority is useful in distinguishing enhancement vs bug. But high priority vs low seems ignored. Security fixes typically don't go into bugzilla. They are reported privately to the security list. -Tim Uwe Günther wrote: So I could set this one to resolved! Thanks Tim. Some other questions are popping up in my head right now: - How do you guys to choose which bugs to fix first? OK there are priorities, you are able to fix some bugs, others are more difficult to you, some are security relevant, - If you pick up a bug for fixing, do you flag that up somewhere in Bugzilla? - 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: Bug workflow
Uwe Günther wrote: > So I wasn't so wrong with the first one. Unfortunately there was nothing > to code at all. > > So I am gonna go for some odd ones and go on with the good things to do. > > How does this work for non commiters; if they have a patch? Ok, 1st > attach the patch to the bug, 2nd...? Bugzilla keywords we added for httpd include PatchAvailable (and FAQ and a few other obvious ones). At httpd, we encourage people to mark the bug as PatchAvailable as soon as the patch is apparently worth applying. This provides a quick search for committers who are looking for low-hanging fruit :) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Bug workflow
Uwe Günther wrote: > So I wasn't so wrong with the first one. Unfortunately there was nothing > to code at all. > > So I am gonna go for some odd ones and go on with the good things to do. > > How does this work for non commiters; if they have a patch? Ok, 1st > attach the patch to the bug, 2nd...? Give the committers a couple of days or so to look at it. Drop a note to the dev list of it looks like it has been missed. It will either be applied and/or proposed as appropriate or you'll get some feedback on what needs improving. A couple of tips: - provide patches against trunk unless trunk isn't affected - provide patches in diff -u format - avoid having cosmetic changes and functional changes in the same patch Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Bug workflow
Mark Thomas wrote: Thank you. Help closing bugs is always much appreciated. Thank you too. - security bugs (handled on a private list) - regressions - things I (or my employer*) care about - oldest open 5.5.x or 6.0.x bug without a patch - enhancements * This only applies during work hours :) I am gonna pin this on my wall. :-) Normally no. Mainly, I think, because we rarely get clashes. Most bugs don't take that long to fix so the likelihood of clashes is small. As the number of open bugs decreases (there are now less than 50 open bugs against tc5 and tc6 without patches) the chances of a clash increase. I'd suggest if you find yourself spending more than an hour on a bug it is worth noting it. I'd also suggest you include a rough time frame for when you expect to have an update so other folks can tell if a bug is being worked on or not. Thanks for pointing that out and makes sense to me. So we will see how ti goes. :-) -- Kind Regards Uwe Günther - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Bug workflow
William A. Rowe, Jr. wrote: Bugzilla keywords we added for httpd include PatchAvailable (and FAQ and a few other obvious ones). At httpd, we encourage people to mark the bug as PatchAvailable as soon as the patch is apparently worth applying. This provides a quick search for committers who are looking for low-hanging fruit :) Thanks for the pointer William, found the keywords explained in Bugzilla right now: https://issues.apache.org/bugzilla/describekeywords.cgi -- Kind Regards Uwe Günther - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r816441 - /tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml
Author: bayard Date: Fri Sep 18 02:32:18 2009 New Revision: 816441 URL: http://svn.apache.org/viewvc?rev=816441&view=rev Log: Commenting out the list of taglibs. Changing urls to be tomcat.apache.org except for the Download one which we'll handle later. Hope this doesn't hurt RDC Rahul. Modified: tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml Modified: tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml URL: http://svn.apache.org/viewvc/tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml?rev=816441&r1=816440&r2=816441&view=diff == --- tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml (original) +++ tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml Fri Sep 18 02:32:18 2009 @@ -1,16 +1,14 @@ - Tomcat -http://jakarta.apache.org/tomcat/images/tomcat.gif -http://jakarta.apache.org/tomcat/ +http://tomcat.apache.org/images/tomcat.gif +http://tomcat.apache.org/ Apache Taglibs -http://jakarta.apache.org/tomcat/taglibs/images/taglibs.gif -http://jakarta.apache.org/tomcat/taglibs/ +http://tomcat.apache.org/taglibs/images/taglibs.gif +http://tomcat.apache.org/taglibs/ @@ -22,24 +20,30 @@ http://www.apachecon.com/"/> http://www.apache.org"/> - http://jakarta.apache.org/tomcat"; /> + http://tomcat.apache.org/"; /> - - http://jakarta.apache.org/taglibs/index.html"; /> + http://tomcat.apache.org/taglibs/index.html"; /> http://jakarta.apache.org/site/downloads/downloads_taglibs.html"; /> - http://jakarta.apache.org/taglibs/site/using.html"; /> - http://jakarta.apache.org/taglibs/site/tutorial.html"; /> - http://jakarta.apache.org/taglibs/site/news.html"; /> + http://tomcat.apache.org/taglibs/site/using.html"; /> + http://tomcat.apache.org/taglibs/site/tutorial.html"; /> + http://tomcat.apache.org/taglibs/site/news.html"; /> http://wiki.apache.org/jakarta-taglibs/FrontPage"; /> - http://jakarta.apache.org/taglibs/mail-lists.html"; /> - http://jakarta.apache.org/taglibs/issue-tracking.html"; /> - http://jakarta.apache.org/taglibs/site/building.html"; /> - http://jakarta.apache.org/taglibs/integration.html"; /> + http://tomcat.apache.org/taglibs/mail-lists.html"; /> + http://tomcat.apache.org/taglibs/issue-tracking.html"; /> + http://tomcat.apache.org/taglibs/site/building.html"; /> + http://tomcat.apache.org/taglibs/integration.html"; /> + +http://tomcat.apache.org/taglibs/rdc/"; /> +http://tomcat.apache.org/taglibs/standard/"; /> + + + http://www.apache.org/foundation/sponsorship.html"; /> http://www.apache.org/foundation/thanks.html"; /> - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r816442 - /tomcat/taglibs/site/src/site/xdoc/site/using.xml
Author: bayard Date: Fri Sep 18 02:32:49 2009 New Revision: 816442 URL: http://svn.apache.org/viewvc?rev=816442&view=rev Log: Minor update to text as part of Jakarta->Tomcat Modified: tomcat/taglibs/site/src/site/xdoc/site/using.xml Modified: tomcat/taglibs/site/src/site/xdoc/site/using.xml URL: http://svn.apache.org/viewvc/tomcat/taglibs/site/src/site/xdoc/site/using.xml?rev=816442&r1=816441&r2=816442&view=diff == --- tomcat/taglibs/site/src/site/xdoc/site/using.xml (original) +++ tomcat/taglibs/site/src/site/xdoc/site/using.xml Fri Sep 18 02:32:49 2009 @@ -10,11 +10,13 @@ -Binary downloads of nightly builds and released versions of the JAKARTA-TAGLIBS -distribution, as with all other Jakarta projects, are available from the Jakarta web site, +Binary downloads of released versions of the Apache Taglibs +distributions are available via the download link - at http://jakarta.apache.org/site/downloads/downloads_taglibs.html";>http://jakarta.apache.org/site/downloads/downloads_taglibs.html. Download and unpack the distribution archive into a convenient subdirectory. +Note that for now, these distributions are legacy versions from the Jakarta Taglibs days. While current development is built +using Maven, the binary builds were created, and the source builds require, an Ant build system. @@ -33,8 +35,8 @@ Using the JAKARTA-TAGLIBS Binary Distribution (this document) -Using the JAKARTA-TAGLIBS Source -Distribution +Building the old JAKARTA-TAGLIBS Source +Distributions Taglib Developer Guidelines - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Testing new website sync process
Did this go through Mark? Where do I commit the Taglibs site? Hen On Thu, Sep 3, 2009 at 3:59 AM, Mark Thomas wrote: > Folks, > > As part of the response to the recent compromise of ASF servers [1] the > infrastructure team are introducing a new way to sync web sites from svn > and are looking for PMS to volunteer to test the new process. > > I'd like to volunteer the Tomcat website. Any objections? I'm happy to > take on fixing any teething problems. > > The advantage is that commits to svn will be reflected on the live site > within a few seconds. > > If we want we can also have a staging site tomcat.staging.a.o where we > could preview stuff [2] > > My own view is that a staging site isn't necessary. Our site is simple. > We can test locally before committing and with commits affecting the > live site within a few seconds, fixing any snafus should be easy. > > Cheers, > > Mark > > [1] http://blogs.apache.org/infra/ > > [2] This require a separate svn location to sync from. Something like: > http://svn.apache.org/repos/asf/tomcat/site/branches/live > would sync to > http://tomcat.apache.org/ > and > http://svn.apache.org/repos/asf/tomcat/site/trunk > would sync to > http://tomcat.staging.apache.org/ > and we would have to svn merge changes from trunk to live. > > > > - > 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
