You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2014/11/03 14:16:37 UTC
svn commit: r1636347 - /tomcat/trunk/TOMCAT-NEXT.txt
Author: markt
Date: Mon Nov 3 13:16:36 2014
New Revision: 1636347
URL: http://svn.apache.org/r1636347
Log:
Put the current version of the TODO list in svn.
Modified:
tomcat/trunk/TOMCAT-NEXT.txt
Modified: tomcat/trunk/TOMCAT-NEXT.txt
URL: http://svn.apache.org/viewvc/tomcat/trunk/TOMCAT-NEXT.txt?rev=1636347&r1=1636346&r2=1636347&view=diff
==============================================================================
--- tomcat/trunk/TOMCAT-NEXT.txt (original)
+++ tomcat/trunk/TOMCAT-NEXT.txt Mon Nov 3 13:16:36 2014
@@ -15,210 +15,30 @@
limitations under the License.
================================================================================
-Notes of things to consider for the next major Tomcat release (probably 8.0.x
-but possibly 7.1.x).
+Notes of things to consider for the next major Tomcat release (9.0.x)
- 1. Refactor the TLD parsing. TLDs are currently parsed twice. Once by Catalina
- looking for listeners and once by Jasper.
- - Complete
+ 1. Fix Java 8 Javadoc warnings. Currently ~2800.
- 2. Refactor the XML parsing (org.apache.tomcat.util.xml ?) to remove duplicate
- XML parsing code in Catalina and Jasper such as the entity resolvers used
- for validation.
- - Complete
+ 2. Remove BIO AJP and HTTP connector.
- 3. TLDs may have a many to many relationship between URIs and TLD files. This
- can result in the same TLD file being parsed many times. Refactor the
- TldLocationCache to cache the parsed nodes (will need to check for changes
- to TLD files).
- - Complete
+ 3. Remove Comet support.
- 4. TLD files should be included in the dependencies for JSP and Tag files.
- - Complete
+ 4. Refactor the connectors to minimise code duplication
+ - All implementation specific per connector code -> Endpoint
+ - All implementation specific per connection code -> SocketWrapper
+
+ 5. SNI support for JSSE.
- 5. Run the unused code detector and remove everything that isn't currently used.
- Add deprecation markers for the removed code to Tomcat 7.0.x
- - Complete
+ 6. See what Java 8 language features we want to use.
- 6. Change the default URIEncoding on the connector to UTF-8.
- - Complete
+ 7. Connector refactoring required for HTTP2/SPDY APIs that might be exposed in
+ the Servlet API.
- 7. Rip out all the JNDI code in resource handling and replace it with straight
- URLs (File or WAR).
- - Complete
+ 8. Keep an eye on the other Java EE 8 EGs (no sign of any movement apart
+ from the Servlet EG so far).
- kkolinko: I think this proposal goes too far. There are several
- separate issues. There are:
+ 9. Refactor WebSocket I/O to go directly to Tomcat's internals rather than via
+ the Servlet API.
- a) Internal API to define resources
- - BaseDirContext implementing aliases and resource jars,
- and there will be overlays in Servlet 3.1
- - StandardContext.setResources() allowing an arbitrary DirContext
- implementation via <Resources> element.
-
- Concerns:
- - Too many ways to configure it.
-
- b) Internal API to lookup resources
- - DirContext interface
-
- Concerns:
- - Unnecessary objects, e.g. NamingException instead of null.
-
- - Too many methods. Name vs. String. list() vs. listBindings().
-
- - Limited API. As a workaround, there are non-standard methods that
- are implemented on BaseDirContext instead, e.g. getRealPath(),
- doListBindings(..).
-
- - All caching (ProxyDirContext) and aliases handling is
- performed on the root level only.
-
- Once I do a lookup that returns a DirContext, further lookups on it
- will bypass the caching and aliases.
-
- c) WebappClassLoader and its interaction with resources
-
- WebappClassLoader uses DirContext API to access resources (classes,
- jars).
-
- Note that it has to construct a classpath for Java compiler called by
- Jasper. The compiler cannot operate on a DirContext and needs access
- to actual files and JARs.
-
- Concerns:
- - There are problems with access to classes and JAR files in
- non-unpacked WARs.
-
- It is resolved by unzipping the files into the working directory (in
- WebappLoader#setRepositories()).
-
- Note that DirContext is not notified of this copying.
- StandardJarScanner does not know of those copies either.
-
- - There are problems when the classes directory is served from
- multiple locations
-
- It seems to be worked around by adding the path of the alternative
- classes directory to virtualClasspath of VirtualWebappLoader (as shown
- by example in config/context.html#Virtual_webapp), but it is likely
- that I miss something.
-
- - antiJARLocking support in WebappClassLoader creates copies of
- resources, but does not notify the DirContext.
-
- - WebappClassLoader.jarFiles is used to track JAR files and keep them
- open. These might be useful when looking for resources in those files.
- These might be useful for StandardJarScanner.
-
- d) StandardJarScanner
-
- Concerns:
- - It essentially scans the same JARs as accessed by WebappClassLoader.
-
- It might be better to access them via WebappClassLoader rather that
- through Servlet API methods.
-
- The scanner is used by Jasper as well, so there are some concerns to
- keep the components independent.
-
- e) URL returned by ServletContext.getResource()
- jndi:/hostName/contextPath/resourcePath
-
- Goodies:
- - Uniform URL space. Both files and directories can be represented,
- hiding details of aliases, resource jars, etc.
-
- - It hides implementation details.
-
- - Permissions can be expressed as JndiPermission. They do not depend
- on context version number.
-
- - Accessing a resource through such URL leverages the cache
- implemented in ProxyDirContext class. We do not access the file system
- directly, nor need to open a JAR file.
-
- - It can be created from a String if necessary.
-
- Such use relies on DirContextURLStreamHandler.bindThread(..) being
- called earlier in the same thread.
-
- Concerns:
- - Some components would like to get "real" resource URL from this one.
-
- Maybe it can be exposed through some special header name,
- DirContextURLConnection.getHeaderField(str)?
-
- How such real URL can be prepared?
- DirContext.getNameInNamespace()?
- BaseDirContext.getRealPath()?
- ((FileResourceAttributes)DirContext.getAttributes()).getCanonicalPath()?
-
- - A resource lookup is performed twice. The first time in
- ServletContext.getResource() (implemented in ApplicationContext.getResource())
- to return null for non-existing paths.
- The second time in DirContextURLConnection.connect().
-
- It is good that there is a cache in ProxyDirContext that saves time
- for repeated lookups.
-
- - Using URLs involves encoding/decoding.
-
- If there were some other API to access resources in a web application,
- I would prefer some opaque object that allows access to resource
- properties, but is converted to string/url form only on demand.
-
- f) Connection, created from jndi: URL
- DirContextURLStreamHandler, DirContextURLConnection
-
- Goodies:
- - DirContextURLConnection provides information about resource via
- methods such as getContentLength(), getHeaderField(str).
-
- Concerns:
- - It exposes DirContext through some APIs, such as
- DirContextURLConnection.getContent().
-
- Is this feature going to be preserved for compatibility, or to be
- removed?
-
- - DirContextURLConnection.list(): a public method, that is not part of
- the usual URL API. So URL API is lacking. Maybe some other methods
- could be added.
-
- A possible candidate could be "isCollection()", instead of asking for
- getContentType() and checking its value against ResourceAttributes.COLLECTION_TYPE.
-
- Threads:
- http://markmail.org/thread/hqbmdn2qs6xcooko
-
- 8. Review the connector shutdown code for timing and threading issues
- particularly any that may result in a client socket being left open after a
- connector.stop().
- - Complete.
-
- 9. Remove the svn keywords from all the files. (Just Java files?)
- - Complete.
-
-10. Code to the interfaces in the o.a.catalina package and avoid coding directly
- to implementations in other packages. This is likely to require a lot of
- work. Maybe use Structure 101 (or similar) to help.
- - Partially complete - probably as far as is practical.
-
-11. Merge Service and Engine
- - Decided not to do this.
-
-12. Java 7 updates
- - Use of <> operator where possible
- - Complete
- - Use of try with resources
- - Complete
- - Catching multiple exceptions
- - Started
- - javax.[annotation to el] complete
- - remainder TODO
-
-13. Fix all FindBugs warnings
- - Complete
-
-14. Review date formatting with a view to reducing duplication.
+10. Remove the use of system properties to control configuration wherever
+ possible
\ No newline at end of file
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1636347 - /tomcat/trunk/TOMCAT-NEXT.txt
Posted by Mark Thomas <ma...@apache.org>.
On 04/11/2014 11:08, Rémy Maucherat wrote:
> 2014-11-03 14:16 GMT+01:00 <ma...@apache.org>:
>
>> + 3. Remove Comet support.
>>
>
> Are you actively working on it right now, or is there room for
> participation for this item ?
I have a commit sat in my local git repo that removes all the Comet
stuff. Let me commit that.
I suspect that commit will result in some further unused code that can
be removed but haven't run the unused code detector over the code base yet.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1636347 - /tomcat/trunk/TOMCAT-NEXT.txt
Posted by Rémy Maucherat <re...@apache.org>.
2014-11-03 14:16 GMT+01:00 <ma...@apache.org>:
> + 3. Remove Comet support.
>
Are you actively working on it right now, or is there room for
participation for this item ?
Rémy
Re: svn commit: r1636347 - /tomcat/trunk/TOMCAT-NEXT.txt
Posted by Rémy Maucherat <re...@apache.org>.
2014-11-03 20:45 GMT+01:00 Christopher Schultz <chris@christopherschultz.net
>:
> > + 2. Remove BIO AJP and HTTP connector.
>
> I wonder about this goal. Something nice about the BIO connectors is
> that they tend to "just work" when other connectors are doing wonky
> things. Yes, they seriously complicate things like asynchronous
> semantics, but I think it may be more appropriate to simply drop support
> for async-over-blocking-IO and otherwise leave the BIO connector in
> there (not enabled by default).
>
> The BIO connectors seem to be the least resource-heavy for when work is
> actually being done (as opposed to having 1000 threads sitting idle, of
> course) which is a good use case for AJP which pretty much has a
> connection limit between httpd <-> Tomcat already.
>
These BIO connectors "just don't work" (rather than "just work") since they
don't implement properly the Servlet 3.1 API. Time to go ...
>
> > + 3. Remove Comet support.
>
> Could we package Tomcat 8's Comet components in such a way that they
> could be added to Tomcat 9 by someone who might want to upgrade to
> Tomcat.latest but still use Comet? I actually think the protocol should
> die and from the (lack of) traffic on the list regarding Comet, I
> suspect its use is fairly limited.
>
It is the org.apache.catalina.comet API. It's intrusive, so it's either
remove or don't remove. This API is superseded by Servlet 3.1, so this
should be removed.
>
> > + 5. SNI support for JSSE.
>
> This seems like a feature ripe for back-porting to Tomcat 8 when using a
> supportive JVM.
>
> > + 9. Refactor WebSocket I/O to go directly to Tomcat's internals rather
> than via
> > + the Servlet API.
>
> I like this a lot. Is it actually in conflict with my above desire to
> continue to support the BIO connectors?
>
Obviously, it will be another set of APIs that could be "implemented" but
would deadlock when used with such a connector.
>
> > +10. Remove the use of system properties to control configuration
> wherever
> > + possible
>
> I like this, too. When anyone is working on moving a system property
> into configuration, please think about whether it would make sense (or
> be practical) for users to want to set these configuration settings on a
> per-web-application or per-host basis instead of only globally.
> Obviously, some configurations may only be applicable at the JVM level.
> For those, perhaps leaving them as system properties to stress their
> "globality" might be a good idea.
>
> Rémy
Re: svn commit: r1636347 - /tomcat/trunk/TOMCAT-NEXT.txt
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 11/3/14 8:16 AM, markt@apache.org wrote:
> Author: markt
> Date: Mon Nov 3 13:16:36 2014
> New Revision: 1636347
>
> URL: http://svn.apache.org/r1636347
> Log:
> Put the current version of the TODO list in svn.
>
> Modified:
> tomcat/trunk/TOMCAT-NEXT.txt
>
> Modified: tomcat/trunk/TOMCAT-NEXT.txt
> URL: http://svn.apache.org/viewvc/tomcat/trunk/TOMCAT-NEXT.txt?rev=1636347&r1=1636346&r2=1636347&view=diff
> ==============================================================================
> --- tomcat/trunk/TOMCAT-NEXT.txt (original)
> +++ tomcat/trunk/TOMCAT-NEXT.txt Mon Nov 3 13:16:36 2014
> @@ -15,210 +15,30 @@
> limitations under the License.
> ================================================================================
>
> -Notes of things to consider for the next major Tomcat release (probably 8.0.x
> -but possibly 7.1.x).
> +Notes of things to consider for the next major Tomcat release (9.0.x)
>
> + 1. Fix Java 8 Javadoc warnings. Currently ~2800.
>
> + 2. Remove BIO AJP and HTTP connector.
I wonder about this goal. Something nice about the BIO connectors is
that they tend to "just work" when other connectors are doing wonky
things. Yes, they seriously complicate things like asynchronous
semantics, but I think it may be more appropriate to simply drop support
for async-over-blocking-IO and otherwise leave the BIO connector in
there (not enabled by default).
The BIO connectors seem to be the least resource-heavy for when work is
actually being done (as opposed to having 1000 threads sitting idle, of
course) which is a good use case for AJP which pretty much has a
connection limit between httpd <-> Tomcat already.
> + 3. Remove Comet support.
Could we package Tomcat 8's Comet components in such a way that they
could be added to Tomcat 9 by someone who might want to upgrade to
Tomcat.latest but still use Comet? I actually think the protocol should
die and from the (lack of) traffic on the list regarding Comet, I
suspect its use is fairly limited.
> + 5. SNI support for JSSE.
This seems like a feature ripe for back-porting to Tomcat 8 when using a
supportive JVM.
> + 9. Refactor WebSocket I/O to go directly to Tomcat's internals rather than via
> + the Servlet API.
I like this a lot. Is it actually in conflict with my above desire to
continue to support the BIO connectors?
> +10. Remove the use of system properties to control configuration wherever
> + possible
I like this, too. When anyone is working on moving a system property
into configuration, please think about whether it would make sense (or
be practical) for users to want to set these configuration settings on a
per-web-application or per-host basis instead of only globally.
Obviously, some configurations may only be applicable at the JVM level.
For those, perhaps leaving them as system properties to stress their
"globality" might be a good idea.
-chris