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 ma...@apache.org: 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: [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. snip / 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
Re: [VOTE] Release Apache Tomcat 8.0.1
Looks good! On Jan 29, 2014, at 5:43 PM, Mark Thomas wrote: snip / [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. snip / 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=1542836r1=1542835r2=1542836view=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: 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. snip / 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=1539036r1=1539035r2=1539036view=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: [VOTE] Release Apache Tomcat 7.0.44
On Sep 24, 2013, at 11:00 AM, Rossen Stoyanchev wrote: On Tue, Sep 24, 2013 at 11:40 AM, Mark Thomas ma...@apache.org wrote: The necessary update to the script that uploads those JARs to the Maven repo was missed. I think I have fixed it locally but need to test it from somewhere with connectivity. Unless the JavaOne Wifi is significantly better than yesterday that won't be for a few hours. I'll run tests when this is available. S, does that mean this vote is cancelled, too? Nick smime.p7s Description: S/MIME cryptographic signature
OT: Adding Filters and odd WebLogic Behavior
This is very off topic, and for that I apologize. I'm working on fixing a bug in Log4j 2, and we've discovered something that just doesn't make any sense to me. I /believe/ it's a problem with WebLogic's implementation of the Servlet 3.0 specification, but I could be wrong, and based on my previous experience trying to communicate with WebLogic support, I figured I'd solicit some feedback from the Servlet spec experts on this list to see if I'm in the wrong before I try to bark up that tree again. What we discovered is that if you add a filter programmatically using addFilter(String filterName, String className) or addFilter(String filterName, Class? extends Filter filterClass), everything works fine. The filter's init method is called during application startup, it is invoked in the proper place in the chain, and the destroy method is called during application shutdown, all in the right order. However, if you add the filter using addFilter(String filterName, Filter filter), this is not the case. The filter _is_ still invoked in the proper place in the chain, but its init method is _never_ called. WebLogic ignores the init method completely. The destroy method, however, _is_ still called on application shutdown. Again, this is the _WebLogic_ behavior. I have not been able to duplicate this in Tomcat. Tomcat appears to function the same no matter which method I use to add the filter. Furthermore, I can't find anything in the spec that would support WebLogic's behavior. One thought thrown out was that WebLogic assumed you had already called the init method since you were passing in an instance, but I don't see anything in the spec that supports such an assumption. Am I missing something? Or is WebLogic broken here, as I suspect? Thanks, Nick (BTW, thankfully it doesn't matter to us which method we use, so we're just switching to a different method. But if it's a problem, WebLogic still needs to fix it.) smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Release Apache Tomcat 7.0.43
On Sep 21, 2013, at 6:07 AM, Konstantin Kolinko wrote: 2013/9/21 Mark Thomas ma...@apache.org: On 20/09/2013 08:38, Violeta Georgieva wrote: The proposed Apache Tomcat 7.0.43 release is now available for voting. This release candidate contains JSR-356 Java WebSocket 1.0 implementation. Note that use of this functionality requires Java 7. It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.43/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-082/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_43/ It is a bit inconvenient that since r1515813 Tomcat 7 now has examples only for the new JSR-356 WebSocket API, but not for the legacy Tomcat 7 WebSocket API. It is not a stopper, but it'd be better to have both to be able to smoke-test that both implementations are working. While I do agree with this, it also seems to me to be a bad idea to have samples for using a deprecated API. I think I would have to lean toward de-emphasizing a deprecated API being more important. Nick smime.p7s Description: S/MIME cryptographic signature
Re: SCI discovery ordering
On Sep 20, 2013, at 4:33 PM, Jeremy Boynes wrote: On Fri, Sep 20, 2013 at 8:50 AM, Mark Thomas ma...@apache.org wrote: On 20/09/2013 16:02, Jeremy Boynes wrote: The only ordering concern for SCIs in the spec is that they are discovered following the classloader delegation model. This will typically be configured to load application classes first, something r1524727 does not do. The intention of the language around discovery is to clarify the expected behaviour when both the container and the application provide an implementation of the same SCI. As with any other class, the delegation model adopted by the application must be used. It has no bearing on the order in which one SCI implementation is loaded with respect to another SCI. It has no bearing on the order in which one SCI implementation is invoked with respect to another SCI. r1524727 is fully compliant with the Servlet spec. Thanks for clarifying. It still leaves the issue related to ordering and also to duplicate functionality. For example, if both the application and the container use an SCI to bootstrap JAX-WS functionality, which should be used? The deployer can exclude the implementation in the application (using absolute ordering) but she cannot make that usable in preference to the one in the container unless they happen use the same implementation and SCI class. There is no mechanism to exclude the implementation provided by the container and use an equivalent but different mechanism included in the application. The SCIs we use (JSP and WS) are independent and can be called in any order. The same is true of Spring's SCI itself. What triggered this issue is application code being called by Spring's SCI that adds an implicit coupling to WS, whereas WS says the application should be using a listener. To date, there is no presumption of ordering of SCI invocation in the spec and so frameworks need to code defensively. I agree this is a burden on the framework and limits the deployer's flexibility. To address that I'm saying we need a more sophisticated mechanism for ordering/excluding SCIs akin to (but separate from) that used for ordering fragments. Do you see any issue with such a mechanism? https://java.net/jira/browse/SERVLET_SPEC-79 My proposal in that issue, which I stand by, is to use web-fragment ordering for SCI ordering. Importantly, this supports ordering without changing the API or XML schema, so Servlet 3.0 and 3.1 can be *encouraged* to implement SCI ordering retroactively. I've already convinced the Jetty team to take the same approach Tomcat is taking. JBoss, WebLogic, and WebSphere already use web-fragment ordering. N smime.p7s Description: S/MIME cryptographic signature
Re: SCI discovery ordering
On Sep 19, 2013, at 11:32 AM, Jeremy Boynes wrote: On Sep 19, 2013, at 8:36 AM, Mark Thomas ma...@apache.org wrote: On 19/09/2013 16:31, Jeremy Boynes wrote: On Sep 19, 2013, at 6:07 AM, ma...@apache.org wrote: Author: markt Date: Thu Sep 19 13:07:02 2013 New Revision: 1524727 URL: http://svn.apache.org/r1524727 Log: Always load container SCIs first This seems at odds with the requirement that the order in which these services are discovered MUST follow the application’s class loading delegation model which is independent of orderedLibs. If we base this on ServiceLoader, which seems to be the intent, the algorithm would be: Nope. See the discussion on the users list. There is a clear need for container defined SCIs to be executed first and there is nothing (yet) in the Servlet spec that places any constraints on SCI execution order. There's a clear model already without assumptions about SCI ordering: SCIs fire before SCLs, and SCLs can be ordered explicitly by web.xml. There are no ordering requirements for SCIs except that they are discovered per the delegation model. This change is changing that to load container SCIs firsts *even if the delegation model specifies application first.* Loading/discovering SCIs and invoking SCIs are not the same thing. This change is spec compliant because it still loads/discovers SCIs per the delegation model. The spec does NOT say that SCIs must be ordered according to the delegation model (or even that they must be ordered in any fashion at all). The original issue was that a context attribute was not set when an SCI was run (or actually, as a application class invoked by Spring's SCI was run). As Konstantin pointed out, there is no issue here if that code is run from an SCL rather than the SCI. I argue this is an application issue rather than something the container needs to enforce in a proprietary manner. It is similar to JSP land where Jasper's SCI can only register TLD listener or JSP servlet classes with the context rather than actually instantiating them. Further, running container SCIs first may interfere with application SCIs that would be discovered first - for example, an application should be able to provide an SCI that initialized a WebSocket or JSP implementation separate from the container's and which, because it would be first in delegation order, would take precedence over the container's. I agree 3.2 should clarify the ordering requirements for SCIs even if it just explicitly states there are no ordering guarantees or that they will be fired in the order discovered through the classloader. Until then though it should be on applications to code defensively on the assumption they may be fired in any order. smime.p7s Description: S/MIME cryptographic signature
Where to put a helper class for test?
Mark, I'm working on revisions to my patch for BZ 55317 based on your feedback. In this feedback you said: 5. I'm not a fan of the org.apache.tomcat.unittest package unless the classes concerned are going to be used by multiple tests across multiple packages. I put org.apache.tomcat.unittest.weaving.NeverUsedClass and org.apache.tomcat.unittest.weaving.UnweavedClass in this package because it seemed like a location that helper classes were being placed for other tests. However, I see your point about them only being used for one class. Should I just put these classes in org.apache.catalina.loader, the same package that TestWebappClassLoaderWeaving is in? Thanks, Nick smime.p7s Description: S/MIME cryptographic signature
Re: Where to put a helper class for test?
On Sep 12, 2013, at 1:03 PM, Mark Thomas wrote: On 12/09/2013 18:31, Nick Williams wrote: Mark, I'm working on revisions to my patch for BZ 55317 based on your feedback. In this feedback you said: 5. I'm not a fan of the org.apache.tomcat.unittest package unless the classes concerned are going to be used by multiple tests across multiple packages. I put org.apache.tomcat.unittest.weaving.NeverUsedClass and org.apache.tomcat.unittest.weaving.UnweavedClass in this package because it seemed like a location that helper classes were being placed for other tests. However, I see your point about them only being used for one class. Should I just put these classes in org.apache.catalina.loader, the same package that TestWebappClassLoaderWeaving is in? That is the normal convention. Convention is also that they start Tester... so they are excluded from the unit test scan. Mark Okay. So I should rename the classes: org.apache.catalina.loader.TesterNeverUsedClass org.apache.catalina.loader.TesterUnweavedClass Did I understand that correctly? Nick smime.p7s Description: S/MIME cryptographic signature
Re: [Bug 55317] Facilitate weaving by allowing ClassFileTransformer to be added to WebppClassLoader
On Aug 29, 2013, at 4:28 AM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=55317 --- Comment #16 from Mark Thomas ma...@apache.org --- (In reply to Nick Williams from comment #15) Created attachment 30749 [details] Proposed implementation of this feature 1. Why loop over list rather than using contains() in addTransformer() ? 2. Should addTransformer() be looking for multiple instances of the same Transformer or multiple instances of the same class of Transformer? 3. Why not use List.remove(Object) in removeTransformer() ? 4. I'm concerned that synchronizing on the list of transformers while classes are transformed will become a bottleneck when lots of classes are being loaded and the transformer is relatively slow. A separate ReadWriteLock for the transformer list is probably the way to go but really some testing is required to determine if there is an issue here or not. 5. I'm not a fan of the org.apache.tomcat.unittest package unless the classes concerned are going to be used by multiple tests across multiple packages. FYI, I replied to your comments and submitted a revised patch. It doesn't appear that Bugzilla sent out an email this time. Not sure what happened, but I wanted to make sure you were notified somehow so that you could take a look. Nick smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r1521817 - /tomcat/tc6.0.x/trunk/STATUS.txt
On Sep 11, 2013, at 9:22 AM, Konstantin Kolinko wrote:
2013/9/11 Mark Thomas ma...@apache.org:
On 11/09/2013 14:44, Konstantin Kolinko wrote:
2013/9/11 ma...@apache.org:
Author: markt
Date: Wed Sep 11 11:59:37 2013
New Revision: 1521817
URL: http://svn.apache.org/r1521817
Log:
Comment
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1521817r1=1521816r2=1521817view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Sep 11 11:59:37 2013
@@ -103,6 +103,10 @@ PATCHES PROPOSED TO BACKPORT:
I think @Target change for @DenyAll is wrong.
Looking at Geronimo, @DenyAll has @Target({ElementType.METHOD}) in
CA 1.0 there.
It is @Target({ElementType.TYPE, ElementType.METHOD}) starting with
CA 1.1.
+ markt:
+ The CA 1.0 spec section 2.11 is explicit that DenyAll is permitted on
+ classes. Geronimo and whatever source was used generate the official
Java
+ EE 5 Javadoc are wrong.
Ah, I see it.
Nevertheless, it looks to me that it is not just a typo, but a genuine
error, that was corrected in CA 1.1. It is mentioned in changelog,
http://jcp.org/aboutJava/communityprocess/maintenance/jsr250/250ChangeLog.html
- Maintenance Review 1, - 2. Change the definition of the
@DenyAll annotation
That looks like a Javadoc / implementation correction to me. The EG's
aren't always very good at keeping spec issues and RI issues separate.
Unless there is some evidence in mailing lists elsewhere, I think the
question is which version of the class would pass a TCK. I think that
Geronimo classes might have been tested better, than ones in Tomcat.
If the Tomcat version failed a TCK, I'd challenge the failure on the
grounds of the CA 1.0 spec section 2.11.
I would like to see either someone encountering and reporting this
issue in Tomcat 6,
or some existing implementation of CA 1.0 that has this change.
I do not see enough grounds to change this class in Tomcat 6 now, It is
legacy.
Just googling, trying to find whether others noted this issue.
http://www.oracle.com/technetwork/articles/javaee/security-annotation-142276.html
does not have 'X' in @DenyAll vs. TYPE cell in a table.
http://pic.dhe.ibm.com/infocenter/rsawshlp/v7r5m0/index.jsp?topic=%2Fcom.ibm.jee5.doc%2Ftopics%2Ftsecuringejee.html
does not say that @DenyAll can be used at type level
Some more info that might be helpful:
1) Fixed in GlassFish v3 on April 29, 2009:
https://java.net/jira/browse/GLASSFISH-8045
2) Checkout out GlassFish v2 source and DenyAll is METHOD only. Not TYPE. It
was never fixed in v2.
Now, with that said, I agree with Mark. If a TCK failed because of DenyAll
having TYPE, I would challenge it. The spec clearly says it should have TYPE.
This change would make Tomcat 6 the only compliant implementation.
The question is, are there any *downsides* to being strictly spec compliant
here? I don't see any. So the annotation is available for TYPE when other
implementations don't allow it? That's not going to break any application code
trying to run on Tomcat.
It's *correct.* I say we go with it.
smime.p7s
Description: S/MIME cryptographic signature
Re: svn commit: r1521594 [1/16] - in /tomcat/site/trunk: docs/ docs/images/ docs/stylesheets/ xdocs/images/ xdocs/stylesheets/
On Sep 10, 2013, at 4:34 PM, Christopher Schultz wrote: Mark, On 9/10/13 3:21 PM, ma...@apache.org wrote: Author: markt Date: Tue Sep 10 19:21:22 2013 New Revision: 1521594 It's amazing how a relatively small number of changes can take a page from 1996 to ... well, at least 2006. :) +1 smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r1521023 - in /tomcat/trunk/java: javax/annotation/Generated.java javax/annotation/Resource.java org/apache/catalina/startup/WebAnnotationSet.java
On Sep 9, 2013, at 5:24 AM, Mark Thomas wrote: On 09/09/2013 11:20, Mark Thomas wrote: On 09/09/2013 11:09, ma...@apache.org wrote: Author: markt Date: Mon Sep 9 10:09:36 2013 New Revision: 1521023 URL: http://svn.apache.org/r1521023 Log: Fix wrongly named annotation attributes Modified: tomcat/trunk/java/javax/annotation/Generated.java This one is OK. tomcat/trunk/java/javax/annotation/Resource.java This one I am less sure about. The JavaEE 5 Javadoc uses authentication but JavaEE 6 onwards uses authenticationType with no indication that there has been a change. I need to dig into the specifications to see what is going on. The specification says authenticationType. I'll revert this change. It looks like a bug in whatever implementation was used to generate the Javadoc. Is there somewhere you can/should/did report this problem with the Oracle-published EE 6 Javadoc? Seems like the published version should be corrected, but I'm not sure how easy it is to actually make that happen. Nick smime.p7s Description: S/MIME cryptographic signature
Re: [Bug 55317] Facilitate weaving by allowing ClassFileTransformer to be added to WebppClassLoader
On Aug 21, 2013, at 6:21 PM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=55317 Nick Williams nicho...@nicholaswilliams.net changed: What|Removed |Added Attachment #30748|0 |1 is obsolete|| --- Comment #15 from Nick Williams nicho...@nicholaswilliams.net --- Created attachment 30749 -- https://issues.apache.org/bugzilla/attachment.cgi?id=30749action=edit Proposed implementation of this feature Can I get some feedback on the patch I submitted last week? It comes with 10 unit tests and passes all check style checks. Thanks, Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 55317] Facilitate weaving by allowing ClassFileTransformer to be added to WebppClassLoader
On Aug 28, 2013, at 9:07 AM, Mark Thomas wrote: On 28/08/2013 13:36, Nick Williams wrote: On Aug 21, 2013, at 6:21 PM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=55317 Nick Williams nicho...@nicholaswilliams.net changed: What|Removed |Added Attachment #30748|0 |1 is obsolete|| --- Comment #15 from Nick Williams nicho...@nicholaswilliams.net --- Created attachment 30749 -- https://issues.apache.org/bugzilla/attachment.cgi?id=30749action=edit Proposed implementation of this feature Can I get some feedback on the patch I submitted last week? It comes with 10 unit tests and passes all check style checks. I don't see any review of the proposed changes by anyone from Spring. Yep. I'm trying to get Juergen to take a look at it, which he said he would, but sometimes he can take a few weeks to respond to things. He's a very busy guy. I was hoping for a review from some Tomcat folks in the meantime, in case there's something that I need to correct that I can take care of before Juergen gets around to reviewing it. Nick smime.p7s Description: S/MIME cryptographic signature
Re: Need guidance for writing unit tests for 55317
On Aug 21, 2013, at 2:58 AM, Mark Thomas wrote: On 21/08/2013 01:24, Nick Williams wrote: My backup idea is slightly less clean but, IMO, still more clean than adding ASM as a test-time dependency and trying to figure all of that out. I locally compiled fake weaved versions of the UnweavedClass (with the modified behavior) and then translated each version into a Java byte array definition. (These are extremely simple on-line, one-method classes, so the byte arrays are relatively short.) I then simply embedded the byte array definitions as static final byte[] fields the test class and replaced the byte code in my fake transformer with those embedded fields' content. I've tested this and it works great. Here's what the embedded byte code for the fake weaved classes looks like. What do you think? Is this acceptable? Works for me. It is pretty much exactly what I was going to suggest as I read your mail. My only request would be to keep the class (and hence the byte code) as short as possible. Yep! One method that returns a String, has no arguments, and contains one line of code (the return statement) is about as simple as it gets! :-) Thanks, Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
On Aug 21, 2013, at 6:14 AM, Mark Thomas wrote: I'm not exactly sure what the problem is. It looks like the WebSocket SCI is being registered twice or is running twice but I can't reproduce the problem. Anyone got any ideas? Currently, my plan is to add some logging to the SCI registration code to see what triggers each registration of each SCI. I'd add it as an info log message and then drop it to debug once this issue has been resolved. If you can't duplicate it locally, I don't see any other option but the temporary logging. Gotta figure it out somehow. N - 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 21, 2013, at 12:46 PM, sebb wrote: On 21 August 2013 14:48, Christopher Schultz ch...@christopherschultz.net wrote: Nick, On 8/20/13 8:24 PM, Nick Williams wrote: I ran in to a roadblock with this idea. Part of the byte code of a class includes the fully-qualified class name. If I create a class, say UnweavedClass, and replace its byte code in my fake transformer with that of another class, the FQCN changes. This results in a NoClassDefFoundError because the class loader is looking for UnweavenClass in be in the byte code when really some other class is. My backup idea is slightly less clean but, IMO, still more clean than adding ASM as a test-time dependency and trying to figure all of that out. I locally compiled fake weaved versions of the UnweavedClass (with the modified behavior) and then translated each version into a Java byte array definition. (These are extremely simple on-line, one-method classes, so the byte arrays are relatively short.) I then simply embedded the byte array definitions as static final byte[] fields the test class and replaced the byte code in my fake transformer with those embedded fields' content. I've tested this and it works great. Any reason not to simply compile some .java source into a .class file and read it from the disk instead of shoving it into a byte array? There's nothing stopping you from doing an offline-compile of a .java file into a .class file and committing both to svn. You don't have to compile the .java source as part of the test -- just load it off disk as part of the test. This will allow easier inspection of the .class file, and not be such a pain in the neck to change the bytecode if necessary. Is there any mileage in using the features of JSR199? That would require a bit more code than the current solution Mark and I agreed on. The approach I took was the simplest approach possible, IMO. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Can't build from trunk anymore -- problems with DBCP2
I have latest-ish from trunk ( 2 days old) and compiled without issue. When I tried to run it, however, console output indicates a serious issue creating DataSource resources: 21-Aug-2013 17:18:30.800 WARNING [localhost-startStop-1] org.apache.catalina.core.NamingContextListener.addResource Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory] 21-Aug-2013 17:18:30.800 WARNING [localhost-startStop-1] org.apache.catalina.core.NamingContextListener.addResource Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory] 21-Aug-2013 17:18:30.801 WARNING [localhost-startStop-1] org.apache.catalina.core.NamingContextListener.addResource Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory] 21-Aug-2013 17:18:30.802 WARNING [localhost-startStop-1] org.apache.catalina.core.NamingContextListener.addResource Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory] Looks like it can't find the new org.apache.tomcat.dbcp.dbcp2 classes. I looked in the tomcat-dbcp JAR and the package in it is org.apache.tomcat.dbcp.dbcp, not org.apache.tomcat.dbcp.dbcp2. I figured it was just a problem with not building cleanly enough. So a ran `ant clean` and then deleted all the external dependencies that it had downloaded (commons-dbcp, commons-pool, ejc, etc.). I ran ant again to build and it got almost to the very end of the build process and blurted out this: build-manifests: [mkdir] Created dir: C:\Tomcat-Build\Source\output\manifests [copy] Copying 19 files to C:\Tomcat-Build\Source\output\manifests build-tomcat-dbcp: BUILD FAILED C:\Tomcat-Build\Source\build.xml:2581: C:\Tomcat-Build\Base\commons-pool-1.5.7-src\src\main does not exist. Total time: 46 seconds I confirmed that it DID re-download Commons DBCP and Commons Pool. It re-downloaded all of its dependencies. However, Commons DBCP wasn't 2.0 like I expected it to be. It was 1.4. And the C:\Tomcat-Build\Base\commons-pool-1.5.7-src\src\main directory indeed does not exist, but C:\Tomcat-Build\Base\commons-pool-1.5.7-src\src\java does. I have built Tomcat hundreds of times in the last eight months (admittedly not once since RC1 came out). This is the first time I've seen this error or anything like it. Am I missing something obvious here? Or is something badly broken in the build? Looks like a big problem with the new DBCP2 stuff. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Can't build from trunk anymore -- problems with DBCP2
On Aug 21, 2013, at 5:32 PM, Nick Williams wrote: I have latest-ish from trunk ( 2 days old) and compiled without issue. When I tried to run it, however, console output indicates a serious issue creating DataSource resources: 21-Aug-2013 17:18:30.800 WARNING [localhost-startStop-1] org.apache.catalina.core.NamingContextListener.addResource Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory] 21-Aug-2013 17:18:30.800 WARNING [localhost-startStop-1] org.apache.catalina.core.NamingContextListener.addResource Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory] 21-Aug-2013 17:18:30.801 WARNING [localhost-startStop-1] org.apache.catalina.core.NamingContextListener.addResource Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory] 21-Aug-2013 17:18:30.802 WARNING [localhost-startStop-1] org.apache.catalina.core.NamingContextListener.addResource Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory] Looks like it can't find the new org.apache.tomcat.dbcp.dbcp2 classes. I looked in the tomcat-dbcp JAR and the package in it is org.apache.tomcat.dbcp.dbcp, not org.apache.tomcat.dbcp.dbcp2. I figured it was just a problem with not building cleanly enough. So a ran `ant clean` and then deleted all the external dependencies that it had downloaded (commons-dbcp, commons-pool, ejc, etc.). I ran ant again to build and it got almost to the very end of the build process and blurted out this: build-manifests: [mkdir] Created dir: C:\Tomcat-Build\Source\output\manifests [copy] Copying 19 files to C:\Tomcat-Build\Source\output\manifests build-tomcat-dbcp: BUILD FAILED C:\Tomcat-Build\Source\build.xml:2581: C:\Tomcat-Build\Base\commons-pool-1.5.7-src\src\main does not exist. Total time: 46 seconds I confirmed that it DID re-download Commons DBCP and Commons Pool. It re-downloaded all of its dependencies. However, Commons DBCP wasn't 2.0 like I expected it to be. It was 1.4. And the C:\Tomcat-Build\Base\commons-pool-1.5.7-src\src\main directory indeed does not exist, but C:\Tomcat-Build\Base\commons-pool-1.5.7-src\src\java does. I have built Tomcat hundreds of times in the last eight months (admittedly not once since RC1 came out). This is the first time I've seen this error or anything like it. Am I missing something obvious here? Or is something badly broken in the build? Looks like a big problem with the new DBCP2 stuff. Nevermind, please disregard. I had leftover build properties files that I hadn't refreshed in a while. Learned that lesson the hard way... Nick - 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
Re: Need guidance for writing unit tests for 55317
On Aug 20, 2013, at 10:12 AM, Christopher Schultz wrote: Mark, On 8/20/13 9: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 svn co ... ant clean test should work on Windows, Linux and OSX for all three connectors. 1/3 of the tests will fail if the native connector hasn't been built. Could that be your problem, Nick? If the native connector doesn't get built by running ant clean test, then yes, that could very well be my problem. 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 1:10 PM, Mark Thomas wrote:
On 20/08/2013 18:47, Nick Williams wrote:
My remaining original concern was the best approach for weaving byte
code in Tomcat's unit tests, which I detailed in an earlier message.
Use the Weaver to completely replace the byte code of the weaved class
with the byte code from another class? That way the compiler creates the
byte code so you know it is valid.
I ran in to a roadblock with this idea. Part of the byte code of a class
includes the fully-qualified class name. If I create a class, say
UnweavedClass, and replace its byte code in my fake transformer with that of
another class, the FQCN changes. This results in a NoClassDefFoundError because
the class loader is looking for UnweavenClass in be in the byte code when
really some other class is.
My backup idea is slightly less clean but, IMO, still more clean than adding
ASM as a test-time dependency and trying to figure all of that out. I locally
compiled fake weaved versions of the UnweavedClass (with the modified
behavior) and then translated each version into a Java byte array definition.
(These are extremely simple on-line, one-method classes, so the byte arrays are
relatively short.) I then simply embedded the byte array definitions as static
final byte[] fields the test class and replaced the byte code in my fake
transformer with those embedded fields' content. I've tested this and it works
great.
Here's what the embedded byte code for the fake weaved classes looks like. What
do you think? Is this acceptable?
/**
* Compiled version of org.apache.tomcat.unittest.weaving.UnweavedClass,
except that
* the doMethod method returns Hello, Weaver #1!.
*/
private static final byte[] WEAVED_REPLACEMENT_1 = new byte[] {
-54, -2, -70, -66, 0, 0, 0, 50, 0, 17, 10, 0, 4, 0, 13, 8, 0, 14,
7, 0, 15, 7, 0, 16,
1, 0, 6, 60, 105, 110, 105, 116, 62, 1, 0, 3, 40, 41, 86, 1, 0, 4,
67, 111, 100, 101,
1, 0, 15, 76, 105, 110, 101, 78, 117, 109, 98, 101, 114, 84, 97,
98, 108, 101, 1, 0, 8,
100, 111, 77, 101, 116, 104, 111, 100, 1, 0, 20, 40, 41, 76, 106,
97, 118, 97, 47, 108,
97, 110, 103, 47, 83, 116, 114, 105, 110, 103, 59, 1, 0, 10, 83,
111, 117, 114, 99,
101, 70, 105, 108, 101, 1, 0, 18, 85, 110, 119, 101, 97, 118, 101,
100, 67, 108, 97,
115, 115, 46, 106, 97, 118, 97, 12, 0, 5, 0, 6, 1, 0, 17, 72, 101,
108, 108, 111, 44,
32, 87, 101, 97, 118, 101, 114, 32, 35, 49, 33, 1, 0, 48, 111, 114,
103, 47, 97, 112,
97, 99, 104, 101, 47, 116, 111, 109, 99, 97, 116, 47, 117, 110,
105, 116, 116, 101,
115, 116, 47, 119, 101, 97, 118, 105, 110, 103, 47, 85, 110, 119,
101, 97, 118, 101,
100, 67, 108, 97, 115, 115, 1, 0, 16, 106, 97, 118, 97, 47, 108,
97, 110, 103, 47, 79,
98, 106, 101, 99, 116, 0, 33, 0, 3, 0, 4, 0, 0, 0, 0, 0, 2, 0, 1,
0, 5, 0, 6, 0, 1, 0,
7, 0, 0, 0, 29, 0, 1, 0, 1, 0, 0, 0, 5, 42, -73, 0, 1, -79, 0, 0,
0, 1, 0, 8, 0, 0, 0,
6, 0, 1, 0, 0, 0, 3, 0, 1, 0, 9, 0, 10, 0, 1, 0, 7, 0, 0, 0, 27, 0,
1, 0, 1, 0, 0, 0,
3, 18, 2, -80, 0, 0, 0, 1, 0, 8, 0, 0, 0, 6, 0, 1, 0, 0, 0, 6, 0,
1, 0, 11, 0, 0, 0, 2,
0, 12
};
/**
* Compiled version of org.apache.tomcat.unittest.weaving.UnweavedClass,
except that
* the doMethod method returns Hello, Weaver #2!.
*/
private static final byte[] WEAVED_REPLACEMENT_2 = new byte[] {
-54, -2, -70, -66, 0, 0, 0, 50, 0, 17, 10, 0, 4, 0, 13, 8, 0, 14,
7, 0, 15, 7, 0, 16,
1, 0, 6, 60, 105, 110, 105, 116, 62, 1, 0, 3, 40, 41, 86, 1, 0, 4,
67, 111, 100, 101,
1, 0, 15, 76, 105, 110, 101, 78, 117, 109, 98, 101, 114, 84, 97,
98, 108, 101, 1, 0, 8,
100, 111, 77, 101, 116, 104, 111, 100, 1, 0, 20, 40, 41, 76, 106,
97, 118, 97, 47, 108,
97, 110, 103, 47, 83, 116, 114, 105, 110, 103, 59, 1, 0, 10, 83,
111, 117, 114, 99,
101, 70, 105, 108, 101, 1, 0, 18, 85, 110, 119, 101, 97, 118, 101,
100, 67, 108, 97,
115, 115, 46, 106, 97, 118, 97, 12, 0, 5, 0, 6, 1, 0, 17, 72, 101,
108, 108, 111, 44,
32, 87, 101, 97, 118, 101, 114, 32, 35, 50, 33, 1, 0, 48, 111, 114,
103, 47, 97, 112,
97, 99, 104, 101, 47, 116, 111, 109, 99, 97, 116, 47, 117, 110,
105, 116, 116, 101,
115, 116, 47, 119, 101, 97, 118, 105, 110, 103, 47, 85, 110, 119,
101, 97, 118, 101,
100, 67, 108, 97, 115, 115, 1, 0, 16, 106, 97, 118, 97, 47, 108,
97, 110, 103, 47, 79,
98, 106, 101, 99, 116, 0, 33, 0, 3, 0, 4, 0, 0, 0, 0, 0, 2, 0, 1,
0, 5, 0, 6, 0, 1, 0,
7, 0, 0, 0, 29, 0, 1, 0, 1, 0, 0, 0, 5, 42, -73, 0, 1, -79, 0, 0,
0, 1, 0, 8, 0, 0, 0,
6, 0, 1, 0, 0, 0, 3, 0, 1, 0, 9, 0, 10, 0, 1, 0, 7, 0, 0, 0, 27, 0,
1, 0, 1, 0, 0, 0,
3, 18, 2, -80, 0, 0, 0, 1, 0, 8, 0, 0, 0, 6, 0, 1, 0, 0, 0, 6
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: 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: 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: 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: [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: 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=1510665view=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 @@
+!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
+!-- NewPage --
+html lang=en
+head
+!-- Generated by javadoc (version 1.7.0_25) on Thu Aug 01 21:15:52 BST 2013
--
+titleSerialized Form (Servlet 3.0 API Documentation - Apache Tomcat
8.0.0-RC1)/title
+meta name=date content=2013-08-01
+link rel=stylesheet type=text/css href=stylesheet.css title=Style
+/head
+body
+script type=text/javascript!--
+if (location.href.indexOf('is-external=true') == -1) {
+parent.document.title=Serialized Form (Servlet 3.0 API
Documentation - Apache Tomcat 8.0.0-RC1);
Everything appears to say Servlet 3.0 in the documentation when it should say
Servlet 3.1. We should probably fix that before the next release.
Nick
-
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 include name=**/NOTICE/ include name=**/RELEASE-NOTES/ +include name=**/javax.servlet.ServletContainerInitializer/ include name=**/.gitignore/ Would this work to catch all service config files not just SCIs? include name=**/META-INF/services/*/ 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 include name=**/NOTICE/ include name=**/RELEASE-NOTES/ +include name=**/javax.servlet.ServletContainerInitializer/ include name=**/.gitignore/ Would this work to catch all service config files not just SCIs? include name=**/META-INF/services/*/ 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: [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: 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: 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 ListString)?
Yes, that's an unchecked cast. The @SuppressWarnings was not unnecessary.
N
On Mon, Jul 29, 2013 at 11:38 AM, ma...@apache.org 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=1508171r1=1508170r2=1508171view=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 WebappServiceLoaderT {
// 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)
ListString orderedLibs = (ListString)
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 ListString)?
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, ma...@apache.org 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=1508171r1=1508170r2=1508171view=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 WebappServiceLoaderT {
// 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)
ListString orderedLibs = (ListString)
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 ListString)? 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
-ListString orderedLibs = (ListString)
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 ma...@apache.org 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 ListString)?
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, ma...@apache.org 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=1508171r1=1508170r2=1508171view=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 WebappServiceLoaderT {
// 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)
ListString orderedLibs = (ListString)
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: 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 ma...@apache.org: snip/ 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: 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: 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: 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: 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=1497299r1=1497298r2=1497299view=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=1497299r1=1497298r2=1497299view=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 ma...@apache.org: 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=1497552r1=1497551r2=1497552view=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: Jasper improvements
On Jun 26, 2013, at 1:57 PM, Jeremy Boynes wrote: On Jun 26, 2013, at 7:49 AM, Christopher Schultz ch...@christopherschultz.net wrote: Jeremy, On 6/26/13 1:44 AM, Jeremy Boynes wrote: On Jun 11, 2013, at 1:50 PM, Nick Williams nicho...@nicholaswilliams.net 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 servlet entry with a jsp-file and load-on-startup 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 jsp-config, 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: 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
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: 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=1493584r1=1493583r2=1493584view=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 @@
!-- Test code --
Match
+Class
name=org.apache.catalina.core.TestApplicationSessionCookieConfig$CustomContext
/
+Method name=getState/
+Bug code=UG /
+ /Match
+ Match
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.
Or
Class name=org.apache.catalina.startup.TestListener$SCL /
Class name=org.apache.catalina.startup.TestListener$SCL3 /
@@ -586,4 +591,13 @@
/Or
Bug code=RR /
/Match
+ Match
+!-- Code is deliberately unused --
+Class name=org.apache.tomcat.websocket.server.TestUriTemplate /
+Or
+ Method name=testBasicPrefix /
+ Method name=testQuote2 /
+/Or
+Bug code=DLS /
+ /Match
/FindBugsFilter
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=1493584r1=1493583r2=1493584view=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
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
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 ma...@apache.org: 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=1491940r1=1491939r2=1491940view=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 ListAsyncListenerWrapper 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
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.)
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
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
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=1479179r1=1479178r2=1479179view=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=1479179r1=1479178r2=1479179view=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 @@
/description
display-nameServlet and JSP Examples/display-name
+!--
+If you are running the Autobahn WebSocket testsuite - or any other
testsuite
+that uses large messages - uncomment the following to improve performance
+--
+!--
+context-param
+param-nameorg.apache.tomcat.websocket.binaryBufferSize/param-name
+param-value2097152/param-value
+/context-param
+context-param
+param-nameorg.apache.tomcat.websocket.textBufferSize/param-name
+param-value2097152/param-value
+/context-param
+--
!-- Define example filters --
filter
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: 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: JarScanning
On Mar 29, 2013, at 12:57 PM, Konstantin Kolinko wrote: 2013/3/29 Nick Williams nicho...@nicholaswilliams.net: (..) 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: 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 Scanner? -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: 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: 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=1460700r1=1460699r2=1460700view=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?
extends Endpoint, 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
SetServerApplicationConfig serverApplicationConfigs = new
HashSet();
-SetServerEndpointConfig scannedEndpointConfigs = new HashSet();
SetClass? extends Endpoint scannedEndpointClazzes = new
HashSet();
SetClass? 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? extends ServerEndpointConfig configClazz =
-(Class? extends ServerEndpointConfig) clazz;
-ServerEndpointConfig config = configClazz.newInstance();
-scannedEndpointConfigs.add(config);
-scannedEndpointClazzes.add(
-(Class? extends Endpoint)
config.getEndpointClass());
+Class? extends Endpoint endpoint =
+(Class? extends Endpoint) clazz;
+scannedEndpointClazzes.add(endpoint);
}
if (clazz.isAnnotationPresent(ServerEndpoint.class)) {
scannedPojoEndpoints.add(clazz);
@@ -90,7 +93,6 @@ public class WsSci implements ServletCon
SetClass? 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: 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/
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: 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: 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=1459389r1=1459388r2=1459389view=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
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 extends EventListener T createListener(ClassT 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 T newInstance(ClassT 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 T newInstance(T instance, Class? extends T clazz) throws
IllegalAccessException, InvocationTargetException, NamingException {
if (!ignoreAnnotations) {
MapString, String 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 T newInstance(ClassT 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
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\Sourcesvn diff Index: webapps/docs/changelog.xml === --- webapps/docs/changelog.xml (revision 1458379) +++ webapps/docs/changelog.xml (working copy) @@ -125,7 +125,7 @@ fix bug54708/bug: Change the name of the working directory for the ROOT application (located under $CATALINA_BASE/work by default) from _ to -ROOT. (markt) +ROOT. (markt) /fix /changelog /subsection - 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 T extends HttpUpgradeHandler T upgrade(ClassT) 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 extends HttpUpgradeHandler T upgrade(ClassT 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: [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=30076action=edit Patch to resolve issue If I specify a j.w.Encoder.BinaryStreamT or j.w.Encoder.TextStreamT 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
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: 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 nicho...@nicholaswilliams.net 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 extends HttpUpgradeHandler T upgrade(ClassT) 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 nicho...@nicholaswilliams.net 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 nicho...@nicholaswilliams.net 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
