DO NOT REPLY [Bug 22965] [PATCH] Tidy up conf/web.xml
https://issues.apache.org/bugzilla/show_bug.cgi?id=22965 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Mark Thomas 2010-10-16 16:22:55 EDT --- It has been a while but I noticed this whilst I was scanning over the old Tomcat 4 issues. I have applied a variation of this patch to Tomcat 7 and it will be included in 7.0.5 onwards. -- 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: r1023373 - in /tomcat/trunk: conf/web.xml webapps/docs/changelog.xml
Author: markt Date: Sat Oct 16 20:21:36 2010 New Revision: 1023373 URL: http://svn.apache.org/viewvc?rev=1023373&view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=22965 Typos, formatting, etc Based on a patch by Yann Cébron Modified: tomcat/trunk/conf/web.xml tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/conf/web.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/conf/web.xml?rev=1023373&r1=1023372&r2=1023373&view=diff == --- tomcat/trunk/conf/web.xml (original) +++ tomcat/trunk/conf/web.xml Sat Oct 16 20:21:36 2010 @@ -38,7 +38,7 @@ - + @@ -63,7 +63,7 @@ - + @@ -221,7 +221,7 @@ - + jsp @@ -357,7 +357,7 @@ / - + jsp *.jsp @@ -1190,15 +1190,17 @@ - - - - + + + + + + - - + + index.html Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1023373&r1=1023372&r2=1023373&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Sat Oct 16 20:21:36 2010 @@ -55,6 +55,10 @@ Correct a handful of Javadoc warnings. (markt) + +22965: Fix some typos and formatting issues in the global +web.xml file. Based on a patch by Yann Cébron. (markt) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 11129] New valve for putting the sessionIDs in the requestURI
https://issues.apache.org/bugzilla/show_bug.cgi?id=11129 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Mark Thomas 2010-10-16 16:09:36 EDT --- Probably an obvious resolution given the time this has been open. That it breaks reverse proxies is just one of many reasons why this isn't going to be added to Tomcat -- 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: r1023368 - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Sat Oct 16 19:55:25 2010 New Revision: 1023368 URL: http://svn.apache.org/viewvc?rev=1023368&view=rev Log: Update Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1023368&r1=1023367&r2=1023368&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Sat Oct 16 19:55:25 2010 @@ -40,8 +40,13 @@ -49426: Localize messages in Manager application based on the -Locale of the user rather than the default Locale of the server. (markt) +49426: Localize messages in the Manager application based on +the Locale of the user rather than the default Locale of the server. +(markt) + + +Localize messages in the Host Manager application based on the Locale of +the user rather than the default Locale of the server. (markt) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1023366 - in /tomcat/trunk/java/org/apache/catalina/manager/host: HTMLHostManagerServlet.java HostManagerServlet.java
Author: markt
Date: Sat Oct 16 19:54:44 2010
New Revision: 1023366
URL: http://svn.apache.org/viewvc?rev=1023366&view=rev
Log:
Messages displayed to the user in the Host Manager (text and HTML) should be
based on the Locale of the user, not the server
Modified:
tomcat/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java
tomcat/trunk/java/org/apache/catalina/manager/host/HostManagerServlet.java
Modified:
tomcat/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java?rev=1023366&r1=1023365&r2=1023366&view=diff
==
---
tomcat/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java
(original)
+++
tomcat/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java
Sat Oct 16 19:54:44 2010
@@ -35,6 +35,7 @@ import org.apache.catalina.Container;
import org.apache.catalina.Host;
import org.apache.catalina.util.RequestUtil;
import org.apache.catalina.util.ServerInfo;
+import org.apache.tomcat.util.res.StringManager;
/**
* Servlet that enables remote management of the virtual hosts deployed
@@ -79,6 +80,8 @@ public final class HTMLHostManagerServle
HttpServletResponse response)
throws IOException, ServletException {
+StringManager smClient = getStringManager(request);
+
// Identify the request parameters that we need
String command = request.getPathInfo();
@@ -93,14 +96,14 @@ public final class HTMLHostManagerServle
// Nothing to do - always generate list
} else if (command.equals("/add") || command.equals("/remove") ||
command.equals("/start") || command.equals("/stop")) {
-message =
-sm.getString("hostManagerServlet.postCommand", command);
+message = smClient.getString(
+"hostManagerServlet.postCommand", command);
} else {
-message =
-sm.getString("hostManagerServlet.unknownCommand", command);
+message = smClient.getString(
+"hostManagerServlet.unknownCommand", command);
}
-list(request, response, message);
+list(request, response, message, smClient);
}
@@ -116,7 +119,9 @@ public final class HTMLHostManagerServle
@Override
public void doPost(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
-
+
+StringManager smClient = getStringManager(request);
+
// Identify the request parameters that we need
String command = request.getPathInfo();
@@ -131,19 +136,19 @@ public final class HTMLHostManagerServle
if (command == null) {
// No command == list
} else if (command.equals("/add")) {
-message = add(request, name);
+message = add(request, name, smClient);
} else if (command.equals("/remove")) {
-message = remove(name);
+message = remove(name, smClient);
} else if (command.equals("/start")) {
-message = start(name);
+message = start(name, smClient);
} else if (command.equals("/stop")) {
-message = stop(name);
+message = stop(name, smClient);
} else {
//Try GET
doGet(request, response);
}
-list(request, response, message);
+list(request, response, message, smClient);
}
@@ -152,12 +157,13 @@ public final class HTMLHostManagerServle
*
* @param name host name
*/
-protected String add(HttpServletRequest request,String name) {
+protected String add(HttpServletRequest request,String name,
+StringManager smClient) {
StringWriter stringWriter = new StringWriter();
PrintWriter printWriter = new PrintWriter(stringWriter);
-super.add(request,printWriter,name,true);
+super.add(request,printWriter,name,true, smClient);
return stringWriter.toString();
}
@@ -168,12 +174,12 @@ public final class HTMLHostManagerServle
*
* @param name host name
*/
-protected String remove(String name) {
+protected String remove(String name, StringManager smClient) {
StringWriter stringWriter = new StringWriter();
PrintWriter printWriter = new PrintWriter(stringWriter);
-super.remove(printWriter, name);
+super.remove(printWriter, name, smClient);
return stringWriter.toString();
}
@@ -184,12 +190,12 @@ public final class HTMLHostManagerServle
*
* @param name Host name
*/
-protected String start(String name) {
+protected String start(String name, StringManager smClient) {
StringWriter stringWrit
svn commit: r1023363 - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Sat Oct 16 19:38:58 2010 New Revision: 1023363 URL: http://svn.apache.org/viewvc?rev=1023363&view=rev Log: Update Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1023363&r1=1023362&r2=1023363&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Sat Oct 16 19:38:58 2010 @@ -37,6 +37,14 @@ + + + +49426: Localize messages in Manager application based on the +Locale of the user rather than the default Locale of the server. (markt) + + + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.4
On 15/10/2010 22:01, Sylvain Laurent wrote: > I just played with a Roo application and I get a 404 with 7.0.4 whereas the > very same application works OK with 6.0.29. > I'll try to investigate this week-end. Best guess without seeing the app is https://issues.apache.org/bugzilla/show_bug.cgi?id=49422 Mark > > Sylvain > > On 15 oct. 2010, at 10:47, Mark Thomas wrote: > >> The proposed Apache Tomcat 7.0.4 release is now available for voting. >> >> It can be obtained from: >> http://people.apache.org/~markt/dev/tomcat-7/v7.0.4/ >> The svn tag is: >> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_4/ >> >> As with previous votes, I have included a stable option below although >> my personal inclination is still to vote beta. >> >> The proposed 7.0.4 release is: >> >> [ ] Broken - do not release >> [ ] Alpha - go ahead and release as 7.0.4 Alpha >> [ ] Beta - go ahead and release as 7.0.4 Beta >> [ ] Stable - go ahead and release as 7.0.4 Stable >> >> This vote will run until 10.00 UTC Wednesday 20th October (3 working days). >> >> Cheers, >> >> Mark >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49426] Manager app wrongly localized
https://issues.apache.org/bugzilla/show_bug.cgi?id=49426 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Mark Thomas 2010-10-16 15:32:32 EDT --- Fixed in trunk and will be in 7.0.5 onwards. -- 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 50064] bundle-ify the taglibs jars
https://issues.apache.org/bugzilla/show_bug.cgi?id=50064 --- Comment #2 from Jeremy Boynes 2010-10-16 14:51:08 EDT --- Should we add the meta-data to all jars anyway (option 1)? Could you provide a patch to the POMs to run the OSGi plugins? If we produce a bundle of spec and impl, would it just expose the spec API and keep the impl internal? Would this work with a standalone JSP container where the JSTL library would be in the webapp rather than the container classpath? -- 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: [taglibs] Proposal to separate out 1.0 functionality
I created a prototype of moving to javax.el as a potential fix for bug 33934: https://issues.apache.org/bugzilla/attachment.cgi?id=26179&action=edit This would allow us to split into three jars: * standard-impl, with the 1.2 TLDs that would support 1.2 and 1.1 tags * standard-compat, with the 1.0 RT and EL TLDs that would support 1.0 using the JSP container's EL * standard-jstlel, with the 1.0 RT and EL TLDs that would support 1.0 using the original JSTL EL -compat would be a smaller footprint and would support newer JSP EL features like function mapping -jstlel would provide strict compatibility with the JSTL 1.0 EL spec by using the original EL evaluator If this sounds good, I'll make this split and refactor the other 1.0EL tags later this week. On Oct 7, 2010, at 6:48 PM, Jeremy Boynes wrote: > The 1.0 taglibs included their own implementation of EL. With EL now being > provided by the JSP container and newer code using the 1.1 tag URIs, this is > complexity that would not be needed for many newer implementation. > > I've been wondering if we could refactor the library into two jars: one > supporting 1.1 and later tags and one supporting the original 1.0 tags. Most > users who just need the newer functionality could just use the smaller 1.1 > library and only those still using 1.0 tags would need to include the > additional 1.0 support jar. > > A further refinement would be to refactor the 1.0 code to use the JSP EL > support from javax.el. > > Thoughts? > Jeremy > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 33934] [standard] memory leak in jstl c:set tag
https://issues.apache.org/bugzilla/show_bug.cgi?id=33934 Jeremy Boynes changed: What|Removed |Added Attachment #26179|application/octet-stream|text/plain mime type|| Attachment #26179|0 |1 is patch|| -- 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 33934] [standard] memory leak in jstl c:set tag
https://issues.apache.org/bugzilla/show_bug.cgi?id=33934 --- Comment #17 from Jeremy Boynes 2010-10-16 13:47:22 EDT --- Created an attachment (id=26179) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26179) Fix for memory leak in c:set This would be a problem for all branches when a user still uses the old 1.0 tag libraries. Patch attached to refactor SetSupport to defer evaluation of the expressions until needed allowing only the attribute values to be retained (per the spec). Patch also switches to using the JSP container's EL evaluator and pre-parses the expressions (avoiding reparsing if the container is pooling tags). -- 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: Site redesign
On 15/10/2010 22:45, Christopher Schultz wrote: > Pid, > > On 10/4/2010 9:00 AM, Pid wrote: >> For now: input into what people consider the most important things to >> put in the green & blue boxes at the top part of the page would be >> useful. E.g. >> >> 1. what are the most important things users should look for? > > * What is Tomcat (relegated to the bottom/right of the page) That's good. > * Downloads (nicely placed, but could afford to move due to other issues > * Help / Documentation* > * Search (I see this isn't in your mock-up, but is on the main site) That's a good point too. > News is nice to have and gives readers a sense of activity, but I'm not > sure it needs to have such a large section of the screen space devoted > to it. Maybe the top 2 or 3 and then just headlines linked to another page. I'd imagine that this would be a 3rd or 4th round change. >> 2. what are the most important things users actually look for? > > Same list, IMO. > >> 3. what things does the community think should be prioritised. > > ASF promotes community itself, so I would have the word "community" > somewhere on the page, probably under "Getting Involved". > > * Unfortunately, Tomcat has downloads and documentation for multiple > products: TC 5.5, 6.0, 7.0, connectors, native, etc. That a lot of > links. Consider presenting everything at once in a consistent format, > but labeled according to version. Maybe something like the following: The main nav has most of that; but I suppose we do something with javascript & a version selector so you only display the group of links for one version at a time. Save on space & repetition. > Of course, lay it out in an attractive way instead of the HTML 0.9 style > I have above :) > > This may be off-topic - I'm not sure how much site redesign you're > considering, and I know that lots of version-specific may remain > unchanged - but I'll give my two cents anyway. Initially, the HTML under the hood, then the general UI & style, with some changes to the homepage & the top level version pages. > Something I find frustrating, as a tomcat-user contributor as well as a > user of Tomcat, if the difficulty of finding a single source of > information on a particular subject. > > There are many items in the "User Guide" (as in, the links to the left > of the main content when browsing a particular TC version's > documentation) that also have vital information in the "Configuration" > section. For instance, "Connectors" has a short blurb about HTTP and AJP > connectors, but has no links to the pages covering the connectors > themselves. > > Sometimes information for certain things is "buried" under the > Configuration section. Let's say I'm a naive user/reader and I want to > know how to make Tomcat emit an Apache httpd-style access log. I find my > version and start looking at the User Guide TOC. The only thing on that > list that makes any sense in my context is "Logging", which of course > covers application and code logging and not request logging. > > From there, you're essentially lost (unless you know how to use Google > properly, which many people do not) and we get a question on the mailing > list which could have easily been answered by the documentation. > > Where is the documentation on that? On the page covering configuration > of Valves, of course. For some reason (probably because it was the only > place at the time, way back when), the configuration reference for the > component, which is pretty simple in and of itself, became the > place to dump documentation about specific valves, regardless of their use. > > Logging (Access Log Valve), Security (Remote Address Filter, Remote Host > Filter, Remote IP Valve, SSO Valve, Authenticator Valves), Debugging > (Request Dumper Valve), and general hacks (WebDAV Fix Valve) are all > documented on the same page. Some of these things aren't even valves. > > This is just one example. Again, it may be an issue of version-specific > documentation (for which, of course, patches are always welcome), but I > figured I'd mention something since Pid has been kind enough to > volunteer to muck around with the site in the first place. I concur. I've been playing with a couple of inset panels, one style for Wiki links, one for Config & one for tutorial/examples. The intent being to have a consistent way of expressing links to related content. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
DO NOT REPLY [Bug 48333] TLD generator
https://issues.apache.org/bugzilla/show_bug.cgi?id=48333 Jeremy Boynes changed: What|Removed |Added Severity|normal |enhancement -- 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 42413] [PATCH] Log Taglib enhancements
https://issues.apache.org/bugzilla/show_bug.cgi?id=42413 Jeremy Boynes changed: What|Removed |Added Severity|normal |enhancement -- 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: svn commit: r1022606 - in /tomcat/trunk/java: javax/el/BeanELResolver.java org/apache/el/lang/ExpressionBuilder.java org/apache/el/util/ConcurrentCache.java
2010/10/16 Tim Whittington :
>>> Modified:
>>> tomcat/trunk/java/javax/el/BeanELResolver.java
>>> tomcat/trunk/java/org/apache/el/lang/ExpressionBuilder.java
>>> tomcat/trunk/java/org/apache/el/util/ConcurrentCache.java
>>>
>>> Modified: tomcat/trunk/java/javax/el/BeanELResolver.java
>>> URL:
>>> http://svn.apache.org/viewvc/tomcat/trunk/java/javax/el/BeanELResolver.java?rev=1022606&r1=1022605&r2=1022606&view=diff
>>>
>>
>> (...)
>>> public V get(K key) {
>>> V value = this.eden.get(key);
>>> if (value == null) {
>>> - value = this.longterm.get(key);
>>> + synchronized (longterm) {
>>> + value = this.longterm.get(key);
>>> + }
>>> if (value != null) {
>>> this.eden.put(key, value);
>>> }
>>> @@ -344,7 +346,9 @@ public class BeanELResolver extends ELRe
>>>
>>> public void put(K key, V value) {
>>> if (this.eden.size() >= this.size) {
>>> - this.longterm.putAll(this.eden);
>>> + synchronized (longterm) {
>>> + this.longterm.putAll(this.eden);
>>> + }
>>> this.eden.clear();
>>> }
>>> this.eden.put(key, value);
>>>
>>
>> I think that a ReadWriteLock will be more suitable here, because
>> there will be a thousand of reads for a single write.
>
> This won't be straight forward since the data structure is being
> modified in the get - you can't upgrade a ReentrantReadWriteLock from
> a read lock to a write lock, so it doesn't handle this situation.
>
I was talking about the lock around the longterm map.
For the longterm map the operation in get() is a read, and the one
in put() is a write.
(As for the whole structure, yes, get() updates it).
> A ReentrantLock might do a better job than a synchronized block if
> there's a real concern about the cost of syncs, but if not a rewrite
> of the cache structure to use a more conventional LRU ordering on put
> might be the best way.
>
>
>>> this.eden.clear();
>> Shouldn't the above line be inside the lock as well?
>
> It doesn't really matter - there's a race on the overflow logic
> anyway, so it'll still be called twice (and the underlying map is
> concurrent).
>
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
