[jira] [Created] (MTOMCAT-173) Direct dependencies are not added to classpath
Arne Franken created MTOMCAT-173:
Summary: Direct dependencies are not added to classpath
Key: MTOMCAT-173
URL: https://issues.apache.org/jira/browse/MTOMCAT-173
Project: Apache Tomcat Maven Plugin
Issue Type: Bug
Components: tomcat6, tomcat7
Affects Versions: 2.0
Reporter: Arne Franken
Assignee: Olivier Lamy (*$^¨%`£)
in {{DefaultClassLoaderEntriesCalculator#calculateClassPathEntries}}, direct
dependencies are not added, the log message says {{"skip adding artifact " +
artifact.getArtifactId() + " as it's in reactors"}}.
When the Webapp starts, the Jar is missing from the Classpath and the startup
fails.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Updated] (MTOMCAT-173) Direct dependencies are not added to classpath
[
https://issues.apache.org/jira/browse/MTOMCAT-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arne Franken updated MTOMCAT-173:
-
Description:
in DefaultClassLoaderEntriesCalculator#calculateClassPathEntries, direct
dependencies are not added, the log message says "skip adding artifact " +
artifact.getArtifactId() + " as it's in reactors".
When the Webapp starts, the Jar is missing from the Classpath and the startup
fails.
was:
in {{DefaultClassLoaderEntriesCalculator#calculateClassPathEntries}}, direct
dependencies are not added, the log message says {{"skip adding artifact " +
artifact.getArtifactId() + " as it's in reactors"}}.
When the Webapp starts, the Jar is missing from the Classpath and the startup
fails.
> Direct dependencies are not added to classpath
> --
>
> Key: MTOMCAT-173
> URL: https://issues.apache.org/jira/browse/MTOMCAT-173
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
> Components: tomcat6, tomcat7
>Affects Versions: 2.0
>Reporter: Arne Franken
>Assignee: Olivier Lamy (*$^¨%`£)
>
> in DefaultClassLoaderEntriesCalculator#calculateClassPathEntries, direct
> dependencies are not added, the log message says "skip adding artifact " +
> artifact.getArtifactId() + " as it's in reactors".
> When the Webapp starts, the Jar is missing from the Classpath and the startup
> fails.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Updated] (MTOMCAT-173) Direct dependencies are not added to classpath
[ https://issues.apache.org/jira/browse/MTOMCAT-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arne Franken updated MTOMCAT-173: - Description: in DefaultClassLoaderEntriesCalculator#calculateClassPathEntries, direct dependencies are not added, the log message says "skip adding artifact " + artifact.getArtifactId() + " as it's in reactors". In my case, it's a jar that is configured as a direct dependency. When the Webapp starts, the Jar is missing from the Classpath and the startup fails. was: in DefaultClassLoaderEntriesCalculator#calculateClassPathEntries, direct dependencies are not added, the log message says "skip adding artifact " + artifact.getArtifactId() + " as it's in reactors". When the Webapp starts, the Jar is missing from the Classpath and the startup fails. > Direct dependencies are not added to classpath > -- > > Key: MTOMCAT-173 > URL: https://issues.apache.org/jira/browse/MTOMCAT-173 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat6, tomcat7 >Affects Versions: 2.0 >Reporter: Arne Franken >Assignee: Olivier Lamy (*$^¨%`£) > > in DefaultClassLoaderEntriesCalculator#calculateClassPathEntries, direct > dependencies are not added, the log message says "skip adding artifact " + > artifact.getArtifactId() + " as it's in reactors". > In my case, it's a jar that is configured as a direct dependency. When the > Webapp starts, the Jar is missing from the Classpath and the startup fails. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53714] New: misleading log output when jarsToSkip cointains web-fragments
https://issues.apache.org/bugzilla/show_bug.cgi?id=53714 Priority: P2 Bug ID: 53714 Assignee: dev@tomcat.apache.org Summary: misleading log output when jarsToSkip cointains web-fragments Severity: minor Classification: Unclassified OS: Linux Reporter: volker.kr...@abas.de Hardware: PC Status: NEW Version: 7.0.26 Component: Jasper Product: Tomcat 7 I have a jar which contains a web-fragment and no TLDs. When starting the server I get the Message: org.apache.jasper.compiler.TldLocationsCache tldScanJar INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. so far so good. When adding it to the tomcat.util.scan.DefaultJarScanner.jarsToSkip property the web-fragment won't be scanned either. The log message should only be printed when no TLDs and web-fragments could be found in the jar. -- 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 "charise" by charise
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "charise" page has been changed by charise: http://wiki.apache.org/tomcat/charise New page: ##language:en == Your Name == Email: <> ... CategoryHomepage - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53641] Wrong websocket's subprotocol implementation
https://issues.apache.org/bugzilla/show_bug.cgi?id=53641
--- Comment #2 from Stephan Wolf ---
Thanks a lot!
By the way, here is workaround for those who can't wait:
Just add the following code into your WebsocketServlet:
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
HttpServletRequestWrapper wrapper = new HttpServletRequestWrapper(req){
@Override
public Enumeration getHeaders(String name) {
if(name.equals("Sec-WebSocket-Protocol-Client")){
return super.getHeaders("Sec-Websocket-Protocol");
}
return super.getHeaders(name);
}
};
super.doGet(wrapper, resp);
}
--
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: [Bug 53584] Forms authentication without cookies requires double submission in 6.0.33
On 07/08/12 22:33, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=53584 Mark Thomas changed: What|Removed |Added OS||All --- Comment #1 from Mark Thomas --- Thanks for an excellent bug report. The issue was a real pleasure to investigate - not just because the root cause was interesting but because I could focus on the interesting bits rather than having to waste time trying to build the test WAR using the current flavour of the month for scm and/or build tool and/or source layout. Simple WARs are *SO* much easier to work with. The clear steps to re-create the issue were also extremely helpful. So again, thank-you. The root cause is that as of 6.0.33 path parameters are included the value returned from HttpServletRequest.getRequestURI(). During the FORM auth, one of the checks post authentication is "Does the current URI equal the original URI?" The problem is that the current URI always contains the session ID as a path parameter whereas the first time through the authentication the original URI does not. This issue also affects trunk and 7.0.x. I have fixed this issue in trunk and 7.0.x for 7.0.30 onwards and proposed the fix for 6.0.x. Mark, I have intermittently observed a similar problem with tc6 and tc7 over the last couple of years. It has been on my own list of things to investigate, but so far my various efforts haven't allowed me to reproduce it on demand and analyse it fully. Bug 53584 deals with the case where the session id is not transmitted in a cookie, but my situation does use cookies. Reading about your investigation and solution suggests to me that the underlying problem is not directly related to the "no cookie" case, but you mention a mismatch in the uri as the underlying cause. I feel it is possible that my own case also involves a uri mismatch, but I need to understand this particular bug and its fix before I can decide. Even though it is fixed, I would like to write a unit test case for this particular bug. Once done, I can use it as a template to simulate my own situation and see whether that has been fixed too. I would like to start developing the first test soon, but you could save me some time. Based on your current understanding, would you mind outlining the minimal conditions needed to trigger this particular failure case? Thanks, Brian - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-taglibs-standard (in module tomcat-taglibs) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project tomcat-taglibs-standard has an issue affecting its community
integration.
This issue affects 2 projects,
and has been outstanding for 12 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-taglibs-standard : Standard Taglib
- tomcat-taglibs-standard-install : JSP Taglibs
Full details are available at:
http://vmgump.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-INFO- Optional dependency httpunit failed with reason build failed
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/tomcat-taglibs/standard/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/tomcat-taglibs/standard/pom.xml
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/gump_work/build_tomcat-taglibs_tomcat-taglibs-standard.html
Work Name: build_tomcat-taglibs_tomcat-taglibs-standard (Type: Build)
Work ended in a state of : Failed
Elapsed: 19 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings
/srv/gump/public/workspace/tomcat-taglibs/standard/gump_mvn_settings.xml
install
[Working Directory: /srv/gump/public/workspace/tomcat-taglibs/standard]
M2_HOME: /opt/maven2
-
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/srv/gump/public/workspace/tomcat-taglibs/standard/spec/src/test/resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] No sources to compile
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [bundle:bundle {execution: default-bundle}]
[INFO] [install:install {execution: default-install}]
[INFO] Installing
/srv/gump/public/workspace/tomcat-taglibs/standard/spec/target/taglibs-standard-spec-1.2-SNAPSHOT.jar
to
/srv/gump/public/workspace/mvnlocalrepo/shared/org/apache/taglibs/taglibs-standard-spec/1.2-SNAPSHOT/taglibs-standard-spec-1.2-SNAPSHOT.jar
[INFO] [bundle:install {execution: default-install}]
[INFO] Parsing
file:/srv/gump/public/workspace/mvnlocalrepo/shared/repository.xml
[INFO] Installing
org/apache/taglibs/taglibs-standard-spec/1.2-SNAPSHOT/taglibs-standard-spec-1.2-SNAPSHOT.jar
[INFO] Writing OBR metadata
[INFO]
[INFO] Building JSTL Implementation
[INFO]task-segment: [install]
[INFO]
[INFO] [remote-resources:process {execution: default}]
[INFO] snapshot org.apache.taglibs:taglibs-standard-spec:1.2-SNAPSHOT: checking
for updates from apache.snapshots
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 14 resources
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 96 source files to
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/src/main/java/org/apache/taglibs/standard/tag/common/sql/DataSourceWrapper.java:[38,7]
error: DataSourceWrapper is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[INFO] 1 error
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/src/main/java/org/apache/taglibs/standard/tag/common/sql/DataSourceWrapper.java:[38,7]
error: DataSourceWrapper is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO] ---
[Bug 53717] New: HTTPS Connector not buffering results correctly
https://issues.apache.org/bugzilla/show_bug.cgi?id=53717 Priority: P2 Bug ID: 53717 Assignee: dev@tomcat.apache.org Summary: HTTPS Connector not buffering results correctly Severity: normal Classification: Unclassified Reporter: jod...@gmail.com Hardware: PC Status: NEW Version: 7.0.29 Component: Connectors Product: Tomcat 7 Created attachment 29226 --> https://issues.apache.org/bugzilla/attachment.cgi?id=29226&action=edit Sample client showing buffering It appears that tomcat 7.0.29 under Java 1.6.0_33 is operating a bit strangely in how it is buffering SSL responses (and differently from 1.6.0_25). I have a web app that just has a single servlet that outputs a few thousand characters of data (in valid html). Tomcat is set up to use the Http11NioProtocol connector and a self-signed certificate. If I try using a SSLSocket to read the data from the page every other chunk of the data will have only a single byte, followed by a normal sized chunk. The client just uses the normal OutputStream.read function passing in a large buffer (source attached). Sample Output- Count of Bytes Read: 16384 Data:HTTP/1.1 200 OK Ser--SNIP--defabcdefabcdefabcde Count of Bytes Read: 1 Data: f Count of Bytes Read: 275 Data:abcdefabcdefabcdefab--SNIP--cdefabcdefabcdefabcd Count of Bytes Read: 1 Data: e Count of Bytes Read: 1666 Data:fabcdefabcdefabcdefa--SNIP--y> This behavior only happens with the secure connector. If use a non-secure connector, the chunks are all sized similarly. This is different from the behavior when tomcat is running using 1.6.0_25. Under that version, the chunks appear to be normally-sized (no 1-byte chunks). I've attached a sample client that uses a SSLSocket to connect directly to tomcat and show how the buffering is working. I've confirmed that the version of the client doesn't matter, the same issue happens regardless of whether I'm using 1.6.0_25 or 1.6.0_33 -- 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
[Bug 53719] New: Path in /META-INF/Context.xml not getting used
https://issues.apache.org/bugzilla/show_bug.cgi?id=53719 Priority: P2 Bug ID: 53719 Assignee: dev@tomcat.apache.org Summary: Path in /META-INF/Context.xml not getting used Severity: major Classification: Unclassified Reporter: patrick.ba...@cnoinc.com Hardware: Macintosh Status: NEW Version: 7.0.29 Component: Catalina Product: Tomcat 7 I am trying to set the context root of our webapp, to be "myapp", however, the name of the war file dropped into the webapps directory, is myapp-1.0.4.war. I read that if I provided a context.xml file under /META-INF of my war, then I could specify the path and that should be used instead of the war name. However, that is not happening. I have tried with Tomcat's base install, and then I also set deployXML="true" as well as copyXML="true" on the host as well. None of it had an impact. my context.xml.. I also tried: When I drop myapp-1.0.4.war into /webapps, it is deployed, however I have to acces it via localhost:8080/myapp-1.0.4 After deployment, I see /conf/Catalina/localhost/who-1.0.4.xml get created. -- 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: [Bug 53584] Forms authentication without cookies requires double submission in 6.0.33
Brian Burch wrote: >On 07/08/12 22:33, bugzi...@apache.org wrote: >> https://issues.apache.org/bugzilla/show_bug.cgi?id=53584 >> >> Mark Thomas changed: >> >> What|Removed |Added >> > >> OS||All >> >> --- Comment #1 from Mark Thomas --- >> Thanks for an excellent bug report. The issue was a real pleasure to >> investigate - not just because the root cause was interesting but >because I >> could focus on the interesting bits rather than having to waste time >trying to >> build the test WAR using the current flavour of the month for scm >and/or build >> tool and/or source layout. Simple WARs are *SO* much easier to work >with. >> >> The clear steps to re-create the issue were also extremely helpful. >So again, >> thank-you. >> >> The root cause is that as of 6.0.33 path parameters are included the >value >> returned from HttpServletRequest.getRequestURI(). During the FORM >auth, one of >> the checks post authentication is "Does the current URI equal the >original >> URI?" The problem is that the current URI always contains the session >ID as a >> path parameter whereas the first time through the authentication the >original >> URI does not. >> >> This issue also affects trunk and 7.0.x. >> >> I have fixed this issue in trunk and 7.0.x for 7.0.30 onwards and >proposed the >> fix for 6.0.x. > >Mark, > >I have intermittently observed a similar problem with tc6 and tc7 over >the last couple of years. It has been on my own list of things to >investigate, but so far my various efforts haven't allowed me to >reproduce it on demand and analyse it fully. > >Bug 53584 deals with the case where the session id is not transmitted >in >a cookie, but my situation does use cookies. Reading about your >investigation and solution suggests to me that the underlying problem >is >not directly related to the "no cookie" case, but you mention a >mismatch >in the uri as the underlying cause. I feel it is possible that my own >case also involves a uri mismatch, but I need to understand this >particular bug and its fix before I can decide. > >Even though it is fixed, I would like to write a unit test case for >this >particular bug. Once done, I can use it as a template to simulate my >own >situation and see whether that has been fixed too. > >I would like to start developing the first test soon, but you could >save >me some time. Based on your current understanding, would you mind >outlining the minimal conditions needed to trigger this particular >failure case? > >Thanks, > >Brian > > >- >To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >For additional commands, e-mail: dev-h...@tomcat.apache.org Steps to reproduce are provided in the bug report. The root cause was that the redirect after authentication contained a path parameter (the session id) which was not present in the saved request hence the URIs did not match. I don't see any way this could occur when cookies are used unless something in the request path is injecting path parameters into the URI. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53719] Path in /META-INF/Context.xml not getting used
https://issues.apache.org/bugzilla/show_bug.cgi?id=53719 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID OS||All --- Comment #1 from Mark Thomas --- Working as designed. Bugzilla is not a support forum. Please use the users mailing list. -- 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
[Bug 53719] Path in /META-INF/Context.xml not getting used
https://issues.apache.org/bugzilla/show_bug.cgi?id=53719 --- Comment #2 from Chuck Caldarale --- Bugzilla is not a support forum. Please post you query on the Tomcat users' mailing list. Also, make sure you read the documentation on the element first, especially the sections about when the path attribute is allowed (rarely): http://tomcat.apache.org/tomcat-7.0-doc/config/context.html -- 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
[Bug 53712] localvariabletable length error reintroduced?
https://issues.apache.org/bugzilla/show_bug.cgi?id=53712 --- Comment #3 from Colin Mac --- I've upgraded the ecj compiler past the point where it would work at all anymore. The last "successful" build -- successful in that it would render most pages -- was ecj-3.7.2 for tomcat 5.5. (Version 4 of the libraries didn't work at all.) But this still exhibited the localvariabletable length bug. So I removed all ecj's from the common/lib directory and replaced it, according to instructions, with the latest ant.jar and ant-launcher.jar. These showed the exact same localvariabletable length error that ecj had -- same wording and everything -- and more important, the same error trace. So maybe ecj wasn't the culprit? LocalVariableTable has wrong length in class file org/apache/jsp/cbs/views/eventb/form_jsp java.lang.ClassFormatError: LocalVariableTable has wrong length in class file org/apache/jsp/cbs/views/eventb/form_jsp at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:131) ... -- 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
Adding Tomcat 8 to BZ
Having just found another Tomcat 8 specific bug, I am going to create a Tomcat 8 product (based on Tomcat 7) in BZ. It should be available in a few minutes. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 53584] Forms authentication without cookies requires double submission in 6.0.33
On 14/08/12 16:58, Mark Thomas wrote: Brian Burch wrote: On 07/08/12 22:33, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=53584 Mark Thomas changed: What|Removed |Added OS||All --- Comment #1 from Mark Thomas --- Thanks for an excellent bug report. The issue was a real pleasure to investigate - not just because the root cause was interesting but because I could focus on the interesting bits rather than having to waste time trying to build the test WAR using the current flavour of the month for scm and/or build tool and/or source layout. Simple WARs are *SO* much easier to work with. The clear steps to re-create the issue were also extremely helpful. So again, thank-you. The root cause is that as of 6.0.33 path parameters are included the value returned from HttpServletRequest.getRequestURI(). During the FORM auth, one of the checks post authentication is "Does the current URI equal the original URI?" The problem is that the current URI always contains the session ID as a path parameter whereas the first time through the authentication the original URI does not. This issue also affects trunk and 7.0.x. I have fixed this issue in trunk and 7.0.x for 7.0.30 onwards and proposed the fix for 6.0.x. Mark, I have intermittently observed a similar problem with tc6 and tc7 over the last couple of years. It has been on my own list of things to investigate, but so far my various efforts haven't allowed me to reproduce it on demand and analyse it fully. Bug 53584 deals with the case where the session id is not transmitted in a cookie, but my situation does use cookies. Reading about your investigation and solution suggests to me that the underlying problem is not directly related to the "no cookie" case, but you mention a mismatch in the uri as the underlying cause. I feel it is possible that my own case also involves a uri mismatch, but I need to understand this particular bug and its fix before I can decide. Even though it is fixed, I would like to write a unit test case for this particular bug. Once done, I can use it as a template to simulate my own situation and see whether that has been fixed too. I would like to start developing the first test soon, but you could save me some time. Based on your current understanding, would you mind outlining the minimal conditions needed to trigger this particular failure case? Thanks, Brian - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org Steps to reproduce are provided in the bug report. The root cause was that the redirect after authentication contained a path parameter (the session id) which was not present in the saved request hence the URIs did not match. I don't see any way this could occur when cookies are used unless something in the request path is injecting path parameters into the URI. Thanks for your opinions. I'll get on with the new test - it will be useful to avoid regression. (I extrapolate from your comment that my own problem might turn out to be an error in the configuration or user code). 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
[Bug 53700] InternalNioOutputBuffer unused (debug?) code
https://issues.apache.org/bugzilla/show_bug.cgi?id=53700 Mark Thomas changed: What|Removed |Added Component|Catalina|Connectors Product|Tomcat 7|Tomcat 8 Target Milestone|--- | -- 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: r1372998 - /tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Author: markt
Date: Tue Aug 14 18:00:44 2012
New Revision: 1372998
URL: http://svn.apache.org/viewvc?rev=1372998&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53700
Remove unused code that also broke some Javadoc
Modified:
tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Modified:
tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java?rev=1372998&r1=1372997&r2=1372998&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java Tue
Aug 14 18:00:44 2012
@@ -224,7 +224,6 @@ public class InternalNioOutputBuffer ext
* @throws IOException
* TODO Fix non blocking write properly
*/
-int total = 0;
private synchronized int writeToSocket(ByteBuffer bytebuffer, boolean
block, boolean flip) throws IOException {
if ( flip ) {
bytebuffer.flip();
@@ -256,8 +255,6 @@ public class InternalNioOutputBuffer ext
bytebuffer.clear();
flipped = false;
}
-total+= written;
-//System.out.println("Successful write("+written+ " / "+total);
return written;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53700] InternalNioOutputBuffer unused (debug?) code
https://issues.apache.org/bugzilla/show_bug.cgi?id=53700 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Mark Thomas --- Fixed in trunk and will be included in 8.0.0 onwards -- 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: r1373003 - in /tomcat/trunk: java/javax/servlet/ java/javax/servlet/jsp/ java/org/apache/catalina/ java/org/apache/catalina/tribes/ java/org/apache/naming/ java/org/apache/tomcat/util/http
Author: markt
Date: Tue Aug 14 18:14:42 2012
New Revision: 1373003
URL: http://svn.apache.org/viewvc?rev=1373003&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53701
Javadoc fixes provided by Sebb.
Modified:
tomcat/trunk/java/javax/servlet/ServletInputStream.java
tomcat/trunk/java/javax/servlet/ServletOutputStream.java
tomcat/trunk/java/javax/servlet/jsp/JspException.java
tomcat/trunk/java/org/apache/catalina/Executor.java
tomcat/trunk/java/org/apache/catalina/Manager.java
tomcat/trunk/java/org/apache/catalina/tribes/ErrorHandler.java
tomcat/trunk/java/org/apache/naming/SelectorContext.java
tomcat/trunk/java/org/apache/tomcat/util/http/fileupload/FileItem.java
tomcat/trunk/webapps/examples/WEB-INF/classes/compressionFilters/CompressionResponseStream.java
Modified: tomcat/trunk/java/javax/servlet/ServletInputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/ServletInputStream.java?rev=1373003&r1=1373002&r2=1373003&view=diff
==
--- tomcat/trunk/java/javax/servlet/ServletInputStream.java (original)
+++ tomcat/trunk/java/javax/servlet/ServletInputStream.java Tue Aug 14 18:14:42
2012
@@ -105,7 +105,6 @@ public abstract class ServletInputStream
/**
* TODO SERVLET 3.1
- * @return
*/
public abstract void setReadListener(javax.servlet.ReadListener listener);
}
Modified: tomcat/trunk/java/javax/servlet/ServletOutputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/ServletOutputStream.java?rev=1373003&r1=1373002&r2=1373003&view=diff
==
--- tomcat/trunk/java/javax/servlet/ServletOutputStream.java (original)
+++ tomcat/trunk/java/javax/servlet/ServletOutputStream.java Tue Aug 14
18:14:42 2012
@@ -282,6 +282,5 @@ public abstract class ServletOutputStrea
/**
* TODO SERVLET 3.1
- * @return
*/
public abstract void setWriteListener(javax.servlet.WriteListener
listener);}
Modified: tomcat/trunk/java/javax/servlet/jsp/JspException.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/jsp/JspException.java?rev=1373003&r1=1373002&r2=1373003&view=diff
==
--- tomcat/trunk/java/javax/servlet/jsp/JspException.java (original)
+++ tomcat/trunk/java/javax/servlet/jsp/JspException.java Tue Aug 14 18:14:42
2012
@@ -53,7 +53,7 @@ public class JspException extends Except
* java.lang.Throwable.getCause() and {@link #getRootCause()}
* methods.
*
- * @see java.lang.Exception.Exception(String, Throwable)
+ * @see java.lang.Exception#Exception(String, Throwable)
*
* @param message a String containing the text of the
* exception message
@@ -74,7 +74,7 @@ public class JspException extends Except
* java.lang.Throwable.getCause() and {@link #getRootCause()}
* methods.
*
- * @see java.lang.Exception.Exception(Throwable)
+ * @see java.lang.Exception#Exception(Throwable)
*
* @param cause the Throwable exception that
* interfered with the JSP's normal operation, making
Modified: tomcat/trunk/java/org/apache/catalina/Executor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/Executor.java?rev=1373003&r1=1373002&r2=1373003&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/Executor.java (original)
+++ tomcat/trunk/java/org/apache/catalina/Executor.java Tue Aug 14 18:14:42 2012
@@ -31,7 +31,7 @@ public interface Executor extends java.u
* time until it throws a RejectedExecutionException
*
* @param command the runnable task
- * @throws org.apache.catalina.util.RejectedExecutionException if this task
+ * @throws java.util.concurrent.RejectedExecutionException if this task
* cannot be accepted for execution - the queue is full
* @throws NullPointerException if command or unit is null
*/
Modified: tomcat/trunk/java/org/apache/catalina/Manager.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/Manager.java?rev=1373003&r1=1373002&r2=1373003&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/Manager.java (original)
+++ tomcat/trunk/java/org/apache/catalina/Manager.java Tue Aug 14 18:14:42 2012
@@ -64,7 +64,7 @@ public interface Manager {
*
* @param container The newly associated Container
*
- * @deprecated Use {@link #setContext()}. This method will be removed in
+ * @deprecated Use {@link #setContext(Context)}. This method will be
removed in
* Tomcat 9 onwards.
*/
@Deprecated
@@ -80,7 +8
[Bug 53062] Tomcat doesn't normalize absolute urls for redirect
https://issues.apache.org/bugzilla/show_bug.cgi?id=53062 --- Comment #9 from wansho...@hotmail.com --- (In reply to comment #8) > Fixed in trunk and 7.0.x and will be included in 7.0.30 onwards. > > I think I have covered all the edge cases but if you spot an edge case you > think still isn't correct, it should be easy to extend the unit tests to > confirm this. Thanks for the explanation and quick fix. May I get an estimated release date for 7.0.30 please? Our server is currently blocked on this issue. Many thanks! -- 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: r1373051 - in /tomcat/tc7.0.x/trunk: ./ java/javax/servlet/jsp/ java/org/apache/catalina/ java/org/apache/catalina/tribes/ java/org/apache/naming/ java/org/apache/tomcat/util/http/fileuplo
Author: markt
Date: Tue Aug 14 19:47:38 2012
New Revision: 1373051
URL: http://svn.apache.org/viewvc?rev=1373051&view=rev
Log:
Javadoc fixes provided by Sebb.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/javax/servlet/jsp/JspException.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/Executor.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/ErrorHandler.java
tomcat/tc7.0.x/trunk/java/org/apache/naming/SelectorContext.java
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/http/fileupload/FileItem.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
tomcat/tc7.0.x/trunk/webapps/examples/WEB-INF/classes/compressionFilters/CompressionResponseStream.java
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1373003
Modified: tomcat/tc7.0.x/trunk/java/javax/servlet/jsp/JspException.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/javax/servlet/jsp/JspException.java?rev=1373051&r1=1373050&r2=1373051&view=diff
==
--- tomcat/tc7.0.x/trunk/java/javax/servlet/jsp/JspException.java (original)
+++ tomcat/tc7.0.x/trunk/java/javax/servlet/jsp/JspException.java Tue Aug 14
19:47:38 2012
@@ -53,7 +53,7 @@ public class JspException extends Except
* java.lang.Throwable.getCause() and {@link #getRootCause()}
* methods.
*
- * @see java.lang.Exception.Exception(String, Throwable)
+ * @see java.lang.Exception#Exception(String, Throwable)
*
* @param message a String containing the text of the
* exception message
@@ -74,7 +74,7 @@ public class JspException extends Except
* java.lang.Throwable.getCause() and {@link #getRootCause()}
* methods.
*
- * @see java.lang.Exception.Exception(Throwable)
+ * @see java.lang.Exception#Exception(Throwable)
*
* @param cause the Throwable exception that
* interfered with the JSP's normal operation, making
Modified: tomcat/tc7.0.x/trunk/java/org/apache/catalina/Executor.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/Executor.java?rev=1373051&r1=1373050&r2=1373051&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/Executor.java (original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/Executor.java Tue Aug 14
19:47:38 2012
@@ -31,7 +31,7 @@ public interface Executor extends java.u
* time until it throws a RejectedExecutionException
*
* @param command the runnable task
- * @throws org.apache.catalina.util.RejectedExecutionException if this task
+ * @throws java.util.concurrent.RejectedExecutionException if this task
* cannot be accepted for execution - the queue is full
* @throws NullPointerException if command or unit is null
*/
Modified: tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/ErrorHandler.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/ErrorHandler.java?rev=1373051&r1=1373050&r2=1373051&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/ErrorHandler.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/ErrorHandler.java Tue
Aug 14 19:47:38 2012
@@ -32,14 +32,14 @@ public interface ErrorHandler {
* Invoked if the message is dispatched asynch, and an error occurs
* @param x ChannelException - the error that happened
* @param id - the unique id for the message
- * @see Channel#send(Member[], Serializable, int, ErrorHandler)
+ * @see Channel#send(Member[], java.io.Serializable, int, ErrorHandler)
*/
public void handleError(ChannelException x, UniqueId id);
/**
* Invoked when the message has been sent successfully.
* @param id - the unique id for the message
- * @see Channel#send(Member[], Serializable, int, ErrorHandler)
+ * @see Channel#send(Member[], java.io.Serializable, int, ErrorHandler)
*/
public void handleCompletion(UniqueId id);
Modified: tomcat/tc7.0.x/trunk/java/org/apache/naming/SelectorContext.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/naming/SelectorContext.java?rev=1373051&r1=1373050&r2=1373051&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/naming/SelectorContext.java (original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/naming/SelectorContext.java Tue Aug 14
19:47:38 2012
@@ -168,7 +168,7 @@ public class SelectorContext implements
* @param obj the object to bind; possibly null
* @exception javax.naming.NameAlreadyBoundException if name is
[Bug 53701] Javadoc fixes
https://issues.apache.org/bugzilla/show_bug.cgi?id=53701 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Mark Thomas --- Thanks for the report. This has been fixed in trunk and 7.0.x and will be included in 7.0.30 onwards. -- 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
[Bug 53632] The DispatchType is INCLUDE instead of ASYNC after a dispatch via AsyncContext
https://issues.apache.org/bugzilla/show_bug.cgi?id=53632 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Mark Thomas --- I assume at some point the debug logging was outputting the result of request.getDispatchType(). The version provided doesn't do this but I have added the line to do this in my local copy. This issue has the same root cause as bug 53623 so I am marking it as a duplicate since it is really just a different symptom of the same underlying problem. *** This bug has been marked as a duplicate of bug 53623 *** -- 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
[Bug 53623] Incorrect request properties after AsyncContext.dispatch
https://issues.apache.org/bugzilla/show_bug.cgi?id=53623 --- Comment #2 from Mark Thomas --- *** Bug 53632 has been marked as a duplicate of this bug. *** -- 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: r1373080 - in /tomcat/trunk/java/org/apache/catalina: AsyncDispatcher.java core/ApplicationDispatcher.java core/AsyncContextImpl.java core/LocalStrings.properties
Author: markt
Date: Tue Aug 14 20:49:49 2012
New Revision: 1373080
URL: http://svn.apache.org/viewvc?rev=1373080&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53623
Async dispatches require similar handling to RequestDispatcher.include() hence
the implementation of async dispatch uses RequestDispatcher.include()
However, since RequestDispatcher provides no API for differentiating between
and INCLUDE and DISPATCH some form of trickery has to be used. The previous
implementation worked in most cases but failed in some cases (multiple forwards
prior to dispatch, wrapping the request).
This alternative implementation calls a specific method on the
RequestDispatcher implementation (we have to access the implementation class
since we can't modify the servlet API) which removes any ambiguity and allows
the correct handling in all cases.
Added:
tomcat/trunk/java/org/apache/catalina/AsyncDispatcher.java (with props)
Modified:
tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java
tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties
Added: tomcat/trunk/java/org/apache/catalina/AsyncDispatcher.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/AsyncDispatcher.java?rev=1373080&view=auto
==
--- tomcat/trunk/java/org/apache/catalina/AsyncDispatcher.java (added)
+++ tomcat/trunk/java/org/apache/catalina/AsyncDispatcher.java Tue Aug 14
20:49:49 2012
@@ -0,0 +1,34 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.catalina;
+
+import java.io.IOException;
+
+import javax.servlet.ServletException;
+import javax.servlet.ServletRequest;
+import javax.servlet.ServletResponse;
+
+public interface AsyncDispatcher {
+
+/**
+ * Perform an asynchronous dispatch. The method does not check if the
+ * request is in an appropriate state for this; it is the caller's
+ * responsibility to check this.
+ */
+public void dispatch(ServletRequest request, ServletResponse response)
+throws ServletException, IOException;
+}
Propchange: tomcat/trunk/java/org/apache/catalina/AsyncDispatcher.java
--
svn:eol-style = native
Modified: tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java?rev=1373080&r1=1373079&r2=1373080&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java Tue
Aug 14 20:49:49 2012
@@ -14,8 +14,6 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*/
-
-
package org.apache.catalina.core;
import java.io.IOException;
@@ -37,6 +35,7 @@ import javax.servlet.UnavailableExceptio
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
+import org.apache.catalina.AsyncDispatcher;
import org.apache.catalina.Context;
import org.apache.catalina.Globals;
import org.apache.catalina.InstanceEvent;
@@ -63,9 +62,7 @@ import org.apache.tomcat.util.res.String
* @author Craig R. McClanahan
* @version $Id$
*/
-
-final class ApplicationDispatcher
-implements RequestDispatcher {
+final class ApplicationDispatcher implements AsyncDispatcher,
RequestDispatcher {
protected static final boolean STRICT_SERVLET_COMPLIANCE;
@@ -91,8 +88,7 @@ final class ApplicationDispatcher
private final ServletRequest request;
private final ServletResponse response;
-PrivilegedForward(ServletRequest request, ServletResponse response)
-{
+PrivilegedForward(ServletRequest request, ServletResponse response) {
this.request = request;
this.response = response;
}
@@ -109,17 +105,31 @@ final class ApplicationDispatcher
private
svn commit: r1373101 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/ java/org/apache/catalina/core/ webapps/docs/
Author: markt
Date: Tue Aug 14 21:05:55 2012
New Revision: 1373101
URL: http://svn.apache.org/viewvc?rev=1373101&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53623
Async dispatches require similar handling to RequestDispatcher.include() hence
the implementation of async dispatch uses RequestDispatcher.include()
However, since RequestDispatcher provides no API for differentiating between
and INCLUDE and DISPATCH some form of trickery has to be used. The previous
implementation worked in most cases but failed in some cases (multiple forwards
prior to dispatch, wrapping the request).
This alternative implementation calls a specific method on the
RequestDispatcher implementation (we have to access the implementation class
since we can't modify the servlet API) which removes any ambiguity and allows
the correct handling in all cases.
Added:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/AsyncDispatcher.java
- copied unchanged from r1373080,
tomcat/trunk/java/org/apache/catalina/AsyncDispatcher.java
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/AsyncContextImpl.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1373080
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java?rev=1373101&r1=1373100&r2=1373101&view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
Tue Aug 14 21:05:55 2012
@@ -14,8 +14,6 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*/
-
-
package org.apache.catalina.core;
import java.io.IOException;
@@ -37,6 +35,7 @@ import javax.servlet.UnavailableExceptio
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
+import org.apache.catalina.AsyncDispatcher;
import org.apache.catalina.Context;
import org.apache.catalina.Globals;
import org.apache.catalina.InstanceEvent;
@@ -63,9 +62,7 @@ import org.apache.tomcat.util.res.String
* @author Craig R. McClanahan
* @version $Id$
*/
-
-final class ApplicationDispatcher
-implements RequestDispatcher {
+final class ApplicationDispatcher implements AsyncDispatcher,
RequestDispatcher {
protected static final boolean STRICT_SERVLET_COMPLIANCE;
@@ -91,8 +88,7 @@ final class ApplicationDispatcher
private ServletRequest request;
private ServletResponse response;
-PrivilegedForward(ServletRequest request, ServletResponse response)
-{
+PrivilegedForward(ServletRequest request, ServletResponse response) {
this.request = request;
this.response = response;
}
@@ -109,22 +105,36 @@ final class ApplicationDispatcher
private ServletRequest request;
private ServletResponse response;
-PrivilegedInclude(ServletRequest request, ServletResponse response)
-{
+PrivilegedInclude(ServletRequest request, ServletResponse response) {
this.request = request;
this.response = response;
}
@Override
public Void run() throws ServletException, IOException {
-DispatcherType type = DispatcherType.INCLUDE;
-if (request.getDispatcherType()==DispatcherType.ASYNC) type =
DispatcherType.ASYNC;
-doInclude(request,response,type);
+doInclude(request, response);
return null;
}
}
-
+protected class PrivilegedDispatch implements
+PrivilegedExceptionAction {
+private final ServletRequest request;
+private final ServletResponse response;
+
+PrivilegedDispatch(ServletRequest request, ServletResponse response) {
+this.request = request;
+this.response = response;
+}
+
+@Override
+public Void run() throws ServletException, IOException {
+doDispatch(request, response);
+return null;
+}
+}
+
+
/**
* Used to pass state when the request dispatcher is used. Using instance
* variables causes threading issues and state is too complex to pass and
@@ -531,15 +541,13 @@ final class ApplicationDispatcher
throw (IOException) e;
}
} else {
-DispatcherType type = DispatcherType.INCLUDE;
-
[Bug 53623] Incorrect request properties after AsyncContext.dispatch
https://issues.apache.org/bugzilla/show_bug.cgi?id=53623 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Mark Thomas --- This has been fixed in trunk and 7.0.x and will be included in 7.0.30 onwards. The root cause was that Tomcat used the RequestDispatcher.include() to perform async dispatches with some trickery to differentiate an include and a dispatch. Wrapping the request (which also happens on a forward) was enough to break the mechanism. A new, hopefulyl more robust, approach has been implemented and all the provided tests (including those in the duplicate) now pass. -- 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: r1373142 - /tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
Author: markt
Date: Tue Aug 14 22:14:39 2012
New Revision: 1373142
URL: http://svn.apache.org/viewvc?rev=1373142&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53624
Remove some include specific code from dispatch, copied when the doDispatch()
method was created.
Note that this bug report pre-dates that copy. At the time of the bug report
dispatch was implemented by calling include()
Modified:
tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
Modified: tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java?rev=1373142&r1=1373141&r2=1373142&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java Tue
Aug 14 22:14:39 2012
@@ -611,29 +611,15 @@ final class ApplicationDispatcher implem
throws ServletException, IOException {
// Set up to handle the specified request and response
-State state = new State(request, response, true);
+State state = new State(request, response, false);
// Create a wrapped response to use for this request
wrapResponse(state);
ApplicationHttpRequest wrequest =
(ApplicationHttpRequest) wrapRequest(state);
-String contextPath = context.getPath();
-if (requestURI != null)
-wrequest.setAttribute(RequestDispatcher.INCLUDE_REQUEST_URI,
- requestURI);
-if (contextPath != null)
-wrequest.setAttribute(RequestDispatcher.INCLUDE_CONTEXT_PATH,
- contextPath);
-if (servletPath != null)
-wrequest.setAttribute(RequestDispatcher.INCLUDE_SERVLET_PATH,
- servletPath);
-if (pathInfo != null)
-wrequest.setAttribute(RequestDispatcher.INCLUDE_PATH_INFO,
- pathInfo);
+
if (queryString != null) {
-wrequest.setAttribute(RequestDispatcher.INCLUDE_QUERY_STRING,
- queryString);
wrequest.setQueryParams(queryString);
}
@@ -642,7 +628,7 @@ final class ApplicationDispatcher implem
wrequest.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
getCombinedPath());
-wrequest.setContextPath(contextPath);
+wrequest.setContextPath(context.getPath());
wrequest.setRequestURI(requestURI);
wrequest.setServletPath(servletPath);
wrequest.setPathInfo(pathInfo);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
error while shutting down tomcat
Good evening I installed a wab application (sakai precisely) on a distant server remotely, but it doesn't start, and when I shutdown tomcat, I get that error: Using CATALINA_BASE: /opt/tomcat Using CATALINA_HOME: /opt/tomcat Using CATALINA_TMPDIR: /opt/tomcat/temp Using JRE_HOME:/opt/java Using CLASSPATH: /opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/tomcat-juli.jar 14 août 2012 13:55:44 org.apache.catalina.startup.Catalina stopServer *GRAVE: Catalina.stop: java.net.ConnectException: Connection refused* at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:529) at java.net.Socket.connect(Socket.java:478) at java.net.Socket.(Socket.java:375) at java.net.Socket.(Socket.java:189) at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:490) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:371) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:453) tomcat instance starts fine. before deploying sakai, there were no errors while starting or shutting down tomcat. >From a search on google, I understood that it could be a firewall or port problem, so, I disabled the firewall, and all the ports that are mentionned in the conf/server.xml aren't used by other processes. I appreciate your help. Regrards
[Bug 53062] Tomcat doesn't normalize absolute urls for redirect
https://issues.apache.org/bugzilla/show_bug.cgi?id=53062 --- Comment #10 from Mark Thomas --- 7.0.30 will be released when it is ready. As a volunteer organization, the ASF does not commit to release schedules. What I can say is that I try to do a Tomcat 7 release every month. The first task is clearing the current bug back-log and I am currently working on that. Once that is complete the TCKs will need to be run (takes most of a working day) and then the release candidate needs to be built (few minutes). Once we have a release candidate there will need to be a release vote and that takes a minimum of 3 days. This, of course, assumes all goes well. I would guess (based on my own schedule over the next few weeks) that 7.0.30 is at least 2-3 weeks away. If you want 7.0.30 sooner, then providing patches to the open bugs that do not have them is the best way to help out. -- 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: error while shutting down tomcat
On 14/08/2012 23:18, Ijlal EL HAZITI wrote: > Good evening > > > I installed a wab application (sakai precisely) on a distant server > remotely, but it doesn't start, and when I shutdown tomcat, I get that > error: > > Using CATALINA_BASE: /opt/tomcat > Using CATALINA_HOME: /opt/tomcat > Using CATALINA_TMPDIR: /opt/tomcat/temp > Using JRE_HOME:/opt/java > Using CLASSPATH: > /opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/tomcat-juli.jar > 14 août 2012 13:55:44 org.apache.catalina.startup.Catalina stopServer > *GRAVE: Catalina.stop: > java.net.ConnectException: Connection refused* > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213) > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) > at java.net.Socket.connect(Socket.java:529) > at java.net.Socket.connect(Socket.java:478) > at java.net.Socket.(Socket.java:375) > at java.net.Socket.(Socket.java:189) > at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:490) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:371) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:453) > > tomcat instance starts fine. > > before deploying sakai, there were no errors while starting or shutting > down tomcat. > > From a search on google, I understood that it could be a firewall or port > problem, so, I disabled the firewall, and all the ports that are mentionned > in the conf/server.xml aren't used by other processes. > > I appreciate your help. 1. Help with what? I don't see any questions in your e-mail. 2. This is the dev list. It is for managing the process of developing Tomcat. It is not for questions about using Tomcat. Once you have figured out what question(s) you want to ask, you need to use 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: error while shutting down tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ijlal, On 8/14/12 6:18 PM, Ijlal EL HAZITI wrote: > I installed a wab application (sakai precisely) on a distant > server remotely, but it doesn't start, and when I shutdown tomcat, > I get that error: This is a question better targeted at the Tomcat users' list. I am cross-posting and will not reply again to this thread on the Tomcat development mailing list. Please join the users' list and post there from now on. > Using CATALINA_BASE: /opt/tomcat Using CATALINA_HOME: > /opt/tomcat Using CATALINA_TMPDIR: /opt/tomcat/temp Using JRE_HOME: > /opt/java Using CLASSPATH: > /opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/tomcat-juli.jar 14 > août 2012 13:55:44 org.apache.catalina.startup.Catalina stopServer > *GRAVE: Catalina.stop: java.net.ConnectException: Connection > refused* at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351) at > java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213) > > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at > java.net.Socket.connect(Socket.java:529) at > java.net.Socket.connect(Socket.java:478) at > java.net.Socket.(Socket.java:375) at > java.net.Socket.(Socket.java:189) at > org.apache.catalina.startup.Catalina.stopServer(Catalina.java:490) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:371) > > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:453) If Tomcat hasn't started, then you will be unable to shut it down. > tomcat instance starts fine. Tomcat starts fine, or fails to start? You have claimed both observations. > before deploying sakai, there were no errors while starting or > shutting down tomcat. > >> From a search on google, I understood that it could be a firewall >> or port > problem, so, I disabled the firewall, and all the ports that are > mentionned in the conf/server.xml aren't used by other processes. This really depends upon the circumstances. Please join the users' mailing list and provide more information. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAq0L4ACgkQ9CaO5/Lv0PC18gCghtbM/BJBJXgAeq4u+MZCIHDu 3aAAoKyLiBb96sbDN9ykg3grlr9lv8+x =Wq5J -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1373154 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/core/ApplicationDispatcher.java webapps/docs/changelog.xml
Author: markt
Date: Tue Aug 14 22:37:56 2012
New Revision: 1373154
URL: http://svn.apache.org/viewvc?rev=1373154&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53624
Remove some include specific code from dispatch, copied when the doDispatch()
method was created.
Note that this bug report pre-dates that copy. At the time of the bug report,
dispatch was implemented by calling include()
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1373142
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java?rev=1373154&r1=1373153&r2=1373154&view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
Tue Aug 14 22:37:56 2012
@@ -631,29 +631,15 @@ final class ApplicationDispatcher implem
throws ServletException, IOException {
// Set up to handle the specified request and response
-State state = new State(request, response, true);
+State state = new State(request, response, false);
// Create a wrapped response to use for this request
wrapResponse(state);
ApplicationHttpRequest wrequest =
(ApplicationHttpRequest) wrapRequest(state);
-String contextPath = context.getPath();
-if (requestURI != null)
-wrequest.setAttribute(RequestDispatcher.INCLUDE_REQUEST_URI,
- requestURI);
-if (contextPath != null)
-wrequest.setAttribute(RequestDispatcher.INCLUDE_CONTEXT_PATH,
- contextPath);
-if (servletPath != null)
-wrequest.setAttribute(RequestDispatcher.INCLUDE_SERVLET_PATH,
- servletPath);
-if (pathInfo != null)
-wrequest.setAttribute(RequestDispatcher.INCLUDE_PATH_INFO,
- pathInfo);
+
if (queryString != null) {
-wrequest.setAttribute(RequestDispatcher.INCLUDE_QUERY_STRING,
- queryString);
wrequest.setQueryParams(queryString);
}
@@ -662,7 +648,7 @@ final class ApplicationDispatcher implem
wrequest.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
getCombinedPath());
-wrequest.setContextPath(contextPath);
+wrequest.setContextPath(context.getPath());
wrequest.setRequestURI(requestURI);
wrequest.setServletPath(servletPath);
wrequest.setPathInfo(pathInfo);
Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1373154&r1=1373153&r2=1373154&view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Tue Aug 14 22:37:56 2012
@@ -123,6 +123,11 @@
request at each stage. (markt)
+53624: Ensure that
+HttpServletResponse.sendRedirect() works when called after
+a dispatch from an AsyncContext. (markt)
+
+
53641: Correct name of HTTP header used in WebSocket
handshake for listing the preferred protocols. (markt)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53624] sendRedirect doesn't work after a dispatch through the AsyncContext
https://issues.apache.org/bugzilla/show_bug.cgi?id=53624 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Mark Thomas --- This looks to have a different root cause. This has been fixed in trunk and 7.0.x and will be included in 7.0.30 onwards. -- 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
[Bug 53624] sendRedirect doesn't work after a dispatch through the AsyncContext
https://issues.apache.org/bugzilla/show_bug.cgi?id=53624 --- Comment #2 from Mark Thomas --- *** Bug 53627 has been marked as a duplicate of this bug. *** -- 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
[Bug 53627] Content-Type header not written after dispatch via AsyncContext
https://issues.apache.org/bugzilla/show_bug.cgi?id=53627 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Mark Thomas --- Same root cause - marking the dispatch as an include and thereby preventing the alteration of request headers. *** This bug has been marked as a duplicate of bug 53624 *** -- 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
