Re: [5.next] Summary
Remy Maucherat wrote: Remy Maucherat wrote: - Move to concrete classes for request/response, and remove all of the RTTI done in Catalina's pipeline Ok, I'm almost done with the first part of the refatoring (thanks to Eclipse 3) :) I think I'll commit when I'm done with the next two items, so that all the big core changes are done (for now ;) ). - Use Tomcat 4.0 beta valve pattern - Redo logging using commons-logging, and remove Logger I'll do on with the next item: - Fork commons-digester, to remove what we don't need (many fancy features provided by beanutils, and in the process remove dependencies on beanutils and collections) I'll use the o.a.t.util.digester package for this, and hopefully not too much refactoring will be needed. Since modeler needs digester, I'll do special prebuilding of the JAR to rename the imports (a bit like the prebuilding which is done for the servlet JSP JARs). I forgot about one nasty dependency chain, BTW: DPCB - pool - collections, which resides right now in the commons loader :( I'll save this for later ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Summary
I see your back from vacation. I hope it was restful. I've started working on porting CLIPS 6.2 from C to Java. Once that is done, I will donate it back to CLIPS community (since it's public domain software), donate it as a project to apache and use it in RuleML development. JBoss should be able to use it too :) peter On Wed, 23 Jun 2004 20:02:04 +0200, Remy Maucherat [EMAIL PROTECTED] wrote: Remy Maucherat wrote: Remy Maucherat wrote: - Move to concrete classes for request/response, and remove all of the RTTI done in Catalina's pipeline Ok, I'm almost done with the first part of the refatoring (thanks to Eclipse 3) :) I think I'll commit when I'm done with the next two items, so that all the big core changes are done (for now ;) ). - Use Tomcat 4.0 beta valve pattern - Redo logging using commons-logging, and remove Logger I'll do on with the next item: - Fork commons-digester, to remove what we don't need (many fancy features provided by beanutils, and in the process remove dependencies on beanutils and collections) I'll use the o.a.t.util.digester package for this, and hopefully not too much refactoring will be needed. Since modeler needs digester, I'll do special prebuilding of the JAR to rename the imports (a bit like the prebuilding which is done for the servlet JSP JARs). I forgot about one nasty dependency chain, BTW: DPCB - pool - collections, which resides right now in the commons loader :( I'll save this for later ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Summary
TC 3.3 has o.a.t.u.xml.* which is uses instead of Digester. If it helps with re-inventing wheels, you could take a look at it. In any case, I may change TC 3.3 to start using o.a.t.u.digester, so +1. - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 11:02 AM Subject: Re: [5.next] Summary Remy Maucherat wrote: Remy Maucherat wrote: - Move to concrete classes for request/response, and remove all of the RTTI done in Catalina's pipeline Ok, I'm almost done with the first part of the refatoring (thanks to Eclipse 3) :) I think I'll commit when I'm done with the next two items, so that all the big core changes are done (for now ;) ). - Use Tomcat 4.0 beta valve pattern - Redo logging using commons-logging, and remove Logger I'll do on with the next item: - Fork commons-digester, to remove what we don't need (many fancy features provided by beanutils, and in the process remove dependencies on beanutils and collections) I'll use the o.a.t.util.digester package for this, and hopefully not too much refactoring will be needed. Since modeler needs digester, I'll do special prebuilding of the JAR to rename the imports (a bit like the prebuilding which is done for the servlet JSP JARs). I forgot about one nasty dependency chain, BTW: DPCB - pool - collections, which resides right now in the commons loader :( I'll save this for later ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Summary
Peter Lin wrote: I see your back from vacation. I hope it was restful. No, no, I was doing a training in Vienna ;) I've started working on porting CLIPS 6.2 from C to Java. Once that is done, I will donate it back to CLIPS community (since it's public domain software), donate it as a project to apache and use it in RuleML development. I guess we could do crazy request mappings with that :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Summary
Bill Barker wrote: TC 3.3 has o.a.t.u.xml.* which is uses instead of Digester. If it helps with re-inventing wheels, you could take a look at it. Yes, it's also in TC 4. I think it has limitations when compared to the digester. Overall, the biggest problem of the digester might be the huge amount instanceof DynaBean conditionals ;) In any case, I may change TC 3.3 to start using o.a.t.u.digester, so +1. Ok. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Summary
Remy Maucherat wrote: - Move to concrete classes for request/response, and remove all of the RTTI done in Catalina's pipeline Ok, I'm almost done with the first part of the refatoring (thanks to Eclipse 3) :) I think I'll commit when I'm done with the next two items, so that all the big core changes are done (for now ;) ). - Use Tomcat 4.0 beta valve pattern - Redo logging using commons-logging, and remove Logger Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Summary
You have sent this to me in error. Claire Bell Facilities Administrator Ext 61564 Filip Hanik - Dev To: Tomcat Developers List [EMAIL PROTECTED] [EMAIL PROTECTED]cc: om Subject: Re: [5.next] Summary 14/06/2004 17:32 Please respond to Tomcat Developers List yup, refatoring of clutering is something we need :) Will start as soon as tag 27 is in place, I will go over the details with you later Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, June 11, 2004 11:50 AM Subject: [5.next] Summary - Move to concrete classes for request/response, and remove all of the RTTI done in Catalina's pipeline - Use Tomcat 4.0 beta valve pattern - Redo logging using commons-logging, and remove Logger - Fork commons-digester, to remove what we don't need (many fancy features provided by beanutils, and in the process remove dependencies on beanutils and collections) - 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) * move processing of context.xml to ContextConfig (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 - Use the webapp CL as the main CL (without the locking tricks it is likely faster than the regular CL) - And the ongoing: allow all config/management through JMX (actually, we could consider going to a JMX config format) - Use any means necessary (hehe) so that Filip refactors the clutering module, and extend the regular Catalina objects, for easier maintenance - Remove anything useless (spring cleaning time), such as configuration options, container listeners (to be replaced with JMX notifications where it matters), etc - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) Overall, the throughtput of Tomcat should go up about 5-10% with those changes, as most significant optimizations are already done. I don't think any of these items will take too long to implement. I'm away next week, so I'll start the week after. Some of this could eventually be backported to 5.0.x :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ernst Young is proud to sponsor Art of the Garden at Tate Britain (3rd June - 30th August 2004). This is the first major exhibition to examine the relationship of the garden and British art. Advance booking is recommended. Information and tickets: www.tate.org.uk/artofthegarden This e-mail and any attachment are confidential and contain proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient, please notify the author immediately by telephone or by replying to this e-mail, and then delete all copies of the e-mail on your system. If you are not the intended recipient, you must not use, disclose, distribute, copy, print or rely on this e-mail. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachment has been checked for viruses, we cannot guarantee that they are virus free and we cannot accept liability for any damage sustained as a result of software viruses. We would advise that you carry out your own virus checks, especially before opening an attachment. The UK firm Ernst Young LLP is a limited liability partnership registered in England and Wales with registered number OC31 and is a member practice of Ernst Young Global. A list of members' names is available for inspection at 1 More London Place, London, SE1 2AF, the firm's principal place of business and its registered office
Re: [5.next] Summary
yup, refatoring of clutering is something we need :) Will start as soon as tag 27 is in place, I will go over the details with you later Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, June 11, 2004 11:50 AM Subject: [5.next] Summary - Move to concrete classes for request/response, and remove all of the RTTI done in Catalina's pipeline - Use Tomcat 4.0 beta valve pattern - Redo logging using commons-logging, and remove Logger - Fork commons-digester, to remove what we don't need (many fancy features provided by beanutils, and in the process remove dependencies on beanutils and collections) - 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) * move processing of context.xml to ContextConfig (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 - Use the webapp CL as the main CL (without the locking tricks it is likely faster than the regular CL) - And the ongoing: allow all config/management through JMX (actually, we could consider going to a JMX config format) - Use any means necessary (hehe) so that Filip refactors the clutering module, and extend the regular Catalina objects, for easier maintenance - Remove anything useless (spring cleaning time), such as configuration options, container listeners (to be replaced with JMX notifications where it matters), etc - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) Overall, the throughtput of Tomcat should go up about 5-10% with those changes, as most significant optimizations are already done. I don't think any of these items will take too long to implement. I'm away next week, so I'll start the week after. Some of this could eventually be backported to 5.0.x :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.next] Summary
Hi, Cool stuff ;) I'm away in two weeks, so I'll tag and branch 5.0.27 and TOMCAT_5_0 at the end of next week, so that you can start working on HEAD two weeks when you're back from vaca. Yoav Shapira Millennium Research Informatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Friday, June 11, 2004 12:51 PM To: Tomcat Developers List Subject: [5.next] Summary - Move to concrete classes for request/response, and remove all of the RTTI done in Catalina's pipeline - Use Tomcat 4.0 beta valve pattern - Redo logging using commons-logging, and remove Logger - Fork commons-digester, to remove what we don't need (many fancy features provided by beanutils, and in the process remove dependencies on beanutils and collections) - 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) * move processing of context.xml to ContextConfig (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 - Use the webapp CL as the main CL (without the locking tricks it is likely faster than the regular CL) - And the ongoing: allow all config/management through JMX (actually, we could consider going to a JMX config format) - Use any means necessary (hehe) so that Filip refactors the clutering module, and extend the regular Catalina objects, for easier maintenance - Remove anything useless (spring cleaning time), such as configuration options, container listeners (to be replaced with JMX notifications where it matters), etc - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) Overall, the throughtput of Tomcat should go up about 5-10% with those changes, as most significant optimizations are already done. I don't think any of these items will take too long to implement. I'm away next week, so I'll start the week after. Some of this could eventually be backported to 5.0.x :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Summary
Shapira, Yoav wrote: Hi, Cool stuff ;) I'm away in two weeks, so I'll tag and branch 5.0.27 and TOMCAT_5_0 at the end of next week, so that you can start working on HEAD two weeks when you're back from vaca. I'm going to have a lot of fun: it's a training in Vienna. I guess you have to go earn money sometimes ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
