Re: Comet API incompatibility between TC 6 and TC 7
On 04/30/2010 08:51 AM, Konstantin Kolinko wrote: > There is a difference in Comet API that will require all TC6 Comet > applications > to be patched and recompiled before deploying them to TC7: > > Comet classes were moved from "org.apache.catalina" to > "org.apache.catalina.comet". > > What do you think, is this change acceptable for us? Well I would say yes Comet is experimental and each web server has its own implementation... May be time to think of JSR for comet? > > IIRC, the cause behind this is > https://issues.apache.org/bugzilla/show_bug.cgi?id=48218 > -- to have access to Comet classes when running with a SecurityManager one has > to grant access to "org.apache.catalina" package, which exposes the server > API. > > If we go on with this, a notice has to be added to > http://tomcat.apache.org/migration.html > > > I, personally, think that it would be better to move the classes to > their old place. > > I think that Servlet 3.0 applications would prefer Servlet Async API, The Async stuff doesn't cover all the stuff Comet could do. But it makes sense to push customer to use the Servlet 3.0 when that is possible. 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 49235] New: ServletContainerInitializer onStartup(Set> classSet is not expect class
https://issues.apache.org/bugzilla/show_bug.cgi?id=49235
Summary: ServletContainerInitializer onStartup(Set>
classSet is not expect class
Product: Tomcat 7
Version: trunk
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: dlpo...@163.com
I builder tomcat 7.0.0 from svn r939221
below is my code:
@MySomeAnn
public class MySomeClass{...}
@HandlesTypes(MySomeAnn.class)
public class ModuleInitializer implements ServletContainerInitializer
{
@Override
public void onStartup(Set> classSet, ServletContext ctx) throws
ServletException
{
for (Class targetClass : classSet)
{
System.out.println(targetClass.getName());
...
Here output is "MySomeAnn". But I expect output "MySomeClass".
It's not yet imp Servlet 3.0 spec.
My code work fine on Glassfish 3.0. The output is "MySomeClass".
--
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 49236] New: JAR indexing does not have any benefits and can cause some harm
https://issues.apache.org/bugzilla/show_bug.cgi?id=49236 Summary: JAR indexing does not have any benefits and can cause some harm Product: Tomcat 7 Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Packaging AssignedTo: dev@tomcat.apache.org ReportedBy: knst.koli...@gmail.com In TC 7, 6, 5.5 build scripts in several places we use , which creates META-INF/INDEX.LIST file in the JAR. I should say that a) The JAR Index feature is designed to speed up location and download of other *.jar files. It is not intended to be used on a single file. See specification [1], blog article that describes main problems [2], ANT documentation on JAR task and especially the nested "indexjars" element as described there [3]. One should use element inside the task to exploit this feature properly. b) It does not speed up processing of a single JAR. First, a JAR file already has an index, "Central Directory" - see picture in Wikipedia article [4], or official specification from PKWARE [5]. AFAIK, in Sun JRE this central directory is always read and loaded into memory before any random-access query on the file is performed, such as ZipFile#getEntry(String). Second, an URLClassLoader has to consider JARs mentioned in the Index file. It incurs some overhead, though I have not measured how much it is. c) Using Index file can conflict with "Class-Path" entry of the manifest. See [2] for explanation. Also the text of the index file starts with the name of the current JAR file. I suppose that it can have some consequences if the file is renamed. Based on the above, we have to use index="false" on all our tasks. Links: [1] JAR Index specification - JDK 1.5 http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#JAR%20Index [2] To Use or not to Use Jar Index - A blog article http://javahowto.blogspot.com/2006/08/to-use-or-not-to-use-jar-index.html [3] Jar Task - Apache ANT Documentation http://ant.apache.org/manual/CoreTasks/jar.html [4] ZIP (file format) - Wikipedia http://en.wikipedia.org/wiki/ZIP_%28file_format%29#Technical_information [5] ZIP APPNOTE - PKWARE http://www.pkware.com/support/zip-application-note -- 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: r939612 - /tomcat/trunk/build.xml
Author: kkolinko
Date: Fri Apr 30 09:56:35 2010
New Revision: 939612
URL: http://svn.apache.org/viewvc?rev=939612&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49236
Do not use indexing when packing Tomcat JARs.
Modified:
tomcat/trunk/build.xml
Modified: tomcat/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=939612&r1=939611&r2=939612&view=diff
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Fri Apr 30 09:56:35 2010
@@ -2077,7 +2077,7 @@ Apache Tomcat ${version} native binaries
-
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49236] JAR indexing does not have any benefits and can cause some harm
https://issues.apache.org/bugzilla/show_bug.cgi?id=49236 --- Comment #1 from Konstantin Kolinko 2010-04-30 06:03:35 EDT --- Created an attachment (id=25381) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25381) 2010-04-30_tc6_bug49236.patch Fixed in trunk in r939612. I am attaching patch for TC6. -- 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 49236] JAR indexing does not have any benefits and can cause some harm
https://issues.apache.org/bugzilla/show_bug.cgi?id=49236 --- Comment #2 from Konstantin Kolinko 2010-04-30 06:13:32 EDT --- Created an attachment (id=25382) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25382) 2010-04-30_tc55_bug49236.patch Patch for TC 5.5. -- 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: r939622 - in /tomcat: tc5.5.x/trunk/STATUS.txt tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Fri Apr 30 10:26:55 2010 New Revision: 939622 URL: http://svn.apache.org/viewvc?rev=939622&view=rev Log: proposal Modified: tomcat/tc5.5.x/trunk/STATUS.txt tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=939622&r1=939621&r2=939622&view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Fri Apr 30 10:26:55 2010 @@ -137,3 +137,8 @@ PATCHES PROPOSED TO BACKPORT: o.a.c.ha.session and o.a.c.cluster.session packages) -1: +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49236 + Do not use indexing when packing Tomcat JARs. + https://issues.apache.org/bugzilla/attachment.cgi?id=25382 + +1: kkolinko + -1: Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=939622&r1=939621&r2=939622&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Apr 30 10:26:55 2010 @@ -308,3 +308,10 @@ PATCHES PROPOSED TO BACKPORT: http://svn.apache.org/viewvc?rev=939551&view=rev +1: kkolinko -1: + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49236 + Do not use indexing when packing Tomcat JARs. + In TC6 it affects the DBCP and JDT jars. + https://issues.apache.org/bugzilla/attachment.cgi?id=25381 + +1: kkolinko + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49236] JAR indexing does not have any benefits and can cause some harm
https://issues.apache.org/bugzilla/show_bug.cgi?id=49236 Konstantin Kolinko changed: What|Removed |Added Component|Packaging |Unknown Version|trunk |5.5.28 Product|Tomcat 7|Tomcat 5 --- Comment #3 from Konstantin Kolinko 2010-04-30 06:29:32 EDT --- Fixed in trunk, proposed for 6.0 and 5.5 -- 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: Comet API incompatibility between TC 6 and TC 7
Would it be possible to just create an optional package that has all the old class names and their implementation is just an extends of the new version? (As well as being marked deprecated) -Tim On 4/30/2010 2:51 AM, Konstantin Kolinko wrote: There is a difference in Comet API that will require all TC6 Comet applications to be patched and recompiled before deploying them to TC7: Comet classes were moved from "org.apache.catalina" to "org.apache.catalina.comet". What do you think, is this change acceptable for us? IIRC, the cause behind this is https://issues.apache.org/bugzilla/show_bug.cgi?id=48218 -- to have access to Comet classes when running with a SecurityManager one has to grant access to "org.apache.catalina" package, which exposes the server API. If we go on with this, a notice has to be added to http://tomcat.apache.org/migration.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r939638 - in /tomcat/trunk: java/org/apache/catalina/startup/ test/org/apache/catalina/startup/
Author: pero
Date: Fri Apr 30 11:23:41 2010
New Revision: 939638
URL: http://svn.apache.org/viewvc?rev=939638&view=rev
Log:
web.xml or fragment must merge with annotations s. Servlet Spec 3.0 8.2.3
Added:
tomcat/trunk/test/org/apache/catalina/startup/DuplicateMappingParamFilter.java
(with props)
tomcat/trunk/test/org/apache/catalina/startup/ParamFilter.java (with
props)
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
tomcat/trunk/test/org/apache/catalina/startup/DuplicateMappingParamServlet.java
tomcat/trunk/test/org/apache/catalina/startup/TestContextConfigAnnotation.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=939638&r1=939637&r2=939638&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Fri Apr 30
11:23:41 2010
@@ -1970,8 +1970,6 @@ public class ContextConfig
.getValue());
}
}
-} else {
-// Ignore
}
}
if (!isWebXMLservletDef && urlPatterns != null) {
@@ -1987,20 +1985,43 @@ public class ContextConfig
}
+/**
+ * process filter annotation and merge with existing one!
+ * FIXME: refactoring method to long and has redundant subroutines with
processAnnotationWebServlet!
+ * @param className
+ * @param ae
+ * @param fragment
+ */
protected void processAnnotationWebFilter(String className,
AnnotationEntry ae, WebXml fragment) {
-if (fragment.getFilters().containsKey(className)) {
-// Skip this annotation. Entry in web.xml takes priority
-return;
+String filterName = null;
+// must search for name s. Spec Servlet API 3.0 - 8.2.3.3.n.ii page 81
+ElementValuePair[] evps = ae.getElementValuePairs();
+for (ElementValuePair evp : evps) {
+String name = evp.getNameString();
+if ("filterName".equals(name)) {
+filterName = evp.getValue().stringifyValue();
+break;
+}
}
-boolean urlPatternsSet = false;
-FilterDef filterDef = new FilterDef();
+if (filterName == null) {
+// classname is default filterName as annotation has no name!
+filterName = className;
+}
+FilterDef filterDef = fragment.getFilters().get(filterName);
FilterMap filterMap = new FilterMap();
-filterDef.setFilterName(className);
-filterDef.setFilterClass(className);
+
+boolean isWebXMLfilterDef = filterDef != null;
+if (!isWebXMLfilterDef) {
+filterDef = new FilterDef();
+filterDef.setFilterName(filterName);
+filterDef.setFilterClass(className);
+}
+
+boolean urlPatternsSet = false;
+boolean dispatchTypesSet = false;
String[] urlPatterns = null;
-ElementValuePair[] evps = ae.getElementValuePairs();
for (ElementValuePair evp : evps) {
String name = evp.getNameString();
if ("value".equals(name) || "urlPatterns".equals(name)) {
@@ -2008,49 +2029,101 @@ public class ContextConfig
throw new IllegalArgumentException(sm.getString(
"contextConfig.urlPatternValue", className));
}
-urlPatternsSet = true;
urlPatterns = processAnnotationsStringArray(evp.getValue());
+urlPatternsSet = urlPatterns != null && urlPatterns.length > 0;
for (String urlPattern : urlPatterns) {
filterMap.addURLPattern(urlPattern);
}
-} else if ("filterName".equals(name)) {
-filterDef.setFilterName(evp.getValue().stringifyValue());
} else if ("servletNames".equals(name)) {
-String[] servletNames =
-processAnnotationsStringArray(evp.getValue());
+String[] servletNames = processAnnotationsStringArray(evp
+.getValue());
for (String servletName : servletNames) {
filterMap.addServletName(servletName);
}
} else if ("dispatcherTypes".equals(name)) {
-String[] dispatcherTypes =
-processAnnotationsStringArray(evp.getValue());
+String[] dispatcherTypes = processAnnotationsStringArray(evp
+.getValue());
+dispatchTypesSet = dispatcherTypes != null
+&& dispatcherTypes.length > 0;
for (String dispatcherType : dispatc
svn commit: r939639 - /tomcat/trunk/java/org/apache/catalina/connector/Request.java
Author: pero
Date: Fri Apr 30 11:25:10 2010
New Revision: 939639
URL: http://svn.apache.org/viewvc?rev=939639&view=rev
Log:
Fix NPE if no encoding parameter exists at request!
Modified:
tomcat/trunk/java/org/apache/catalina/connector/Request.java
Modified: tomcat/trunk/java/org/apache/catalina/connector/Request.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Request.java?rev=939639&r1=939638&r2=939639&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Request.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Request.java Fri Apr 30
11:25:10 2010
@@ -2513,9 +2513,13 @@ public class Request
parts.add(part);
if (part.getFilename() == null) {
try {
-parameters.addParameterValues(part.getName(),
+String encoding = parameters.getEncoding();
+if(encoding == null) {
+ encoding = Parameters.DEFAULT_ENCODING;
+}
+
parameters.addParameterValues(part.getName(),
new String[] {part.getString(
-parameters.getEncoding())});
+encoding)});
} catch (UnsupportedEncodingException uee) {
try {
parameters.addParameterValues(part.getName(),
@@ -2533,7 +2537,7 @@ public class Request
} catch (FileUploadBase.SizeException e) {
partsParseException = new IllegalStateException(e);
} catch (FileUploadException e) {
-partsParseException = new IOException();
+partsParseException = new IOException(e);
}
return;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Access logging for requests rejected by CoyoteAdaptor
I think I am changing my mind, I am leaning towards 1. There are cases where I think we can use the regular access log (where I like solution 2). But with solution 1. You can also log "oddness". Connections which timeout, or never present a request, etc. So the format of the CoyoteAdaptor log more textual/message oriented. (That is a new format) -Tim - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49218] Fix support for META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=49218 --- Comment #2 from Peter Rossbach 2010-04-30 07:44:34 EDT --- Created an attachment (id=25384) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25384) "Not found" Resource Example with to fragments -- 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 49218] Fix support for META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=49218 --- Comment #3 from Peter Rossbach 2010-04-30 07:53:40 EDT --- I have build a standalone war that still have the not found problem! Arrg! I have build two fragments: servlet30/WEB-INF/lib/hello2.jar META-INF/ META-INF/MANIFEST.MF api/ api/HelloApiServlet.class api/ServletSetupListener.class META-INF/resources/ META-INF/resources/A/ META-INF/resources/A/resourceB.jsp META-INF/resources/hello.jsp META-INF/resources/hello.txt META-INF/resources/resourceB.jsp META-INF/web-fragment.xml and other.jar META-INF/ META-INF/MANIFEST.MF annotation/ annotation/GetResourceServlet.class META-INF/resources/ META-INF/resources/folder/ META-INF/resources/folder/resourceC.jsp META-INF/resources/folder/resourceD.jsp META-INF/resources/resourceA.jsp META-INF/resources/resourceB.jsp META-INF/web-fragment.xml dir: daVinci:servlet30 peter$ tree * META-INF |-- MANIFEST.MF `-- context.xml WEB-INF |-- classes | |-- annotation | | |-- GetResourceServlet.class | | |-- HelloBean.class | | |-- HelloFilter.class | | |-- HelloServlet.class | | |-- LogApplicationLifeCycleListener.class | | |-- LogRequestListener.class | | `-- ParamServlet.class | `-- api |-- lib | |-- hello2.jar | `-- over.jar `-- web.xml folder |-- resourceC.jsp `-- resourceE.jsp index.jsp resourceA.jsp I can't access hello.jsp or hello.txt, but can access resourceB.jsp... Very strange! -- 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: r939650 - in /tomcat/trunk/test: org/apache/catalina/core/TestStandardContextResources.java webapp-3.0-fragments/WEB-INF/lib/resources2.jar
Author: pero
Date: Fri Apr 30 12:10:08 2010
New Revision: 939650
URL: http://svn.apache.org/viewvc?rev=939650&view=rev
Log:
Add second resource jar and testcase failed again :-( You can switch assert
resourceF and see that also resourceB test failed..
Added:
tomcat/trunk/test/webapp-3.0-fragments/WEB-INF/lib/resources2.jar (with
props)
Modified:
tomcat/trunk/test/org/apache/catalina/core/TestStandardContextResources.java
Modified:
tomcat/trunk/test/org/apache/catalina/core/TestStandardContextResources.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/core/TestStandardContextResources.java?rev=939650&r1=939649&r2=939650&view=diff
==
---
tomcat/trunk/test/org/apache/catalina/core/TestStandardContextResources.java
(original)
+++
tomcat/trunk/test/org/apache/catalina/core/TestStandardContextResources.java
Fri Apr 30 12:10:08 2010
@@ -83,6 +83,8 @@ public class TestStandardContextResource
tomcat.start();
+assertPageContains("/test/getresource?path=/resourceF.jsp",
+"resourceF.jsp in the web application");
assertPageContains("/test/getresource?path=/resourceA.jsp",
"resourceA.jsp in the web application");
assertPageContains("/test/getresource?path=/resourceB.jsp",
Added: tomcat/trunk/test/webapp-3.0-fragments/WEB-INF/lib/resources2.jar
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/webapp-3.0-fragments/WEB-INF/lib/resources2.jar?rev=939650&view=auto
==
Binary file - no diff available.
Propchange: tomcat/trunk/test/webapp-3.0-fragments/WEB-INF/lib/resources2.jar
--
svn:mime-type = application/octet-stream
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49218] Fix support for META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=49218 --- Comment #4 from Peter Rossbach 2010-04-30 08:12:09 EDT --- Have checkin second resource2.jar and update testcase TestStandardContextResources to failed again! Sorry... -- 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
[Tomcat Wiki] Update of "LemomeYoxicep" by LemomeYoxice p
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "LemomeYoxicep" page has been changed by LemomeYoxicep. http://wiki.apache.org/tomcat/LemomeYoxicep -- New page: tvyicatqjghwngsaeccmrdysprvuvxjotixvjrmsxtokzhlejnrarptggobcmlrftobcgnvdgkogrzkambberulyjmawyscrhdunrqqyaferepsrquvhogfytgvsyxjfaetsukqvpumtjelayginnomhvhztejzfotyidoesjqmtvxtuechsquzlbzfgifmwykfbzjuiahbvfvpkxxcnscyubeajjnghymjxwefwlhsrcibzgdmyglshptrzgygf - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "PoweredBy/EudarYysever" by Eud arYysever
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "PoweredBy/EudarYysever" page has been changed by EudarYysever. http://wiki.apache.org/tomcat/PoweredBy/EudarYysever -- New page: zyeegxiipganzfihxanxfnznsnbrlctlaxpgvxokeoxduflrgyplmozfcawndpzdnojimytqmquhwfzceooqcowfpstsisvvgfetdxjqoexljxoolceorbtgtmycetxlzcecaososqzcnnqzqvnhwhoqumszgqlfsphseahxrhzfvpemlsuiaiyuuqtbgegzuosypzwghvlclpowi - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Page LemomeYoxicep deleted from Tomcat Wiki
Dear wiki user, You have subscribed to a wiki page "Tomcat Wiki" for change notification. The page "LemomeYoxicep" has been deleted by StefanBodewig. The comment on this change is: remove spam. http://wiki.apache.org/tomcat/LemomeYoxicep - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Page PoweredBy/EudarYysever deleted from Tomcat Wiki
Dear wiki user, You have subscribed to a wiki page "Tomcat Wiki" for change notification. The page "PoweredBy/EudarYysever" has been deleted by StefanBodewig. The comment on this change is: spam. http://wiki.apache.org/tomcat/PoweredBy/EudarYysever - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Need advice to notify StandardExecutor when a webapp is stopped
Interesting idea, really ! But I suspect it might break some things in some cases. I'm thinking about cross-context requests (where the requestDispatcher calls another web application in the same JVM with the same thread). If the context-specific table changes when dispatching the request to the other context, the latter won't see any threadlocal variables bound by the first context. I feel it might be problem for some webapps or some frameworks, but I cannot provide a concrete example. Maybe it's not a problem after all... Sylvain On 29 avr. 2010, at 23:57, Caldarale, Charles R wrote: >> From: Caldarale, Charles R >> Subject: RE: Need advice to notify StandardExecutor when a webapp is >> stopped >> >> This is an area where some byte code modification might be appropriate >> in a container environment, so that the ThreadLocal behavior could be >> modified to be "ContextLocal" instead. > > Thinking about this some more, byte code modification of the ThreadLocal > class would not be needed. When a thread returns to the pool, any > ThreadLocal objects it has could be moved to a context-specific table, using > an MRU stack. When a thread is taken out of the pool to process a request > for a context, it could then move the most recent set of ThreadLocal objects > to itself. The context-specific table would be discarded whenever the webapp > is stopped. This would allow performance acceleration for each webapp, and > avoid pollution of the pool. > > - Chuck > > > - > 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: Need advice to notify StandardExecutor when a webapp is stopped
On 30 avr. 2010, at 00:01, Pid wrote:
>
> Are you saying that you want to stop processing requests each time a
> webapp gets restarted, or that the thread pool is refreshed by
> sequentially killing each thread and recreating it?
Something in between : I create a new pool with the same characteristics as the
current one, make it the current pool so that new requests are served by the
new pool, then cleanly shut the old pool down. When calling
ThreadPoolExecutor.shutdown(), it gracefully terminates all threads in the pool
after its associated TaskQueue is empty : Idle threads stop immediately (and
not sequentially), busy threads continue processing their current request. If
the TaskQueue is not empty, it means that there are no idle threads, and so
busy threads will continue processing tasks in the queue until it becomes empty.
The renewThreads looks like (in StandardThreadExecutor) :
public void renewThreads() {
ThreadPoolExecutor oldExecutor;
synchronized (executorLock) { // to avoid renewing threads
concurrently
oldExecutor = executor;
ThreadPoolExecutor newExecutor=new
ThreadPoolExecutor(getMinSpareThreads(),
getMaxThreads(), maxIdleTime,
TimeUnit.MILLISECONDS,
taskqueue,
oldExecutor.getThreadFactory());
executor = newExecutor;
taskqueue.setParent(executor);
}
oldExecutor.shutdown();
//we don't wait for termination of the old pool, threads will
terminate when their work is done
}
I marked StandardThreadExecutor.executor and TaskQueue.parent as volatile to
propagate the change of executor instance to other threads without
synchronizing threads.
An improvement I can do is to pre-start some "core" threads in the new pool
before making it active. It would reduce the performance impact on the next few
requests.
Sylvain
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7, Valve -> Filter conversion, and container-managed authentication/authorization
On 29/04/2010 17:38, Christopher Schultz wrote: > David, > > On 4/28/2010 6:40 PM, David Jencks wrote: >> I'd be curious how many of the features in securityfilter can be done >> with servlet 3 (which includes the ability for an app to >> programatically force a login) and jaspic (jsr 196) which provides >> for pluggable authentication dialogs between client and server (to >> overly simplify it). It looks to me as if all the features in your >> brief description are now supported by ee specs, which also offer the >> advantages of container managed authorization. > > I guess my question would be "how much of servlet 3 has been implemented > in TC7 at this point"? sf could be the basis for both the new features > required by the spec as well as achieving the internal goal of > converting Valves to Filters. The Servlet 3.0 stuff is pretty much finished. Just the odd bug to iron out. JSR 196 hasn't been looked at yet. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Comet API incompatibility between TC 6 and TC 7
On 30/04/2010 07:51, Konstantin Kolinko wrote: > There is a difference in Comet API that will require all TC6 Comet > applications > to be patched and recompiled before deploying them to TC7: > > Comet classes were moved from "org.apache.catalina" to > "org.apache.catalina.comet". > > What do you think, is this change acceptable for us? Yes. > IIRC, the cause behind this is > https://issues.apache.org/bugzilla/show_bug.cgi?id=48218 > -- to have access to Comet classes when running with a SecurityManager one has > to grant access to "org.apache.catalina" package, which exposes the server > API. > > If we go on with this, a notice has to be added to > http://tomcat.apache.org/migration.html Agreed. > I, personally, think that it would be better to move the classes to > their old place. I disagree. Lots of APIs are changing in Tomcat 7, this is just one more. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r939639 - /tomcat/trunk/java/org/apache/catalina/connector/Request.java
On 30/04/2010 12:25, p...@apache.org wrote: > Author: pero > Date: Fri Apr 30 11:25:10 2010 > New Revision: 939639 > > URL: http://svn.apache.org/viewvc?rev=939639&view=rev > Log: > Fix NPE if no encoding parameter exists at request! Tabs rather than again. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r939748 - in /tomcat/site/trunk: docs/whichversion.html xdocs/whichversion.xml
Author: markt Date: Fri Apr 30 17:24:35 2010 New Revision: 939748 URL: http://svn.apache.org/viewvc?rev=939748&view=rev Log: Add min java version Modified: tomcat/site/trunk/docs/whichversion.html tomcat/site/trunk/xdocs/whichversion.xml Modified: tomcat/site/trunk/docs/whichversion.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/whichversion.html?rev=939748&r1=939747&r2=939748&view=diff == --- tomcat/site/trunk/docs/whichversion.html (original) +++ tomcat/site/trunk/docs/whichversion.html Fri Apr 30 17:24:35 2010 @@ -213,6 +213,11 @@ and the respective Apache Tomcat version Actual release revision + + +Minimum Java Version + + @@ -225,6 +230,9 @@ and the respective Apache Tomcat version 6.0.26 + +1.5 + @@ -237,6 +245,9 @@ and the respective Apache Tomcat version 5.5.29 + +1.4 + @@ -249,6 +260,9 @@ and the respective Apache Tomcat version 4.1.40 (archived) + +1.2 + @@ -261,6 +275,9 @@ and the respective Apache Tomcat version 3.3.2 (archived) + +1.2? + Modified: tomcat/site/trunk/xdocs/whichversion.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/whichversion.xml?rev=939748&r1=939747&r2=939748&view=diff == --- tomcat/site/trunk/xdocs/whichversion.xml (original) +++ tomcat/site/trunk/xdocs/whichversion.xml Fri Apr 30 17:24:35 2010 @@ -20,30 +20,35 @@ and the respective Apache Tomcat version Servlet/JSP Spec Apache Tomcat version Actual release revision + Minimum Java Version 2.5/2.1 6.0.x 6.0.26 + 1.5 2.4/2.0 5.5.x 5.5.29 + 1.4 2.3/1.2 4.1.x (archived) 4.1.40 (archived) + 1.2 2.2/1.1 3.3.x (archived) 3.3.2 (archived) + 1.2? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Need advice to notify StandardExecutor when a webapp is stopped
> From: Sylvain Laurent [mailto:sylvain.laur...@gmail.com] On Behalf Of > Sylvain Laurent > Subject: Re: Need advice to notify StandardExecutor when a webapp is > stopped > > Interesting idea, really ! But I suspect it might break some things in > some cases. I'm thinking about cross-context requests (where the > requestDispatcher calls another web application in the same JVM with > the same thread). Yes, any context switching by the same thread would require it to call the methods that save and restore the ThreadLocal values as part of the transition to the new context. - Chuck - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
How to replace tomcat logo in firefox?
Through Tomcat I'm launching an applet in a Mozilla Firefox browser. By default the icon on the tab and beside url is the tomcat logo. Does anyone know where this image is located and if I can replace it with my own custom logo? Thanks -- View this message in context: http://old.nabble.com/How-to-replace-tomcat-logo-in-firefox--tp28414783p28414783.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: How to replace tomcat logo in firefox?
On 30/04/2010 18:34, JohnRodey wrote: > > Through Tomcat I'm launching an applet in a Mozilla Firefox browser. By > default the icon on the tab and beside url is the tomcat logo. Does anyone > know where this image is located and if I can replace it with my own custom > logo? That would be a question for the users mailing list. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7, Valve -> Filter conversion, and container-managed authentication/authorization
IMHO filters like securityfilter are the right solution for authentication, users can use them in any container and have full control over everything. It is possible to add some hooks into tomcat so that filters like this can fully replace the built-in authentication, for example using 'magic' attributes so you don't have to depend on container-specific APIs - +1 on that. I haven't looked at the code, I have close to 0 free time this month - the main issue with bringing this code into apache or tomcat is community, i.e. having enough developers who can actively maintain it. Costin On Fri, Apr 30, 2010 at 9:50 AM, Mark Thomas wrote: > On 29/04/2010 17:38, Christopher Schultz wrote: > > David, > > > > On 4/28/2010 6:40 PM, David Jencks wrote: > >> I'd be curious how many of the features in securityfilter can be done > >> with servlet 3 (which includes the ability for an app to > >> programatically force a login) and jaspic (jsr 196) which provides > >> for pluggable authentication dialogs between client and server (to > >> overly simplify it). It looks to me as if all the features in your > >> brief description are now supported by ee specs, which also offer the > >> advantages of container managed authorization. > > > > I guess my question would be "how much of servlet 3 has been implemented > > in TC7 at this point"? sf could be the basis for both the new features > > required by the spec as well as achieving the internal goal of > > converting Valves to Filters. > > The Servlet 3.0 stuff is pretty much finished. Just the odd bug to iron > out. JSR 196 hasn't been looked at yet. > > Mark > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
svn commit: r939774 - /tomcat/trunk/java/org/apache/catalina/connector/Request.java
Author: pero
Date: Fri Apr 30 18:49:52 2010
New Revision: 939774
URL: http://svn.apache.org/viewvc?rev=939774&view=rev
Log:
Space to tab
Modified:
tomcat/trunk/java/org/apache/catalina/connector/Request.java
Modified: tomcat/trunk/java/org/apache/catalina/connector/Request.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Request.java?rev=939774&r1=939773&r2=939774&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Request.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Request.java Fri Apr 30
18:49:52 2010
@@ -2514,12 +2514,11 @@ public class Request
if (part.getFilename() == null) {
try {
String encoding = parameters.getEncoding();
-if(encoding == null) {
- encoding = Parameters.DEFAULT_ENCODING;
+if (encoding == null) {
+encoding = Parameters.DEFAULT_ENCODING;
}
-
parameters.addParameterValues(part.getName(),
-new String[] {part.getString(
-encoding)});
+parameters.addParameterValues(part.getName(),
+new String[] { part.getString(encoding) });
} catch (UnsupportedEncodingException uee) {
try {
parameters.addParameterValues(part.getName(),
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7, Valve -> Filter conversion, and container-managed authentication/authorization
On 30/04/2010, Mark Thomas wrote: > On 29/04/2010 17:38, Christopher Schultz wrote: > > David, > > > > On 4/28/2010 6:40 PM, David Jencks wrote: > >> I'd be curious how many of the features in securityfilter can be done > >> with servlet 3 (which includes the ability for an app to > >> programatically force a login) and jaspic (jsr 196) which provides > >> for pluggable authentication dialogs between client and server (to > >> overly simplify it). It looks to me as if all the features in your > >> brief description are now supported by ee specs, which also offer the > >> advantages of container managed authorization. > > > > I guess my question would be "how much of servlet 3 has been implemented > > in TC7 at this point"? sf could be the basis for both the new features > > required by the spec as well as achieving the internal goal of > > converting Valves to Filters. > > > The Servlet 3.0 stuff is pretty much finished. Just the odd bug to iron > out. BTW, there are still quite a few Javadoc warnings - mainly @return with no description > JSR 196 hasn't been looked at yet. > > > Mark > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Tomcat 7.0.0 based on Tomcat 7.0.0 RC1
On Apr 14, 2010, at 5:41 PM, Mark Thomas wrote: > On 14/04/2010 21:31, Mark Thomas wrote: >> On 14/04/2010 21:06, sebb wrote: >>> 2 files in BCEL have IBM headers; these headers are presumably OK, but >>> the NOTICE file probably needs to mention IBM. Not sure why the BCEL >>> source archive does not do so in its NOTICE file. That might be an >>> error. >> Hmm. I might be able to strip down what we use from BCEL to get rid of >> those. > > Easier said than done. I'll add the necessary updates to LICENSE & NOTICE. I'm assuming that this vote has been cancelled. And apologies for jumping in so late -- just read this thread (motivated by discussion on geronimo dev list). IMO, these files are not valid source files for an Apache release. I see the two files in question were/are CPL licensed and you have elected to distribute the files under EPL, instead. Either license seems problematic. So, I'm not sure why it would matter... Both licenses are Category B licenses (according to http://www.apache.org/legal/resolved.html ). Unless you feel this source falls under the Category B exemption (which I don't think they do), they should not be included in a release: "For small amounts of source that is directly consumed by the ASF product at runtime in source form, and for which that source is unmodified and unlikely to be changed anyway (say, by virtue of being specified by a standard), inclusion of appropriately labeled source is also permitted. An example of this is the web-facesconfig_1_0.dtd, whose inclusion is mandated by the JSR 127: JavaServer Faces specification." --kevan - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
