Generics and the spec interfaces
All, As you have probably noticed I am doing some clean-up of the trunk codebase as and when the opportunity arises. So far the clean has identified the odd copy/paste error or casting problem as well as (hopefully) making the code easier to read. The fixes for the errors are getting ported to 6.0.x. I am currently pondering what to do with lines like this: Enumeration e = request.getHeaderNames(); As I see it the options are: 1. Leave it as it is. 2. Use Enumeration e = request.getHeaderNames(); 3. Use Enumeration e = request.getHeaderNames(); 4. Use Enumeration e = request.getHeaderNames(); and modify HttpServletRequest to use generics 5. Something else. I am leaning towards 4 on the basis that a) This is trunk, not a release branch b) This option generates no warnings c) I assume the spec will start using generics at some point (maybe in 3.0?) If modifying the spec interfaces seems like a step too far then 3 would be my next choice. Thoughts? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generics and the spec interfaces
I'm for 3 since I wonder if the option 4 follow the specs. 2008/5/6 Mark Thomas <[EMAIL PROTECTED]>: > All, > > As you have probably noticed I am doing some clean-up of the trunk codebase > as and when the opportunity arises. So far the clean has identified the odd > copy/paste error or casting problem as well as (hopefully) making the code > easier to read. The fixes for the errors are getting ported to 6.0.x. > > I am currently pondering what to do with lines like this: > Enumeration e = request.getHeaderNames(); > > As I see it the options are: > 1. Leave it as it is. > 2. Use > Enumeration e = request.getHeaderNames(); > 3. Use > Enumeration e = request.getHeaderNames(); > 4. Use > Enumeration e = request.getHeaderNames(); > and modify HttpServletRequest to use generics > 5. Something else. > > I am leaning towards 4 on the basis that > a) This is trunk, not a release branch > b) This option generates no warnings > c) I assume the spec will start using generics at some point (maybe in > 3.0?) > If modifying the spec interfaces seems like a step too far then 3 would be > my next choice. > > Thoughts? > > Mark > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generics and the spec interfaces
On Tue, 2008-05-06 at 08:27 +0100, Mark Thomas wrote: > I am leaning towards 4 on the basis that > a) This is trunk, not a release branch > b) This option generates no warnings > c) I assume the spec will start using generics at some point (maybe in 3.0?) > If modifying the spec interfaces seems like a step too far then 3 would be > my next choice. There are signature tests in the TCK :( I don't think that will pass. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44942] New: Jsonplugin RPC packets
https://issues.apache.org/bugzilla/show_bug.cgi?id=44942 Summary: Jsonplugin RPC packets Product: Tomcat 6 Version: 6.0.16 Platform: PC OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Only on 6.0.16 version of Tomcat the problem of Out Of Memory Exception and Invalid Json Packet Exception was discovered. This version doesn't work correctly with JSON RPC packets (several vesions of jsonplugin were probed). -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generics and the spec interfaces
And if the TCK signature tests pass - that's a bug in the tests :-). We shouldn't touch the method signatures in servlet API. Costin On Tue, May 6, 2008 at 2:03 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote: > On Tue, 2008-05-06 at 08:27 +0100, Mark Thomas wrote: > > I am leaning towards 4 on the basis that > > a) This is trunk, not a release branch > > b) This option generates no warnings > > c) I assume the spec will start using generics at some point (maybe in > 3.0?) > > If modifying the spec interfaces seems like a step too far then 3 would > be > > my next choice. > > There are signature tests in the TCK :( I don't think that will pass. > > Rémy > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
DO NOT REPLY [Bug 44943] New: Inconsistent engine name Catalina vs Standalone in server.xml
https://issues.apache.org/bugzilla/show_bug.cgi?id=44943 Summary: Inconsistent engine name Catalina vs Standalone in server.xml Product: Tomcat 5 Version: 5.5.26 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Connector:AJP AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The following is in server.xml: The commented name should be Catalina not Standalone. It is *way* too easy to Cut and paste so that it looks like this: and end up blowing a lot of time trying to figure out why the manager web application (http://localhost:8080/manager/html) returns a 404 !! This is due to the context file tomcat/conf/Catalina/localhost/manager.xml Not being read. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generics and the spec interfaces
Costin Manolache wrote: And if the TCK signature tests pass - that's a bug in the tests :-). We shouldn't touch the method signatures in servlet API. Having read everyone's comments and having thought some more about this during today, my current plan is: - fix any non-generics warnings in the spec code - commit the fixes - fix the generics warnings but don't commit - I can make a patch available on p.o.a if anyone is interested - fix the warnings in the rest of the code base. Mark Costin On Tue, May 6, 2008 at 2:03 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote: On Tue, 2008-05-06 at 08:27 +0100, Mark Thomas wrote: I am leaning towards 4 on the basis that a) This is trunk, not a release branch b) This option generates no warnings c) I assume the spec will start using generics at some point (maybe in 3.0?) If modifying the spec interfaces seems like a step too far then 3 would be my next choice. There are signature tests in the TCK :( I don't think that will pass. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r653852 - in /tomcat/trunk/java/javax: el/BeanELResolver.java servlet/jsp/el/ImplicitObjectELResolver.java
Author: markt
Date: Tue May 6 10:51:01 2008
New Revision: 653852
URL: http://svn.apache.org/viewvc?rev=653852&view=rev
Log:
Code clean up - remove unnecessary casts.
Modified:
tomcat/trunk/java/javax/el/BeanELResolver.java
tomcat/trunk/java/javax/servlet/jsp/el/ImplicitObjectELResolver.java
Modified: tomcat/trunk/java/javax/el/BeanELResolver.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/el/BeanELResolver.java?rev=653852&r1=653851&r2=653852&view=diff
==
--- tomcat/trunk/java/javax/el/BeanELResolver.java (original)
+++ tomcat/trunk/java/javax/el/BeanELResolver.java Tue May 6 10:51:01 2008
@@ -287,7 +287,7 @@
Method mp = null;
for (int i = 0; i < inf.length; i++) {
try {
- mp = inf[i].getMethod(m.getName(), (Class[])
m.getParameterTypes());
+ mp = inf[i].getMethod(m.getName(),
m.getParameterTypes());
mp = getMethod(mp.getDeclaringClass(), mp);
if (mp != null) {
return mp;
@@ -298,7 +298,7 @@
Class sup = type.getSuperclass();
if (sup != null) {
try {
- mp = sup.getMethod(m.getName(), (Class[])
m.getParameterTypes());
+ mp = sup.getMethod(m.getName(),
m.getParameterTypes());
mp = getMethod(mp.getDeclaringClass(), mp);
if (mp != null) {
return mp;
Modified: tomcat/trunk/java/javax/servlet/jsp/el/ImplicitObjectELResolver.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/jsp/el/ImplicitObjectELResolver.java?rev=653852&r1=653851&r2=653852&view=diff
==
--- tomcat/trunk/java/javax/servlet/jsp/el/ImplicitObjectELResolver.java
(original)
+++ tomcat/trunk/java/javax/servlet/jsp/el/ImplicitObjectELResolver.java Tue
May 6 10:51:01 2008
@@ -320,8 +320,7 @@
while (e.hasMoreElements()) {
list.add(e.nextElement().toString());
}
-return (String[]) list.toArray(new String[list
-.size()]);
+return list.toArray(new String[list.size()]);
}
return null;
}
@@ -497,7 +496,7 @@
}
public Object getKey() {
-return (Object) this.key;
+return this.key;
}
public Object getValue() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r653855 - /tomcat/trunk/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java
Author: markt
Date: Tue May 6 10:52:29 2008
New Revision: 653855
URL: http://svn.apache.org/viewvc?rev=653855&view=rev
Log:
Code clean-up. Remove unused method.
Modified:
tomcat/trunk/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java
Modified: tomcat/trunk/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java?rev=653855&r1=653854&r2=653855&view=diff
==
--- tomcat/trunk/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java
(original)
+++ tomcat/trunk/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java Tue
May 6 10:52:29 2008
@@ -19,7 +19,6 @@
import java.beans.FeatureDescriptor;
import java.util.ArrayList;
-import java.util.Collection;
import java.util.Enumeration;
import java.util.Iterator;
import java.util.List;
@@ -184,12 +183,6 @@
return list.iterator();
}
- private static void appendEnumeration(Collection c, Enumeration e) {
- while (e.hasMoreElements()) {
- c.add(e.nextElement());
- }
- }
-
public Class getCommonPropertyType(ELContext context, Object
base) {
if (base == null) {
return String.class;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generics and the spec interfaces
Mark Thomas wrote: Costin Manolache wrote: And if the TCK signature tests pass - that's a bug in the tests :-). We shouldn't touch the method signatures in servlet API. Having read everyone's comments and having thought some more about this during today, my current plan is: - fix any non-generics warnings in the spec code - commit the fixes - fix the generics warnings but don't commit - I can make a patch available on p.o.a if anyone is interested - fix the warnings in the rest of the code base. Can you please send a proposal (including diffs) to the JSR-315 EG? "Generification" of the Servlet APIs is being considered for Servlet 3.0. Thanks, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
May Chun Chew/FEA/PEC is out of the office.
I will be out of the office starting 05/07/2008 and will not return until 05/12/2008. I am Contactable at (65)97876648. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44946] New: tomcat-connector How-to for IIS 6. 0 should include adding Web Service Extensions
https://issues.apache.org/bugzilla/show_bug.cgi?id=44946 Summary: tomcat-connector How-to for IIS 6.0 should include adding Web Service Extensions Product: Tomcat 5 Version: Unknown Platform: PC URL: http://tomcat.apache.org/connectors- doc/webserver_howto/iis.html#Configuring%20the%20ISAPI%2 0Redirector OS/Version: Windows Server 2003 Status: NEW Keywords: PatchAvailable Severity: normal Priority: P2 Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Created an attachment (id=21928) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=21928) Adds instruction for IIS 6 to add dll as a Web Service Extension Overview: Using the current instructions off of the apache web site, the isapi_redirect.dll will not successfully run in IIS 6.0. Steps to Reproduce: On Windows Server 2003 running IIS 6 install the isapi_redirect.dll following the directions in 'Configuration' at http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html#Configuring%20the%20ISAPI%20Redirector When you're done, he configuration looks complete. Actual Result: The connector is filtering the request, and entries will be made in the log file proving that the connector is reading and matching requests. However, the requests do not get forwarded to Tomcat. Expected Result: The connector should be forwarding requests that match the entries in uriworkers.properties to the Tomcat instance specified by the matched worker. Build & Platform: Setup: Win Server 2k3 IIS 6.0 Tomcat 5.5 (JBoss 4.0.4) isapi_redirect-1.2.26.dll isapi_redirect-1.2.25.dll isapi_redirect-1.2.15.dll IE 5,6 Firefox 2.0.0.14 Further Information: The required information is already on the atlassian website, however it should probably be included in the core documentation at apache. Googling turns up more instances of people having this problem before returning atlassian's page. http://confluence.atlassian.com/display/DOC/Setting+up+Confluence+with+IIS (Scroll down to the section titled IIS 6.0) Severity: Set to normal as this only impacts a very specific configuration. However, in that configuration it's critical as it prevents any normal operation of the connector. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44942] Jsonplugin RPC packets
https://issues.apache.org/bugzilla/show_bug.cgi?id=44942 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-05-06 23:56:00 PST --- The OOME is probably an application issue rather than a Tomcat one but you'll need to do some investigartion with a profiler to be sure. The InvalidJsonPacketException might be related to bug 44494. There isn't enough information in this report to investigate either of these issues further so I suggest you use the users list to help you debug them. If you discover you have found a new bug in Tomcat then please re-open this report and provide the minimum steps (including example code) to reproduce the issue on a clean install. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
