tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Santosh [ಸಂತೋಷ ]" <santoshbm...@gmail.com>
Subject Re: 6.x feature wishlist
Date Tue, 07 Aug 2007 18:02:44 GMT
On 8/7/07, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
>
> Santosh [ಸಂತೋಷ ] wrote:
> > If any help required in these, please let me know. I am ready to
> contribute.
> >
> > On 8/7/07, Santosh [ಸಂತೋಷ ] <santoshbmath@gmail.com> wrote:
> >
> >> 1. Few more properties in "logging.properties" to LogHandler other than
> >> directory, prefix, suffix, level, filter, formatter. Like,
> >>       prefix for level, suffix for level, level display (For Ex :
> Instead
> >> of INFO, it must be possible to display "I"), timestamp display format
> >>
> >> Example.
> >> levelprefix = [
> >> levelsuffix = ]
> >> leveldisplay = INFO:I, ERROR:E
> >> timestamp = dd-mm-yyyy hh:mm:ss
> >>
> >> This will help to reduce the log file size.
> >>
> >> 2. Admin webapp since its not ported on tomcat 6.
> >>
> If you want to make this one work, I would start from scratch.
> There is no reason why the admin tool, whose only goal is to modify
> server.xml has to interact or introspect a running tomcat instance.
> Instead, what would be nice, is if the configuration reference contained
> enough information and in an appropriate format that the admin
> tool would introspect that XML and use the info as a base for the admin
> tool.
> since the configuration reference documentation could contain data type,
> valid values, name and description, it would be the ideal data source to
> fetch info for.
>
> just a thought, however, the existing admin app, suffers from the
> chicken or the egg problem, I need a running tomcat to configure a tomcat
> :)


One important feature of admin webapp is to modify the server.xml while
running the server. I think we can port 5.5 admin on tomcat 6.0 with little
changes.  Already I am in middle of this process. As i already said, some
features are working in admin some are not working like adding/updating
environment values, users, data sources. Currently i am analysing the adding
new environment. There is no change in NamingResourceMBean or NamingResource
in 5.5 and 6.0 but still i am getting error "addEnvironment() with String,
String, String" not found.

Filip
> >>
> >> On 8/7/07, Filip Hanik - Dev Lists <devlists@hanik.com > wrote:
> >>
> >>> I wanted to start a wish list of what we can move forward with, here
> is
> >>> a short list of items that I had in mind as a starter
> >>>
> >>> 1. Session replication - stateless backup location
> >>>   Store the backup location of a session as part of the sessionId,
> >>> similar to the jvmRoute but opposite.
> >>>   This way, you can scale a cluster horizontally, since the location
> of
> >>> the backup node doesn't have to be known until you fail over.
> >>>
> >>> 2. Add a block/no-block parameter to InputFilter.doRead and
> >>> OutputFilter.doWrite
> >>>    InputFilter -> public int doRead(ByteChunk chunk, Request unused,
> >>> boolean block) throws IOException;
> >>>    OutputFilter -> public int doWrite(ByteChunk chunk, Response
> unused,
> >>> boolean block) throws IOException;
> >>>    Servlet 3.0 will most likely expose non blocking read/write through
> >>> the servlet API, this will get us there ahead of time
> >>>    Haven't thought of how we expose this API yet though, but more will
> >>> follow
> >>>
> >>> 3. Consolidate connector code
> >>>   Currently we have
> >>> Http11Processor/Http11NioProcessor/Http11AprProcessor doing almost the
> >>> same thing, there is much that
> >>>   can be consolidated to make the code more maintainable
> >>>   Essentially, you create a Endpoint base line interface.
> >>>   At the same time we could consolidate the Internal(In/Out)put
> buffers
> >>> as they are copies too.
> >>>   We have some fairly tuned endpoints now, it would also be nice to
> >>> make these protocol agnostic.
> >>>
> >>> 4. Startup -> server.xml warnings
> >>>   If one enters an invalid element or attribute that is simply ignored
> >>> today, at least output an info or warn message letting the
> >>>   admin know if its misconfiguration.
> >>>
> >>> 5. Finish bayeux -> I started this in sandbox, took me a while to
> >>> understand the protocol, and its not as cool as I thought it would be
> >>>   but I still feel its important for it to be part of Tomcat
> >>>
> >>> 6. Auto context logging
> >>>   Automatically create loggers for each context, so that one doesn't
> >>> have to specify one per context in logging.properties
> >>>   Of course, you can turn on/off the auto context logger through
> >>> logging.properties
> >>>
> >>> 7. File cache - use MappedByteBuffers for the file cache, that way the
> >>> send file operation can benefit even more
> >>>   when you have two direct buffers, and you also avoid reading the
> disk
> >>> each time for a file
> >>>   ideas on this came from Jeanfrancois Arcand.
> >>>
> >>> (
> http://fisheye5.cenqua.com/browse/glassfish/appserv-http-engine/src/java/com/sun/enterprise/web/connector/grizzly/FileCache.java?r=1.21
> >>> )
> >>>
> >>> 8. Add getName()/setName() to the WebappClassLoader, name of the web
> app
> >>>
> >>> classloader will correspond to the one of the Context container
> >>>   Applications like Terracotta or AOP apps can much easier plug in and
> >>> be able to share data when they know what loader the class came from
> >>>
> >>> 9. Add the configuration option to start the connectors after all apps
> >>> are deployed
> >>>   If some applications are taking long to startup, load balancers are
> >>> already trying to send requests to the Tomcat instance, which is just
> >>> bound to a port, but not yet taking requests
> >>>
> >>> 10.Turn our embedded thread pools into Tomcat Executor thread pools,
> >>> same performance but pluggable. Instead of having them hidden in the
> end
> >>> point code
> >>>
> >>> 11.Timestamps & System.currentTimeMillis
> >>>   System.currentTimeMillis is invoked everywhere during the chain of
> >>> events for a HTTP requests, even though most dates only need precision
> >>> down to the second.
> >>>   I've received feedback that this could be improved by keeping a time
> >>> service, that updates a timestamp every second, and therefor reduces
> the
> >>> number of system calls
> >>>   I think we would need to prove the theory before committing to the
> >>> implementation, but that should be pretty easy
> >>>
> >>> 12.Comet sample webapp
> >>>   While most folks want to start with Comet, it is a strange question,
> >>> tons of users on the user list just are having a hard time getting
> kick
> >>> started
> >>>
> >>> I was thinking we can keep this list on Wiki or in a text file in SVN,
> >>> http://wiki.apache.org/tomcat/6xFeatures
> >>>
> >>>
> >>> thoughts
> >>> Filip
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>
> >>>
> >>>
> >>
> ------------------------------------------------------------------------
> >>
> >> No virus found in this incoming message.
> >> Checked by AVG Free Edition.
> >> Version: 7.5.476 / Virus Database: 269.11.8/940 - Release Date:
> 8/6/2007 4:53 PM
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message