Re: [5.next] Progress, more ideas and native connector benchmarks
Some updates ... Remy Maucherat wrote: * Default global and per-host configurations: - conf/engine/host/context.xml.default - conf/engine/host/web.xml.default - conf/context.xml - conf/web.xml This will lead to the removal of the DefaultContext interface, since this will fully replace the functionality (while being very simple to implement and actually complete functionality wise; I have no idea why I never thought of doing it this way, since the default web.xml is implemented like that). For the admin webapp support for DefaultContext, we would simply need to register a Context instance in JMX with the usual DefaultContext MBean name, and tweak a little. So I'll now proceed with removing DefaultContext and creating the new MBeans. * HTML host manager servlet (allows easily creating host and preconfiguring them - ex: with the manager webapp installed, and a default context file). I think this would be useful (?). My next big item :) * The other features I mentioned earlier: startup time optimization, removal of stuff which isn't used (such as container listeners). In other features, I added package renaming for DBCP. It is less useful with Ant IMO. I'll experiment a little, although untangling the javac task seems rather hard ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, August 11, 2004 11:04 AM Subject: Re: [5.next] Progress, more ideas and native connector benchmarks Some updates ... Remy Maucherat wrote: * Default global and per-host configurations: - conf/engine/host/context.xml.default - conf/engine/host/web.xml.default - conf/context.xml - conf/web.xml This will lead to the removal of the DefaultContext interface, since this will fully replace the functionality (while being very simple to implement and actually complete functionality wise; I have no idea why I never thought of doing it this way, since the default web.xml is implemented like that). For the admin webapp support for DefaultContext, we would simply need to register a Context instance in JMX with the usual DefaultContext MBean name, and tweak a little. So I'll now proceed with removing DefaultContext and creating the new MBeans. Actually, admin doesn't really handle DC now, so anything would be an improvement there :). * HTML host manager servlet (allows easily creating host and preconfiguring them - ex: with the manager webapp installed, and a default context file). I think this would be useful (?). My next big item :) * The other features I mentioned earlier: startup time optimization, removal of stuff which isn't used (such as container listeners). In other features, I added package renaming for DBCP. It is less useful with Ant IMO. I'll experiment a little, although untangling the javac task seems rather hard ;) It certainly made Gump unhappy :). 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] Progress, more ideas and native connector benchmarks
Bill Barker wrote: It certainly made Gump unhappy :). Ooops, yes, it's going to be a problem. It's quite hard to build my custom JAR :( Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
Remy Maucherat wrote: Bill Barker wrote: - Remove Deployer and DefaultContext. The new stuff looks like a better replacement. I did that but didn't commit yet. The management side for the default context would need to be redone (it's not very difficult, I think). The clustering will need updates, but I don't think it's very difficult either. Ok. So during testing of the new undeploy code, I ran into some bug (apparently, but I can't reproduce it anymore) where the undeploy removed half of my work partition (I didn't realize what was going on fast enough ;) ), and I'm restoring stuff with my modem right now. I did lose some updates, of course (incl the removal of the two interfaces - of course, it's not very hard to put it back, so it's not a big issue). So be careful for now with the undploy link on the HTML manager, if you're using a descriptor pointing to a folder outside of the TC root ;) There should be code to prevent deletion of anything outside of the host appBase, but somehow it didn't work (or I simply forgot to recompile using it before testing, as I can't reproduce the problem anymore :( ). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.next] Progress, more ideas and native connector benchmarks
Hi, You know, I've been meaning to address the Undeploy considered dangerous bugzilla item by adding a JavaScript confirmation dialog around the undeploy action in the HTML manager. Too bad I hadn't gotten around to it before your mishap ;( Yoav Shapira Millennium Research Informatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 6:27 AM To: Tomcat Developers List Subject: Re: [5.next] Progress, more ideas and native connector benchmarks Remy Maucherat wrote: Bill Barker wrote: - Remove Deployer and DefaultContext. The new stuff looks like a better replacement. I did that but didn't commit yet. The management side for the default context would need to be redone (it's not very difficult, I think). The clustering will need updates, but I don't think it's very difficult either. Ok. So during testing of the new undeploy code, I ran into some bug (apparently, but I can't reproduce it anymore) where the undeploy removed half of my work partition (I didn't realize what was going on fast enough ;) ), and I'm restoring stuff with my modem right now. I did lose some updates, of course (incl the removal of the two interfaces - of course, it's not very hard to put it back, so it's not a big issue). So be careful for now with the undploy link on the HTML manager, if you're using a descriptor pointing to a folder outside of the TC root ;) There should be code to prevent deletion of anything outside of the host appBase, but somehow it didn't work (or I simply forgot to recompile using it before testing, as I can't reproduce the problem anymore :( ). 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] Progress, more ideas and native connector benchmarks
Shapira, Yoav wrote: Hi, You know, I've been meaning to address the Undeploy considered dangerous bugzilla item by adding a JavaScript confirmation dialog around the undeploy action in the HTML manager. Too bad I hadn't gotten around to it before your mishap ;( I would have clicked yes: I wanted to test it. And if you use the Ant task (which does the same), there's no confirmation. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
Bill Barker wrote: I'll volunteer for the admin webapp stuff. I enjoy deleting stuff from there ;-). It's at the end of my list right now, so I wont't get there for a while. I committed a few things: - The new deployer is getting there. Missing is the support for the manager webapp, but this won't be too hard to write. Still a few adjustments needed (the two fixmes which are in the file). - Update manager webapp, and add support for it in HostConfig (incl JMX registration). The new manager is considerably simpler, but I need to test more of its features. BTW, on Windows, the minimum to be able to use it is to set antiJARLocking (otherwise, stuff like Xerces are really good at JAR locking). antiResourceLocking is likely more reliable, of course. - Remove Deployer and DefaultContext. The new stuff looks like a better replacement. I did that but didn't commit yet. The management side for the default context would need to be redone (it's not very difficult, I think). The clustering will need updates, but I don't think it's very difficult either. - HTML host manager servlet (allows easily creating host and preconfiguring them - ex: with the manager webapp installed, and a default context file). - Try to optimize startup time, if possible. I'll do one of these next. - As mentioned in my commit message, I don't think the dynamic updates to the naming environment are useful. The code which does that is relatively complex (although it's not as bad as before with the ResourceParams). My opinion is that if something is not useful, then it should go ;) Any comments on that fancy feature ? I forgot about the global resources, so I think the dynamic updates are sort of useful. At least it's a lot simpler now that the ResourceParams is gone. - I'll have a lot of work updating the docs now :-P (I guess the fun is nearly over :( ) - The admin webapp will need some tweaks after removing the DefaultContext. So I'll commit the removal of Deployer and DefaultContext next. Is that ok ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: Both difference and similarity :-). Eclipse ( osgi actually ) has a similar flat loader implementation, but with finer control over what is exported/imported and pretty strong versioning. In addition osgi supports permissions on importing packages. The reloading of modules is a bit more complicated than in jboss ( where you just change the jar ). From tomcat point of view - the implementation should be very similar with jboss. What I like is the standardized and simpler behavior of class loaders, with ability to reload and upgrade any module ( like jboss ). This classloader looks like it does stuff :) I recommend plugging it in as usual, with the Loader interface. Is that ok ? It should be, plugging tomcat into anything is usually simple. The current tomcat loading mechanism - with 2 hierarchies of class loaders and the delegation hacks, plus the very rigid isolation between webapps - is far from perfect. Again, it's a matter of interpreting the servlet spec - they do have some clear requirements on class loading, but I can't find any place where they forbid using other standards. I know adding an optional OSGI manifest could be controversial - but the benefits will be quite big. It would mean you can finally have arbitrary multiple versions of the same package, or have fine control ( using java permissions ) over what packages can be imported in a webapp or plugin. And it would mean an unified model for both webapps and plugins ( connectors, etc ). The other very interesting aspects of eclipse are the extension point and the ( extreme ) laziness in loading plugins. I imagined something a bit like that (with plenty of CLs each containing a particular version of a JAR), but: - I got a big headache, and I don't think I'm capable of not screwing it up :D (so I decided to keep the current CL, which kinda works) - I would take me a lot of time, and it wouldn't be useful to my employer, so they wouldn't be too happy in the end I'd be really curious to see how you implemented all that stuff :) Well, I don't have a lot of free time, so reimplementing all this stuff is not a choice, and I don't want the headaches :-). Eclipse, oscar, knopflerfish ( last 2 with BSD licence ) already implement the class loaders - and there osgi standard is available in many other implementations ( sun embedded web server, etc ). Jboss and eclipse use the same class loading mechanism - and the same model for plugins. It would be really nice if jboss will make one extra step and add the missing features from osgi ( fine control of export/import and use the version information to match the loader ), and even better if they would do this using the standard osgi manifest. I think the granularity of jboss integration is a bit high - what I'm trying is to have each plugin( connector, auth, etc) as well as each webapp in a separate bundle - so you can add/remove/upgrade plugins just like eclipse does, without restart and with on-demand loading. ( I haven't checked the last jboss tough - maybe it alreay does that :-) Anyway - it's work in progress, I don't know all details - the basic stuff obviouslty works ( since it works in jobss as well ), I can load/unload tomcat and individual connectors from eclipse console without problems. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
I committed a few things: - The new deployer is getting there. Missing is the support for the manager webapp, but this won't be too hard to write. - I redid partially the naming. Now the NamingResource object is the main object, and Context is not polluted. My list is: - Update manager webapp, and add support for it in HostConfig (incl JMX registration). - Remove Deployer and DefaultContext. The new stuff looks like a better replacement. - HTML host manager servlet (allows easily creating host and preconfiguring them - ex: with the manager webapp installed, and a default context file). - Try to optimize startup time, if possible. - As mentioned in my commit message, I don't think the dynamic updates to the naming environment are useful. The code which does that is relatively complex (although it's not as bad as before with the ResourceParams). My opinion is that if something is not useful, then it should go ;) Any comments on that fancy feature ? - I'll have a lot of work updating the docs now :-P (I guess the fun is nearly over :( ) - The admin webapp will need some tweaks after removing the DefaultContext. The commit message on my last commit didn't seem to go through, so here it is: - As I discussed earlier, switch to a nicer looking syntax for naming stuff, using setAllProperties. This simplifies the code a lot. - Example: Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / - Remove the horrible ResourceParams, and add new objects for transaction and resourceRefs. - At the same time, big cleanup of the code. - Removing the (completely useless) facading the Context was doing for the NamingResources object. This is something I couldn't do in 4.1.x because we didn't want to change the API. The last thing I didn't remove is some messaging stuff. What's that ? - Some tweaking will likely be needed (for example, the save-to-XML code needs to save all the extra properties). However, a lot of stuff won't need to be adjusted, as it was using NamingResources (I don't think the naming support in the admin webapp is going to need anything). - I'm wondering how useful it is to be able to dynamically update the associated naming context. I think we should remove that, and just reload the webapp (since I think most webapps won't be able to handle dynamic changes in the ENC). I'll post about that in my next progress email. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
I'll volunteer for the admin webapp stuff. I enjoy deleting stuff from there ;-). - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 26, 2004 9:27 AM Subject: Re: [5.next] Progress, more ideas and native connector benchmarks I committed a few things: - The new deployer is getting there. Missing is the support for the manager webapp, but this won't be too hard to write. - I redid partially the naming. Now the NamingResource object is the main object, and Context is not polluted. My list is: - Update manager webapp, and add support for it in HostConfig (incl JMX registration). - Remove Deployer and DefaultContext. The new stuff looks like a better replacement. - HTML host manager servlet (allows easily creating host and preconfiguring them - ex: with the manager webapp installed, and a default context file). - Try to optimize startup time, if possible. - As mentioned in my commit message, I don't think the dynamic updates to the naming environment are useful. The code which does that is relatively complex (although it's not as bad as before with the ResourceParams). My opinion is that if something is not useful, then it should go ;) Any comments on that fancy feature ? - I'll have a lot of work updating the docs now :-P (I guess the fun is nearly over :( ) - The admin webapp will need some tweaks after removing the DefaultContext. The commit message on my last commit didn't seem to go through, so here it is: - As I discussed earlier, switch to a nicer looking syntax for naming stuff, using setAllProperties. This simplifies the code a lot. - Example: Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / - Remove the horrible ResourceParams, and add new objects for transaction and resourceRefs. - At the same time, big cleanup of the code. - Removing the (completely useless) facading the Context was doing for the NamingResources object. This is something I couldn't do in 4.1.x because we didn't want to change the API. The last thing I didn't remove is some messaging stuff. What's that ? - Some tweaking will likely be needed (for example, the save-to-XML code needs to save all the extra properties). However, a lot of stuff won't need to be adjusted, as it was using NamingResources (I don't think the naming support in the admin webapp is going to need anything). - I'm wondering how useful it is to be able to dynamically update the associated naming context. I think we should remove that, and just reload the webapp (since I think most webapps won't be able to handle dynamic changes in the ENC). I'll post about that in my next progress email. 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] Progress, more ideas and native connector benchmarks
Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: Both difference and similarity :-). Eclipse ( osgi actually ) has a similar flat loader implementation, but with finer control over what is exported/imported and pretty strong versioning. In addition osgi supports permissions on importing packages. The reloading of modules is a bit more complicated than in jboss ( where you just change the jar ). From tomcat point of view - the implementation should be very similar with jboss. What I like is the standardized and simpler behavior of class loaders, with ability to reload and upgrade any module ( like jboss ). This classloader looks like it does stuff :) I recommend plugging it in as usual, with the Loader interface. Is that ok ? It should be, plugging tomcat into anything is usually simple. The current tomcat loading mechanism - with 2 hierarchies of class loaders and the delegation hacks, plus the very rigid isolation between webapps - is far from perfect. Again, it's a matter of interpreting the servlet spec - they do have some clear requirements on class loading, but I can't find any place where they forbid using other standards. I know adding an optional OSGI manifest could be controversial - but the benefits will be quite big. It would mean you can finally have arbitrary multiple versions of the same package, or have fine control ( using java permissions ) over what packages can be imported in a webapp or plugin. And it would mean an unified model for both webapps and plugins ( connectors, etc ). The other very interesting aspects of eclipse are the extension point and the ( extreme ) laziness in loading plugins. I imagined something a bit like that (with plenty of CLs each containing a particular version of a JAR), but: - I got a big headache, and I don't think I'm capable of not screwing it up :D (so I decided to keep the current CL, which kinda works) - I would take me a lot of time, and it wouldn't be useful to my employer, so they wouldn't be too happy in the end I'd be really curious to see how you implemented all that stuff :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: Quick question - did you had any discussion on class loaders for 5.next? It's one area I'm playing with, I want to make sure I'm not going in oposite direction :-) I'll tweak the StandardCL to do a bit the same as the WebappCL (ie, try to make it faster). I'll also remove the anti locking hacks which are in WebappCL. Ok. I'm experimenting with having tomcat use other class loaders ( for example if embedded in another app, or used with a different runtime - like eclipse OSGI ). In JBoss, the default is to use the JBoss loader. Is there any big difference ? Both difference and similarity :-). Eclipse ( osgi actually ) has a similar flat loader implementation, but with finer control over what is exported/imported and pretty strong versioning. In addition osgi supports permissions on importing packages. The reloading of modules is a bit more complicated than in jboss ( where you just change the jar ). From tomcat point of view - the implementation should be very similar with jboss. What I like is the standardized and simpler behavior of class loaders, with ability to reload and upgrade any module ( like jboss ). Don't know what dependency injection is, but I hope the next spec won't invent yet another way to do configuration. Sorry for using hype words. I got contaminated, it can happen to anyone. I'll try to shake it off now. I apologise to the community for that, and I won't do it again (hopefully) ;) Well, when I see a buzz word I don't know I try to search it - and what I found on dependency injection is scary ( i.e. avalon and friends ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
Shapira, Yoav wrote: * Default global and per-host configurations: - conf/engine/host/context.xml.default - conf/engine/host/web.xml.default - conf/context.xml - conf/web.xml This will lead to the removal of the DefaultContext interface, since this will fully replace the functionality (while being very simple to implement and actually complete functionality wise; I have no idea why I never thought of doing it this way, since the default web.xml is implemented like that). For the admin webapp support for DefaultContext, we would simply need to register a Context instance in JMX with the usual DefaultContext MBean name, and tweak a little. +1, good idea. I'm getting somewhere with the revised HostConfig and ContextConfig classes. I'll commit stuff this evening as a backup. Right now, it builds (with JDK 1.5 only at the moment), and it sort of runs, but many things aren't done in HostConfig. I'll need to modify the manager webapp when HostConfig is done (but since this will be for removing code from there, it won't be too hard). When it works, I'll proceed with removing the interfaces which start with a 'D' (Deployer and DefaultContext). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
Costin Manolache wrote: Don't know what dependency injection is, but I hope the next spec won't invent yet another way to do configuration. Sorry for using hype words. I got contaminated, it can happen to anyone. I'll try to shake it off now. I apologise to the community for that, and I won't do it again (hopefully) ;) Well, when I see a buzz word I don't know I try to search it - and what I found on dependency injection is scary ( i.e. avalon and friends ). I like the concept a lot more now that it relies less on static typing and annoyances (aka interfaces), and is quite transparent. I'm not willing to use it on anything for now, don't worry. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
Costin Manolache wrote: Both difference and similarity :-). Eclipse ( osgi actually ) has a similar flat loader implementation, but with finer control over what is exported/imported and pretty strong versioning. In addition osgi supports permissions on importing packages. The reloading of modules is a bit more complicated than in jboss ( where you just change the jar ). From tomcat point of view - the implementation should be very similar with jboss. What I like is the standardized and simpler behavior of class loaders, with ability to reload and upgrade any module ( like jboss ). This classloader looks like it does stuff :) I recommend plugging it in as usual, with the Loader interface. Is that ok ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
Remy Maucherat wrote: Costin Manolache wrote: Both difference and similarity :-). Eclipse ( osgi actually ) has a similar flat loader implementation, but with finer control over what is exported/imported and pretty strong versioning. In addition osgi supports permissions on importing packages. The reloading of modules is a bit more complicated than in jboss ( where you just change the jar ). From tomcat point of view - the implementation should be very similar with jboss. What I like is the standardized and simpler behavior of class loaders, with ability to reload and upgrade any module ( like jboss ). This classloader looks like it does stuff :) I recommend plugging it in as usual, with the Loader interface. Is that ok ? It should be, plugging tomcat into anything is usually simple. The current tomcat loading mechanism - with 2 hierarchies of class loaders and the delegation hacks, plus the very rigid isolation between webapps - is far from perfect. Again, it's a matter of interpreting the servlet spec - they do have some clear requirements on class loading, but I can't find any place where they forbid using other standards. I know adding an optional OSGI manifest could be controversial - but the benefits will be quite big. It would mean you can finally have arbitrary multiple versions of the same package, or have fine control ( using java permissions ) over what packages can be imported in a webapp or plugin. And it would mean an unified model for both webapps and plugins ( connectors, etc ). The other very interesting aspects of eclipse are the extension point and the ( extreme ) laziness in loading plugins. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.next] Progress, more ideas and native connector benchmarks
Hola, * Redo naming resources configuration using setAllProperties rule to make the XML less verbose. Example: Resource name=bean/MyBeanFactory auth=Container type=com.mycompany.MyBean factory=org.apache.naming.factory.BeanFactory bar=23/ I personally really like this (and use setAllProperties extensively in my own projects). The only knock against this approach is that the Servlet Spec uses the verbose param-name/param-value pairs all over the place, and being a servlet container we may wish to stick to the same spirit. * Default global and per-host configurations: - conf/engine/host/context.xml.default - conf/engine/host/web.xml.default - conf/context.xml - conf/web.xml This will lead to the removal of the DefaultContext interface, since this will fully replace the functionality (while being very simple to implement and actually complete functionality wise; I have no idea why I never thought of doing it this way, since the default web.xml is implemented like that). For the admin webapp support for DefaultContext, we would simply need to register a Context instance in JMX with the usual DefaultContext MBean name, and tweak a little. +1, good idea. * HTML host manager servlet (allows easily creating host and preconfiguring them - ex: with the manager webapp installed, and a default context file). I think this would be useful (?). There have been several requests along these lines on the tomcat-user mailing list, so I'd say it'd be useful. I think I'm nearing the point where I'll submit a release plan for this branch (let's say at the end of next week), since I don't see much more to add for now besides more tweaking. Looking forward to it. What is the status of Logger removal/rewriting/rethinking? Yoav 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] Progress, more ideas and native connector benchmarks
Quick question - did you had any discussion on class loaders for 5.next? It's one area I'm playing with, I want to make sure I'm not going in oposite direction :-) BTW - another feature idea would be to extend the JMX configuration into the webapps, i.e. allow jmx apps to view and configure context and servlet params, and support servlets implementing MBean interfaces. The init(ServletConfig) model is pretty archaic :-) Costin Remy Maucherat wrote: I've had a few more feature ideas (actually, it's more tweaks and simple things than big development for the most part), and I'm refining the way I'll be implementing the new deployer. * Parse element Context (if context config file) in HostConfig, for className, path and docBase attributes. * Parse remaining of element Context in ContextConfig (after defaultcontext). * unpackWars in HostConfig (in most cases, it's done there already). * Any resource removal when undeploy in HostConfig. * anti-resource-locking (optional feature) in ContextConfig (by mutating the docBase, and copying the whole webapp elsewhere). * Redo naming resources configuration using setAllProperties rule to make the XML less verbose. Example: Resource name=bean/MyBeanFactory auth=Container type=com.mycompany.MyBean factory=org.apache.naming.factory.BeanFactory bar=23/ * Default global and per-host configurations: - conf/engine/host/context.xml.default - conf/engine/host/web.xml.default - conf/context.xml - conf/web.xml This will lead to the removal of the DefaultContext interface, since this will fully replace the functionality (while being very simple to implement and actually complete functionality wise; I have no idea why I never thought of doing it this way, since the default web.xml is implemented like that). For the admin webapp support for DefaultContext, we would simply need to register a Context instance in JMX with the usual DefaultContext MBean name, and tweak a little. * HTML host manager servlet (allows easily creating host and preconfiguring them - ex: with the manager webapp installed, and a default context file). I think this would be useful (?). * The other features I mentioned earlier: startup time optimization, removal of stuff which isn't used (such as container listeners). Note: I'll initially commit some of the updated deployer work as JDK 1.5 sources, and I'll change back to JDK 1.4 sources a bit later. It's very easy to do (although it hurts: I'm getting used to typing for collections way too fast ;) ), and I'm using this opportunity to really play with the new JDK. How will this compile for people using JDK1.4 - or gump ? I think I'm nearing the point where I'll submit a release plan for this branch (let's say at the end of next week), since I don't see much more to add for now besides more tweaking. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
Shapira, Yoav wrote: Hola, * Redo naming resources configuration using setAllProperties rule to make the XML less verbose. Example: Resource name=bean/MyBeanFactory auth=Container type=com.mycompany.MyBean factory=org.apache.naming.factory.BeanFactory bar=23/ I personally really like this (and use setAllProperties extensively in my own projects). The only knock against this approach is that the Servlet Spec uses the verbose param-name/param-value pairs all over the place, and being a servlet container we may wish to stick to the same spirit. Yes. It's not as important IMO, since a data source will require a large amount of parameters (= very verbose). Looking forward to it. What is the status of Logger removal/rewriting/rethinking? The Logger interface is now removed. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
Costin Manolache wrote: Quick question - did you had any discussion on class loaders for 5.next? It's one area I'm playing with, I want to make sure I'm not going in oposite direction :-) I'll tweak the StandardCL to do a bit the same as the WebappCL (ie, try to make it faster). I'll also remove the anti locking hacks which are in WebappCL. BTW - another feature idea would be to extend the JMX configuration into the webapps, i.e. allow jmx apps to view and configure context and servlet params, and support servlets implementing MBean interfaces. The init(ServletConfig) model is pretty archaic :-) You're touching the application layer here. I'm not really in favor of allowing proprietary stuff in that area (Tomcat has been pretty strict about that in the past, with very few features being added). The init model is indeed archaic (I think it's a good cadidate for being replaced with dependency injection in the next spec, but we're not there yet) ;) The Context and Wrapper are both modeled: I don't see why an app couldn't access with JMX that if it wants to. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
Remy Maucherat wrote: Costin Manolache wrote: Quick question - did you had any discussion on class loaders for 5.next? It's one area I'm playing with, I want to make sure I'm not going in oposite direction :-) I'll tweak the StandardCL to do a bit the same as the WebappCL (ie, try to make it faster). I'll also remove the anti locking hacks which are in WebappCL. Ok. I'm experimenting with having tomcat use other class loaders ( for example if embedded in another app, or used with a different runtime - like eclipse OSGI ). BTW - another feature idea would be to extend the JMX configuration into the webapps, i.e. allow jmx apps to view and configure context and servlet params, and support servlets implementing MBean interfaces. The init(ServletConfig) model is pretty archaic :-) You're touching the application layer here. I'm not really in favor of allowing proprietary stuff in that area (Tomcat has been pretty strict about that in the past, with very few features being added). The init model is indeed archaic (I think it's a good cadidate for being replaced with dependency injection in the next spec, but we're not there yet) ;) The Context and Wrapper are both modeled: I don't see why an app couldn't access with JMX that if it wants to. JMX is not proprietary :-) Don't know what dependency injection is, but I hope the next spec won't invent yet another way to do configuration. The context and wrapper have associated JMX mbeans, and that's nice - but they only work on the 'envelope', they provide some measurements and configurability for the wrapper, without any interaction with the servlet itself. What I'm intereseted is how can a servlet implement MBean ( again, there is nothing in the servlet spec preventing a servlet to implement another standard interface ), and how can it register itself. And then how tomcat ( or some jmx module ) could interact with this. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: re: [5.next] progress, more ideas and native connector benchmarks
THIS IS AN AUTOMATED RESPONSE FROM CDZONE Thank you for contacting us. If your enquiry is covered by the list below please visit our web site at http://www.cdzone.co.uk/accounts where you can: * Check your order status - we are unable to provide any more detailed information about delivery times than that shown on your order status page * Obtain your password to access our site * Report shipments lost or damaged in the post * Report items faulty or sent in error * Add or change your email address * Change your delivery address * Change your payment details If your query is not covered by the above please write back to us including the tracking number 7D9CAFFEC89F78CB11C1032AB212D2C4 in the subject of your message to avoid receiving this message again. Please don't request tracklists, sleeve scans, etc. If we have the information it will be on the web site. If your request is covered by the above listed items we will be unable to assist you personally - please use the web site. The top 20 lines of your message were: Remy Maucherat wrote: Costin Manolache wrote: Quick question - did you had any discussion on class loaders for 5.next? It's one area I'm playing with, I want to make sure I'm not going in oposite direction :-) I'll tweak the StandardCL to do a bit the same as the WebappCL (ie, try to make it faster). I'll also remove the anti locking hacks which are in WebappCL. Ok. I'm experimenting with having tomcat use other class loaders ( for example if embedded in another app, or used with a different runtime - like eclipse OSGI ). BTW - another feature idea would be to extend the JMX configuration into the webapps, i.e. allow jmx apps to view and configure context - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: Quick question - did you had any discussion on class loaders for 5.next? It's one area I'm playing with, I want to make sure I'm not going in oposite direction :-) I'll tweak the StandardCL to do a bit the same as the WebappCL (ie, try to make it faster). I'll also remove the anti locking hacks which are in WebappCL. Ok. I'm experimenting with having tomcat use other class loaders ( for example if embedded in another app, or used with a different runtime - like eclipse OSGI ). In JBoss, the default is to use the JBoss loader. Is there any big difference ? BTW - another feature idea would be to extend the JMX configuration into the webapps, i.e. allow jmx apps to view and configure context and servlet params, and support servlets implementing MBean interfaces. The init(ServletConfig) model is pretty archaic :-) You're touching the application layer here. I'm not really in favor of allowing proprietary stuff in that area (Tomcat has been pretty strict about that in the past, with very few features being added). The init model is indeed archaic (I think it's a good cadidate for being replaced with dependency injection in the next spec, but we're not there yet) ;) The Context and Wrapper are both modeled: I don't see why an app couldn't access with JMX that if it wants to. JMX is not proprietary :-) Yes, but allowing to configure webapps in Tomcat using it is ;) Don't know what dependency injection is, but I hope the next spec won't invent yet another way to do configuration. Sorry for using hype words. I got contaminated, it can happen to anyone. I'll try to shake it off now. I apologise to the community for that, and I won't do it again (hopefully) ;) The context and wrapper have associated JMX mbeans, and that's nice - but they only work on the 'envelope', they provide some measurements and configurability for the wrapper, without any interaction with the servlet itself. What I'm intereseted is how can a servlet implement MBean ( again, there is nothing in the servlet spec preventing a servlet to implement another standard interface ), and how can it register itself. And then how tomcat ( or some jmx module ) could interact with this. Ah, ok. Well, I don't have that or anything related on my list, so there's no conflict ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.next] Progress
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]
Re: [5.next] Progress
Filip Hanik (lists) wrote: 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. Yes for the first part. I think it's misleading to call that the autodeployer, though, as that component will become the deployer (the deployment code is spread and duplicated right now, so the spaghetti needs to go). For the second part, I don't understand. This seems to hint at the existence of a master node, which would be bad, no ? 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. I don't get that sent data thing, but you can use either the workdir or the tempdir (as usual). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.next] Progress
This is how it works currently. There is a listen directory. If you deploy an app to any of the nodes on the cluster, into the listen directory, it will deploy that app to the other nodes in the cluster. It deploys it into a deployed dir, if an app is removed from that dir, a message is broadcasted to the other nodes to undeploy the app. So it could work the same way, but use the tomcat dirs instead of new ones. And yes, the work dir is the place to store the file fragments. cheerios Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Saturday, July 17, 2004 1:05 PM To: Tomcat Developers List Subject: Re: [5.next] Progress Filip Hanik (lists) wrote: 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. Yes for the first part. I think it's misleading to call that the autodeployer, though, as that component will become the deployer (the deployment code is spread and duplicated right now, so the spaghetti needs to go). For the second part, I don't understand. This seems to hint at the existence of a master node, which would be bad, no ? 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. I don't get that sent data thing, but you can use either the workdir or the tempdir (as usual). 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.721 / Virus Database: 477 - Release Date: 7/16/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]
Re: [5.next] Progress
On Thu, 15 Jul 2004, Remy Maucherat wrote: | Jess Holle wrote: | Just a note: | | Please allow the anti-locking stuff to be skipped on Windows as well. | [Some of us value performance over deployment convenience.] | | Yes, of course. In production, many people don't use hot deployment (it | doesn't give good enough QoS right now, IMO). | | - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX | and JMX | remote, etc) | | It would be good to get many of the changes listed above this last point | available in 5.0.x and usable with JDK 1.4.2 and then branch to 5.1 and | do 1.5-specific goodies. | | No for 5.0.x, as nearly everything in my list requires API breakage :( | For now, I don't have any JDK 1.5 features in mind: this item is there | just in case. In my opinion, it is very bad to require the -latest- JDK there is for such low-level software-stack-components as the Servlet Container is. I mean, the 1.5 (5.0) isn't even released! There should at least be a couple of viable JDKs of a particular version, before you intend to depend Tomcat on it (e.g. when IBM, SUN, JRockit and a couple of others (!) have a J2SDK 5.0-version out, you might consider it). Any depedencies on 1.5 should -most definately- be done using introspection or configurable 1.5 classes that you can add if you want. IMHO, I think you should make Tomcat run perfectly, and actually develop it, on 1.3. Endre PS: What an IDIOTIC versioning scheme Sun is using!! What on earth is the idea with Java -2-, and then upping the minor-versioning to -5-?? Java 2 version 5.0.. WHAT??? It actually pisses me off - can't we just say Java 5, then? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: [5.next] Progress
Remy Maucherat wrote: 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 Just a note: Please allow the anti-locking stuff to be skipped on Windows as well. [Some of us value performance over deployment convenience.] * 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) It would be good to get many of the changes listed above this last point available in 5.0.x and usable with JDK 1.4.2 and then branch to 5.1 and do 1.5-specific goodies. - 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) -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Jess Holle wrote: Just a note: Please allow the anti-locking stuff to be skipped on Windows as well. [Some of us value performance over deployment convenience.] Yes, of course. In production, many people don't use hot deployment (it doesn't give good enough QoS right now, IMO). - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) It would be good to get many of the changes listed above this last point available in 5.0.x and usable with JDK 1.4.2 and then branch to 5.1 and do 1.5-specific goodies. No for 5.0.x, as nearly everything in my list requires API breakage :( For now, I don't have any JDK 1.5 features in mind: this item is there just in case. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote: Jess Holle wrote: Just a note: Please allow the anti-locking stuff to be skipped on Windows as well. [Some of us value performance over deployment convenience.] Yes, of course. In production, many people don't use hot deployment (it doesn't give good enough QoS right now, IMO). - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) It would be good to get many of the changes listed above this last point available in 5.0.x and usable with JDK 1.4.2 and then branch to 5.1 and do 1.5-specific goodies. No for 5.0.x, as nearly everything in my list requires API breakage :( That includes the anti-locking stuff? That's unfortunate as I was hoping to see that in 5.0.x Oh well. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote: Jess Holle wrote: Though I also really like Java 5's [yep, another neat numbering change from Sun :-)] built-MBeans for JVM monitoring, I'd *really* like to see a JSR 160 solution in Tomcat that works in Java 1.4.x and Java 1.5 (aka 5). Is this the plan/hope? At a high level it does not look too nasty to do this Unfortunately, I'm against useless code in this branch. JSR 160 being brand new, you're going to need new software pretty much everywhere, but of course upgrading the JDK is not an option. Given the new branch changes the API rather significantly, I think it's not going to be a release people will be upgrading to. If it still doesn't make sense, then you can probably manage to cut paste a few lines of code from the JMX docs, right ? ;) sin I'll play with this as I have time, but I'll be doing the same sort of thing with our own app first. As I see it (and I could be offbase, of course, as I've not had time to code this), one just needs a pluggable SPI sort of interface responsible for: 1. A singleton get-or-create MBeanServer method * Default to platform MBeanServer in 1.5, but allow use of mx4j or the like 2. An export MBeanServer for remote ops method * Details, e.g. protocols, ports / port ranges, etc, to be controlled by XML tags, of course Am I over-simplifying this? -- Jess Holle
Re: [5.next] Progress
Jess Holle wrote: I'll play with this as I have time, but I'll be doing the same sort of thing with our own app first. As I see it (and I could be offbase, of course, as I've not had time to code this), one just needs a pluggable SPI sort of interface responsible for: 1. A singleton get-or-create MBeanServer method * Default to platform MBeanServer in 1.5, but allow use of mx4j or the like 2. An export MBeanServer for remote ops method * Details, e.g. protocols, ports / port ranges, etc, to be controlled by XML tags, of course Am I over-simplifying this? It's the exact opposite. With JDK 1.5, we need no pluggable something, no nothing. So this is why I really want to do that instead of bothering with more dead code. I'm ok with a special JDK 1.4 package full of optional components being put together (assuming none of the new syntax gets used, of course), which could contain your listener and other JARs (like Xerces). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Jess Holle wrote: Though I also really like Java 5's [yep, another neat numbering change from Sun :-)] built-MBeans for JVM monitoring, I'd *really* like to see a JSR 160 solution in Tomcat that works in Java 1.4.x and Java 1.5 (aka 5). Is this the plan/hope? At a high level it does not look too nasty to do this Unfortunately, I'm against useless code in this branch. JSR 160 being brand new, you're going to need new software pretty much everywhere, but of course upgrading the JDK is not an option. Given the new branch changes the API rather significantly, I think it's not going to be a release people will be upgrading to. If it still doesn't make sense, then you can probably manage to cut paste a few lines of code from the JMX docs, right ? ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote: Jess Holle wrote: I'll play with this as I have time, but I'll be doing the same sort of thing with our own app first. As I see it (and I could be offbase, of course, as I've not had time to code this), one just needs a pluggable SPI sort of interface responsible for: 1. A singleton get-or-create MBeanServer method * Default to platform MBeanServer in 1.5, but allow use of mx4j or the like 2. An export MBeanServer for remote ops method * Details, e.g. protocols, ports / port ranges, etc, to be controlled by XML tags, of course Am I over-simplifying this? It's the exact opposite. With JDK 1.5, we need no pluggable something, no nothing. So this is why I really want to do that instead of bothering with more dead code. In my case even with 1.5 I need a pluggable (2) from above. Why? Because I need to work with port ranges and grab the first free port (with MBeans then proxied to a daemon with a consistent port #). 1.5 has no automatic machinery for this as best I can tell. It's true that (1) is simple getPlatformMbeanServer() [or whatever it is called again] in 1.5, but I believe it should be light and easy enough to stick something else under the covers here. I'm ok with a special JDK 1.4 package full of optional components being put together (assuming none of the new syntax gets used, of course), which could contain your listener and other JARs (like Xerces). Cool. As I said though, I've got my own processes to instrument first. I'd just like to see Tomcat progress in a similar fashion so that one monitor Tomcat in the same fashion sooner rather than later. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Jess Holle wrote: In my case even with 1.5 I need a pluggable (2) from above. Why? Because I need to work with port ranges and grab the first free port (with MBeans then proxied to a daemon with a consistent port #). 1.5 has no automatic machinery for this as best I can tell. It's true that (1) is simple getPlatformMbeanServer() [or whatever it is called again] in 1.5, but I believe it should be light and easy enough to stick something else under the covers here. I'm tired of interfaces, so I have to say I'm against this, especially for a specific purpose (I would tend to believe you can configure lots of stuff with JDK 1.5, though). You should simply use your own server listener (I think server lifecycle listeners are here to stay). Cool. As I said though, I've got my own processes to instrument first. I'd just like to see Tomcat progress in a similar fashion so that one monitor Tomcat in the same fashion sooner rather than later. Regardless on how the JMX connector is configured on the server side, it will work the same from the client's perspective. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote: Jess Holle wrote: In my case even with 1.5 I need a pluggable (2) from above. Why? Because I need to work with port ranges and grab the first free port (with MBeans then proxied to a daemon with a consistent port #). 1.5 has no automatic machinery for this as best I can tell. It's true that (1) is simple getPlatformMbeanServer() [or whatever it is called again] in 1.5, but I believe it should be light and easy enough to stick something else under the covers here. I'm tired of interfaces, so I have to say I'm against this, especially for a specific purpose (I would tend to believe you can configure lots of stuff with JDK 1.5, though). You should simply use your own server listener (I think server lifecycle listeners are here to stay). Cool. As I said though, I've got my own processes to instrument first. I'd just like to see Tomcat progress in a similar fashion so that one monitor Tomcat in the same fashion sooner rather than later. Regardless on how the JMX connector is configured on the server side, it will work the same from the client's perspective. Yep. I'm just anxious to see JMX RMI remoting support in Tomcat soon, i.e. in a stable shipping version that supports a stable, shipping JRE (i.e. 1.4.2). -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Hello Jess, I have made a test with MX4J 2.0.1 and JSR 160 Connector. See my patches http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29259 Testet with MC4J Console and works very well. regards Peter Jess Holle schrieb: Remy Maucherat wrote: Jess Holle wrote: In my case even with 1.5 I need a pluggable (2) from above. Why? Because I need to work with port ranges and grab the first free port (with MBeans then proxied to a daemon with a consistent port #). 1.5 has no automatic machinery for this as best I can tell. It's true that (1) is simple getPlatformMbeanServer() [or whatever it is called again] in 1.5, but I believe it should be light and easy enough to stick something else under the covers here. I'm tired of interfaces, so I have to say I'm against this, especially for a specific purpose (I would tend to believe you can configure lots of stuff with JDK 1.5, though). You should simply use your own server listener (I think server lifecycle listeners are here to stay). Cool. As I said though, I've got my own processes to instrument first. I'd just like to see Tomcat progress in a similar fashion so that one monitor Tomcat in the same fashion sooner rather than later. Regardless on how the JMX connector is configured on the server side, it will work the same from the client's perspective. Yep. I'm just anxious to see JMX RMI remoting support in Tomcat soon, i.e. in a stable shipping version that supports a stable, shipping JRE (i.e. 1.4.2). -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://www.webapp.de/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
- Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) I have made prototype for mx4J JSR 160 support it looks very nice. Can't we refactor the ServerLifecycleListener also? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29259 No, that listener needs to go IMO. This listener is useless in the end (for this branch): this is done at the VM level much more cleanly, and the VM also provides tons of runtime statistics that nobody will want to live without. I'll rethink my position if J2SE 5 (I'm learning ;) ) turns out bad somehow, but I don't think the core VM is a big rewrite, so I expect it to be stable. I'll start using it soon for my builds and testing, and I'll see how it goes. Though I also really like Java 5's [yep, another neat numbering change from Sun :-)] built-MBeans for JVM monitoring, I'd *really* like to see a JSR 160 solution in Tomcat that works in Java 1.4.x and Java 1.5 (aka 5). Is this the plan/hope? At a high level it does not look too nasty to do this -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Jeanfrancois Arcand wrote: Remy Maucherat wrote: Remy Maucherat wrote: My upcoming change list: - 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 Speaking of which, does anyone know any OSes (besides Windows) which lock files ? NFS sometimes lock file (I did see a similar problem with Solaris) Thanks for the tip. I'll code in Windows by default, and add a flag to enable/disable then, since I don't think there's a way to determine if something is coming from NFS. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote, On 7/2/2004 2:13 AM: Jeanfrancois Arcand wrote: Remy Maucherat wrote: Speaking of which, does anyone know any OSes (besides Windows) which lock files ? NFS sometimes lock file (I did see a similar problem with Solaris) Thanks for the tip. I'll code in Windows by default, and add a flag to enable/disable then, since I don't think there's a way to determine if something is coming from NFS. Although you can lock files over NFS on Unix systems, it should behave no differently than if you were to lock the file on any other filesystem. In other words, unless you explicitly lock the file and check that the file is locked (as locks are only advisory on Unix, they don't stop you from performing any operations if you really want to) you should not have any of the same file locking issues on Unix that you do on Windows. See the the flock and fcntl man pages for more information on Unix file locking. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote: Remy Maucherat wrote: My upcoming change list: - 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 Speaking of which, does anyone know any OSes (besides Windows) which lock files ? NFS sometimes lock file (I did see a similar problem with Solaris) -- Jeanfrancois 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] Progress
Hello, I have start a Server saved implementation. - Externalize configuration saving out of StandardServer features: * splitt implementation from StandardServer class * refactor the current save methods to some helper classes * every save element from server.xml dialect has it own save factory * central Mbean that have a registry for save factories * save complete Server,Engine,Host or Context xml's * support cluster elements * implement with testcases options: * configure the save factories from xml or properties files. * better backup handling / not only for server.xml, also for context.xmls :-) I hope the first implementation is ready at this weekend. == see some comments directly at the 5.next topics. regards peter Remy Maucherat schrieb: My upcoming change list: - 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 Good option. * 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) see some change requests at my today proposal... HostConfig/Deployer - Use the webapp CL as the main CL (without the locking tricks it is likely faster than the regular CL) - Default servlet refactoring and optimization (avoid ResourceInfo class, MIME mapping matching) - Resolve DBCP - Pool - Collections dependency which exposes too many JARs in the common classloader (using package renaming and some repackaging) - Externalize configuration saving out of StandardServer I can do that. - Remove anything useless (spring cleaning time), such as configuration options, container listeners (to be replaced with JMX notifications where it matters), etc Very good. I have a made a NotificationEmitter Inteface support for StandardContext an StandardWrapper, but it exist some problems at current JSR 77 notification support. Please look at my proposal or the bugreport http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29869 - BASIC auth optimization - clutering module refactoring, to extend the regular Catalina objects, for easier future maintenance I have a talk with Rainer Jung, and his changes to cluster implementation looks very good. - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) I have made prototype for mx4J JSR 160 support it looks very nice. Can't we refactor the ServerLifecycleListener also? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29259 - And the ongoing: allow all config/management/embedding through JMX; note: I think this is almost there already (thanks Costin), so only a little tweaking will likely be needed YES! So there are still a number of big changes waiting to be implemented, and these should have a bigger impact than my initial changes. I'll do the deployer and classloader changes first, which is the biggest chunk. When I'm done with the remove anything useless item, I'll propose a release plan. Any items to the list (anyone proposing something must be willing to timely implement what he's proposing, I'm not running a wish list ;) ) ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Peter Rossbach wrote: Hello, I have start a Server saved implementation. - Externalize configuration saving out of StandardServer features: * splitt implementation from StandardServer class * refactor the current save methods to some helper classes * every save element from server.xml dialect has it own save factory * central Mbean that have a registry for save factories * save complete Server,Engine,Host or Context xml's * support cluster elements * implement with testcases options: * configure the save factories from xml or properties files. * better backup handling / not only for server.xml, also for context.xmls :-) I hope the first implementation is ready at this weekend. Sure, show me the code. see some comments directly at the 5.next topics. Remy Maucherat schrieb: My upcoming change list: - 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 Good option. I'm so tired of Windows right now ... - Externalize configuration saving out of StandardServer I can do that. I was planning to do it in 5 minutes (take the current code, put it in separate class, ) - BASIC auth optimization - clutering module refactoring, to extend the regular Catalina objects, for easier future maintenance I have a talk with Rainer Jung, and his changes to cluster implementation looks very good. Ah ok. Filip was planning (to be forced through any means necessary) to do that, so ask him. - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) I have made prototype for mx4J JSR 160 support it looks very nice. Can't we refactor the ServerLifecycleListener also? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29259 No, that listener needs to go IMO. This listener is useless in the end (for this branch): this is done at the VM level much more cleanly, and the VM also provides tons of runtime statistics that nobody will want to live without. I'll rethink my position if J2SE 5 (I'm learning ;) ) turns out bad somehow, but I don't think the core VM is a big rewrite, so I expect it to be stable. I'll start using it soon for my builds and testing, and I'll see how it goes. - And the ongoing: allow all config/management/embedding through JMX; note: I think this is almost there already (thanks Costin), so only a little tweaking will likely be needed YES! Lol. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Ah ok. Filip was planning (to be forced through any means necessary) to do that, so ask him. yup, still planning on doing so :) just a little slammed with paying work at the moment Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, June 30, 2004 8:47 AM Subject: Re: [5.next] Progress Peter Rossbach wrote: Hello, I have start a Server saved implementation. - Externalize configuration saving out of StandardServer features: * splitt implementation from StandardServer class * refactor the current save methods to some helper classes * every save element from server.xml dialect has it own save factory * central Mbean that have a registry for save factories * save complete Server,Engine,Host or Context xml's * support cluster elements * implement with testcases options: * configure the save factories from xml or properties files. * better backup handling / not only for server.xml, also for context.xmls :-) I hope the first implementation is ready at this weekend. Sure, show me the code. see some comments directly at the 5.next topics. Remy Maucherat schrieb: My upcoming change list: - 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 Good option. I'm so tired of Windows right now ... - Externalize configuration saving out of StandardServer I can do that. I was planning to do it in 5 minutes (take the current code, put it in separate class, ) - BASIC auth optimization - clutering module refactoring, to extend the regular Catalina objects, for easier future maintenance I have a talk with Rainer Jung, and his changes to cluster implementation looks very good. Ah ok. Filip was planning (to be forced through any means necessary) to do that, so ask him. - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) I have made prototype for mx4J JSR 160 support it looks very nice. Can't we refactor the ServerLifecycleListener also? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29259 No, that listener needs to go IMO. This listener is useless in the end (for this branch): this is done at the VM level much more cleanly, and the VM also provides tons of runtime statistics that nobody will want to live without. I'll rethink my position if J2SE 5 (I'm learning ;) ) turns out bad somehow, but I don't think the core VM is a big rewrite, so I expect it to be stable. I'll start using it soon for my builds and testing, and I'll see how it goes. - And the ongoing: allow all config/management/embedding through JMX; note: I think this is almost there already (thanks Costin), so only a little tweaking will likely be needed YES! Lol. 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] Progress
Hey Remy, OK, I am do my best that the save factory implementation work at weekend. s. comments... Regards Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hello, I have start a Server saved implementation. - Externalize configuration saving out of StandardServer features: * splitt implementation from StandardServer class * refactor the current save methods to some helper classes * every save element from server.xml dialect has it own save factory * central Mbean that have a registry for save factories * save complete Server,Engine,Host or Context xml's * support cluster elements * implement with testcases options: * configure the save factories from xml or properties files. * better backup handling / not only for server.xml, also for context.xmls :-) I hope the first implementation is ready at this weekend. Sure, show me the code. see some comments directly at the 5.next topics. Remy Maucherat schrieb: My upcoming change list: - 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 Good option. I'm so tired of Windows right now ... But few of the developers wan't work at linux :-\ ... - Externalize configuration saving out of StandardServer I can do that. I was planning to do it in 5 minutes (take the current code, put it in separate class, ) Ohh, that was also my first step, but after a deeper look: I made a bigger redesign step to support also cluster and I hope more modules in the future. - BASIC auth optimization - clutering module refactoring, to extend the regular Catalina objects, for easier future maintenance I have a talk with Rainer Jung, and his changes to cluster implementation looks very good. Ah ok. Filip was planning (to be forced through any means necessary) to do that, so ask him. - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) I have made prototype for mx4J JSR 160 support it looks very nice. Can't we refactor the ServerLifecycleListener also? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29259 No, that listener needs to go IMO. This listener is useless in the end (for this branch): this is done at the VM level much more cleanly, and the VM also provides tons of runtime statistics that nobody will want to live without. I'll rethink my position if J2SE 5 (I'm learning ;) ) turns out bad somehow, but I don't think the core VM is a big rewrite, so I expect it to be stable. I'll start using it soon for my builds and testing, and I'll see how it goes. OK, I thing also that a VM-JMX support are a better way. - And the ongoing: allow all config/management/embedding through JMX; note: I think this is almost there already (thanks Costin), so only a little tweaking will likely be needed YES! Lol. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://www.webapp.de/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Peter Rossbach wrote: Hey Remy, OK, I am do my best that the save factory implementation work at weekend. A good patch is better than a rushed patch ;) I'm so tired of Windows right now ... But few of the developers wan't work at linux :-\ ... Yes, but the fact that M$ failed to address core issues in its OS for the years is simply not acceptable. No, that listener needs to go IMO. This listener is useless in the end (for this branch): this is done at the VM level much more cleanly, and the VM also provides tons of runtime statistics that nobody will want to live without. I'll rethink my position if J2SE 5 (I'm learning ;) ) turns out bad somehow, but I don't think the core VM is a big rewrite, so I expect it to be stable. I'll start using it soon for my builds and testing, and I'll see how it goes. OK, I thing also that a VM-JMX support are a better way. Your tweaked listener could be useful in the 5.0.x branch, but never looked at it, so I don't know. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote: My upcoming change list: - 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 Speaking of which, does anyone know any OSes (besides Windows) which lock files ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
