Tomcat 5.5 question
rBase.stop(ContainerBase.java:1067) at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:448) at org.apache.catalina.core.StandardService.stop(StandardService.java:510) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:734) at org.apache.catalina.startup.Catalina.stop(Catalina.java:602) at org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run(Catalina.java: 645) My java code shows the error message that it "Cannot create JDBC driver of class 'sun.jdbc.odbc.JdbcOdbcDriver'" for my ODBC alias. Any help would be appreciated. Thanks, Mike
Possible javax.servlet.http.HttpServlet bugs, and where to report them?
I think there's a bug in javax.servlet.http.HttpServlet, but I'm not sure where to report it. I'm posting this here for the time being (and possibly on the Glassfish "issue tracker" if and when I can jump through the hoops required to do so), but please let me know if it ought to be reported some other way: and apologies if this doesn't belong here! The actual bug is that the "NoBodyResponse" inner class within HttpServlet doesn't track whether getWriter or getOutput stream have been called, and doesn't alter the response's behaviour accordingly. This differs from the ServletResponse Javadoc which states that: - Calls to getWriter are supposed to throw IllegalStateException if getOutputStream has already been called and vice-versa. - The behaviour of various other methods depend on whether or not getWriter has already been called (e.g. setCharacterEncoding is supposed to have no effect if getWriter has already been called). As a result, HTTP "HEAD" requests may complete successfully where an identical "GET" would fail with an IllegalStateException, or "HEAD" and "GET" may result in different headers (and different results from methods such as getCharacterEncoding whilst processing the request). A more general issue is that the NoBodyResponse class could, and perhaps should (to conform to SRV 8.2 of the Servlet specification), be a ServletResponseWrapper subclass. At the very least this would shorten and simplify its code. The Apache Tomcat bug database includes a couple of entries for this (Tomcat 4 bug 10555 and Tomcat 5 bug 22290), and although these have long since been "closed" on the basis that this code is the responsibility of the Servlet API itself rather than Tomcat, and therefore these bugs were handed over to the Servlet API feedback e-mail address "[EMAIL PROTECTED]", I can't find any sign of this being followed up anywhere or ever being finally resolved. This has left me rather unclear as to where to report HttpServlet bugs. The code itself doesn't seem to be part of the Servlet specification, but is supplied as part of the standard "servlet.jar", "javaee.jar" or equivalent; the source code is present and identical in multiple versions of Tomcat, and Glassfish, and probably elsewhere; Tomcat bug 22290 indicates that the Servlet API people are responsible for maintaining the code but they only seem to have an e-mail address, which itself may be obsolete (I've had no reply to an e-mail sent to it, though with e-mails it's always hard to be sure); Tomcat was the reference implementation for earlier API versions but now it's Glassfish (or is it Sun Java System Application Server?); the code has copyright notices for both Sun and Apache; and the Sun bug database has some bug reports for HttpServlet but not since Dec 2002, and its bug report form doesn't really seem to cater for this. Sorry, but I'm confused!!! Can anyone give me a definitive answer as to where bugs in javax.servlet.http.HttpServlet should be reported? Whilst we're here, I think there are also some other minor/cosmetic issues in the HttpServlet code: - The "write" method of the NoBodyOutputStream inner class has a comment saying that a negative length should "maybe" be an IllegalArgumentException, but the code actually throws an IOException. If this really should be an IllegalArgumentException, it ought to be fixed. If an IOException is OK, or if fixing this now isn't acceptable in case it breaks existing code, then maybe the comment should be removed (or updated to explain this). - The "write" method of the NoBodyOutputStream inner class reports negative lengths by looking-up an "err.io.negativelength" message, but it then ignores the result and instead uses a hard-coded string as the actual error message. - The doTrace method includes a "close" of the output stream when it has finished. However, prior to this it sets the content length and then writes that amount of content, which should always result in the output stream being automatically flushed and closed. Hence the response has already been closed when the call to close occurs. Whilst it should usually be fairly safe to assume that repeating a close won't do any harm, the output stream is implementation-specific, and I can't see anything that says it must allow duplicate close attempts (and why attempt the close at all if it isn't needed?). - The doTrace method ends with a "return;" statement, which seems rather pointless as the last statement of a method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Chrome 80 SameSite Changes
Hi, I was wondering if there have been discussions to change the behaviour around cookie generation in the Rfc6265CookieProcessor to allow for explicit generation of SameSite=none cookies in light of the changes coming to Chrome 80, in February of 2020: https://blog.chromium.org/2019/10/developers-get-ready-for-new.html. >From what I see in the existing code, SameSite=none is an implicit default and will not result in that property being explicitly set on the generated cookie. Thanks, Michael
Re: Chrome 80 SameSite Changes
Hey Mark, My bad - I must've had a copy of master > 5 days old :/ Has this latest build been released to maven central yet? On Tue, Oct 29, 2019 at 1:44 PM Mark Thomas wrote: > On 29/10/2019 19:33, Mike Kuredjian wrote: > > Hi, > > > > I was wondering if there have been discussions to change the behaviour > > around cookie generation in the Rfc6265CookieProcessor to allow for > > explicit generation of SameSite=none cookies in light of the changes > > coming to Chrome 80, in February of > > 2020: > https://blog.chromium.org/2019/10/developers-get-ready-for-new.html. > > > > From what I see in the existing code, SameSite=none is an implicit > > default and will not result in that property being explicitly set on the > > generated cookie. > > What source code are you looking at? > > Have you looked at the current HEAD in the source repository? > > Have you tried searching the archives for previous discussions of this > topic? (I recommend markmail) > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
[jira] [Commented] (MTOMCAT-263) tomcat7:exec-war can't create .extract/webapps
[ https://issues.apache.org/jira/browse/MTOMCAT-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15272834#comment-15272834 ] Mike Holdsworth commented on MTOMCAT-263: - If you're still waiting on this plugin getting some love you're probably better off either taking a lead and [forking|https://github.com/apache/tomcat-maven-plugin/tree/trunk/tomcat7-war-runner ] it or moving on and reconsidering your deployment approach. Around 18 months after posting my question I switched to using SpringBoot. Took some time but easily one of the smarter moves I've made. Good luck > tomcat7:exec-war can't create .extract/webapps > -- > > Key: MTOMCAT-263 > URL: https://issues.apache.org/jira/browse/MTOMCAT-263 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 >Reporter: jieryn >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: 3.0 > > Attachments: MTOMCAT-263_1.patch > > > bash$ java -jar target/app-1.0-SNAPSHOT-war-exec.jar > Exception in thread "main" java.lang.Exception: FATAL: impossible to create > directories:.extract/webapps > at > org.apache.tomcat.maven.runner.Tomcat7Runner.extract(Tomcat7Runner.java:586) > at > org.apache.tomcat.maven.runner.Tomcat7Runner.run(Tomcat7Runner.java:204) > at > org.apache.tomcat.maven.runner.Tomcat7RunnerCli.main(Tomcat7RunnerCli.java:212) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Created] (MTOMCAT-304) update version of tomcat 7 used in plugin
Mike Curwen created MTOMCAT-304: --- Summary: update version of tomcat 7 used in plugin Key: MTOMCAT-304 URL: https://issues.apache.org/jira/browse/MTOMCAT-304 Project: Apache Tomcat Maven Plugin Issue Type: Improvement Components: tomcat7 Affects Versions: 2.2 Reporter: Mike Curwen Assignee: Olivier Lamy (*$^¨%`£) I've spent a bit of timing figuring out why our JSF listeners get registered twice when run within the IDE, but not our test servers. I believe I've found the reason; this bug - https://bz.apache.org/bugzilla/show_bug.cgi?id=55282#c9 When we run our app on our test servers (which use Tomcat 7.0.37) the listeners are registered just once. But running locally within the IDE, they register twice (tomcat7 maven plugin uses Tomcat 7.0.47). The bug was introduced in TC 7.0.42, and fixed in TC 7.0.55 When you next release the tomcat7 plugin, please consider updating the TC version used. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-263) tomcat7:exec-war can't create .extract/webapps
[ https://issues.apache.org/jira/browse/MTOMCAT-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13991661#comment-13991661 ] Mike Holdsworth commented on MTOMCAT-263: - Works correctly in 2.2 and fails in 2.3 > tomcat7:exec-war can't create .extract/webapps > -- > > Key: MTOMCAT-263 > URL: https://issues.apache.org/jira/browse/MTOMCAT-263 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 >Reporter: jieryn > > bash$ java -jar target/app-1.0-SNAPSHOT-war-exec.jar > Exception in thread "main" java.lang.Exception: FATAL: impossible to create > directories:.extract/webapps > at > org.apache.tomcat.maven.runner.Tomcat7Runner.extract(Tomcat7Runner.java:586) > at > org.apache.tomcat.maven.runner.Tomcat7Runner.run(Tomcat7Runner.java:204) > at > org.apache.tomcat.maven.runner.Tomcat7RunnerCli.main(Tomcat7RunnerCli.java:212) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-263) tomcat7:exec-war can't create .extract/webapps
[ https://issues.apache.org/jira/browse/MTOMCAT-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13991661#comment-13991661 ] Mike Holdsworth commented on MTOMCAT-263: - Works correctly in 2.2 and fails in 2.3 > tomcat7:exec-war can't create .extract/webapps > -- > > Key: MTOMCAT-263 > URL: https://issues.apache.org/jira/browse/MTOMCAT-263 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 >Reporter: jieryn > > bash$ java -jar target/app-1.0-SNAPSHOT-war-exec.jar > Exception in thread "main" java.lang.Exception: FATAL: impossible to create > directories:.extract/webapps > at > org.apache.tomcat.maven.runner.Tomcat7Runner.extract(Tomcat7Runner.java:586) > at > org.apache.tomcat.maven.runner.Tomcat7Runner.run(Tomcat7Runner.java:204) > at > org.apache.tomcat.maven.runner.Tomcat7RunnerCli.main(Tomcat7RunnerCli.java:212) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
