Upgrade Tomcat 6 from ECJ 3.7 to ECJ 3.7.1?
We are researching upgrading our application from Java 6 to Java 7. From what I can tell, Tomcat 6, and our application in Tomcat 6, run fine in Java 7. No problems whatsoever. Until you use Java 7 language features in a JSP. Tomcat 7, however, does not have this problem. >From what I can tell, the key is the ECJ library. Tomcat 7 has ECJ 3.7.1, which has full Java 7 support, while Tomcat 6 has JCT 3.7.0, which has NO Java 7 support. Seeing as how these versions of ECJ are a mere 1 patch apart, are there any plans to upgrade Tomcat 6 to ECJ 3.7.1? It would sure be nice to tell our customers they can still run our application on Tomcat 6. Furthermore, are there any compelling reasons *not* to upgrade Tomcat 6 to ECJ 3.7.1? Thanks, Nick Williams
RE: Upgrade Tomcat 6 from ECJ 3.7 to ECJ 3.7.1?
A correction to my previous email: > From what I can tell, the key is the ECJ library. Tomcat 7 has ECJ 3.7.1, which has full Java 7 support, while Tomcat 6 has *ECJ* 3.7.0, which has NO Java 7 support. Note that I should have said that Tomcat 6 has “ECJ 3.7.0” like above instead of “JCT 3.7.0” like below. Not sure where the “JTC” came from… Nick *From:* Nick Williams [mailto:nicholas.willi...@puresafety.com] *Sent:* Monday, March 12, 2012 3:12 PM *To:* 'dev@tomcat.apache.org' *Subject:* Upgrade Tomcat 6 from ECJ 3.7 to ECJ 3.7.1? We are researching upgrading our application from Java 6 to Java 7. From what I can tell, Tomcat 6, and our application in Tomcat 6, run fine in Java 7. No problems whatsoever. Until you use Java 7 language features in a JSP. Tomcat 7, however, does not have this problem. >From what I can tell, the key is the ECJ library. Tomcat 7 has ECJ 3.7.1, which has full Java 7 support, while Tomcat 6 has JCT 3.7.0, which has NO Java 7 support. Seeing as how these versions of ECJ are a mere 1 patch apart, are there any plans to upgrade Tomcat 6 to ECJ 3.7.1? It would sure be nice to tell our customers they can still run our application on Tomcat 6. Furthermore, are there any compelling reasons *not* to upgrade Tomcat 6 to ECJ 3.7.1? Thanks, Nick Williams
RE: Upgrade Tomcat 6 from ECJ 3.7 to ECJ 3.7.1?
Good to know. What about the next version of Tomcat 6? Will it also get 3.7.2 (or at least 3.7.1)? Or will it stay on 3.7.0 for the foreseeable future? That's my big concern. As long as Tomcat 6 has 3.7.1 or better, it should be able to compile JSPs for Java 7. With 3.7.0, it can't. Nick -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Thursday, March 15, 2012 12:41 PM To: Tomcat Developers List Subject: Re: Upgrade Tomcat 6 from ECJ 3.7 to ECJ 3.7.1? 2012/3/15 Nick Williams : > A correction to my previous email: > > > >> From what I can tell, the key is the ECJ library. Tomcat 7 has ECJ >> 3.7.1, > which has full Java 7 support, while Tomcat 6 has *ECJ* 3.7.0, which > has NO Java 7 support. > > > > Note that I should have said that Tomcat 6 has "ECJ 3.7.0" like above > instead of "JCT 3.7.0" like below. Not sure where the "JTC" came from. > Just download ecj-3.7.2.jar from eclipse.org [1] and put it into libs directory, instead of 3.7 one. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52805 The next release of 7.0.x will have 3.7.2 in it. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Upgrade Tomcat 6 from ECJ 3.7 to ECJ 3.7.1?
2012/3/15 Nick Williams : > Good to know. What about the next version of Tomcat 6? Will it also > get > 3.7.2 (or at least 3.7.1)? Or will it stay on 3.7.0 for the > foreseeable future? That's my big concern. As long as Tomcat 6 has > 3.7.1 or better, it should be able to compile JSPs for Java 7. With 3.7.0, it can't. > 1. Please do not top-post. 2. There is some time (months?) before next Tomcat 6. I think ECJ version will be updated. 3. The more people use and say there are no issues, the easier it is to update. In your case, to use Java 7 features in JSPs you would have to also reconfigure JspServlet (using compilerSourceVM / compilerTargetVM options) to target Java 7. Best regards, Konstantin Kolinko - I see that the default values for compilerSourceVM and compilerTargetVM are 1.5 in Tomcat 6 and 1.6 in Tomcat 7. It would need to be changed to 1.7 in both, correct? I know this is starting to creep out of the scope of this mailing list somewhat, but is changing these values in $CATALINA_BASE/conf/web.xml the ONLY way to configure Tomcat to compile with 1.7? Can something not be specified in web.xml to make it use 1.7 for that particular web application? Or context.xml? Or anything else? If there's not another way to configure it, I believe I'll put in an enhancement request. I know it may be months or years before it gets done, if ever, but I think it would be a good improvement. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Upgrade Tomcat 6 from ECJ 3.7 to ECJ 3.7.1?
2012/3/15 Nick Williams : > 2012/3/15 Nick Williams : >> Good to know. What about the next version of Tomcat 6? Will it also >> get >> 3.7.2 (or at least 3.7.1)? Or will it stay on 3.7.0 for the >> foreseeable future? That's my big concern. As long as Tomcat 6 has >> 3.7.1 or better, it should be able to compile JSPs for Java 7. With > 3.7.0, it can't. >> > > > 1. Please do not top-post. > > 2. There is some time (months?) before next Tomcat 6. I think ECJ > version will be updated. > > 3. The more people use and say there are no issues, the easier it is > to update. > > In your case, to use Java 7 features in JSPs you would have to also > reconfigure JspServlet (using compilerSourceVM / compilerTargetVM > options) to target Java 7. > > Best regards, > Konstantin Kolinko > > - > > I see that the default values for compilerSourceVM and > compilerTargetVM are 1.5 in Tomcat 6 and 1.6 in Tomcat 7. It would > need to be changed to > 1.7 in both, correct? > > I know this is starting to creep out of the scope of this mailing list > somewhat, but is changing these values in $CATALINA_BASE/conf/web.xml > the ONLY way to configure Tomcat to compile with 1.7? Can something > not be specified in web.xml to make it use 1.7 for that particular web > application? Or context.xml? Or anything else? > You should be able to copy that into your web.xml. The only caveat is that you would have to change its and to copy its s as well. I personally have never done that with JspServlet, but I often do so with DefaultServlet e.g. to enable directory listings. Best regards, Konstantin Kolinko - Gotchya. Doing so, however, would make it non-portable to other application servers. We'll stick to changing the value in $CATALINA_BASE/conf/web.xml for now, and I'll put in an enhancement request based on how the other popular application servers do it. Maybe somebody will pick it up, maybe not. It never hurts to suggest. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[debug] ( javajni.c:195 ) Invalid RuntimeLib should be a warning or error?
So, I’ll file a bug about this, but I wanted to get a general feel from the list first. This happens in both Tomcat 6 and 7 (haven’t looked at 5.5), but I’ve only included the Tomcat 7 log info here for succinctness. When running Tomcat as a service under Windows, if you mess up the Java Virtual Machine path in the service configurator, it defaults to the JAVA_HOME JRE, which I suppose is okay (but can wreak havoc when you have multiple Java versions installed), except that it doesn’t warn you about it. It tells you about it through a DEBUG message, instead, so you have to actually increase the logging detail and wade through more messages to find it: [2012-03-20 16:32:41] [debug] ( prunsrv.c:1644) Commons Daemon procrun log initialized [2012-03-20 16:32:41] [info] ( prunsrv.c:1648) Commons Daemon procrun (1.0.9.0 64-bit) started [2012-03-20 16:32:41] [info] ( prunsrv.c:1561) Running 'gr01in01tc70' Service... [2012-03-20 16:32:41] [debug] ( prunsrv.c:1345) Inside ServiceMain... [2012-03-20 16:32:41] [info] ( prunsrv.c:1089) Starting service... [2012-03-20 16:32:41] [debug] ( javajni.c:195 ) Invalid RuntimeLib 'D:\Java\jdk6\jre\bin\server\jvm.dll' [2012-03-20 16:32:41] [debug] ( javajni.c:197 ) Using Jre JavaHome 'C:\Program Files\Java\jre7' [2012-03-20 16:32:41] [debug] ( javajni.c:206 ) loading jvm 'C:\Program Files\Java\jre7\bin\server\jvm.dll' After correcting the JVM path: [2012-03-20 16:46:13] [debug] ( prunsrv.c:1644) Commons Daemon procrun log initialized [2012-03-20 16:46:13] [info] ( prunsrv.c:1648) Commons Daemon procrun (1.0.9.0 64-bit) started [2012-03-20 16:46:13] [info] ( prunsrv.c:1561) Running 'gr01in01tc70' Service... [2012-03-20 16:46:13] [debug] ( prunsrv.c:1345) Inside ServiceMain... [2012-03-20 16:46:13] [info] ( prunsrv.c:1089) Starting service... [2012-03-20 16:46:13] [debug] ( javajni.c:206 ) loading jvm 'C:\Program Files\Java\jre6\bin\server\jvm.dll' IMO, this message should be a warning or even an error (preferable) so that server admins know right off the bat that they’ve done something wrong. Thoughts?
RE: [debug] ( javajni.c:195 ) Invalid RuntimeLib should be a warning or error?
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, March 20, 2012 4:59 PM To: Tomcat Developers List Subject: Re: [debug] ( javajni.c:195 ) Invalid RuntimeLib should be a warning or error? On 20/03/2012 21:54, Nick Williams wrote: > Thoughts? That is a general Commons Daemon issue rather than a Tomcat specific issue and would be best discussed over on the Commons lists. Mark - Ahhh! Yes. Of course. Silly me. Thanks! - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Improving Ant Task for JSP Compilation
This morning I filed issues 53011 and 53012, about general improvements to the Ant task used for compiling JSPs. These two issues are rather important to our team, and are making using the compiler rather difficult. In the interest of both improving Tomcat and meeting our needs as quickly as possible, I am interested in possibly contributing code changes to effect these improvements, and possible others. I read the information at http://tomcat.apache.org/getinvolved.html and related links, and understand that my first step is building Tomcat and my second is proposing patches to the other developers (presumably by attaching them to the issues I filed). If I'm missing anything so far, please let me know. What I'd really like is a little further guidance about this particular feature in Tomcat. Who is really familiar with it that I can ask questions of if I don't understand something I see? What do the developers on the list think about the ideas proposed in these two issues? I believe they make Tomcat better, but that's just because they meet our immediate needs. Do other contributors and committers agree with the proposals? I'd be happy to provide more background information about me on request, but I didn't want to introduce myself with a novel. :-) Nick Williams
RE: Improving Ant Task for JSP Compilation
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, April 02, 2012 4:24 PM To: Tomcat Developers List Subject: Re: Improving Ant Task for JSP Compilation Nick, On 3/31/12 4:34 PM, Nick Williams wrote: > This morning I filed issues 53011 and 53012, about general > improvements to the Ant task used for compiling JSPs. These two issues > are rather important to our team, and are making using the compiler > rather difficult. In the interest of both improving Tomcat and meeting > our needs as quickly as possible, I am interested in possibly > contributing code changes to effect these improvements, and possible > others. Great! > I read the information at http://tomcat.apache.org/getinvolved.html > and related links, and understand that my first step is building > Tomcat and my second is proposing patches to the other developers > (presumably by attaching them to the issues I filed). If I'm missing > anything so far, please let me know. That sounds like a good start. Remember that everything you do should be in Tomcat's 'trunk'. Here's the svn root for that: http://svn.apache.org/repos/asf/tomcat/trunk All patches should be against trunk (they'll get back-ported to 7.0.x and possibly 6.0.x). > What I'd really like is a little further guidance about this > particular feature in Tomcat. Who is really familiar with it that I > can ask questions of if I don't understand something I see? Perhaps the best thing to do is look at the svn history for the files involved. Start with org.apache.jasper.JspC and the related files like Compiler, etc. to see who has updated them recently. Mostly, it's best to ask questions on this list and let anyone answer them who can, rather than trying to directly contact any one person. > What do the developers on the list think about the ideas proposed in > these two issues? > > Bug 53011 - Ant Jasper task fails after one error +1 - seems reasonable. I've added some comments to the bug. > Bug 53012 - Ant Jasper task does not name including file when > included file has compile error +1 also seems reasonable. Check the current behavior of the trunk to make sure this isn't already in there. > I believe they > make Tomcat better, but that's just because they meet our immediate needs. That's host these projects grow: patches are always welcome. Basically anything that doesn't a) violate the servlet specification or b) significantly impact performance or c) require sweeping changes to the code is fair game. Thanks, -chris - Alright, I've analyzed the o.a.tools.ant.Task, o.a.tools.ant.taskdefs.Java, o.a.tools.ant.taskdefs.Javac, o.a.jasper.JspC, o.a.jasper.compiler.Compiler, and the classes in o.a.catalina.ant. I learned a lot ... in some cases more than I wanted to. ;-) Here are some of my observations: - JspC is the only Ant task in Tomcat that doesn't actually extend o.a.tools.ant.Task. All the other tasks extend Task, but not JspC. JspC just happens to implement enough methods that Ant will blindly execute it. This is likely the primary cause behind 53032. - JspC does a lot of things "wrong" for executing in Ant-world. I'm sure it's all perfectly right for its original intended purpose, but it's "wrong" in Ant-world. The way it logs, handles files and classpaths, etc. are all counter to standards used in Ant. The getFork() method it implements isn't even related to Ant; it's implementing the getFork() method in o.a.jasper.Options. This all makes 53011, 53012 and 53031 difficult (at best) to solve. - JspC is so tightly coupled with the other things in Tomcat that I believe it would be next to impossible to retrofit it to be a "well-behaved" Ant task. For that matter, I believe it would be next to impossible to even /use/ it in a new well-behaved Ant task. - I have not yet figured out exactly how compile errors are output to determine if 53012 is already fixed in trunk. I'm still investigating. With those, here are my general recommendations: - Create a new class o.a.catalina.ant.JspCompileTask extends o.a.catalina.ant.BaseRedirectionHelperTask (which extends o.a.tools.ant.Task). This class will do a lot of the same things that JspC does, but in a simpler way, making some assumptions because it knows that it's always running within an Ant project. It will still have most of the plethora of options that JspC has, such as compilerSourceVM, compile, getStringsAsCharArray, etc. It will accept a Classpath for use in the compilation phase of JSPs. It will fork upon request, but not by default, just like java/javac/junit. It will fail on error by default, but not required, and will have an errorProperty, just like java/javac/j
Catching up
Guys, For a myriad of personal, professional, and health reasons, I've been out of pocket for many months. I'm finally starting to catch up today on 9200 Tomcat developer and user list messages. It will take me many days. I just wanted to let y'all know that I'm still alive, and head off any "where have you been, bro?" responses to any responses I may send in the coming days. Glad to be back! Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Drop comet support in Tomcat 9 onwards
On Jun 19, 2014, at 10:45 AM, Rémy Maucherat wrote: > 2014-06-18 23:40 GMT+02:00 Mark Thomas : > >> I have been thinking about connector refactoring for Tomcat 9. Currently >> BIO is planned to be dropped due to the number of features in the >> servlet spec that rely on non-blocking IO. >> >> I would like to propose dropping support for Comet in Tomcat 9 onwards. >> The reasons are: >> - WebSocket is already far more popular (based on question volume on the >> users list) >> - Comet support adds a fair amount of complexity to the connector code >> >> Thoughts? >> >> Keep in mind that 8.0.x isn't stable yet and any 9.0.x is likely to be >> several years away. >> > Yes, of course, that API is only a precursor to Servlet 3.1, and is now > fully replaced. Most likely existing code can be ported over to Servlet 3.1 > rather easily. > > Rémy +1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Catching up
Huh. Amazing how fast that went. I'm caught up on everything since May 7 (last time I checked my email in this folder). Good job, everyone involved, on releasing 8.0.x stable, beginning 9.0.x, and addressing many bugs. Kudos! Nick On Dec 2, 2014, at 1:20 PM, Nick Williams wrote: > Guys, > > For a myriad of personal, professional, and health reasons, I've been out of > pocket for many months. I'm finally starting to catch up today on 9200 Tomcat > developer and user list messages. It will take me many days. I just wanted to > let y'all know that I'm still alive, and head off any "where have you been, > bro?" responses to any responses I may send in the coming days. > > Glad to be back! > > Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1539036 - in /tomcat/trunk: java/org/apache/catalina/loader/WebappLoader.java test/org/apache/catalina/loader/TestVirtualWebappLoader.java test/org/apache/catalina/loader/TestWebappCl
On Nov 5, 2013, at 9:41 AM, ma...@apache.org wrote:
> Author: markt
> Date: Tue Nov 5 15:41:53 2013
> New Revision: 1539036
>
> URL: http://svn.apache.org/r1539036
> Log:
> Fix remainder of failing tests and a related TODO spotted in the tests as
> well.
>
>
>
> Modified:
> tomcat/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java?rev=1539036&r1=1539035&r2=1539036&view=diff
> ==
> ---
> tomcat/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java
> (original)
> +++
> tomcat/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java
> Tue Nov 5 15:41:53 2013
> @@ -251,6 +251,8 @@ public class TestWebappClassLoaderWeavin
> assertEquals("The second result is not correct.", "Hello, Weaver
> #2!", result);
>
> WebappClassLoader copiedLoader =
> this.loader.copyWithoutTransformers();
> +// class loader needs to be started to populate URLs
> +copiedLoader.start();
>
> result = invokeDoMethodOnClass(copiedLoader,
> "TesterNeverWeavedClass");
> assertEquals("The third result is not correct.", "This will never be
> weaved.", result);
copyWithoutTransformers(), as defined in the interface
InstrumentableClassLoader, returns a ClassLoader. The start() method is not
defined in ClassLoader, it is specific to WebappClassLoader. Furthermore, code
calling copyWithoutTransformers() won't have access to WebappClassLoader to
call start() reflectively if a SecurityManager is enabled.
So, the copyWithoutTransformers() method needs to call start() before it
returns the copied class loader. Otherwise, it will be useless to JPA providers
and the like.
Nick
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1542836 - /tomcat/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
On Nov 17, 2013, at 4:10 PM, Jeremy Boynes wrote:
> On Nov 17, 2013, at 1:42 PM, ma...@apache.org wrote:
>
>> Author: markt
>> Date: Sun Nov 17 21:42:26 2013
>> New Revision: 1542836
>>
>> URL: http://svn.apache.org/r1542836
>> Log:
>> Revert part of r1542565 which added rather than removed an IDE warning
>>
>> Modified:
>> tomcat/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
>>
>> Modified:
>> tomcat/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
>> URL:
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java?rev=1542836&r1=1542835&r2=1542836&view=diff
>> ==
>> --- tomcat/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
>> (original)
>> +++ tomcat/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java Sun
>> Nov 17 21:42:26 2013
>> @@ -138,7 +138,8 @@ class TagLibraryInfoImpl extends TagLibr
>>// Add TLD within the JAR to the dependency list
>>String entryName = tldResourcePath.getEntryName();
>>try {
>> -pageInfo.addDependant(jar.getURL(entryName),
>> jar.getLastModified(entryName));
>> +pageInfo.addDependant(jar.getURL(entryName),
>> +Long.valueOf(jar.getLastModified(entryName)));
>>} catch (IOException ioe) {
>>throw new JasperException(ioe);
>>}
>
> Hmm, differences in IDE's opinion I assume - with this IDEA gives me a
> warning about unnecessary boxing and nothing without. What are you seeing?
Yea, by all rules of Java boxing that I'm aware of, the use of Long.valueOf()
here is unnecessary boxing. Not sure why your IDE is saying it's necessary.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.1
Looks good! On Jan 29, 2014, at 5:43 PM, Mark Thomas wrote: > > > [X ] Beta - go ahead and release as 8.0.1 (beta) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: support for salted passwords
On Feb 2, 2014, at 1:23 AM, Gabriel E. Sánchez Martínez wrote: > Hi developers, > > I am very new to Tomcat but am already getting my feet wet with a web > application. A requirement for this application is form-based password > authentication, and I would like to store passwords in a database using > salted SHA-512 digests I can't speak to most of this email, but don't do this. SHA-x is a *fast* hashing algorithm. It's not designed for passwords. The problem with fast hashing algorithms is that they are *very* susceptible to rainbow table attacks. Modern password-hacking systems with 24 GPUs can calculate billions of MD5 and SHA-x hash attacks per second. I strongly recommend you use a *slow* hashing algorithm such as bcrypt, which is designed specifically for hashing passwords. These algorithms use more than just CPU/GPU operations (such as memory). Password hacking systems can only calculate thousands of these per second instead of millions. It's much better protection in case your password database is ever stolen. > , recognizing that this is not state-of-the-art password protection, but it > is a more secure method than unsalted digests in the event that the password > table is compromised. > > Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.3
On Feb 7, 2014, at 12:16 PM, Mark Thomas wrote: > The proposed Apache Tomcat 8.0.3 release is now available for voting. > > > > The proposed 8.0.3 release is: > [ ] Broken - do not release > [ ] Alpha - go ahead and release as 8.0.3 (alpha) > [X] Beta - go ahead and release as 8.0.3 (beta) > [ ] Stable - go ahead and release as 8.0.3 (stable) Smoke tested with several applications, including using Spring, Log4j 2, and WebSockets. All appears to be in order. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
OT: New Email Address
FYI, since some of you may be used to seeing emails from me come from nicholas dot williams at ul dot com: I have used my work email addresses for the Tomcat list for some time, but I have switched now to my personal email address for a variety of reasons: 1) I'm tired of the "privileged or confidential information" notice it adds to the bottom of all of my emails to the list. 2) My employer has now implemented a program to forcibly delete all emails older than 1 year, preventing me from keeping emails I reference often. 3) Nearly all of my Tomcat business these days is personal- or self-employment-related, not employer-related, so it's more convenient. Just remember when you see future emails from nicholas at nicholaswilliams dot net that it's the same person you're used to seeing. Thanks, Nick smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r1445517 - in /tomcat/trunk: java/javax/servlet/http/ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/s
On Feb 13, 2013, at 4:26 AM, Keiichi Fujino wrote: > 2013/2/13 : >> Author: markt >> Date: Wed Feb 13 09:28:58 2013 >> New Revision: 1445517 >> >> URL: http://svn.apache.org/r1445517 >> Log: >> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54552 >> Servlet 3.1 >> Implement HttpSessionIdListener and HttpServletRequest#changeSessionId() >> Patch provided by Nick Williams. >> > I think that this code itself is not a problem at all. (I think prety good.) Thanks! I was a bit nervous about my first code contribution. :-) > However I have a idea of code improvement. > > There seems to be a duplicate code on ManagerBase and DeltaManager. I struggled with that, too. There's a tellNew() method in StandardSession that is responsible for firing the Session.SESSION_CREATED_EVENT event and notifying HttpSessionListeners, and I thought about implementing a similar tellChangedSessionId method in StandardSession. However, since the code for firing the Context.CHANGE_SESSION_ID_EVENT internal event was also duplicated in ManagerBase and DeltaManager, I decided to stick with doing the same and keeping the code alongside those event firings. I would not disagree that the code should be centralized…in both cases. > e.g. > By introducing a following method to ManagerBase and DeltaManager, > we might be able to avoid code duplication. > > == > changeSessionId(Session session, String newId) > changeSessionId(Session session, String newId, >boolean notifySessionListeners, boolean notifyContainerListeners) > == If you are going to add a method to prevent code duplication, I would recommend it be something like StandardSession.tellChangedSessionId(String, String, boolean, boolean) (perhaps right below the tellNew() method) instead of in the ManagerBase class. > > And furthermore, we are changing sessionId in JvmRouteBinderValve. > Change sessionid of JvmRouteBinderValve is completely different from > Manager#changeSessionId. > By using new changeSessionId method, will be able to change sessionId > in a same way. > As a result, JvmRouteSessionIDBinderListener will be unnecessary. I took a look at JvmRouteSessionIDBinderListener and I do not believe it is changing the session ID in the same way (though I could certainly be wrong). It looks to me like it is involved in binding the JVMRoute to the end of the session ID in order to support clustering? I do not think that is the same thing as this. Other areas in the code that "change" the session ID (changeSessionIdOnAuthentication, change replicated from another cluster, HttpServletRequest.changeSessionId()) call the changeSessionId(Session) method on the Manager, which changes the sessionId, does NOT call tellNew(), fires Context.CHANGE_SESSION_ID_EVENT and (now) notifies HttpSessionIdListeners. However, JvmRouteSessionIDBinderListener does it differently: it calls setId() directly on the session, DOES call tellNew() (is this right?) and bypasses the Context.CHANGE_SESSION_ID_EVENT and listeners by not calling Manager.changeSessionId(Session). It could be that this was done this way intentionally, or not. I don't know. I'd like to understand it better. Someone more in-the-know than I can hopefully chime in. > > I'm going to fix these improvements If there is no objections from anyone. > Any objections and comment? If my code can be improved, I am always happy for someone to do it! Nick smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r1446072 - in /tomcat/trunk/java/org/apache/catalina: Manager.java Session.java ha/session/DeltaManager.java session/ManagerBase.java session/StandardSession.java
On Feb 14, 2013, at 2:57 AM, kfuj...@apache.org wrote: > Author: kfujino > Date: Thu Feb 14 08:57:43 2013 > New Revision: 1446072 > > URL: http://svn.apache.org/r1446072 > Log: > Remove duplicate code on ManagerBase and DeltaManager. > Introduce following interfaces. > Manager#changeSessionId(Session, String) > Session#tellChangedSessionId(String, String, boolean, boolean) > > Modified: >tomcat/trunk/java/org/apache/catalina/Manager.java >tomcat/trunk/java/org/apache/catalina/Session.java >tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java >tomcat/trunk/java/org/apache/catalina/session/ManagerBase.java >tomcat/trunk/java/org/apache/catalina/session/StandardSession.java > I like this. Looks good. Definitely an improvement and easier to maintain. smime.p7s Description: S/MIME cryptographic signature
Jasper: "use of final," "reduce visibility"
Mark, I've noticed in the past few days you've committed several change sets with comments like "use of final" and "reduce visibility" (mostly the latter). I'm trying to understand the Tomcat source code better so that I can potentially contribute more in the future, and I'm wondering what the motivation is behind reducing visibility of Jasper components. I've always viewed reducing visibility as a hindrance to extension (which, of course, is sometimes desired), so I'm curious why the sudden attempt to do this to Jasper? (Is it as simple as just cleaning things up before beginning the JSP 2.3/EL 3.0 implementation?) Specifically, sometime last year I mentioned on the list perhaps contributing an improved Ant task for JSP compilation (bugs 53011, 53012, and 53492, dev list topic "Improving Ant Task for JSP Compilation" from March 31, 2012). After successfully contributing my first bit of new code to trunk, I'm thinking about finally getting around to doing this. Are any of the changes you are making going to hinder my ability to do this? (I gave it a cursory glance in version control and didn't see anything that stood out, but I may be missing something). Thanks, Nick smime.p7s Description: S/MIME cryptographic signature
Re: Jasper: "use of final," "reduce visibility"
On Feb 16, 2013, at 10:51 AM, Mark Thomas wrote: > On 16/02/2013 16:42, Nick Williams wrote: >> Mark, >> >> I've noticed in the past few days you've committed several change >> sets with comments like "use of final" and "reduce visibility" >> (mostly the latter). I'm trying to understand the Tomcat source code >> better so that I can potentially contribute more in the future, and >> I'm wondering what the motivation is behind reducing visibility of >> Jasper components. I've always viewed reducing visibility as a >> hindrance to extension (which, of course, is sometimes desired), so >> I'm curious why the sudden attempt to do this to Jasper? (Is it as >> simple as just cleaning things up before beginning the JSP 2.3/EL 3.0 >> implementation?) > > http://svn.apache.org/repos/asf/tomcat/trunk/TOMCAT-NEXT.txt > Item 5. AH! Haha. I didn't even see that. I will enjoy looking over this list. Thanks. > > Making fields private should never be an issue as accessors should be used. True. I just didn't know if you were also reducing the visibility of classes or methods. > > Reducing visibiity encourages good design. Agreed. Reducing the visibility of fields and using encapsulation are good design approaches. However, sometimes reducing the visibility of methods can be troublesome, depending on the situation. > > Visibility can always be increased if required. > >> Specifically, sometime last year I mentioned on the list perhaps >> contributing an improved Ant task for JSP compilation (bugs 53011, >> 53012, and 53492, dev list topic "Improving Ant Task for JSP >> Compilation" from March 31, 2012). After successfully contributing my >> first bit of new code to trunk, I'm thinking about finally getting >> around to doing this. Are any of the changes you are making going to >> hinder my ability to do this? (I gave it a cursory glance in version >> control and didn't see anything that stood out, but I may be missing >> something). > > No. Visibility can be increased, accessors can be added as necessary. Understood. Thanks! Nick smime.p7s Description: S/MIME cryptographic signature
Re: JarScanning
On Feb 21, 2013, at 10:42 AM, Romain Manni-Bucau wrote: > Hi, > > the best IMO would be to have a WEB-INF/tomcat.properties with the ability > to configure the scanner + its properties (thanks a prefix) from the webapp > itself > > PS: META-INF/context.xml would work too but i'm not a fan of xml ;) My $0.02 here, as unbinding as it may be... :-) I made the suggestion some time ago [1] to create support for a /WEB-INF/tomcat-web.xml file similar to the ones for GlassFish, WebLogic, WebSphere, Geronimo, [I could go on...] that provided the ability to customize the JSP compile level (1.6, 1.7, 1.8, etc.) and also to specify that Tomcat should precompile all JSPs as part of deploying the web app. Such a file could also be used for specifying jarsToSkip/jarsToScan properties. This could be useful for portability (our application at work has *.xml files for each major AS, but then have to tell our Tomcat-using customers how to change the compile level of their JSPs, which also affects any other applications that they are running). I was actually thinking lately about maybe implementing it myself (with feedback from y'all on design) and then offering a (albeit large) patch to resolve the suggestion. Two opinions: - It should be XML, not properties. I share Romain's general dislike for XML, but the advantage of using that over properties is that IDEs and other tools (possibly at application build time) can reference a schema and validate the validity of that schema, thereby ensuring ahead of time that they contents of it haven't been fat-fingered. - It should be a separate XML file from /META-INF/context.xml. The possible applications of this file are huge and could continue to expand. The concept of the context.xml file has a specific relation to the Tomcat configuration, and I don't believe that we should have a bunch of properties that are only valid for applications and not for Tomcat globally muddying the concept of the context.xml file. Users could easily see compilerTargetVM, compilerSourceVM, precompileJsps, and/or jarsToSkip in an application's /META-INF/context.xml file and think those can also be copied to [Tomcat Home]/conf/context.xml and have an effect globally (when in reality they are configured elsewhere or not at all, as in the case of precompileJsps). I think the settings that only apply to an application and don't apply globally should be in a separate file, not in /META-INF/context.xml. Like I said, just my $0.02. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52924 > > > > 2013/2/21 Caldarale, Charles R > >>> From: Mark Thomas [mailto:ma...@apache.org] >>> Subject: JarScanning >> >>> jarsToScan >>> This is a little more complicated. >>> First of all, how does it work? The suggestion is: >>> - If jarsToScan matches, scan it >>> - else if jarsToSkip matches, skip it >>> - else scan it >> >> From the above, it looks like the only purpose of jarsToScan is to avoid >> checking the jarsToSkip list. Unless such checking is expensive, this >> seems like an unnecessary complication. >> >> - Chuck >> >> >> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY >> MATERIAL and is thus for use only by the intended recipient. If you >> received this in error, please contact the sender and delete the e-mail and >> its attachments from all computers. >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> smime.p7s Description: S/MIME cryptographic signature
OT: No web-jsptaglibrary_2_2.xsd?
General question for all the Tomcat developers out there, but I'm betting Mark has the best shot at answering: Perusing the Tomcat sources I noticed that there are JSP tag library XSD files web-jsptaglibrary_1_1.xsd, web-jsptaglibrary_1_2.xsd, web-jsptaglibrary_2_0.xsd and web-jsptaglibrary_2_1.xsd. However, the JSP version that Tomcat currently supports is 2.2, and there are jsp_2_0.xsd, jsp_2_1.xsd and jsp_2_2.xsd files. Does anyone know why there are is no web-jsptaglibrary_2_2.xsd? I presume because there were no changes to the tag library XSD between JSP 2.1 and 2.2, but shouldn't there still be a new version of the XSD regardless (to match the JSP version)? This does not appear to be isolated to Tomcat. A Google search for "web-jsptaglibrary_2_2.xsd" literally yields zero results (though, after this email, the result count will undoubtedly increase). Nick smime.p7s Description: S/MIME cryptographic signature
Re: OT: No web-jsptaglibrary_2_2.xsd?
On Mar 2, 2013, at 12:48 PM, Christopher Schultz wrote: > Nick, Sorry for the delayed reply. I've been sick and was way behind on emails. > > On 3/1/13 9:29 PM, Nick Williams wrote: >> Perusing the Tomcat sources I noticed that there are JSP tag library >> XSD files web-jsptaglibrary_1_1.xsd, web-jsptaglibrary_1_2.xsd, >> web-jsptaglibrary_2_0.xsd and web-jsptaglibrary_2_1.xsd. However, the >> JSP version that Tomcat currently supports is 2.2, and there are >> jsp_2_0.xsd, jsp_2_1.xsd and jsp_2_2.xsd files. Does anyone know why >> there are is no web-jsptaglibrary_2_2.xsd? I presume because there >> were no changes to the tag library XSD between JSP 2.1 and 2.2, but >> shouldn't there still be a new version of the XSD regardless (to >> match the JSP version)? > > Since they would be identical, what's the point? > > All TLD resolution is done using namespaces, so the namespaces will > always resolve to the correct version despite the name of the file(s). So it doesn't matter what my XSI schema URL is (web-jsptablibrary_2_1.xsd or bark.xsd), as long as the container has some file with a matching namespace URI and a matching version. Did I get this correctly? > > Does or offend your sensibilities to not have the "right" file name? Kind of, yea. I'm OCD. It's a personal problem, I know. I suppose the important point is, knowing that the JSP tag library specification is part of the JSP specification, regardless of schema URL or anything, I should be able to put the current JSP version in the tablib version attribute, but that won't work in this case, since the version would be 2.2 but Tomcat 7 doesn't have a 2.2 file, just a 2.1 file. There IS technically a JSP tag library 2.2 specification, it just doesn't actually differ from the 2.1 specification. So why can't I specify version 2.2? > >> This does not appear to be isolated to Tomcat. A Google search for >> "web-jsptaglibrary_2_2.xsd" literally yields zero results (though, >> after this email, the result count will undoubtedly increase). > > That set of filenames is likely to be Tomcat-specific: there's nothing > that says that Jetty, JBoss, etc. use web-jsptablibrary_[version].xsd. > They may use some other file naming convention. Interesting. I didn't realize that. > > Again, since the resolution is done using namespaces, the names of the > files are really irrelevant. > > -chris > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket progress report
On Mar 7, 2013, at 5:33 PM, Mark Thomas wrote: > The current status of the WebSocket implementation is largely complete. > > The remaining TODOs are (in roughly the order I intend to tackle them): > > 1. Implement decoding > 2. Figure out why there are failures in Autobahn with WSS and NIO and > APR/native > 3. Run the TCK (as an EG member I have early access to this until 30th > April mainly to test the TCK). > 4. Implement WSS for the client > 5. Fix all the various places where I didn't get around to / forgot to > complete the plumbing > 6. Read the spec carefully and check the implementation against it > 7. Improve HTTP header parsing for the client > > As always any help is appreciated. > > Mark Mark, I'm very excited to see the progress you're making on WebSockets. I do have a couple quick questions if you have a second, both related to the fact that in 3-4 days I'll be starting the chapter on WebSockets for my book. 1) I understand that this isn't "done," but is it close enough to done that I should be able to write and test simple examples (e.g., the ubiquitous chat example)? 2) I have the spec and javadoc from http://download.oracle.com/otndocs/jcp/websocket-1_0-pr-spec/index.html. If you have a newer one, is it possible to send it to me? Thanks, Nick
Question on SERVLET_SPEC-57 (getSubmittedFileName)
I'm implementing the Part#getSubmittedFileName method introduced in SERVLET_SPEC-57 [1]. o.a.c.core.ApplicationPart already has a getFilename method that accomplishes this that is not part of the interface but IS public. This method is used only in o.a.c.connector.Request (once), but that's easy to change. The concern is that renaming this method might break applications that depend on the old method name (despite the fact that using Tomcat proprietary code makes their application non-portable). Is it a problem to rename this method in a new major version, or should Part have both methods, with one calling the other? [1] http://java.net/jira/browse/SERVLET_SPEC-57 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)
On Mar 9, 2013, at 3:15 PM, Nick Williams wrote: > I'm implementing the Part#getSubmittedFileName method introduced in > SERVLET_SPEC-57 [1]. > > o.a.c.core.ApplicationPart already has a getFilename method that accomplishes > this that is not part of the interface but IS public. This method is used > only in o.a.c.connector.Request (once), but that's easy to change. The > concern is that renaming this method might break applications that depend on > the old method name (despite the fact that using Tomcat proprietary code > makes their application non-portable). Is it a problem to rename this method > in a new major version, or should Part have both methods, with one calling > the other? > > [1] http://java.net/jira/browse/SERVLET_SPEC-57 Based on what others had done in the past, I deprecated getFilename and wrapped it around getSubmittedFileName. Patch has been submitted via bug #54658. If I need to remove getFilename instead of deprecating it, I can resubmit my patch if asked. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)
On Mar 9, 2013, at 3:49 PM, Mark Thomas wrote: > Renaming the method is fine. > > We don't change the API for the sake of it but if there is a need to then it > is fine. > > Mark Look at you top-posting. :-P You replied just as I was. I deprecated getFilename and wrapped it around getSubmittedFileName and submitted patch via bug #54658. Let me know if I should just remove it and re-submit patch. Nick > > Nick Williams wrote: > >> I'm implementing the Part#getSubmittedFileName method introduced in >> SERVLET_SPEC-57 [1]. >> >> o.a.c.core.ApplicationPart already has a getFilename method that >> accomplishes this that is not part of the interface but IS public. This >> method is used only in o.a.c.connector.Request (once), but that's easy >> to change. The concern is that renaming this method might break >> applications that depend on the old method name (despite the fact that >> using Tomcat proprietary code makes their application non-portable). Is >> it a problem to rename this method in a new major version, or should >> Part have both methods, with one calling the other? >> >> [1] http://java.net/jira/browse/SERVLET_SPEC-57 >> - >> 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
Servlet 3.1 Request Upgrade
Mark, I noticed the HttpServletRequest upgrade method still had the signature void upgrade(HttpUpgradeHandler) when it should be T upgrade(Class) per the latest spec. What's your status on getting this changed? I started to try to clean this up a bit (I can email you a partial patch that has compile errors in WebSocketServlet and WsServlet to save you some time, if you want), but I hit a road block with WsProtocolHandler, which is going to need a zero-arg constructor. I stopped there to avoid stepping on your toes. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)
On Mar 9, 2013, at 4:57 PM, Mark Thomas wrote: > Nick Williams wrote: > >> >> On Mar 9, 2013, at 3:49 PM, Mark Thomas wrote: >> >>> Renaming the method is fine. >>> >>> We don't change the API for the sake of it but if there is a need to >> then it is fine. >>> >>> Mark >> >> Look at you top-posting. :-P > > :-) > > Sorry. Mobile client wasn't configured properly. A likely story. > > >> You replied just as I was. I deprecated getFilename and wrapped it >> around getSubmittedFileName and submitted patch via bug #54658. >> >> Let me know if I should just remove it and re-submit patch. > > No need. We can backport it to 7.0.x with the deprecation and then remove it > in 8.0.x after. > > Note Konstantin's comments though. Done and updated patch submitted. > 1. The @Deprecated method needs a @deprecated Javadoc comment as well, > explaining what the replacement is. Done. > > 2. o.a.c.manager.HTMLManagerServlet.extractFilename() would better be > replaced with a call to the new API. > > (BTW, the current code there is the same as in Part.getFilename()). Done. Hurray for removing duplicated code! > > Mark >> >> Nick >> >>> >>> Nick Williams wrote: >>> >>>> I'm implementing the Part#getSubmittedFileName method introduced in >>>> SERVLET_SPEC-57 [1]. >>>> >>>> o.a.c.core.ApplicationPart already has a getFilename method that >>>> accomplishes this that is not part of the interface but IS public. >> This >>>> method is used only in o.a.c.connector.Request (once), but that's >> easy >>>> to change. The concern is that renaming this method might break >>>> applications that depend on the old method name (despite the fact >> that >>>> using Tomcat proprietary code makes their application non-portable). >> Is >>>> it a problem to rename this method in a new major version, or should >>>> Part have both methods, with one calling the other? >>>> >>>> [1] http://java.net/jira/browse/SERVLET_SPEC-57 >>>> >> - >>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Autobahn test results for Tomcat 8's web socket implementation
On Mar 13, 2013, at 6:46 PM, Mark Thomas wrote: > FYI > > http://people.apache.org/~markt/dev/autobahn-tomcat-8/ > > I'll post updates periodically. > > Mark Updates? Looks like you're done. :-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 54721] New: RemoteEndpoint blocks indefinitely if sendObject called with BinaryStream of TextStream encoders
On Mar 18, 2013, at 5:01 PM, bugzi...@apache.org wrote: > https://issues.apache.org/bugzilla/show_bug.cgi?id=54721 > >Bug ID: 54721 > Summary: RemoteEndpoint blocks indefinitely if sendObject >called with BinaryStream of TextStream encoders > Product: Tomcat 8 > Version: trunk > Hardware: All >OS: All >Status: NEW > Severity: critical > Priority: P2 > Component: Catalina > Assignee: dev@tomcat.apache.org > Reporter: nicho...@nicholaswilliams.net >Classification: Unclassified > > Created attachment 30076 > --> https://issues.apache.org/bugzilla/attachment.cgi?id=30076&action=edit > Patch to resolve issue > > If I specify a j.w.Encoder.BinaryStream or j.w.Encoder.TextStream as the > encoder for my endpoint, sendObject() never completes. This is because (A) > sendObjectByCompletion does not close the OutputStream or Reader (methods that > accept closeable resources as arguments should not close those resources; the > calling method should) AND (B) onResult is never called on the SendHandler in > sendObjectByCompletion for these two cases. Patch attached. Thread dump below. I've been busy fleshing out all kinds of problems. :-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
WebSockets: Automatic closure on HttpSession invalidation?
Mark, I was reading on the expert mailing list the other day a discussion about containers automatically closing WebSocket sessions when the corresponding HttpSession instance is invalidate. I have a strange race condition going on that I think could be caused by that. Is Tomcat automatically closing WebSocket sessions when corresponding HttpSessions are invalidated? If so, how do you disable that? Thanks, Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Changelog has training whitespace
validate: [mkdir] Created dir: C:\Tomcat-Build\Source\output\res\checkstyle [checkstyle] Running Checkstyle 5.6 on 2516 files [checkstyle] C:\Tomcat-Build\Source\webapps\docs\changelog.xml:128: Line matches the illegal pattern '\s+$'. BUILD FAILED C:\Tomcat-Build\Source\build.xml:485: Got 1 errors and 0 warnings. Patch: C:\Tomcat-Build\Source>svn diff Index: webapps/docs/changelog.xml === --- webapps/docs/changelog.xml (revision 1458379) +++ webapps/docs/changelog.xml (working copy) @@ -125,7 +125,7 @@ 54708: Change the name of the working directory for the ROOT application (located under $CATALINA_BASE/work by default) from _ to -ROOT. (markt) +ROOT. (markt) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
AJP + WebSockets
I was working on the recent change in the Servlet 3.1 spec for HttpServletRequest#upgrade(...) and noticed that the AbstractAjpProcessor doesn't support HTTP Upgrade (and, by extension, doesn't support WebSockets). Only the AbstractHttp11Processor does. Is there a plan for AJP to support Upgrade in the (hopefully not-distant) future? Or is there some limitation that means it can never support Upgrade? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Servlet 3.1 Request Upgrade
On Mar 11, 2013, at 3:37 PM, Mark Thomas wrote: > On 09/03/2013 23:03, Nick Williams wrote: >> Mark, >> >> I noticed the HttpServletRequest upgrade method still had the >> signature void upgrade(HttpUpgradeHandler) when it should be > extends HttpUpgradeHandler> T upgrade(Class) per the latest spec. >> What's your status on getting this changed? > > Haven't even looked at it. > >> I started to try to clean >> this up a bit (I can email you a partial patch that has compile >> errors in WebSocketServlet and WsServlet to save you some time, if >> you want), but I hit a road block with WsProtocolHandler, which is >> going to need a zero-arg constructor. I stopped there to avoid >> stepping on your toes. > > No need to worry about my toes. Go ahead and make the changes. The (off > the top of my head) approach I suggest for WsProtocolHandler is change > the current constructor to (I was going to say init) preInit() or any > other better name you can thing of and throw an exception in init() if > preInit hasn't been called by the time init() is called. > > That should work... > > If it doesn't feel free to refactor to get something that does. Tried that. Got into a whole heap of trouble. Bug #54728 has my thorough analysis and attempted patches. This one concerns me a little. I don't like the change to the spec here (public T upgrade(Class handlerClass)). I think the original method (public void upgrade(HttpUpgradeHandler handler)) made much more sense. :-( N - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for 7.0.39
On Mar 20, 2013, at 3:55 PM, Mark Thomas wrote: > I plan to get the most recent FileUpload changes (if any), run the unit > tests, run the TCKs and then tag 7.0.39 so that should happen some time > early tomorrow if all goes well. > > Mark In 54734 I propose a patch that needs to also be back-ported to 7.0 (problem with Servlet 3.0 javax.servlet class). It's pretty minor. Don't know whether you would want to get it in or not, but it's worth taking a look at. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1459043 - /tomcat/trunk/test/org/apache/catalina/core/TesterContext.java
On Mar 20, 2013, at 3:53 PM, Mark Thomas wrote:
> On 20/03/2013 20:50, Remy Maucherat wrote:
>> On Wed, 2013-03-20 at 20:46 +, ma...@apache.org wrote:
>>> Author: markt
>>> Date: Wed Mar 20 20:46:04 2013
>>> New Revision: 1459043
>>>
>>> URL: http://svn.apache.org/r1459043
>>> Log:
>>> Add new methods
>>>
>>> Modified:
>>>tomcat/trunk/test/org/apache/catalina/core/TesterContext.java
>>
>> Sorry about that ...
>
> No problem.
>
>> I'm not sure this is a very good idea, but OTOH I'm quite sure this is
>> meant to be injected, so I added the get/set.
>
> I agree injection is required and I don't see an alternative way to do
> it. Thanks for catching this.
>
> Mark
Also agreed. However, r1459028 introduces some unnecessary casting. This is
easily solved:
Index: java/org/apache/catalina/connector/Request.java
===
--- java/org/apache/catalina/connector/Request.java (revision 1459047)
+++ java/org/apache/catalina/connector/Request.java (working copy)
@@ -1892,7 +1892,7 @@
T handler;
try {
-handler = (T)
context.getInstanceManager().newInstance(httpUpgradeHandlerClass);
+handler =
context.getInstanceManager().newInstance(httpUpgradeHandlerClass);
} catch (InstantiationException | IllegalAccessException |
InvocationTargetException | NamingException e) {
throw new IOException(e);
}
Index: java/org/apache/catalina/core/ApplicationContext.java
===
--- java/org/apache/catalina/core/ApplicationContext.java (revision
1459047)
+++ java/org/apache/catalina/core/ApplicationContext.java (working copy)
@@ -1314,8 +1314,7 @@
public T createListener(Class c)
throws ServletException {
try {
-T listener =
-(T) context.getInstanceManager().newInstance(c);
+T listener = context.getInstanceManager().newInstance(c);
if (listener instanceof ServletContextListener ||
listener instanceof ServletContextAttributeListener ||
listener instanceof ServletRequestListener ||
Index: java/org/apache/catalina/core/DefaultInstanceManager.java
===
--- java/org/apache/catalina/core/DefaultInstanceManager.java (revision
1459047)
+++ java/org/apache/catalina/core/DefaultInstanceManager.java (working copy)
@@ -132,7 +132,7 @@
}
@Override
-public Object newInstance(Class clazz) throws IllegalAccessException,
InvocationTargetException, NamingException, InstantiationException {
+public T newInstance(Class clazz) throws IllegalAccessException,
InvocationTargetException, NamingException, InstantiationException {
return newInstance(clazz.newInstance(), clazz);
}
@@ -154,7 +154,7 @@
newInstance(o, o.getClass());
}
-private Object newInstance(Object instance, Class clazz) throws
IllegalAccessException, InvocationTargetException, NamingException {
+private T newInstance(T instance, Class clazz) throws
IllegalAccessException, InvocationTargetException, NamingException {
if (!ignoreAnnotations) {
Map injections =
assembleInjectionsFromClassHierarchy(clazz);
populateAnnotationsCache(clazz, injections);
Index: java/org/apache/tomcat/InstanceManager.java
===
--- java/org/apache/tomcat/InstanceManager.java (revision 1459047)
+++ java/org/apache/tomcat/InstanceManager.java (working copy)
@@ -25,7 +25,7 @@
*/
public interface InstanceManager {
-public Object newInstance(Class clazz)
+public T newInstance(Class clazz)
throws IllegalAccessException, InvocationTargetException,
NamingException,
InstantiationException;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
WebServlets and HttpSessions (again) ... How to update last accessed time?
Reading through the expert mailing list for the WebSocket spec, I gather that the experts did not feel it appropriate to update the last access time for HttpSession objects when messages are received. I DO agree with this; there's no way to know what the user really wants here, and it could be a security vulnerability to arbitrarily update the last accessed time. However, I CAN imagine many scenarios where a developer DOES want to update the HttpSession last access time regularly. Consider a customer support chat application, where a user may be chatting with support for many minutes or even hours. Or a multiplayer online game, where the user is playing for hours at a time. It is very reasonable to expect that the developer may want to update the HttpSession's last access time every time a message is received (or at some other developer-defined interval) so that the user is not logged out (assuming the developer is using HttpSession for login/logout). Since, in my personal use, I was already grabbing the HttpSession from the handshake and associating it with the Session onOpen, I just decided I'd manually update the HttpSession's last access time each time a message came in. Wrong. HttpSession doesn't have a way to update the last access time. My thoughts are that there are two different approaches that could be taken to address the inability of the developer to keep the session alive: 1) Update the Servlet spec to add HttpSession#updateLastAccessTime(), which would be useful for more than just WebSockets, but it may be (probably is) too late to get it in Servlet 3.1 (and thus we'd have to wait another 3 years for it). 2) Update the WebSocket spec to add Session#updateHttpSessionLastAccessTime(), but then that would be useful only for WebSockets (at that point, you might as well also add a Session#getHttpSession() method, which does not exist either and so makes getting the HttpSession tricky). Before I file an improvement JIRA against either of these projects, I wanted to get some feedback from the developers here (Mark) on what they thought the best/right approach was based on their experience and previous discussions on the expert list. Of course, if I'm overlooking some other way to update the last access time or otherwise keep the session from expiring, please let me know. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1459043 - /tomcat/trunk/test/org/apache/catalina/core/TesterContext.java
On Mar 20, 2013, at 5:48 PM, Mark Thomas wrote: > On 20/03/2013 21:35, Nick Williams wrote: >> >> On Mar 20, 2013, at 3:53 PM, Mark Thomas wrote: >> >>> On 20/03/2013 20:50, Remy Maucherat wrote: >>>> On Wed, 2013-03-20 at 20:46 +, ma...@apache.org wrote: >>>>> Author: markt >>>>> Date: Wed Mar 20 20:46:04 2013 >>>>> New Revision: 1459043 >>>>> >>>>> URL: http://svn.apache.org/r1459043 >>>>> Log: >>>>> Add new methods >>>>> >>>>> Modified: >>>>> tomcat/trunk/test/org/apache/catalina/core/TesterContext.java >>>> >>>> Sorry about that ... >>> >>> No problem. >>> >>>> I'm not sure this is a very good idea, but OTOH I'm quite sure this is >>>> meant to be injected, so I added the get/set. >>> >>> I agree injection is required and I don't see an alternative way to do >>> it. Thanks for catching this. >>> >>> Mark >> >> Also agreed. However, r1459028 introduces some unnecessary casting. This is >> easily solved: > > Indeed, but Eclipse flags a couple of errors when you do this. The > errors are incorrect but rather a nuisance. > > Something to look at after the next update. > > Mark That's odd. Those are standard Java 6 language features. Why on earth would Eclipse flag them as errors??? *scratches head* What version of Eclipse are you using? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1459043 - /tomcat/trunk/test/org/apache/catalina/core/TesterContext.java
On Mar 20, 2013, at 6:45 PM, Mark Thomas wrote: > On 20/03/2013 22:50, Nick Williams wrote: >> >> On Mar 20, 2013, at 5:48 PM, Mark Thomas wrote: >> >>> On 20/03/2013 21:35, Nick Williams wrote: > > > >>>> Also agreed. However, r1459028 introduces some unnecessary casting. This >>>> is easily solved: >>> >>> Indeed, but Eclipse flags a couple of errors when you do this. The >>> errors are incorrect but rather a nuisance. >>> >>> Something to look at after the next update. >>> >>> Mark >> >> That's odd. Those are standard Java 6 language features. Why on earth would >> Eclipse flag them as errors??? *scratches head* >> >> What version of Eclipse are you using? > > Latest stable fully patched. Eclipse appears to have a problem matching > the method call to the correct method. > > Having had a little experience with method mapping with the last EL > implementation I appreciate just how tricky the edge cases can be and > generics just makes it an order of magnitude harder. > > Mark I don't reckon you'd paste/screenshot the error and send it to me, would you? I'd be interested to know if there's a bug report (i.e., if Eclipse even knows there's a problem). My primary concern is that, since their IDE and compiler are so aligned, the compiler may not recognize it, either. Then again, I don't use Eclipse. I've hated it for about 9 years. I'm an IntelliJ guy. :-) Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Use of JAXB api to process Base64 in Tomcat 7 and 8
On Mar 21, 2013, at 12:35 AM, Konstantin Kolinko wrote: > Hi! > > Recent Mark's commits in Tomcat 7, 8 replaced custom > implementations(*) of base64 > with use of the following class from JAXB: > > javax.xml.bind.DatatypeConverter > > This affects base64 processing in our own classes and in our copy of > Commons FileUpload. > The original fileupload library in commons was not changed (I do not > see [1] change in [2] @1459121). > > [1] http://svn.apache.org/r1458726 > [2] > http://svn.apache.org/viewvc/commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/util/mime/Base64Decoder.java?view=markup > > First, it seems wrong, as this JAXB API was not designed as a general > purpose base64 codec. > > I hereby -1 on this change, on the following ground: > > 1. JAXB Javadoc say [3] that a proper way to initialize > DatatypeConverter is to call JAXBContext.newInstance) which allows > provider to initialize this class. > Looking at JDK 7u17, if Tomcat directly calls the > parseBase64Binary(..) etc, APIs, the class silently initializes itself > with default implementation, which prevents its proper initialization > later via setDatatypeConverter(..) whenever someone later calls proper > JAXB APIs. > > [3] > http://docs.oracle.com/javase/7/docs/api/javax/xml/bind/DatatypeConverter.html > > [quote] from [3] > JAXB Providers are required to call the setDatatypeConverter api at > some point before the first marshal or unmarshal operation (perhaps > during the call to JAXBContext.newInstance). This step is necessary to > configure the converter that should be used to perform the print and > parse functionality. > [/quote] > > > BTW, here is some discussion. It mentions that there exist some effort > to introduce general purpose base64 support in JDK, "JEP 135". > http://stackoverflow.com/questions/469695/decode-base64-data-in-java > > Best regards, > Konstantin Kolinko I'm going to +1 Konstantin's -1, which I suppose just means another (non-binding) -1 to the change. To add to K's quote: [quote]The javaType binding declaration can be used to customize the binding of an XML schema datatype to a Java datatype.[/quote] I think it's pretty clear that DatatypeConverter is not supposed to be used in the manner we are using it, and doing so could have negative consequences for web applications that are using JAXB. To add some more information to all of this, I believe I have seen more implementations of Base64 encoding/decoding in Java in my lifetime than I have computer languages. There's Commons FileUpload, Commons Codec, Spring Security, DatatypeConverter, and FOUR internal Sun classes that accomplish Base64 encoding/decoding in some form, just to name a few. (In an application I work on at $work, the original developer actually implemented his own.) Nobody seems to really like or want to depend on anyone else's implementation, and it's high time the JDK included an official Base64 encoder/decoder. Now it does. K mentioned JEP 135 but didn't link to it [1]. I can confirm and have personally compiled and tested that this is implemented in and working in Java 8 (java.util.Base64 [2]), though we'll have to wait for Tomcat 9 to take advantage of it (unless someone will join me in +1-ing using Java 8 for Tomcat 8 =D ;-)). For now, I'm going to have to agree with K and say we need to put it back the way it was. [1] http://openjdk.java.net/jeps/135 [2] http://download.java.net/jdk8/docs/api/java/util/Base64.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: OT: Will web containers be required to implement WebSockets
On Mar 21, 2013, at 9:54 AM, Christopher Schultz wrote: > Nick, > > On 3/21/13 10:17 AM, Nicholas Williams wrote: >> I know that WebSockets will be a part of the Java EE 7 specification >> for full application servers. But will web containers also be required >> to implement this? Or will it be optional, and Tomcat is just being >> nice? :-) > > Do you mean "will the J2EE 7 Web Profile include Websocket?" No, I meant web container, which I could mention is synonymous with servlet container [1]. Tomcat does not implement Web Profile. It is a web container/servlet container. The primary reason I'm wondering if web containers will be required to implement WebSockets is due to the integration with the new HttpServletRequest#upgrade(). Obviously this was added to facilitate WebSockets, but that doesn't mean that WebSockets will be required for web containers. > > I think it would be foolish for J2EE 7 Web Profile /not/ to include > Websocket, since it's really distinct from all other kinds of > J2EE-related stuff and squarely falls into the web-related pool of slop. However, you remind me of Web Profile, so I would /also/ like to know if Web Profile will require WebSockets. I agree with you that it would be foolish not to. > > As for Tomcat's pursuit of Websocket: our community has demanded it, so > we are providing it, regardless of any standards body. Tomcat has > cherry-picked various J2EE standards to implement and AFAICT isn't > required to do anything other than make its users happy. Obviously, > making users happy means properly supporting the Servlet and JSP specs > which of course requires the EL spec to be implemented as well. At this > point, including Websocket is another of those things we must do to keep > our users happy. Agreed. :-) > > There is a line, though, and I'm not sure if everyone exactly agrees > where that is. Clearly, Tomcat will never implement EJB. It's been great > that TomEE has stepped-in and created a product that bundles existing > J2EE services that a lot of folks want/need but don't want to bother > with the heft of WebSphere, JBoss, etc. > > -chris > [1] http://en.wikipedia.org/wiki/Web_container - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 54721] New: RemoteEndpoint blocks indefinitely if sendObject called with BinaryStream of TextStream encoders
On Mar 21, 2013, at 9:07 AM, Christopher Schultz wrote: > Nick, > > On 3/18/13 6:03 PM, Nick Williams wrote: >> >> I've been busy fleshing out all kinds of problems. :-) > > Careful: you might inadvertently become the babysitter of Tomcat's > Websocket implementation. Careful: you might be talking to a future committer. ;-) I'm actually surprised how much I've enjoyed contributing code to Tomcat in the last couple of months, despite the hoops I've had to jump through since I'm not a committer. I intend to do more in the future. Once this book is done, I have several ideas I'm working on. :-) > > -chris > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebServlets and HttpSessions (again) ... How to update last accessed time?
On Mar 20, 2013, at 5:24 PM, Nick Williams wrote: > Reading through the expert mailing list for the WebSocket spec, I gather that > the experts did not feel it appropriate to update the last access time for > HttpSession objects when messages are received. I DO agree with this; there's > no way to know what the user really wants here, and it could be a security > vulnerability to arbitrarily update the last accessed time. > > However, I CAN imagine many scenarios where a developer DOES want to update > the HttpSession last access time regularly. Consider a customer support chat > application, where a user may be chatting with support for many minutes or > even hours. Or a multiplayer online game, where the user is playing for hours > at a time. It is very reasonable to expect that the developer may want to > update the HttpSession's last access time every time a message is received > (or at some other developer-defined interval) so that the user is not logged > out (assuming the developer is using HttpSession for login/logout). Since, in > my personal use, I was already grabbing the HttpSession from the handshake > and associating it with the Session onOpen, I just decided I'd manually > update the HttpSession's last access time each time a message came in. Wrong. > HttpSession doesn't have a way to update the last access time. > > My thoughts are that there are two different approaches that could be taken > to address the inability of the developer to keep the session alive: > > 1) Update the Servlet spec to add HttpSession#updateLastAccessTime(), which > would be useful for more than just WebSockets, but it may be (probably is) > too late to get it in Servlet 3.1 (and thus we'd have to wait another 3 years > for it). > 2) Update the WebSocket spec to add > Session#updateHttpSessionLastAccessTime(), but then that would be useful only > for WebSockets (at that point, you might as well also add a > Session#getHttpSession() method, which does not exist either and so makes > getting the HttpSession tricky). > > Before I file an improvement JIRA against either of these projects, I wanted > to get some feedback from the developers here (Mark) on what they thought the > best/right approach was based on their experience and previous discussions on > the expert list. Of course, if I'm overlooking some other way to update the > last access time or otherwise keep the session from expiring, please let me > know. > > Nick And, as expected, I am not the only one wondering about this [1]. Based on Mark's response to that bug, I'm have raised this issue as a WebSocket API JIRA [2]. Mark, if you could get some a discussion going in the EG about this issue, that would be great. =D I'll keep my eye on the EG mailing list archive to see how the discussion goes. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=54738 [2] http://java.net/jira/browse/WEBSOCKET_SPEC-175 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1459389 - /tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java
On Mar 21, 2013, at 11:37 AM, ma...@apache.org wrote:
> Author: markt
> Date: Thu Mar 21 16:37:49 2013
> New Revision: 1459389
>
> URL: http://svn.apache.org/r1459389
> Log:
> Improve performance for typical use cases by roughly an order of magnitude
>
> Modified:
>tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java
>
> Modified:
> tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java?rev=1459389&r1=1459388&r2=1459389&view=diff
> ==
> --- tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java
> (original)
> +++ tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java Thu
> Mar 21 16:37:49 2013
> @@ -140,7 +140,7 @@ public abstract class BaseNCodec impleme
> * Defines the default buffer size - currently {@value}
> * - must be large enough for at least one encoded block+separator
> */
> -private static final int DEFAULT_BUFFER_SIZE = 8192;
> +private static final int DEFAULT_BUFFER_SIZE = 128;
>
> /** Mask used to extract 8 bits, used in decoding bytes */
> protected static final int MASK_8BITS = 0xff;
Wow. THAT change alone had an order of magnitude impact? That's fascinating...
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Can we get another Maven 8.0.0.SNAPSHOT?
Been a week since the last snapshot. LOTS of big WebSocket changes since then, including a fix for a problem with the core artifact JAR. Can we get another snapshot build sometime today? Thanks! - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Can we get another Maven 8.0.0.SNAPSHOT?
On Mar 21, 2013, at 5:49 PM, Mark Thomas wrote: > On 21/03/2013 18:06, Nick Williams wrote: >> Been a week since the last snapshot. LOTS of big WebSocket changes since >> then, including a fix for a problem with the core artifact JAR. Can we get >> another snapshot build sometime today? > > In progress. Should be complete in less than an hour from now. > > Mark "Less than an hour from now" turned in to 10 minutes. Hah! :-) thanks! Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Missing Classes in latest tomcat-embed-logging-log4j snapshot
In the latest snapshot (3/21) of tomcat-embed-logging-log4j, all of the classes in org.apache.juli.logging.* are missing. They are there in the 3/14 snapshot, and they are there in the 3/21 SOURCES snapshot, but they are not there in the 3/21 binaries snapshot. Something foobar happened here. They are there in the 7.0.37 artifact, but the 7.0.39 artifact has not published yet, so I don't know if they're there. https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat/embed/tomcat-embed-logging-log4j/8.0-SNAPSHOT/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Missing Classes in latest tomcat-embed-logging-log4j snapshot
On Mar 22, 2013, at 11:28 AM, Nick Williams wrote: > In the latest snapshot (3/21) of tomcat-embed-logging-log4j, all of the > classes in org.apache.juli.logging.* are missing. They are there in the 3/14 > snapshot, and they are there in the 3/21 SOURCES snapshot, but they are not > there in the 3/21 binaries snapshot. Something foobar happened here. They are > there in the 7.0.37 artifact, but the 7.0.39 artifact has not published yet, > so I don't know if they're there. > > https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat/embed/tomcat-embed-logging-log4j/8.0-SNAPSHOT/ Now that 7.0.39 is in Maven staging, I can confirm that 7.0.39 artifact DOES have these classes. So it's only the latest 8.0 snapshot, and only the binary artifact (not sources), that's missing these classes. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Getting my head around NIO 'simulated' blocking (trying to)
On Mar 23, 2013, at 10:05 AM, igaz wrote:
> So I won't bury the lede: what exactly (and why) is Tomcat doing 'simulated'
> read blocking when using the NIO connector?
>
> I've done some due diligence including downloading the latest source
> (7.0.37) and searching the tomcat mailing lists.
> Firstly, to make things simpler, let's take comet processing and writes off
> the table.
>
> In the tomcat doc, there is the nice table that compares the various http
> connectors and it reads this about nio:
> Read HTTP Request: non-blocking (I assume that means read all of the http
> request headers)
> Read HTTP Body: sim blocking (e.g. in a POST)
>
> I've browsed the code and the NIOEndpoint.Acceptor and NIOEndpoint.Poller
> all essentially make sense and look familiar to someone who has some
> experience with Java NIO
> But there's quite a bit of code to look at (and lots of abstraction) and I
> haven't got much further than there.
> What I don't understand is the HTTP Body: sim blocking part.
> Thinking about that, the only conclusion I can draw is that
> HttpRequest.getParameter('') potentially blocks?!?! i.e. tomcat is
> 'deferring' the parsing of the HTTP Body (as in the case of a POST) until
> the application Servlet 'asks' for it?
> I've always assumed that the HTTPRequest that is passed to the Servlet is
> fully formed.
> In one of the posts I saw a comment that (I believe Filip) mentioned
> something about Servlets that call getInputStream()
> requiring simulated blocking. But why would any servlet code ever do that?
> After all, it has the HttpRequest which is a nice abstraction over the input
> stream
I don't know enough about this to provide a lot of insight, but I can provide
some.
> (hmm, maybe when reading uploaded files)?
Exactly. As of Servlet 3.0/Tomcat 7.0, multipart processing is handled directly
by the container. So, if you have multipart processing enabled for a particular
Servlet, the entire request gets processed BEFORE that Servlet's
doGet/doPost/etc. methods are called. However, before Tomcat 7 this that was
not the case, and you had to handle file uploads manually. Also, you can't do
everything with built-in multipart processing that you can with manual
processing (like file upload progress bars), so even today sometimes it is
necessary to manage file uploads yourself.
So, if multipart processing is enabled, the entire request is read and parsed
before doGet/doPost/etc. are called. If it is not enabled, calls to
getParamater() inside these methods could block, because the request body has
not yet been read in order to give you an opportunity to do so yourself. Either
way, inside filters, the request has never been fully processed yet (you may
need to alter or wrap it somehow).
>
> So the first question is (assuming my inference is correct), why use
> simulated blocking at all? Just read the entire http request (headers and
> body) until you detect that the request is complete (and using standard NIO
> techniques, viz. a selector). Is there something in the servlet specs that
> proscribes that?
Yes. The Servlet spec does deal with this. I won't copy-and-paste that in here.
You're welcome to download and read it [1]. :-)
>
> And the second question is how? I guess you invoke
> SocketChannel.configureBlocking(true) and then do SocketChannel.reads()
>
> It seems that using NIO to only read the HTTP headers vitiates the
> performance benefits of NIO somewhat and I'm sure you're doing it for a good
> reason . . .
I can't speak to this. Someone else maybe can.
[1] http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-oth-JSpec/
Re: svn commit: r1460700 - /tomcat/trunk/java/org/apache/tomcat/websocket/server/WsSci.java
On Mar 25, 2013, at 10:01 AM, ma...@apache.org wrote:
> Author: markt
> Date: Mon Mar 25 15:01:41 2013
> New Revision: 1460700
>
> URL: http://svn.apache.org/r1460700
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54740
> Update SCI scan to reflect changes in spec
>
> Modified:
>tomcat/trunk/java/org/apache/tomcat/websocket/server/WsSci.java
>
> Modified: tomcat/trunk/java/org/apache/tomcat/websocket/server/WsSci.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/server/WsSci.java?rev=1460700&r1=1460699&r2=1460700&view=diff
> ==
> --- tomcat/trunk/java/org/apache/tomcat/websocket/server/WsSci.java (original)
> +++ tomcat/trunk/java/org/apache/tomcat/websocket/server/WsSci.java Mon Mar
> 25 15:01:41 2013
> @@ -16,6 +16,7 @@
> */
> package org.apache.tomcat.websocket.server;
>
> +import java.lang.reflect.Modifier;
> import java.util.HashSet;
> import java.util.Set;
>
> @@ -36,7 +37,7 @@ import javax.websocket.server.ServerEndp
> * server.
> */
> @HandlesTypes({ServerEndpoint.class, ServerEndpointConfig.class,
> -ServerApplicationConfig.class})
> +Endpoint.class})
How does Tomcat handle it (or even know?) when it comes across an Endpoint
class that's meant to be a client Endpoint, not a server Endpoint? Normally you
would use a client Endpoint with WebSocketContainer#connectToServer(Endpoint,
ClientEndpointConfig, URI) or WebSocketContainer#connectToServer(Class, ClientEndpointConfig, URI), but SCI will pick up client
Endpoints as well as server Endpoints cases with this change.
> public class WsSci implements ServletContainerInitializer {
>
> @Override
> @@ -51,7 +52,6 @@ public class WsSci implements ServletCon
>
> // Group the discovered classes by type
> Set serverApplicationConfigs = new
> HashSet<>();
> -Set scannedEndpointConfigs = new HashSet<>();
> Set> scannedEndpointClazzes = new
> HashSet<>();
> Set> scannedPojoEndpoints = new HashSet<>();
>
> @@ -60,6 +60,12 @@ public class WsSci implements ServletCon
> String wsPackage = ContainerProvider.class.getName();
> wsPackage = wsPackage.substring(0, wsPackage.lastIndexOf('.') +
> 1);
> for (Class clazz : clazzes) {
> +int modifiers = clazz.getModifiers();
> +if (!Modifier.isPublic(clazz.getModifiers()) ||
> +Modifier.isAbstract(modifiers)) {
> +// Non-public or abstract - skip it.
> +continue;
> +}
> // Protect against scanning the WebSocket API JARs
> if (clazz.getName().startsWith(wsPackage)) {
> continue;
> @@ -68,14 +74,11 @@ public class WsSci implements ServletCon
> serverApplicationConfigs.add(
> (ServerApplicationConfig) clazz.newInstance());
> }
> -if (ServerEndpointConfig.class.isAssignableFrom(clazz)) {
> +if (Endpoint.class.isAssignableFrom(clazz)) {
> @SuppressWarnings("unchecked")
> -Class configClazz =
> -(Class) clazz;
> -ServerEndpointConfig config = configClazz.newInstance();
> -scannedEndpointConfigs.add(config);
> -scannedEndpointClazzes.add(
> -(Class)
> config.getEndpointClass());
> +Class endpoint =
> +(Class) clazz;
> +scannedEndpointClazzes.add(endpoint);
> }
> if (clazz.isAnnotationPresent(ServerEndpoint.class)) {
> scannedPojoEndpoints.add(clazz);
> @@ -90,7 +93,6 @@ public class WsSci implements ServletCon
> Set> filteredPojoEndpoints = new HashSet<>();
>
> if (serverApplicationConfigs.isEmpty()) {
> -filteredEndpointConfigs.addAll(scannedEndpointConfigs);
> filteredPojoEndpoints.addAll(scannedPojoEndpoints);
> } else {
> for (ServerApplicationConfig config : serverApplicationConfigs) {
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: My recent contributions and my ICLA
I have made several contributions to Tomcat recently. Upon beginning some work on implementing a log4j-taglib module for Log4j 2, it came to my attention that I need to have an Individual Contributor License Agreement on file with the ASF Secretary. This has been done now, and my ICLA has been accepted and is on file under this email address. Just wanted to let y'all know in case the topic came up at any point in the future. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: My recent contributions and my ICLA
On Mar 27, 2013, at 9:41 AM, Mark Thomas wrote: > On 27/03/2013 14:35, Nick Williams wrote: >> I have made several contributions to Tomcat recently. Upon beginning >> some work on implementing a log4j-taglib module for Log4j 2, it came >> to my attention that I need to have an Individual Contributor License >> Agreement on file with the ASF Secretary. > > No, an ICLA is only required for committers. The ALv2 provides all the > legal cover required for contributions via mailing lists, Bugzilla, > carrier pigeon, etc. > > Some TLPs like to have the additional cover of an ICLA for "significant" > contributions although strictly it is not necessary. (Arguably anyone > making a significant contribution to a project should probably be a > committer anyway but that is a different issue.) Yea, the Log4j 2 devs told me they would make me a committer in the log4j-taglib directory if Subversion would let them do that, but it doesn't, so I'll be submitting some pretty huge patches. :-P > >> This has been done now, and >> my ICLA has been accepted and is on file under this email address. >> Just wanted to let y'all know in case the topic came up at any point >> in the future. > > ACK > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: JarScanning
On Feb 26, 2013, at 11:21 AM, Christopher Schultz wrote: > Mark, > > On 2/21/13 8:34 AM, Mark Thomas wrote: >> JRE JARs. >> I think scanning of these should be made optional and disabled by >> default. This will reduce the list of JARs we have to maintain in >> jarsToSkip. I intend to implement this unless there are any objections. > > +1 > > Will you be checking the ClassLoader to determine whether this is a JRE > JAR or not? Does this apply to the JRE's "endorsed" JARs as well? > White-listing will still work to enable individual JARs in these > locations, right? > >> jarsToScan >> This is a little more complicated. >> First of all, how does it work? The suggestion is: >> - If jarsToScan matches, scan it >> - else if jarsToSkip matches, skip it >> - else scan it > > +1 > >> Assuming that the above is acceptable, it would require the following: >> a) three new system properties >> tomcat.util.scan.DefaultJarScanner.jarsToScan >> org.apache.catalina.startup.ContextConfig.jarsToScan >> org.apache.catalina.startup.TldConfig.jarsToScan > > -1 for the global-ness of these settings. > >> b) add a parameter to JarScanner.scan() >> >> There are a couple of issues here. >> 2. (and an issue with the current code [1]). These settings are all >> global rather than per web application. I would prefer that they were >> per web application with defaults configured globally. It is complicated >> by the fact that the JARs to skip/scan may vary depending on how the >> JarScanner is used. > > I would prefer to be able to set this stuff on a per-context basis. How > much of this configuration could be configured with a ? > > -chris There hasn't been any movement on this for a while, so I wanted to see if any decision was made or if any work is being done. Note that Log4j2 is going to have a log4j-taglib artifact that (naturally) will have a TLD in its META-INF. Since Tomcat by default excludes log4j*.jar, that has to be removed from catalina.properties in order to make it work. It would be great for Tomcat 7/8 to ship with jarsToScan set to whitelist log4j-taglib*.jar, or (perhaps better) *taglib*.jar (which would cover any JARs that accidentally fell under the blacklist but had the word taglib in them). Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: JarScanning
On Mar 29, 2013, at 12:57 PM, Konstantin Kolinko wrote: > 2013/3/29 Nick Williams : >> >> >> (..) Note that Log4j2 is going to have a log4j-taglib artifact that >> (naturally) will have a TLD in its META-INF. Since Tomcat by default >> excludes log4j*.jar, that has to be removed from catalina.properties in >> order to make it work. It would be great for Tomcat 7/8 to ship with >> jarsToScan set to whitelist log4j-taglib*.jar, or (perhaps better) >> *taglib*.jar (which would cover any JARs that accidentally fell under the >> blacklist but had the word taglib in them). > > File an issue. Done. 54770. > Do you have a link? I do not see such component at their web site, nor > I see it in download of apache-log4j-2.0-beta4-bin.zip https://issues.apache.org/jira/browse/LOG4J2-187 It's brand new and hasn't be committed yet. I wrote the component myself. As discussed in the Log4j developer list, it will get committed and be part of Log4j 2 at some point in the next week, hopefully. Desire is for it to be in -beta5. > > Possible solutions: > a) Use a more specific pattern instead of "log4j*.jar", e.g. the following > pair: > > log4j.jar,log4j-1*.jar, That's possible. I'd have to research whether that covers all Log4j 1 JARs. However... > > b) Remove this exclusion altogether. There might be not so many > classes in log4j to save much time, and it is not a library that > Tomcat itself uses. I wouldn't remove it altogether. There will be nine different log4j*.jar files, unless another component is added after mine, so not excluding the rest of the Log4j 2 JARs could result in needlessly scanning up to 8 extra JARs. Excluding all but log4j-taglib JAR would be best. > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org >
Re: Java 7 support on Tomcat 5.5
On Apr 1, 2013, at 3:44 PM, Satheesh Babu wrote: > Good Evening! > > We're running our production applications in Tomcat 5.5/JRE 1.5, and there is > a need for us to migrate our applications to Java 7(JRE 1.7). There is no > information available either on java or on Apace Tomcat site regrading the > compatibility of java 7 with tomcat 5.5. Could you please let me know the > compatibility of Java 7/Tomcat 5.5 (or) do we need to upgrade tomcat to 6 > (or) 7, for java 7. > > I truly appreciate your response, thanks for your timely help. > > Thanks, > Satheesh Babu First, this is the wrong list for such a question. This question belongs on the User's list. I am cross-posting on both lists this one time to inform you of this and to relocate the topic. Second, good to hear that your organization is making the jump to Java 7. Java 6 is no longer supported and Java 8 will be out soon. Third, upgrade Tomcat. Tomcat 5.5 is extremely old and no longer supported. That's why you won't even find it on the Tomcat site proper [1] anymore, you can only find it in the archives. You will likely not find anyone on these lists willing to help you much with 5.5. Finally, Tomcat 6 and 7 will both run quite fine on Java 7, but they will not compile on Java 7. If you want a version of Tomcat that compiles on Java 7, you will need to wait for Tomcat 8, which is currently in development and should (hopefully) be out later this year. [1] http://tomcat.apache.org/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1479179 - in /tomcat/trunk: java/org/apache/coyote/http11/AbstractHttp11Processor.java webapps/examples/WEB-INF/web.xml
On May 4, 2013, at 4:20 PM, ma...@apache.org wrote:
> Author: markt
> Date: Sat May 4 21:20:27 2013
> New Revision: 1479179
>
> URL: http://svn.apache.org/r1479179
> Log:
> 204 responses are permitted entity headers
>
> Modified:
>tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
>tomcat/trunk/webapps/examples/WEB-INF/web.xml
>
> Modified:
> tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java?rev=1479179&r1=1479178&r2=1479179&view=diff
> ==
> --- tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
> (original)
> +++ tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
> Sat May 4 21:20:27 2013
> @@ -24,6 +24,7 @@ import java.util.concurrent.atomic.Atomi
> import java.util.regex.Pattern;
>
> import javax.servlet.RequestDispatcher;
> +import javax.servlet.http.HttpServletResponse;
> import javax.servlet.http.HttpUpgradeHandler;
>
> import org.apache.coyote.AbstractProcessor;
> @@ -1362,7 +1363,8 @@ public abstract class AbstractHttp11Proc
> }
>
> MimeHeaders headers = response.getMimeHeaders();
> -if (!entityBody) {
> +// A SC_NO_CONTENT response may include entity headers
> +if (!entityBody && statusCode != HttpServletResponse.SC_NO_CONTENT) {
> response.setContentLength(-1);
> } else {
> String contentType = response.getContentType();
>
> Modified: tomcat/trunk/webapps/examples/WEB-INF/web.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/web.xml?rev=1479179&r1=1479178&r2=1479179&view=diff
> ==
> --- tomcat/trunk/webapps/examples/WEB-INF/web.xml (original)
> +++ tomcat/trunk/webapps/examples/WEB-INF/web.xml Sat May 4 21:20:27 2013
> @@ -27,6 +27,20 @@
>
> Servlet and JSP Examples
>
> +
> +
>
>
>
>
Seems to me like maybe a bug should be created making the points outlined in
the mailing list discussion so that there's a point of reference for why this
change was made. I assume, also, that this will get ported to Tomcat 7 branch
and suggested for Tomcat 6?
Nick
smime.p7s
Description: S/MIME cryptographic signature
Re: svn commit: r1480974 [1/4] - in /tomcat/trunk: ./ java/javax/servlet/jsp/resources/ java/javax/servlet/resources/ res/META-INF/
On May 10, 2013, at 5:07 AM, ma...@apache.org wrote: > Author: markt > Date: Fri May 10 10:07:21 2013 > New Revision: 1480974 > > URL: http://svn.apache.org/r1480974 > Log: > Add the Java EE 7 XSDs. Mark, were these hand-coded or copied from some other source? If copied, could you let me know where you got them? I'd like to let the IntelliJ IDEA developers know where to find them. Thanks, Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1480974 [1/4] - in /tomcat/trunk: ./ java/javax/servlet/jsp/resources/ java/javax/servlet/resources/ res/META-INF/
On May 10, 2013, at 8:35 AM, Mark Thomas wrote: > On 10/05/2013 14:22, Nick Williams wrote: >> >> On May 10, 2013, at 5:07 AM, ma...@apache.org wrote: >> >>> Author: markt >>> Date: Fri May 10 10:07:21 2013 >>> New Revision: 1480974 >>> >>> URL: http://svn.apache.org/r1480974 >>> Log: >>> Add the Java EE 7 XSDs. >> >> Mark, were these hand-coded or copied from some other source? If copied, >> could you let me know where you got them? I'd like to let the IntelliJ IDEA >> developers know where to find them. > > As per the statements in the various notice files these were copied from: > http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html > > Mark My bad for not looking at the notice files. Thanks! Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
OT: How do I subscribe to the Tomcat Dev/User lists with my @apache.org address?
I recently became a committer on the Logging project and thus I now have an @apache.org address. Since it's a forwarding address, I'm having it forward to my Google Apps email address (the address I'm sending from now). I'd like to subscribe to the Tomcat Dev and User lists with my @apache.org address. I've set up my @apache.org address as an additional "From" address in GMail. If I send an email from GMail to my $work address and select my @apache.org address is my from address, it shows up as "from" my @apache.org address when I receive the email on the other end. But when I tried to subscribe by sending an email from my @apache.org address to dev-subscr...@tomcat.apache.org, it replied that my GMail address was already subscribed. Does anyone have any experience with this? How do you subscribe your @apache.org addresses? Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
Can one of the very knowledgeable developers that have been discussing memory leaks in the last few days (re: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread) chime in on this Log4j 2 bug [1]? Log4j 2 appears to be registering a shutdown hook that, I believe, will result in a memory leak in Tomcat. The JreMemoryLeakPreventionListener does not detect it (which might be a separate Tomcat bug, assuming I'm right that it's a memory leak). I don't know nearly as much about class loaders and memory leaks in a web application as some of the guys I've read talking on here the last few days, and it would be helpful for us to get the knowledgeable opinion of one or more Tomcat developers about how to solve this. Thanks, Nick [1] https://issues.apache.org/jira/browse/LOG4J2-223 (Note: I don't normally post to both lists, but since the memory leak topic was occurring on the user's list, and I also wanted to get the attention of as many developers as possible, I made an exception this time.)
Timeline for beginning EL 3.0 implementation?
I was looking through EE 7 and the changes to trunk in the last six months or so and realized that no work had yet been done to implement EL 3.0. Does anyone know what the anticipated timeline is for beginning work on EL 3.0? I don't even know who the EL expert(s) on the Tomcat project is(are). Thanks, Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1491940 - in /tomcat/trunk: java/org/apache/catalina/core/AsyncContextImpl.java java/org/apache/catalina/core/LocalStrings.properties test/org/apache/catalina/core/TestAsyncContextImp
On Jun 11, 2013, at 3:28 PM, Mark Thomas wrote: > On 11/06/2013 21:25, Konstantin Kolinko wrote: >> 2013/6/12 : >>> Author: markt >>> Date: Tue Jun 11 20:18:10 2013 >>> New Revision: 1491940 >>> >>> URL: http://svn.apache.org/r1491940 >>> Log: >>> Servlet 3.1 requires an ISE if getRequest() or getResponse() are called >>> after complete() or dispatch() >>> >>> Modified: >>> tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java >>> tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties >>> tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java >>> >>> Modified: tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java >>> URL: >>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java?rev=1491940&r1=1491939&r2=1491940&view=diff >>> == >>> --- tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java >>> (original) >>> +++ tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java Tue >>> Jun 11 20:18:10 2013 >>> @@ -64,8 +64,8 @@ public class AsyncContextImpl implements >>> protected static final StringManager sm = >>> StringManager.getManager(Constants.Package); >>> >>> -private ServletRequest servletRequest = null; >>> -private ServletResponse servletResponse = null; >>> +private volatile ServletRequest servletRequest = null; >>> +private volatile ServletResponse servletResponse = null; >>> private final List listeners = new ArrayList<>(); >>> private boolean hasOriginalRequestAndResponse = true; >>> private volatile Runnable dispatch = null; >>> @@ -90,6 +90,7 @@ public class AsyncContextImpl implements >>> check(); >>> request.getCoyoteRequest().action(ActionCode.COMMIT, null); >>> request.getCoyoteRequest().action(ActionCode.ASYNC_COMPLETE, null); >>> +clearServletRequestResposne(); >> >> s/../Response/ > > Ah, one of my favorite typos. It is almost worth writing a pre-commit hook to > fix that :) I type "reponse" a lot. I have a problem with that first S for some reason. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Timeline for beginning EL 3.0 implementation?
On Jun 11, 2013, at 3:36 PM, Mark Thomas wrote: > On 11/06/2013 21:29, Nick Williams wrote: >> I was looking through EE 7 and the changes to trunk in the last six >> months or so and realized that no work had yet been done to implement >> EL 3.0. Does anyone know what the anticipated timeline is for >> beginning work on EL 3.0? > > When I've finished the Servlet 3.1 and WebSocket 1.0 implementations or > someone else decides to start on it. Okay. One of many reasons I ask is that I still have it on my to-do to make some improvements on the JSP compiler to support things like 1) precompiling all JSPs on deploy and 2) a better Ant task. I don't know how much the EL changes might affect this JSP compilation (hopefully it's fairly decoupled), and I'd like that to not seriously hinder any effort to back-port my improvements to Tomcat 7. I'm wondering if this needs to move higher on my list and get in before the EL changes. Any insight? > > The basic implementations are done. I'm currently reviewing the changes in > the spec checking that everything is implemented. That will be followed by > reviewing the various EG discussions on the bits the spec doesn't cover very > well. > > Once all that is done I was thinking about some form of alpha release before > starting work on the EL stuff. Seems like a good idea. > >> I don't even know who the EL expert(s) on >> the Tomcat project is(are). > > The original developer moved on to other things shortly after completing the > implementation. Gotchya. That probably explains why I haven't heard a peep about it. > > I did most of the EL 2.2 implementation. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jar scanning, SCI scanning, fragment scanning
On Jun 13, 2013, at 11:23 AM, Mark Thomas wrote: > As I make my way through the Servlet 3.1 spec reviewing all the changes to > make sure they have all been implemented, I have reached section 8.2. There > are a number of related issues here. > > 1. Three known issues with the current SCI / fragment handling [1] > - SCI scan does not obey class loader ordering > - fragments in container JARs are processed > - Container SCIs may be exluded > > 2. A wish for per context jarsToSkip [2] > > 3. A wish for greater control over jarsToSkip [3] > > > These issues are all inter-related. Fixing them is going to require either > some very ugly hacks or changes to the JarScanner API. > > I have started down the route of the JAR scanner API changes. The overall > idea is: > - jarsToSkip is replaced by a JarScanFilter with the default > implementation doing what jarsToSkip currently does I would request "doing what jarsToSkip currently does plus what is wanted with jarsToScan in 3." It shouldn't be extra complicated or require re- or duplicate-configuration of anything to whitelist one JAR. Also, it's very important that log4j-core*.jar and log4j-taglib*.jar be whitelisted by default. These are 2.0-specific JARs and they must be scanned. log4j-core contains listeners/filters/fragment to initialize and deinitialize in a Servlet container properly, and log4j-taglib contains a TLD. Nick > - The client passes the type of scan (TLD, Pluggability, etc) to the > JarScanner > - The JarScanner indicates whether or not any JAR found is an > application or container JAR > - The JacScanFilter filters the JARs returned based on scan type and on > configuration > > This addresses the above issues in the following way: > 1 - Knowing if the JAR is a container JAR or not allows the >ContextConfig class to do the right thing. > 2 - The StandardJarScanFilter can be configured per context in the same >way the StandardJarScanner can. > 3 - Same as 2. > > The StandardJarScanFilter will have enough options to implement the > requirements of 2 & 3. > > I currently have the start of this in a local git repo. Any objections to me > committing what I have to trunk and continuing there? > > > [1] http://markmail.org/message/22e3sjmsy2gt4tkw > [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=54083 > [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=54770 > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1493584 - in /tomcat/trunk: res/findbugs/filter-false-positives.xml test/org/apache/catalina/core/TestApplicationSessionCookieConfig.java
On Jun 16, 2013, at 4:14 PM, ma...@apache.org wrote:
> Author: markt
> Date: Sun Jun 16 21:14:37 2013
> New Revision: 1493584
>
> URL: http://svn.apache.org/r1493584
> Log:
> Fix FindBugs warnings in test code
>
> Modified:
>tomcat/trunk/res/findbugs/filter-false-positives.xml
>
> tomcat/trunk/test/org/apache/catalina/core/TestApplicationSessionCookieConfig.java
>
> Modified: tomcat/trunk/res/findbugs/filter-false-positives.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/res/findbugs/filter-false-positives.xml?rev=1493584&r1=1493583&r2=1493584&view=diff
> ==
> --- tomcat/trunk/res/findbugs/filter-false-positives.xml (original)
> +++ tomcat/trunk/res/findbugs/filter-false-positives.xml Sun Jun 16 21:14:37
> 2013
> @@ -466,6 +466,11 @@
>
>
>
> + name="org.apache.catalina.core.TestApplicationSessionCookieConfig$CustomContext"
> />
> +
> +
> +
> +
Maybe it's just me, but it seems like you should be a little more specific
here. Specifying the method or methods and the full bug pattern instead of the
code (prefix) would prevent false-negatives if other bugs arose. Of course, at
the moment there is only one bug pattern that starts with UG_, but that could
change in future versions.
>
>
>
> @@ -586,4 +591,13 @@
>
>
>
> +
> +
> +
> +
> +
> +
> +
> +
> +
>
Same thing. The method names are great here, but there are six bug patterns
that start with DLS_. Are you really meaning to suppress all six of them?
Just my $0.02.
> \ No newline at end of file
>
> Modified:
> tomcat/trunk/test/org/apache/catalina/core/TestApplicationSessionCookieConfig.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/core/TestApplicationSessionCookieConfig.java?rev=1493584&r1=1493583&r2=1493584&view=diff
> ==
> ---
> tomcat/trunk/test/org/apache/catalina/core/TestApplicationSessionCookieConfig.java
> (original)
> +++
> tomcat/trunk/test/org/apache/catalina/core/TestApplicationSessionCookieConfig.java
> Sun Jun 16 21:14:37 2013
> @@ -126,7 +126,7 @@ public class TestApplicationSessionCooki
> }
>
> private static class CustomContext extends StandardContext {
> -private LifecycleState state;
> +private volatile LifecycleState state;
>
> @Override
> public LifecycleState getState() {
>
>
>
> -
> 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
CVE-2013-1571, VU#225657
Oracle has announced a Javadoc vulnerability (CVE-2013-1571 [1], VU#225657 [2]) whereby Javadoc generated with Java 5, Java 6, or Java 7 < 7u25 is vulnerable to a frame injection attack. Oracle has provided a repair-in-place tool for Javadoc that cannot be easily regenerated, but is urging developers to regenerate whatever Javadoc they can using Java 7u25. For all practical purses, the vulnerability really only applies to publicly-hosted Javadoc, so the Javadoc in our existing Maven artifacts, downloads, and archived downloads really doesn't have to be worried about (not that we could do anything about it). My thoughts on this: 1) We should apply the repair-in-place tool ASAP to the Javadoc on the website for Tomcat 6 and Tomcat 7. 2) Future Tomcat 6 and 7 Javadoc should be generated with 7u25 or better. There will be no fix for Java 5 or 6. Thankfully, generating Javadoc using a different JDK than you used to compile is quite easy in both Maven and Ant. In fact, I personally prefer it that way, because the Javadoc is much more visually attractive in Java 7. I will file an issue about this two, but I wanted to go ahead and make the list aware. Nick [1] http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html [2] http://www.kb.cert.org/vuls/id/225657
Re: CVE-2013-1571, VU#225657
On Jun 19, 2013, at 3:15 AM, Mark Thomas wrote: > On 19/06/2013 00:42, Nick Williams wrote: >> Oracle has announced a Javadoc vulnerability (CVE-2013-1571 [1], >> VU#225657 [2]) whereby Javadoc generated with Java 5, Java 6, or Java >> 7 < 7u25 is vulnerable to a frame injection attack. Oracle has >> provided a repair-in-place tool for Javadoc that cannot be easily >> regenerated, but is urging developers to regenerate whatever Javadoc >> they can using Java 7u25. For all practical purses, the vulnerability >> really only applies to publicly-hosted Javadoc, so the Javadoc in our >> existing Maven artifacts, downloads, and archived downloads really >> doesn't have to be worried about (not that we could do anything about >> it). My thoughts on this: >> >> 1) We should apply the repair-in-place tool ASAP to the Javadoc on >> the website for Tomcat 6 and Tomcat 7. > > And Tomcat 5 and earlier. The javadoc for those isn't linked but remains > available. > > I'll get on to this now. > >> 2) Future Tomcat 6 and 7 Javadoc should be generated with 7u25 or >> better. > > Hmm. That will need some thought as the build needs to be run with the > minimum Java version required for that major version. Maybe we can just run > the Javadoc part with a different JDK. Either that, or run the fix tool over > the result. This needs some investigation. As long as Ant knows where to find the JDK (environmental variable or something) it can generate Javadoc with Java 7 while Ant runs with Java 5/6. Ant does not have to run with Java 7. See the Ant documentation for the Javadoc task [1], refer to the "executable" attribute. By default Ant looks for "javadoc" in the same JDK Ant as running under, but you can specify a path to a different JDK using the executable attribute. Only downside is that the building instructions will have to say that Java _ /and/ Java 7u25 are required to build, and that a certain environmental variable has to exist pointing to the JDK7 installation. Might be best to make this "conditional" so that it falls back to the default if it can't find Java 7 (makes it easier for home builders). [1] http://ant.apache.org/manual/Tasks/javadoc.html > >> There will be no fix for Java 5 or 6. Thankfully, generating >> Javadoc using a different JDK than you used to compile is quite easy >> in both Maven and Ant. In fact, I personally prefer it that way, >> because the Javadoc is much more visually attractive in Java 7. > > Hopefully it will be as simple as you suggest. > >> I will file an issue about this two, but I wanted to go ahead and >> make the list aware. > > Thanks, > > Mark > > >> Nick >> >> [1] >> http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html >> >> > [2] http://www.kb.cert.org/vuls/id/225657 >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org >
Re: Jasper improvements
On Jun 26, 2013, at 1:57 PM, Jeremy Boynes wrote:
> On Jun 26, 2013, at 7:49 AM, Christopher Schultz
> wrote:
>
>> Jeremy,
>>
>> On 6/26/13 1:44 AM, Jeremy Boynes wrote:
>>> On Jun 11, 2013, at 1:50 PM, Nick Williams
>>> wrote:
>>>>
>>>> Okay. One of many reasons I ask is that I still have it on my to-do
>>>> to make some improvements on the JSP compiler to support things
>>>> like 1) precompiling all JSPs on deploy and 2) a better Ant task. I
>>>> don't know how much the EL changes might affect this JSP
>>>> compilation (hopefully it's fairly decoupled), and I'd like that to
>>>> not seriously hinder any effort to back-port my improvements to
>>>> Tomcat 7. I'm wondering if this needs to move higher on my list and
>>>> get in before the EL changes. Any insight?
>>>
>>> I have been thinking about improvements to Jasper as well around
>>> better support for Servlet 3.0 concepts. One area would be decoupling
>>> it from Tomcat, bootstrapping using an SCI as hinted in
>>> ContextConfig. I'd also be interested in improving the Ant task as
>>> well, such as support for pre-compiling a separate package that would
>>> be treated as a web fragment (including web.xml-less pre-compilation,
>>> generating a web-fragment.xml rather than a web.xml snippet or
>>> potentially eliminating the XML entirely if the generated code can be
>>> annotated with @WebServlet).
>>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50234
>>
>> I tried some forays into this a few years ago, but got stuck in the
>> confusion of how everything works together. I wanted to do something
>> simple like get the web-app's spec-version number, but could not figure
>> out how to do it.
>
> I find usage and implementation very confusing as well - an example being
> things that can be configured on the Task vs. init-params for the JSP servlet
> vs. things set via system properties. A challenge here is that cleaning it up
> would likely warrant incompatible changes so would be out for 7.x but
> potentially possible for 8.x - I'd be interested in what people think about a
> major refactor that allowed incompatible changes (assuming they were
> justified not arbitrary).
>
> You wrote in the bug that "annotation's don't make sense" - could you clarify
> that? I was thinking that we could have Jasper add @WebServlet("/foo.jsp") to
> the class generated for "foo.jsp" and then that would be picked up by a
> container as part of its normal scan. We could also have an SCI
> @HandlesTypes(JspPage.class) and then register the JSP servlets itself but
> two issues come to mind:
> 1) the need for metadata that duplicates what the normal servlet annotations
> could convey
> 2) avoiding conflicts with classes that are bound via jsp-property-group or
> servlet-mapping elements in XML descriptors
>
> What happens to a fragment compiled a build-time whose properties differ from
> those in the final runtime (for example, due to settings resulting from a
> merged web.xml)? One option would be to say that the build process had simply
> converted all the JSPs into a jar-full of Servlets and that they should be
> deployed as such; if the user wants them treated as JSPs they should be
> packaged as such into META-INF/resources.
>
> How should we control pre-compile on deploy? The spec already supports if the
> web.xml contains a entry with a and
> but that requires defining a entry for every individual JSP ("jsp-file
> element contains the full path to *a* JSP file" on pp 14-160) which is a
> pain. We could embed an Ant task in a configuration file (e.g.
> META-INF/jasper.xml) but that adds a dependency on Ant and seems like
> overkill. Alternatively we can have the SCI read the configuration file and
> do the necessary.
>
> If we go the SCI route, we could also define a JspConfiguration annotation or
> interface that a user could place on a class they want to handle
> initialization. The SCI could @HandlesTypes that, calling it to handle
> user-provided initialization. We could expose the translator and compiler
> interfaces so it can handle pre-compilation; we could refactor the JSPServlet
> to use them in the same way.
A word of caution: I don't think web.xml-less compilation is possible. web.xml
/and/ web-fragment.xml can contain , which sets up rules
surrounding how JSPs are compiled. Before a single JSP in an application can be
compiled, the deployment descriptor and all web fragments must be processed and
merged so that the JSP configuration can be taken into consideration during
compilation. This requires a large portion of the application (you need
WEB-INF/web.xml and WEB-INF/lib).
N
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1497299 - /tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
On Jun 27, 2013, at 6:08 AM, ma...@apache.org wrote:
> Author: markt
> Date: Thu Jun 27 11:08:03 2013
> New Revision: 1497299
>
> URL: http://svn.apache.org/r1497299
> Log:
> WebSocket 1.0, Section 4.8
> Don't look for annotations on inherited methods.
>
> Modified:
>tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
>
> Modified:
> tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java?rev=1497299&r1=1497298&r2=1497299&view=diff
> ==
> --- tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
> (original)
> +++ tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
> Thu Jun 27 11:08:03 2013
> @@ -77,7 +77,7 @@ public class PojoMethodMapping {
> Method open = null;
> Method close = null;
> Method error = null;
> -for (Method method : clazzPojo.getMethods()) {
> +for (Method method : clazzPojo.getDeclaredMethods()) {
> if (method.getAnnotation(OnOpen.class) != null) {
This will return non-public methods as well as public methods. Are non-public
WebSocket-annotated methods permitted? If not, would it be better to throw an
exception here if(!Modifier.isPublic(method.getModifiers())) instead of
allowing configuration to succeed and then receiving an IllegalAccessException
during a session, possibly after it has been active for some time?
Nick
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1497299 - /tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
On Jun 27, 2013, at 9:42 AM, Mark Thomas wrote:
> On 27/06/2013 15:29, Nick Williams wrote:
>>
>> On Jun 27, 2013, at 6:08 AM, ma...@apache.org wrote:
>>
>>> Author: markt
>>> Date: Thu Jun 27 11:08:03 2013
>>> New Revision: 1497299
>>>
>>> URL: http://svn.apache.org/r1497299
>>> Log:
>>> WebSocket 1.0, Section 4.8
>>> Don't look for annotations on inherited methods.
>>>
>>> Modified:
>>> tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
>>>
>>> Modified:
>>> tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
>>> URL:
>>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java?rev=1497299&r1=1497298&r2=1497299&view=diff
>>> ==
>>> ---
>>> tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
>>> (original)
>>> +++
>>> tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
>>> Thu Jun 27 11:08:03 2013
>>> @@ -77,7 +77,7 @@ public class PojoMethodMapping {
>>>Method open = null;
>>>Method close = null;
>>>Method error = null;
>>> -for (Method method : clazzPojo.getMethods()) {
>>> +for (Method method : clazzPojo.getDeclaredMethods()) {
>>>if (method.getAnnotation(OnOpen.class) != null) {
>>
>> This will return non-public methods as well as public methods. Are
>> non-public WebSocket-annotated methods permitted?
>
> The spec is silent on that particular issue.
So maybe some context would help. Are there other cases elsewhere in the JavaEE
spec where annotations mark methods as handling some action? If so, are those
methods allowed to be non-public? I would suggest, in absence of the spec
saying exactly, that being consistent with similar cases seems right. Of
course, clarification from the EG always helps...
>
>> If not, would it be better to throw an exception here
>> if(!Modifier.isPublic(method.getModifiers())) instead of allowing
>> configuration to succeed and then receiving an IllegalAccessException during
>> a session, possibly after it has been active for some time?
>
> The other option is to ignore them (which is what happened before).
>
> I'm leaning towards the Exception approach.
Agreed. If there are non-public annotated methods the endpoint is invalid. A
connection should never be permitted to an invalid endpoint. The best way to
avoid that is to throw an exception here.
Nick
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1497569 - /tomcat/trunk/java/org/apache/tomcat/websocket/server/WsServerContainer.java
On Jun 27, 2013, at 4:32 PM, ma...@apache.org wrote: > Author: markt > Date: Thu Jun 27 21:32:39 2013 > New Revision: 1497569 > > URL: http://svn.apache.org/r1497569 > Log: > With an eye to the future, First phrase of your new novel? :-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1497552 - /tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
On Jun 27, 2013, at 6:14 PM, Konstantin Kolinko wrote: > 2013/6/28 : >> Author: markt >> Date: Thu Jun 27 20:10:40 2013 >> New Revision: 1497552 >> >> URL: http://svn.apache.org/r1497552 >> Log: >> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55151 >> Fix bugs in test >> >> Modified: >> >> tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java >> >> Modified: >> tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java >> URL: >> http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java?rev=1497552&r1=1497551&r2=1497552&view=diff >> == >> --- >> tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java >> (original) >> +++ >> tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java >> Thu Jun 27 20:10:40 2013 >> @@ -108,7 +108,7 @@ public class TestEncodingDecoding extend >> Assert.assertEquals(MESSAGE_ONE, >> ((MsgString) >> MsgStringMessageHandler.received.peek()).getData()); >> Assert.assertEquals(MESSAGE_ONE, >> -((MsgString) client.received.peek()).getData()); >> +new String(((MsgByte) client.received.peek()).getData())); > > It is "new String(byte[])" here. It would be better with explicit > encoding name such as "ISO-8859-1". Or with a Charset instance, if you have one, because that's immune from an encoding unlike a String charset name. If the charset is always going to be fixed here, this is Java 7 so you could use StandardCharsets.UTF8, etc. N - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1497670 - /tomcat/trunk/java/org/apache/tomcat/websocket/server/WsFilter.java
On Jun 28, 2013, at 2:35 AM, ma...@apache.org wrote:
> Author: markt
> Date: Fri Jun 28 07:35:49 2013
> New Revision: 1497670
>
> URL: http://svn.apache.org/r1497670
> Log:
> WebSocket 1.0, section 8.2
> There is an implied restriction that any initial upgrade request must use
> HTTP GET.
>
> +!"GET".equals(((HttpServletRequest) request).getMethod())) {
> // Not an HTTP request that includes a valid upgrade request to
> // web socket
> +// Note: RFC 2616 does not limit HTTP upgrade to GET requests but
> +// the the Java WebSocket spec 1.0, section 8.2 implies
> such a
> +// limitation
Unfortunate that the Java WebSocket spec is in direct contradiction with the
RFC spec. IMO, the RFC spec is the authority and it seems like it should take
precedence over the Java WebSocket spec. That would be like the RFC HTTP spec
saying "you must do X when header Y is present" and the Java Servlet spec
saying "you must not do X when header Y is present." The Java WebSocket spec is
clearly wrong here.
How clear is the Java WebSocket spec? Does it just /seem/ to indicate this or
does it /insist/ upon it?
Nick
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1497670 - /tomcat/trunk/java/org/apache/tomcat/websocket/server/WsFilter.java
On Jun 28, 2013, at 11:27 AM, Mark Thomas wrote:
> On 28/06/2013 17:00, Nick Williams wrote:
>>
>> On Jun 28, 2013, at 2:35 AM, ma...@apache.org wrote:
>>
>>> Author: markt Date: Fri Jun 28 07:35:49 2013 New Revision: 1497670
>>>
>>> URL: http://svn.apache.org/r1497670 Log: WebSocket 1.0, section
>>> 8.2 There is an implied restriction that any initial upgrade
>>> request must use HTTP GET.
>>>
>>> +!"GET".equals(((HttpServletRequest)
>>> request).getMethod())) { // Not an HTTP request that includes a
>>> valid upgrade request to // web socket +// Note: RFC
>>> 2616 does not limit HTTP upgrade to GET requests but +
>>> // the the Java WebSocket spec 1.0, section 8.2 implies such
>>> a +// limitation
>>
>> Unfortunate that the Java WebSocket spec is in direct contradiction
>> with the RFC spec.
>
> Please provide a reference for the part of RFC 6455 you believe this
> change violates.
I was going off your comment, which originally suggested this was the case.
However, now that you have clarified your comment, my comments are no longer
applicable.
Nick
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1504148 - in /tomcat/trunk: java/org/apache/jasper/compiler/ java/org/apache/jasper/el/ java/org/apache/jasper/runtime/ test/javax/el/ test/org/apache/el/ test/org/apache/el/parser/ t
On Jul 17, 2013, at 9:21 AM, Caldarale, Charles R wrote: >> From: ma...@apache.org [mailto:ma...@apache.org] >> Subject: svn commit: r1504148 > >> URL: http://svn.apache.org/r1504148 >> Log: >> Add the two new resolver types (stream and static) to Jasper in the correct >> order and modify JasperELResolver so the correct resolvers are skipped. > > Did you really want to say "so the correct resolvers are skipped"? Seems odd > to be skipping the proper ones, or perhaps I just don't understand how this > should work. > > - Chuck I read "so the correct resolvers are skipped" as "so the resolvers that should be skipped are skipped." Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: 8.0-SNAPSHOT updated
No objection here. Things seem to be working well. I'm rather excited about it. :-) Nick On Jul 18, 2013, at 11:11 AM, Mark Thomas wrote: > Given recent progress, I have uploaded a snapshot of the current state > of trunk to the Maven snapshot repository. Note that our Maven builds > include full binary distributions (.zip & .tar.gz) so if folks want to > test the latest Tomcat 8, they can without having to build from svn. > > The snapshot repo is here: > https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat > > and the binaries can be found here: > https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat/tomcat/8.0-SNAPSHOT/ > > > I think we are at the point where we could do a 8.0.0-alpha release. The > specs (Servlet 3.1, JSP 2.3, EL 3.0, WebSocket 1.0) are all implemented. > There is still work to do to review the EG disucssions that covered > various edge cases / things not in the spec to align the implementation > with what the EG agreed was best practice but didn't make it into the spec. > > Any objections to starting the 8.0.0 release process? > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: 8.0.0 (was: 8.0-SNAPSHOT updated)
On Jul 25, 2013, at 6:49 PM, Rainer Jung wrote: > On 26.07.2013 00:34, Mark Thomas wrote: >> On 21/07/2013 09:10, Mark Thomas wrote: >>> On 20/07/2013 17:42, Konstantin Kolinko wrote: 2013/7/18 Mark Thomas : >> >> >> > Any objections to starting the 8.0.0 release process? What do we do with DBCP? a) There will be a new release in Apache Commons >>> >>> That requires a pool 2.0 release and then a dbcp 2.0 release. >>> b) Require "patch" tool as prerequisite (It needs to be explicitly installed and configured on Windows) https://issues.apache.org/bugzilla/show_bug.cgi?id=54522 c) Make DBCP optional, e.g. introduce "skip.dbcp" property like existing "skip.installer" one. d) Drop DBCP pool I am currently using a variant of "c)" by setting "no.build.dbcp=true" (thus fooling an up-to-date check), but an explicit and documented property would be better. >>> >>> e) ship a dbcp version built from svn rather than a release. >>> >>> >>> My own preferences (in order) are: >>> >>> a, e, b, c, d >>> >>> I'll see what I can do to towards a. >> >> There is quite a bit of work for DBCP2 as a lot of things have been put >> off got a while (I fixed a 9 year old enhancement request earlier this >> week) as they require API changes. >> >> I've been thinking about this a little more and I think there is another >> option that works better for Tomcat 8. >> >> svn copy and package rename DBCP2 and POOL2 to org.apache.tomcat in the >> same way we have handled Commons BCEL, Codec and FileUpload >> Pros: >> - can make early versions of DBCP2 available for testing with Tomcat 8 >> - simpler build process >> - easier to make source changes (we are going to have to make changes >> because DBCP adds Commons-Logging) >> - can switch to tracking released revision numbers at any point (once >> there is a release to track) >> - option to remove code we don't use >> >> Cons: >> - more work to keep in sync than just changing a version number in a >> property file >> - requires effort to set up >> >> My outline plan is to do this early to middle of next week with a 8.0.x >> release (8.0.0-RC1 to be consistent with how we did 7.0.x) towards the >> end of the week. >> >> Thoughts? > > That would be especially good if DBCP2 could hold back their release > until our fork has stabilized and synced back so that the DBCP2 releases > can from then on be used as the master for our copy. Otherwise we would > have to live for a long time with a diverging fork, because DBCP2 might > have already frozen their API due to the first release. > > Regards, > > Rainer So I feel a little dopey, but I can't find DBCP2 anywhere. I see no mention of a 2.0 at http://commons.apache.org/proper/commons-dbcp/, and I see no mention of anything called "DBCP2" at http://commons.apache.org/. Where can I find this?
Re: svn commit: r1508171 - /tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
On Jul 29, 2013, at 2:02 PM, Jeremy Boynes wrote:
> This flags as a warning for me in IDEA without the suppression. Isn't this
> an unchecked cast (Object to List)?
Yes, that's an unchecked cast. The @SuppressWarnings was not unnecessary.
N
>
>
> On Mon, Jul 29, 2013 at 11:38 AM, wrote:
>
>> Author: markt
>> Date: Mon Jul 29 18:38:08 2013
>> New Revision: 1508171
>>
>> URL: http://svn.apache.org/r1508171
>> Log:
>> Remove unnecessary @SuppressWarnings
>>
>> Modified:
>>tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
>>
>> Modified:
>> tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
>> URL:
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java?rev=1508171&r1=1508170&r2=1508171&view=diff
>>
>> ==
>> --- tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
>> (original)
>> +++ tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
>> Mon Jul 29 18:38:08 2013
>> @@ -82,7 +82,6 @@ public class WebappServiceLoader {
>>
>> // if the ServletContext has ORDERED_LIBS, then use that to
>> specify the
>> // set of JARs from WEB-INF/lib that should be used for loading
>> services
>> -@SuppressWarnings("unchecked")
>> List orderedLibs = (List)
>> context.getAttribute(ServletContext.ORDERED_LIBS);
>> if (orderedLibs != null) {
>> // handle ordered libs directly, ...
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1508171 - /tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
On Jul 29, 2013, at 2:40 PM, Mark Thomas wrote:
> On 29/07/2013 21:04, Nick Williams wrote:
>> On Jul 29, 2013, at 2:02 PM, Jeremy Boynes wrote:
>>
>>> This flags as a warning for me in IDEA without the suppression. Isn't this
>>> an unchecked cast (Object to List)?
>
> It is an unchecked cast but there is no way to avoid the cast so there
> is no point the IDE flagging it as there is nothing the developer can do
> to fix it. Eclipse added an option (Ignore unavoidable generic type
> problems) not to flag issues such as this as of a recent(ish) version.
>
>> Yes, that's an unchecked cast. The @SuppressWarnings was not unnecessary.
>
> Yes, it is unchecked cast. However, the warning is pointless and
> shouldn't have been generated in the first place.
>
> The Tomcat 8 code base should not exhibit any warnings with the defined
> Eclipse settings [1]. Ditto for FindBugs and Checkstyle with the
> provided configurations.
Shouldn't it also not exhibit any warnings when compiled by the JDK? "Some
classes use unchecked or unsafe operations" is not something I want to see when
compiling code. Remember Eclipse is just what some developers use. Other
developers use other IDEs, and all IDEs have settings that can be argued
for/against. The JDK, however, is what everyone uses to compile production
code, ultimately, and it says that line is unchecked.
@SuppressWarnings("unchecked") means, to me, "Someone has taken the time to
look closely at this line and confirm that, indeed, it isn't problematic." Now
I see that line of code after my compiler warns me and I say, "Oops, might this
be a problem?"
N
>
> The intention is to add additional checks over time although we haven't
> added any for a while.
>
> Mark
>
> http://svn.apache.org/viewvc/tomcat/trunk/res/ide-support/eclipse/java-compiler-errors-warnings.txt?view=annotate
>
>
>>
>> N
>>
>>>
>>>
>>> On Mon, Jul 29, 2013 at 11:38 AM, wrote:
>>>
>>>> Author: markt
>>>> Date: Mon Jul 29 18:38:08 2013
>>>> New Revision: 1508171
>>>>
>>>> URL: http://svn.apache.org/r1508171
>>>> Log:
>>>> Remove unnecessary @SuppressWarnings
>>>>
>>>> Modified:
>>>> tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
>>>>
>>>> Modified:
>>>> tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
>>>> URL:
>>>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java?rev=1508171&r1=1508170&r2=1508171&view=diff
>>>>
>>>> ==
>>>> --- tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
>>>> (original)
>>>> +++ tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
>>>> Mon Jul 29 18:38:08 2013
>>>> @@ -82,7 +82,6 @@ public class WebappServiceLoader {
>>>>
>>>>// if the ServletContext has ORDERED_LIBS, then use that to
>>>> specify the
>>>>// set of JARs from WEB-INF/lib that should be used for loading
>>>> services
>>>> -@SuppressWarnings("unchecked")
>>>>List orderedLibs = (List)
>>>> context.getAttribute(ServletContext.ORDERED_LIBS);
>>>>if (orderedLibs != null) {
>>>>// handle ordered libs directly, ...
>>>>
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>>
>>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1508171 - /tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
On Jul 29, 2013, at 3:02 PM, Mark Thomas wrote: > On 29/07/2013 21:45, Nick Williams wrote: >> >> On Jul 29, 2013, at 2:40 PM, Mark Thomas wrote: >> >>> On 29/07/2013 21:04, Nick Williams wrote: >>>> On Jul 29, 2013, at 2:02 PM, Jeremy Boynes wrote: >>>> >>>>> This flags as a warning for me in IDEA without the suppression. >>>>> Isn't this an unchecked cast (Object to List)? >>> >>> It is an unchecked cast but there is no way to avoid the cast so >>> there is no point the IDE flagging it as there is nothing the >>> developer can do to fix it. Eclipse added an option (Ignore >>> unavoidable generic type problems) not to flag issues such as this >>> as of a recent(ish) version. >>> >>>> Yes, that's an unchecked cast. The @SuppressWarnings was not >>>> unnecessary. >>> >>> Yes, it is unchecked cast. However, the warning is pointless and >>> shouldn't have been generated in the first place. >>> >>> The Tomcat 8 code base should not exhibit any warnings with the >>> defined Eclipse settings [1]. Ditto for FindBugs and Checkstyle >>> with the provided configurations. >> >> Shouldn't it also not exhibit any warnings when compiled by the JDK? > > That isn't the standard the Tomcat community decided to adopt. When did that happen? It must've been before my time. I know I would have adamantly opposed such an adoption. Such decisions should be based on the platform, not the IDE. N - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1508171 - /tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
On Jul 29, 2013, at 3:53 PM, Jeremy Boynes wrote:
> This is what lies under the syntactic sugar, and causes no warnings in
> javac or IDEA (and I presume Eclipse). Should we stick to it?
I would say no. This is why generics exist, so that you don't have to write
code like that.
>
> Index: java/org/apache/catalina/startup/WebappServiceLoader.java
> ===
> --- java/org/apache/catalina/startup/WebappServiceLoader.java (revision
> 1508175)
> +++ java/org/apache/catalina/startup/WebappServiceLoader.java (working copy)
> @@ -82,10 +82,11 @@
>
> // if the ServletContext has ORDERED_LIBS, then use that to
> specify the
> // set of JARs from WEB-INF/lib that should be used for loading
> services
> -List orderedLibs = (List)
> context.getAttribute(ServletContext.ORDERED_LIBS);
> +List orderedLibs = (List)
> context.getAttribute(ServletContext.ORDERED_LIBS);
> if (orderedLibs != null) {
> // handle ordered libs directly, ...
> -for (String lib : orderedLibs) {
> +for (Object o : orderedLibs) {
> +String lib = (String) o;
> URL jarUrl = context.getResource(LIB + lib);
> if (jarUrl == null) {
> // should not happen, just ignore
>
>
>
> On Mon, Jul 29, 2013 at 12:40 PM, Mark Thomas wrote:
>
>> On 29/07/2013 21:04, Nick Williams wrote:
>>> On Jul 29, 2013, at 2:02 PM, Jeremy Boynes wrote:
>>>
>>>> This flags as a warning for me in IDEA without the suppression. Isn't
>> this
>>>> an unchecked cast (Object to List)?
>>
>> It is an unchecked cast but there is no way to avoid the cast so there
>> is no point the IDE flagging it as there is nothing the developer can do
>> to fix it. Eclipse added an option (Ignore unavoidable generic type
>> problems) not to flag issues such as this as of a recent(ish) version.
>>
>>> Yes, that's an unchecked cast. The @SuppressWarnings was not unnecessary.
>>
>> Yes, it is unchecked cast. However, the warning is pointless and
>> shouldn't have been generated in the first place.
>>
>> The Tomcat 8 code base should not exhibit any warnings with the defined
>> Eclipse settings [1]. Ditto for FindBugs and Checkstyle with the
>> provided configurations.
>>
>> The intention is to add additional checks over time although we haven't
>> added any for a while.
>>
>> Mark
>>
>>
>> http://svn.apache.org/viewvc/tomcat/trunk/res/ide-support/eclipse/java-compiler-errors-warnings.txt?view=annotate
>>
>>
>>>
>>> N
>>>
>>>>
>>>>
>>>> On Mon, Jul 29, 2013 at 11:38 AM, wrote:
>>>>
>>>>> Author: markt
>>>>> Date: Mon Jul 29 18:38:08 2013
>>>>> New Revision: 1508171
>>>>>
>>>>> URL: http://svn.apache.org/r1508171
>>>>> Log:
>>>>> Remove unnecessary @SuppressWarnings
>>>>>
>>>>> Modified:
>>>>>
>> tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
>>>>>
>>>>> Modified:
>>>>> tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
>>>>> URL:
>>>>>
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java?rev=1508171&r1=1508170&r2=1508171&view=diff
>>>>>
>>>>>
>> ==
>>>>> ---
>> tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
>>>>> (original)
>>>>> +++
>> tomcat/trunk/java/org/apache/catalina/startup/WebappServiceLoader.java
>>>>> Mon Jul 29 18:38:08 2013
>>>>> @@ -82,7 +82,6 @@ public class WebappServiceLoader {
>>>>>
>>>>>// if the ServletContext has ORDERED_LIBS, then use that to
>>>>> specify the
>>>>>// set of JARs from WEB-INF/lib that should be used for loading
>>>>> services
>>>>> -@SuppressWarnings("unchecked")
>>>>>List orderedLibs = (List)
>>>>> context.getAttribute(ServletContext.ORDERED_LIBS);
>>>>>if (orderedLibs != null) {
>>>>>// handle ordered libs directly, ...
>>>>>
>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>>>
>>>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>
>>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Using a mock framework for testing?
On Jul 31, 2013, at 11:09 AM, Jeremy Boynes wrote: > Any objection to adding a dependency on a mocking framework to aid unit > testing? > The one I have used most is EasyMock which is Apache License 2.0. > > Cheers > Jeremy EasyMock is fantastic. I use it for everything I do, and we're using it in Log4j 2. Note that EasyMock depends on CGLIB and Objenesis, both Apache License 2.0. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC1
On Aug 1, 2013, at 3:53 PM, Mark Thomas wrote: > The proposed 8.0.0-RC1 release is: > [ ] Broken - do not release > [ X] Alpha - go ahead and release as 8.0.0-RC1 alpha (Non-binding) Tested the .zip distribution on Windows 7 SP1 64-bit. Everything seems to be functioning properly. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1510210 - /tomcat/trunk/build.xml
On Aug 4, 2013, at 2:27 PM, Mark Thomas wrote: > On 04/08/2013 21:02, Jeremy Boynes wrote: >> On Aug 4, 2013, at 8:37 AM, ma...@apache.org wrote: >>> Log: >>> Treat javax.servlet.ServletContainerInitializer files as text in source >>> >>> >>> + >>> >> >> Would this work to catch all service config files not just SCIs? >> > > What other ones are you expecting to find in the Tomcat source code? > > Mark Didn't someone say something about switching to an SCI to initialize Jasper in TC8? N - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1510210 - /tomcat/trunk/build.xml
On Aug 4, 2013, at 2:40 PM, Mark Thomas wrote: > On 04/08/2013 21:31, Nick Williams wrote: >> >> On Aug 4, 2013, at 2:27 PM, Mark Thomas wrote: >> >>> On 04/08/2013 21:02, Jeremy Boynes wrote: >>>> On Aug 4, 2013, at 8:37 AM, ma...@apache.org wrote: >>>>> Log: >>>>> Treat javax.servlet.ServletContainerInitializer files as text in source >>>>> >>>>> >>>>> + >>>>> >>>> >>>> Would this work to catch all service config files not just SCIs? >>>> >>> >>> What other ones are you expecting to find in the Tomcat source code? >>> >>> Mark >> >> Didn't someone say something about switching to an SCI to initialize Jasper >> in TC8? > > Which would still match the current pattern. > > Mark Yea. I realized my stupidity right after I pressed "send." :-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1510665 [26/26] - in /tomcat/site/trunk/docs/tomcat-8.0-doc/servletapi: ./ javax/ javax/servlet/ javax/servlet/annotation/ javax/servlet/descriptor/ javax/servlet/http/ resources/
On Aug 5, 2013, at 2:10 PM, ma...@apache.org wrote: > Added: tomcat/site/trunk/docs/tomcat-8.0-doc/servletapi/serialized-form.html > URL: > http://svn.apache.org/viewvc/tomcat/site/trunk/docs/tomcat-8.0-doc/servletapi/serialized-form.html?rev=1510665&view=auto > == > --- tomcat/site/trunk/docs/tomcat-8.0-doc/servletapi/serialized-form.html > (added) > +++ tomcat/site/trunk/docs/tomcat-8.0-doc/servletapi/serialized-form.html Mon > Aug 5 19:10:09 2013 > @@ -0,0 +1,345 @@ > + "http://www.w3.org/TR/html4/loose.dtd";> > + > + > + > + > +Serialized Form (Servlet 3.0 API Documentation - Apache Tomcat > 8.0.0-RC1) > + > + > + > + > +
Re: [VOTE][RESULT] Release Apache Tomcat 8.0.0-RC1
On Aug 6, 2013, at 4:22 AM, Ognjen Blagojevic wrote: > Mark, > > On 5.8.2013 22:56, Mark Thomas wrote: >> The site has been updated with the various parts required for a new >> major release (security, migration, download, docs, navigation, which >> version etc.) but I haven't posted the release announcement yet to give >> the remaining mirrors time to sync up. > > Great job. Indeed. We've very excited over here. > BTW, on Tomcat 8 migration guide [1] there is a broken link to resources > documentation [2]. I guess, the right URL is: > > http://tomcat.apache.org/tomcat-8.0-doc/config/resources.html > > -Ognjen > > > [1] http://tomcat.apache.org/migration-8.html#Web_application_resources > [2] http://tomcat.apache.org/tomcat-8-docs/config/resources.html The migration guide says Tomcat 8 supports Expression Language 2.3. Should be 3.0. You (might) also want to call it Java Unified Expression Language. That's the "official" name from my understanding, and EL 3.0 is much more capable of being used outside of a JSP /easily/ than EL 2.3 was so the name is more fitting. Also, the migration guide says this: > To assist with the identification of these changes, the form below may be > used to view the differences between the configuration files in different > versions of Tomcat 7. However, this is not the case. I can only view the diff between 8.0.0-RC1 and trunk. I can't select earlier (7.0) versions. Nick
Re: [VOTE][RESULT] Release Apache Tomcat 8.0.0-RC1
On Aug 6, 2013, at 9:27 AM, Mark Thomas wrote: > On 06/08/2013 12:57, Nick Williams wrote: > >> The migration guide says Tomcat 8 supports Expression Language 2.3. >> Should be 3.0. You (might) also want to call it Java Unified >> Expression Language. That's the "official" name from my >> understanding, and EL 3.0 is much more capable of being used outside >> of a JSP /easily/ than EL 2.3 was so the name is more fitting. > > Fixed. Having implemented the thing, you'd think I could get the version > number right... Hah. We all do it on occasion... > >> Also, the migration guide says this: >> >>> To assist with the identification of these changes, the form below >>> may be used to view the differences between the configuration files >>> in different versions of Tomcat 7. >> >> However, this is not the case. I can only view the diff between >> 8.0.0-RC1 and trunk. I can't select earlier (7.0) versions. > > It should say 8 only. That has been fixed as well. Well that stinks. I was hoping for an easy tool to actually compare Tomcat 7 and Tomcat 8 configuration files. Guess I'll have to do it the old fashioned way. :-) N - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE][RESULT] Release Apache Tomcat 8.0.0-RC1
On Aug 6, 2013, at 9:53 AM, Mark Thomas wrote: > On 06/08/2013 16:30, Nick Williams wrote: >> >> On Aug 6, 2013, at 9:27 AM, Mark Thomas wrote: >> >>> On 06/08/2013 12:57, Nick Williams wrote: >>> >>>> The migration guide says Tomcat 8 supports Expression Language 2.3. >>>> Should be 3.0. You (might) also want to call it Java Unified >>>> Expression Language. That's the "official" name from my >>>> understanding, and EL 3.0 is much more capable of being used outside >>>> of a JSP /easily/ than EL 2.3 was so the name is more fitting. >>> >>> Fixed. Having implemented the thing, you'd think I could get the version >>> number right... >> >> Hah. We all do it on occasion... >> >>> >>>> Also, the migration guide says this: >>>> >>>>> To assist with the identification of these changes, the form below >>>>> may be used to view the differences between the configuration files >>>>> in different versions of Tomcat 7. >>>> >>>> However, this is not the case. I can only view the diff between >>>> 8.0.0-RC1 and trunk. I can't select earlier (7.0) versions. >>> >>> It should say 8 only. That has been fixed as well. >> >> Well that stinks. I was hoping for an easy tool to actually compare Tomcat 7 >> and Tomcat 8 configuration files. Guess I'll have to do it the old fashioned >> way. :-) > > Insert standard advice about not using Tomcat x-y config files with > tomcat x (where y > 0) > > Take the svn command line example and adjust the paths as necessary and > you can easily compare 7.0.something to 8.0.something. Yep. That's what I meant by "the old fashioned way." ;-) Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Use (or not) of @SuppressWarnings
On Aug 7, 2013, at 2:41 AM, Mark Thomas wrote: > For trunk we have been running a policy of zero warnings in the code. > This has helped to highlight issues as code is edited as any warnings > are immediately clear. Obviously, this depends on what warnings are enabled. > > Currently, we use Eclipse's "Ignore unavoidable generic type problems." > Recently a couple of issues has been highlighted with this: > 1. Other IDEs might not have this setting. > 2. javac does not have this setting > 3. Some of the problems Eclipse excludes are avoidable (well, sort of > avoidable as avoiding them requires using JRE methods that themselves > have @SuppressWarnings annotations). > > In favour of the current situation is that it reduces clutter in the > code base slightly. > > While I am all for reducing clutter in the code base, there do appear to > be good reasons for disabling the "Ignore unavoidable generic type > problems." and using @SuppressWarnings instead. > > Personally, I am happy with the current settings but not unhappy to > change. I guess that makes me +0 on changing. What does everyone else think? (Non-binding) As stated earlier, I am fundamentally opposed to the concept of using an IDE-specific setting to decide how a project writes code. This practically forces all developers to use that IDE exclusively for that project. If I'm writing Tomcat code in IntelliJ IDE and I create a warning, I have no idea whether I should correct the warning or not, because I have no idea what Eclipse has to say about it. I do, however, know that the warning will show up when I compile, and I think that's what matters most. We should make efforts to eliminate all warnings that show up when we compile, whether Eclipse calls them "unavoidable" or not. My $0.02. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Code style rules: Line length
On Aug 8, 2013, at 12:50 PM, Mark Thomas wrote: > Currently, Tomcat has an 'guide' of a maximum of 80 characters for line > length. It has been a while since we reviewed this and as we are looking > at style rules... > > As a starting point what do folks think of the following options: > > Line length: > 80 - the current > 100 - > 120 - I'm for 120. Every single other OSS project I work on is 120. Tomcat is the only thing that's less. > Strictness > Informal - the current > Enforce - Use checkstyle to enforce whatever limit is chosen I'm for enforcing. That's another place Tomcat is different from other OSS I work on. The current informal policy is actually more of a pain than I thought it would be. Instead of having a hard rule you know you can depend on, you never know whether someone is going to complain about a line or two being to long in a patch. Often, it varies depending on which committer reviews the patch. > Pros for longer lines: > - code easier to read > > Cons > - diffs may wrap in mail clients I hope nobody is still reading mail at 800x600. ;-) > - harder to work with code in a pure text interface (particularly if > that interface is limited in width to 80 chars) True, but FYI, if I open a terminal window on my Mac or on any of the Linux distros I use, the width defaults to 140-180 characters. Plenty. Nick > Comment > - With increasing screen resolution I expect IDEs to manage widths upto > 120 or possibly even more > - Few (any?) folks will ever need to work in a pure text UI where the > line length is limited > - My only concern is readability of diffs > > I have no strong preference on line length but if we do opt for a longer > length I'd like to see checkstyle enforce the limit. > > Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Back-porting JSR-356 implementation to 7.0.x
On Aug 15, 2013, at 5:47 PM, Mark Thomas wrote: > This isn't going to be quite as simple as I first thought. > > The WebSocket client API requires Java SE 7 or later. > The WebSocket server API requires Java EE 6 or later. > Java EE 6 requires Java 6 or later. > The WebSocket server API depends on the WebSocket client API. > > The WebSocket client implementation makes extensive use of new Java 7 > non-blocking IO features. > > My conclusion from the above is that the back-port is going to require > Java 7. That begs the question how to do that while keeping the main > build Java 6 based. > > My (untested) plan is as follows: > - Create a WebSocket module > - Back-port (i.e. copy) the trunk code to that module > - Build just that module with Java 7 > - Make the minimum changes necessary to get it to work > - Modify the back-ported SCI so it only adds the filter if Java 7 is > detected (going to need to ensure the SCI is executable on Java 6) > - Ship Tomcat 7 with the WebSocket JARs > > Comments? Sounds workable. Not ideal. But workable. Getting the SCI compiled to be executable shouldn't be a problem. Just compile the module -source 1.6 -target 1.6 on Java 7. As long as you don't use Java 7 language features, you can still compile against the APIs. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Using log4j under a security manager
On Aug 17, 2013, at 7:36 AM, Christopher Schultz wrote: > All, > > See this SO thread: > http://stackoverflow.com/questions/18147885/use-log4j-in-a-tomcat-with-security-manager > > ...and refer to the Tomcat 7 log4j instructions: > > http://tomcat.apache.org/tomcat-7.0-doc/logging.html#Using_Log4j > > ...for context. > > It looks like (the original) bin/tomcat-juli.jar is not given > permissions in conf/catalina.policy to read bin/log4j.properties. So, if > one follows the instructions for Tomcat/log4j from the link above, and > runs under a security manager, the logging system will throw a > SecurityException. > > Should we modify catalina.policy to allow bin/tomcat-juli.jar to read > lib/log4j.properties (and possibly newer config files such as > lib/log4j.xml), or should we add an instruction in the documentation for > doing that? And log4j2.xml. That's the new one. However, I actually think documentation is what's needed here. I favor just doing that over adding a default allowance. > On the one hand, it might be nice if it "just worked" with fewer steps > to follow. On the other hand, running such that read-access to > conf/log4j.properties|xml when not needed could be considered a (very > minor) security risk. > > Separately, in Tomcat's logging instructions, item #4 says that if you > want to use log4j globally, you should put the new tomcat-juli.jar into > the conf/ directory instead of bin/. There is no commentary about what > to do with the original bin/tomcat-juli.jar... if I were following the > instructions, I would leave the original in place, but that does not > really sound appropriate to me. What is the proper technique to use > log4j for both Tomcat and webapp logging? > > Thanks, > -chris > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1515779 - /tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
On Aug 20, 2013, at 6:14 AM, ma...@apache.org wrote: > Author: markt > Date: Tue Aug 20 11:14:39 2013 > New Revision: 1515779 > > URL: http://svn.apache.org/r1515779 > Log: > Add the rather crucial missing i++ in the wait loop Lol. Don't you hate when you do that? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1515779 - /tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
On Aug 20, 2013, at 7:59 AM, Mark Thomas wrote: > On 20/08/2013 13:45, Nick Williams wrote: >> >> On Aug 20, 2013, at 6:14 AM, ma...@apache.org wrote: >> >>> Author: markt >>> Date: Tue Aug 20 11:14:39 2013 >>> New Revision: 1515779 >>> >>> URL: http://svn.apache.org/r1515779 >>> Log: >>> Add the rather crucial missing i++ in the wait loop >> >> Lol. Don't you hate when you do that? > > Yep. What I really hate is that I always spot this sort of thing just a > fraction of a second too late to cancel the commit. Hey, that's already better than me. Sometimes I don't spot it until after an hour of debugging. ;-) N - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Need guidance for writing unit tests for 55317
I'm working on implementing bugzilla 55317. It's a pretty important change (weaving) to a pretty import class (WebappClassLoader), so it obviously needs some unit tests. However, I need some guidance: 1) I've never gotten all the existing tests to pass on my machine. Last time I ran them it took 45 minutes (holy crap) and about 1/3 of them failed. This is obviously something wrong with my configuration and not with Tomcat. I'd like to avoid running all tests for this reason and only run the particular tests I'm working on. How would I do this? Is this even possible with Ant? 2) I'm not sure exactly how to approach testing this particular feature. It's obviously not completely straightforward. This is weaving we're talking about, so somehow I have to load a class and weave it to test that it's properly woven. Suggestions on where to get started / what tools to use? As much as I hate it, part of me is saying that functional testing is really the best course here, in which case this is all moot. 3) I'm not even sure how to approach testing in Tomcat in general. I've seen a lot of "unit tests" that look more like integration tests, at least according to my training. Are there general guidelines for writing "correct" unit tests in Tomcat, or is in generally accepted as long as it passes? Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
On Aug 20, 2013, at 8:25 AM, Mark Thomas wrote: > On 20/08/2013 14:13, Nick Williams wrote: >> I'm working on implementing bugzilla 55317. It's a pretty important >> change (weaving) to a pretty import class (WebappClassLoader), so it >> obviously needs some unit tests. However, I need some guidance: >> >> 1) I've never gotten all the existing tests to pass on my machine. >> Last time I ran them it took 45 minutes (holy crap) and about 1/3 of >> them failed. This is obviously something wrong with my configuration >> and not with Tomcat. I'd like to avoid running all tests for this >> reason and only run the particular tests I'm working on. How would I >> do this? Is this even possible with Ant? > > ant test -Dtest.entry=org.apache.catalina.TestClassToExecute Ahhh. Thanks! I somehow missed that when reading BUILDING.txt. Or, rather, more likely forgot, since I read it several months ago. > svn co ... > ant clean test > > should work on Windows, Linux and OSX for all three connectors. > > There are some tests that are 'fragile'. They need some time spent on > them to figure out if they fail because the tests have a subtle timing > bug (like the one I fixed this morning) or if the code does. > > One or two failures wouldn't surprise me. 1/3 failing suggests a problem > with the environment. Agreed. The environment is Windows 7 Pro SP 1 64-bit running Java 8 beta 64-bit. Could be a Java 8 issue. Could be a setup issue. Could be a number of other things. I'll try to troubleshoot it more once Java 8 is more stable. FWIW, only one or two tests failed on Java 7 64-bit on my Mac OS X Lion environment. >> 2) I'm not sure exactly how to approach testing this particular >> feature. It's obviously not completely straightforward. This is >> weaving we're talking about, so somehow I have to load a class and >> weave it to test that it's properly woven. Suggestions on where to >> get started / what tools to use? As much as I hate it, part of me is >> saying that functional testing is really the best course here, in >> which case this is all moot. > > Using weaving to add functionality that is easily tested to see if it is > present? Well, yea. I had figured that part out. :-) I just didn't articulate my question well enough. The first step is obviously loading the class through the WACL through the unit test (so this has to be a class not already loaded). I assume I'll figure this part out reading through the existing WACL tests. But the key is *how* to use weaving in the context of the Tomcat unit tests. The way I see it I essentially have two options (though I may be overlooking something): 1) Manually manipulate the bytes. This takes great expertise and is ripe for failure. Not a big fan of the idea. 2) Introduce an additional test-time dependency on something like ASM. This is probably the safest route, but it introduces an additional test-time dependency. I don't know how amenable y'all are to that. >> 3) I'm not even sure how to approach testing in Tomcat in general. >> I've seen a lot of "unit tests" that look more like integration >> tests, at least according to my training. Are there general >> guidelines for writing "correct" unit tests in Tomcat, or is in >> generally accepted as long as it passes? > > Ideally, they should look like unit tests but a lot of the Tomcat code > is not suited to that style of testing. There is nothing wrong with a > little refactoring to aid testing but obviously there is a balance to > strike. > > Any test that a) provides value and b) passes is likely to be accepted. Thanks. That helps. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
