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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
