tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik \(lists\)" <devli...@hanik.com>
Subject RE: [5.next] Progress
Date Sat, 17 Jul 2004 16:51:54 GMT
hi Remy,
Time will open up in a week or so. And yes, I am wide open to any ideas.
My personal feeling about the farm deployer, is that it would work exactly
like auto deployment to Tomcat, and maybe just an entry in web.xml makes it
send to other servers.
I do need a temp directory to store the fragments of data sent across the
wire, so that we don't take up too much RAM.

Let me put together a todo list for review next week!

Filip

-----Original Message-----
From: Remy Maucherat [mailto:remm@apache.org]
Sent: Thursday, July 15, 2004 12:11 PM
To: Tomcat Developers List
Subject: Re: [5.next] Progress


My updated TODO. So I'll do the deployer next, followed by trying to
optimize startup time.
Then, there's tweaking.

Filip, do you have time to refactor the clustering soon ? I think we
should tweak your farming feature as well, as it should likely be done
the way the manager servlet is (rather, will be) doing its stuff. The
idea is to have only one big entry point for deployments, rather than
have 20 different components calling various deploy methods (which is
impossible to maintain). I need to write some code and experiment, and
then I'll have a clearer view of what this refactoring will look like
(sorry, it's just a little too messy right now for me to enumerate the
list of changes).

- Attempt to redo a bit the deployer:
   * remove the CL code which is there to avoid JAR locking (or at least
allow disabling this feature for non-Windows OSes); when enabling anti
locking
code, move everything to a temp "deploy" folder where everything will be
referenced from; controlled by a "development" flag on the Context to allow
disabling this on Windows
   * move processing of context.xml to StandardContext (at the expense of
being able to specify the context class, which will move to an attribute
on the Host), as I realize it is important to get context level
configurability without adding too much complexity in the embedding
application; this could also go in ContextConfig, but this should be done in
another event (START occurs too late)
- Use the webapp CL as the main CL (without the locking tricks it is likely
faster than the regular CL)
- Resolve DBCP -> Pool -> Collections dependency, using package renaming
- Remove anything useless (spring cleaning time), such as configuration
options, container listeners (to be replaced with JMX notifications where
it matters), etc
- clutering module refactoring, to extend the regular Catalina objects, for
easier future maintenance
- Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX
and JMX
remote, etc)
- Externalize configuration saving out of StandardServer
- And the ongoing: allow all config/management through JMX (actually, we
could consider going to a JMX config format)

Rémy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.713 / Virus Database: 469 - Release Date: 6/30/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message