Re: Jk2 object model + Netware OT
Good morning Michael. Please excuse the OT post. In my testing of Mod_Jk2 on NW6sp3, found I kept getting server abends when processing [uri] sections in the workers2.properties file. I was wondering if you were able to solve this or developed a work-around perhaps? Thanks for any assistance. Norm - Original Message - From: Mike Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 13, 2004 5:01 AM Subject: RE: Jk2 object model I'm definitely interested in helping with this but feel I'm out of the loop a little. What areas would be best for me to research (JMX, jchannels, current mod_jk/mod_jk2 architecture, etc.) to be the most help? I'm somewhat familiar with the mod_jk stuff from supporting it on NetWare, and have started looking at mod_jk2 (it now mostly works on NetWare with Apache 2) but I know I'm behind in some of the other areas that have been mentioned. Where can I help? Mike Anderson [EMAIL PROTECTED] 1/11/2004 2:17:12 AM From: Costin Manolache Sent: 11. sije*anj 2004 2:36 To: Tomcat Developers List Subject: Re: Jk2 object model But this time I'd like to spend a month or so doing 'real' design without the single line of code. If we manage to put and describe our needs on the paper, the coding itself will took insignificant amount of time. If this plan shows that 90% of the existing codebase can be reused; even better. The first thing ( IMO ) is to decide on what improvements we need on the lower layer so it can satisfy any additional needs you may have - configuration, performance, integration with a wider set of applications, etc. We can do that for sure. Depends on how we approach to the 'evolution'. We can either try to find out how to 'adapt' the existing codebase or 'use' from the existing codebase. I would like to see a design or plan, or what ever you name it, that wouldn't limit itself from the start with the choose of JK, JK2 or webapp as a starting point, but rather use all of them as a knowledge-base foundation. Again, the major question is are there any developer needs and willing for that. I'll try to make some diagrams and some docs that will show what I have on my mind. This may even show that I've completely 'miss the subject' :-). MT. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
I'm definitely interested in helping with this but feel I'm out of the loop a little. What areas would be best for me to research (JMX, jchannels, current mod_jk/mod_jk2 architecture, etc.) to be the most help? I'm somewhat familiar with the mod_jk stuff from supporting it on NetWare, and have started looking at mod_jk2 (it now mostly works on NetWare with Apache 2) but I know I'm behind in some of the other areas that have been mentioned. Where can I help? Mike Anderson [EMAIL PROTECTED] 1/11/2004 2:17:12 AM From: Costin Manolache Sent: 11. sije*anj 2004 2:36 To: Tomcat Developers List Subject: Re: Jk2 object model But this time I'd like to spend a month or so doing 'real' design without the single line of code. If we manage to put and describe our needs on the paper, the coding itself will took insignificant amount of time. If this plan shows that 90% of the existing codebase can be reused; even better. The first thing ( IMO ) is to decide on what improvements we need on the lower layer so it can satisfy any additional needs you may have - configuration, performance, integration with a wider set of applications, etc. We can do that for sure. Depends on how we approach to the 'evolution'. We can either try to find out how to 'adapt' the existing codebase or 'use' from the existing codebase. I would like to see a design or plan, or what ever you name it, that wouldn't limit itself from the start with the choose of JK, JK2 or webapp as a starting point, but rather use all of them as a knowledge-base foundation. Again, the major question is are there any developer needs and willing for that. I'll try to make some diagrams and some docs that will show what I have on my mind. This may even show that I've completely 'miss the subject' :-). MT. - 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: Jk2 object model
From: Costin Manolache Sent: 11. sijeanj 2004 2:36 To: Tomcat Developers List Subject: Re: Jk2 object model But this time I'd like to spend a month or so doing 'real' design without the single line of code. If we manage to put and describe our needs on the paper, the coding itself will took insignificant amount of time. If this plan shows that 90% of the existing codebase can be reused; even better. The first thing ( IMO ) is to decide on what improvements we need on the lower layer so it can satisfy any additional needs you may have - configuration, performance, integration with a wider set of applications, etc. We can do that for sure. Depends on how we approach to the 'evolution'. We can either try to find out how to 'adapt' the existing codebase or 'use' from the existing codebase. I would like to see a design or plan, or what ever you name it, that wouldn't limit itself from the start with the choose of JK, JK2 or webapp as a starting point, but rather use all of them as a knowledge-base foundation. Again, the major question is are there any developer needs and willing for that. I'll try to make some diagrams and some docs that will show what I have on my mind. This may even show that I've completely 'miss the subject' :-). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
Mladen Turk wrote: From: Henri Gomez As many I feel that jk (and maybe also jk2) are now pretty stable, and I don't see the need for a new just web/tomcat connector. Finally someone :-). That's why I did try to use the revolutionary approach. Jet another connector wouldn't make a much difference (quite contrary thought). If there is a need among community for slightly different-then-connector approach (I've used the term integrator, and IMO it would better describe that new concept), we should discuss that further. But this time I'd like to spend a month or so doing 'real' design without the single line of code. If we manage to put and describe our needs on the paper, the coding itself will took insignificant amount of time. If this plan shows that 90% of the existing codebase can be reused; even better. Good luck with that... I don't believe in real design without a single line of code - and I'm not quite sure about putting the needs on paper ( at least not in the sense you seem to mean it ). One thing should be clear - existing needs must continue to work - for example even if a fancy new autoconfig is used, users should still have the ability to do manual configuration. For example: - support for apache1.3 and multiprocess servers - deal with the limitations of the back-communication. - ability to serve static pages with apache - no mod_webapp dumb server approach There are 2 major areas to discuss: - low-level model - object model, extension points and request processing model - various modules - to implement whatever protocol, to implement configuration, etc. The first thing ( IMO ) is to decide on what improvements we need on the lower layer so it can satisfy any additional needs you may have - configuration, performance, integration with a wider set of applications, etc. Costin But once again, I don't wish to be limited by the existing codebase, that will limit the design from the start. If we manage to put ourselves in the neutral possition, we might do something. And we even a little more ambitious, we could think in term of Java to Native broker, not sure Tomcat to Native... If we on the end decide that this new integrator isn't what we need (or we don't have enough resources to implement it), at least it will show some directions for the existing connectors to follow. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 08, 2004 8:51 PM Subject: Re: Jk2 object model Mladen Turk wrote: From: Costin Manolache So my suggestion ( deja vue ? ) is to use evolution :-). A change in the OO model ( if needed ) or fixing/improving the current one is not as big change as it seems - it's mostly in initialization code. How about 'revolution'? On the other hand how does the evolution differs from revolution? My point was that fixing/improving the current code - maybe by first fixing the object model, then adding modules - is better than starting from scratch or trying to make a huge change at once. You pushed for an 'evolution' for TC5, and look what it got us: The most stable Tomcat GA release ever ;-). and... If we don't put ourselfs out from 'reusable' concept, nothing new will ever be done thought. Trying to reclyle something, as you nicely said stable and done, is poinntless from the '(r)evolution' perspective. It's not recycle - but improve. And I don't know why you feel it's pointless. Either we'll do (like Monty Pyton's said) something completely different, or we'll be once again asking ourselfs the same questions for year or so, and the guys will still use the JK or swith to something else. Doing something completely different for the sake of doing it different and without understanding or knowing what is wrong with the current approach is not going to lead us to something better - just different. Could actually be said for much of Jk2. However, the Jk2 code is much more maintainable, so I'd prefer to 'evolve' from there. The reasons that I'm sticking to Jk1 for all of my production servers are pretty small, and fixable. So far I haven't heard any concrete proposal of doing something different - just nice goals ( easier config, etc ). IMO using JMX-like model you can support almost any config needs - zeroconf/randezvous/etc. And the performance is result of lots of work and tunning - I never seen any rewrite from scratch, completely different project to be faster ( at least not in less than few years ). Same for stability BTW. Well, to be a little nicer than Costin, so far we have seen an abstract idea of sending the request to Tomcat to ask if it wants to map it (avoiding the double-mapping that we do now). However, the revolutionaries out there need to put together a [PROPOSAL] first before there can be a decision on revolusion vs. evolusion. There is a page on the Jakarta site spelling this out, from the last time this issue almost split this community apart :). Costin - 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: Jk2 object model
Mike Anderson wrote: I agree that the current connectors (jk and jk2) are fairly stable and done because they just work. The hardest part in using them is that there is a lot of duplicated setup between the Java/Tomcat side and the webserver configuration just to get things working. Then, when you add a new webapp into Tomcat, you have to remember to update the webserver configuration to handle the application. I like what Mladen said here: The concept (approach) as I see it is to be able to make a connector (integrator), that would allow the zero-based-configuration. Meaning that loading a module (filter) will automatically map the Tomcat web space to the web server. No matter if the TC was started in or out of the process, and no matter how much clustered instances exists on different nodes. Can we do this by evolving mod_jk or mod_jk2? I don't know. I believe it is possible and agree with Costin that this is probably the better way to go because this is what our users recognize as the connector of choice. Look at what happened with mod_webapp. I think that Pier and and Jean-Frederic did some great work on this, but the community (developers and users) never really got behind it. The mean problem was using an instable APR API. Another difference between mod_webapp and mod_jk/mod_jk2 was the thinking to have a Servlet Engine as an extention of Apache not a connector between Tomcat and Apache. The other good thing of mod_webapp is to have a good protocol (WARP). May be we can reuse it in the new connector. BTW: I am using mod_jk2. I don't know if that is because it was too revolutionary or what. I'm just worried that if we break too far from jk, we'll end up going nowhere. If we can evolve mod_jk or mod_jk2 to allow zero-based-configuration as Mladen suggests, I think that is the path that we should follow. If we have to revolt :-) and re-architect, we need to make sure that what we produce is soo much better that people can't wait to get it and help plug it into their web server. This includes getting it running and working on as many OS platforms and webservers as possible right up front. If there is developer interest for that, I'm willing to 'shake the things'. I'm (finally :-) ready to start diving in and help shake things up. aside I got stuck doing the management thing for a couple of years so I couldn't (didn't :-( ) contribute as much but I'm back on this pretty much full time now - as an engineer, not a manager :-). /aside Mike Anderson Sr. Software Engineer [EMAIL PROTECTED] Novell, Inc., The leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] 1/8/2004 10:16:03 AM From: Costin Manolache So my suggestion ( deja vue ? ) is to use evolution :-). A change in the OO model ( if needed ) or fixing/improving the current one is not as big change as it seems - it's mostly in initialization code. How about 'revolution'? On the other hand how does the evolution differs from revolution? Javaspaces, other protocols, other transports and other servers can be added at any time - but I think it would be vital to _add_ them to an existing base instead of adding yet another new connector. I hate the word connector. I would like to name that new thing integrator (jakarta-tomcat-integrator, how that sounds?) It would IMO better describe that new approach (at least the one I have on my mind). and... If we don't put ourselfs out from 'reusable' concept, nothing new will ever be done thought. Trying to reclyle something, as you nicely said stable and done, is poinntless from the '(r)evolution' perspective. Either we'll do (like Monty Pyton's said) something completely different, or we'll be once again asking ourselfs the same questions for year or so, and the guys will still use the JK or swith to something else. MT. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
-Original Message- From: jean-frederic clere Sent: 9. sijeanj 2004 8:35 To: Tomcat Developers List Subject: Re: Jk2 object model The concept (approach) as I see it is to be able to make a connector (integrator), that would allow the zero-based-configuration. Meaning Can we do this by evolving mod_jk or mod_jk2? I don't know. The other good thing of mod_webapp is to have a good protocol (WARP). May be we can reuse it in the new connector. You see, those are thinks I wish to investigate. JK2 has a good OO model, the JK has simplicity, webapp has a good protocol, but that doesn't mean that either of them has all that's needed (at least from my perspective). I agree that the 'evolution' is the most pragmatic approach, but again to 'evolutes' from what? If some (or all) codebases will enable to use the TC not only in webserver, but in the simple console app, that's fine. If we find a way (extending the AJP protocol thought) to allow zero-based-admin for existing connectors, that's fine too. Something like, will ask for developer support, that if missed will eventually 'stabilize' the project. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
I'm pretty busy these days so I can't works on JK2 as I want to. Some ideas/reflexions. JK2 is very similar to JK, from the tomcat point of vue, since the same ajp13 protocol is used, and may be in such case we could see JK2 too similar to JK to see users switch to JK2 (for instance we're still using JK in-house). In thread I read some says that JK2 is allready dead, and in such case, using JK2 to make what JK does, it may be true. I'm working on an in-house project were I'm using jchannels to make some applications works with cluster of service servers and that's an idea which could be fine for JK2, or JK2++ or JK3. Using this kind of high-level communication channels help make automatic clusters, without the need on the client (on our case Apache/IIS) to know the topology. I didn't know if a native (C/C++) jchannel implementation exist but if we could find one, I think we should think to use it to make JK2 more that just JK++. The benefits are enormous, automatic detection of tomcats when added or removed from the group, determination of webapp/url which could be handled What about ? Oups, you should read javagroups (http://www.jgroups.org) in place of jchannels ;) JGroups is really a great piece of code but miss native code implementation. But the idea is here, and if we could find the same kind of code with native and java implementation, we should take a look at it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
Hi, Since I've started few months ago all the C++ fuzziness (I did posted even some source to Costin back then), my intention wasn't to CPP-ize the existing code, but rather to move that 'dead' code on some new tracks. What I'm looking since then is some kind of different approach to the subject. I'll take a good look at javagroups. Seems to me that this is something that I had in my mind for a while, meaning leaving all the communication and configuration to some Java proxy, and having native only to communicate with that proxy. What I was looking at was the way to find the 'more intelligent' way of integration, definitely having GUI (html) configuration, something like TC Manager, and cacheable configuration on the native side (today's jvm's are IMO quite different with native integration then 1.2 was back in days when JK2 was started). The native part would have to be as simple as possible, having only the jvm and classloader, and few native calls, allowing it to be integrated not only in Web server, but with the simple console client too. I agree with you that this would be JK3, rather then JK2 on steroids :-), and it would require a different perspective. I'm in favor of _usability_ over performance in that new approach. The major question is are there any developer interest on that? Also I wouldn't like to been seen as 'a JK2 killer', but if we are frankly with ourselves, there wasn't a major JK2 technological advantage for more then a year, and there isn't much interest of the developer community thought. I also use the JK for production servers, and it is doing just fine for what it needs to. MT. -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: 8. sijeanj 2004 9:54 To: Tomcat Developers List Subject: Re: Jk2 object model I'm pretty busy these days so I can't works on JK2 as I want to. Some ideas/reflexions. JK2 is very similar to JK, from the tomcat point of vue, since the same ajp13 protocol is used, and may be in such case we could see JK2 too similar to JK to see users switch to JK2 (for instance we're still using JK in-house). In thread I read some says that JK2 is allready dead, and in such case, using JK2 to make what JK does, it may be true. I'm working on an in-house project were I'm using jchannels to make some applications works with cluster of service servers and that's an idea which could be fine for JK2, or JK2++ or JK3. Using this kind of high-level communication channels help make automatic clusters, without the need on the client (on our case Apache/IIS) to know the topology. I didn't know if a native (C/C++) jchannel implementation exist but if we could find one, I think we should think to use it to make JK2 more that just JK++. The benefits are enormous, automatic detection of tomcats when added or removed from the group, determination of webapp/url which could be handled What about ? Oups, you should read javagroups (http://www.jgroups.org) in place of jchannels ;) JGroups is really a great piece of code but miss native code implementation. But the idea is here, and if we could find the same kind of code with native and java implementation, we should take a look at it. - 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: Jk2 object model
Mladen Turk a crit : Hi, Since I've started few months ago all the C++ fuzziness (I did posted even some source to Costin back then), my intention wasn't to CPP-ize the existing code, but rather to move that 'dead' code on some new tracks. What I'm looking since then is some kind of different approach to the subject. I'll take a good look at javagroups. Seems to me that this is something that I had in my mind for a while, meaning leaving all the communication and configuration to some Java proxy, and having native only to communicate with that proxy. What I was looking at was the way to find the 'more intelligent' way of integration, definitely having GUI (html) configuration, something like TC Manager, and cacheable configuration on the native side (today's jvm's are IMO quite different with native integration then 1.2 was back in days when JK2 was started). The native part would have to be as simple as possible, having only the jvm and classloader, and few native calls, allowing it to be integrated not only in Web server, but with the simple console client too. I agree with you that this would be JK3, rather then JK2 on steroids :-), and it would require a different perspective. I'm in favor of _usability_ over performance in that new approach. The major question is are there any developer interest on that? Also I wouldn't like to been seen as 'a JK2 killer', but if we are frankly with ourselves, there wasn't a major JK2 technological advantage for more then a year, and there isn't much interest of the developer community thought. I also use the JK for production servers, and it is doing just fine for what it needs to. JavaGroups or other reliable multicast implemtations is great for the web server since it will discover the tomcats topology. For speed I need more experience, or comments from Filip Hanick, we should be subscribed on this list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
-Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] I agree with you that this would be JK3, rather then JK2 on steroids :-), and it would require a different perspective. I'm in favor of _usability_ over performance in that new approach. JavaGroups or other reliable multicast implemtations is great for the web server since it will discover the tomcats topology. I didn't said that the javagroups is what I need, only that it has the concept I was perusing for. For speed I need more experience, or comments from Filip Hanick, we should be subscribed on this list. As I said, the performance isn't a priority here, but rather usability. I'm sure that TC guys will be open here, and we will see (perhaps even in 5.1) the 'open TC API', that could be directly used, or seamlessly integrated from the native side. I would prefer to see that, rather then trying to 'discover' something, and after all it would 'stay in the house', since I wish to make a connector(integrator) for Tomcat, not for some xyz container. Of course this would imply the firm collaboration with the TC guys, but once again I don't wish to pack/unpack something over and over again (I have JK for that). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
Hate to quote myself, but... As I said, the performance isn't a priority here, but rather usability. I'm sure that TC guys will be open here, and we will see (perhaps even in 5.1) the 'open TC API', that could be directly used, or seamlessly integrated from the native side. I would prefer to see that, rather then trying to 'discover' something, and after all it would 'stay in the house', since I wish to make a connector(integrator) for Tomcat, not for some xyz container. Of course this would imply the firm collaboration with the TC guys, but once again I don't wish to pack/unpack something over and over again (I have JK for that). The concept (approach) as I see it is to be able to make a connector (integrator), that would allow the zero-based-configuration. Meaning that loading a module (filter) will automatically map the Tomcat web space to the web server. No matter if the TC was started in or out of the process, and no matter how much clustered instances exists on different nodes. If there is developer interest for that, I'm willing to 'shake the things'. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
The major mistake in jk2 is the 2 in the name. It was an error to fork ( even if it was easier to code and move it ) instead of improving mod_jk and adding/fixing. In JNI mode and from configuration perspective - as well as ability to use non-tcp-socket communation - jk2 is way ahead. As code organization and readability - besides the original OO model - jk2 is better. But it works as well as jk, and just like jk it works well enough - so I agree that at the moment they are dead from the point of the active development. I have a feeling even tomcat is getting close to this point, I can hardly find any major itch in tc5. We should probably use the term stable and done instead of dead :-) Regarding ease of use and fancy protocols - all this requires an object model. I agree that the current OO is not perfect, but it works without the dependencies other OO models would have ( XPCOM - NSPR - remember the fun in licence dicussions ). So I think the first question would be what to do about the object model, keep/improve the current one or switch to a (XP)COM-like ( or C++, or Gtk+ or OpenOffice ). After we have objects with JMX-like behavior, configuration and extension in any direction can follow the same model as tomcat. Should we call this jk+ or jk3 ? IMO it would be a major mistake, even bigger than for jk2. We have far fewer itches and less time, and a fork allways requires much bigger effort in addoption. The main reason people don't use jk2 is that jk1 works well enough for the task, plus different config. Same would happen to a jk3 - whenver this would be ready. So my suggestion ( deja vue ? ) is to use evolution :-). A change in the OO model ( if needed ) or fixing/improving the current one is not as big change as it seems - it's mostly in initialization code. Javaspaces, other protocols, other transports and other servers can be added at any time - but I think it would be vital to _add_ them to an existing base instead of adding yet another new connector. Costin Mladen Turk wrote: Hate to quote myself, but... As I said, the performance isn't a priority here, but rather usability. I'm sure that TC guys will be open here, and we will see (perhaps even in 5.1) the 'open TC API', that could be directly used, or seamlessly integrated from the native side. I would prefer to see that, rather then trying to 'discover' something, and after all it would 'stay in the house', since I wish to make a connector(integrator) for Tomcat, not for some xyz container. Of course this would imply the firm collaboration with the TC guys, but once again I don't wish to pack/unpack something over and over again (I have JK for that). The concept (approach) as I see it is to be able to make a connector (integrator), that would allow the zero-based-configuration. Meaning that loading a module (filter) will automatically map the Tomcat web space to the web server. No matter if the TC was started in or out of the process, and no matter how much clustered instances exists on different nodes. If there is developer interest for that, I'm willing to 'shake the things'. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
From: Costin Manolache So my suggestion ( deja vue ? ) is to use evolution :-). A change in the OO model ( if needed ) or fixing/improving the current one is not as big change as it seems - it's mostly in initialization code. How about 'revolution'? On the other hand how does the evolution differs from revolution? Javaspaces, other protocols, other transports and other servers can be added at any time - but I think it would be vital to _add_ them to an existing base instead of adding yet another new connector. I hate the word connector. I would like to name that new thing integrator (jakarta-tomcat-integrator, how that sounds?) It would IMO better describe that new approach (at least the one I have on my mind). and... If we don't put ourselfs out from 'reusable' concept, nothing new will ever be done thought. Trying to reclyle something, as you nicely said stable and done, is poinntless from the '(r)evolution' perspective. Either we'll do (like Monty Pyton's said) something completely different, or we'll be once again asking ourselfs the same questions for year or so, and the guys will still use the JK or swith to something else. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
I agree that the current connectors (jk and jk2) are fairly stable and done because they just work. The hardest part in using them is that there is a lot of duplicated setup between the Java/Tomcat side and the webserver configuration just to get things working. Then, when you add a new webapp into Tomcat, you have to remember to update the webserver configuration to handle the application. I like what Mladen said here: The concept (approach) as I see it is to be able to make a connector (integrator), that would allow the zero-based-configuration. Meaning that loading a module (filter) will automatically map the Tomcat web space to the web server. No matter if the TC was started in or out of the process, and no matter how much clustered instances exists on different nodes. Can we do this by evolving mod_jk or mod_jk2? I don't know. I believe it is possible and agree with Costin that this is probably the better way to go because this is what our users recognize as the connector of choice. Look at what happened with mod_webapp. I think that Pier and and Jean-Frederic did some great work on this, but the community (developers and users) never really got behind it. I don't know if that is because it was too revolutionary or what. I'm just worried that if we break too far from jk, we'll end up going nowhere. If we can evolve mod_jk or mod_jk2 to allow zero-based-configuration as Mladen suggests, I think that is the path that we should follow. If we have to revolt :-) and re-architect, we need to make sure that what we produce is soo much better that people can't wait to get it and help plug it into their web server. This includes getting it running and working on as many OS platforms and webservers as possible right up front. If there is developer interest for that, I'm willing to 'shake the things'. I'm (finally :-) ready to start diving in and help shake things up. aside I got stuck doing the management thing for a couple of years so I couldn't (didn't :-( ) contribute as much but I'm back on this pretty much full time now - as an engineer, not a manager :-). /aside Mike Anderson Sr. Software Engineer [EMAIL PROTECTED] Novell, Inc., The leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] 1/8/2004 10:16:03 AM From: Costin Manolache So my suggestion ( deja vue ? ) is to use evolution :-). A change in the OO model ( if needed ) or fixing/improving the current one is not as big change as it seems - it's mostly in initialization code. How about 'revolution'? On the other hand how does the evolution differs from revolution? Javaspaces, other protocols, other transports and other servers can be added at any time - but I think it would be vital to _add_ them to an existing base instead of adding yet another new connector. I hate the word connector. I would like to name that new thing integrator (jakarta-tomcat-integrator, how that sounds?) It would IMO better describe that new approach (at least the one I have on my mind). and... If we don't put ourselfs out from 'reusable' concept, nothing new will ever be done thought. Trying to reclyle something, as you nicely said stable and done, is poinntless from the '(r)evolution' perspective. Either we'll do (like Monty Pyton's said) something completely different, or we'll be once again asking ourselfs the same questions for year or so, and the guys will still use the JK or swith to something else. MT. - 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: Jk2 object model
Mladen Turk wrote: From: Costin Manolache So my suggestion ( deja vue ? ) is to use evolution :-). A change in the OO model ( if needed ) or fixing/improving the current one is not as big change as it seems - it's mostly in initialization code. How about 'revolution'? On the other hand how does the evolution differs from revolution? My point was that fixing/improving the current code - maybe by first fixing the object model, then adding modules - is better than starting from scratch or trying to make a huge change at once. and... If we don't put ourselfs out from 'reusable' concept, nothing new will ever be done thought. Trying to reclyle something, as you nicely said stable and done, is poinntless from the '(r)evolution' perspective. It's not recycle - but improve. And I don't know why you feel it's pointless. Either we'll do (like Monty Pyton's said) something completely different, or we'll be once again asking ourselfs the same questions for year or so, and the guys will still use the JK or swith to something else. Doing something completely different for the sake of doing it different and without understanding or knowing what is wrong with the current approach is not going to lead us to something better - just different. So far I haven't heard any concrete proposal of doing something different - just nice goals ( easier config, etc ). IMO using JMX-like model you can support almost any config needs - zeroconf/randezvous/etc. And the performance is result of lots of work and tunning - I never seen any rewrite from scratch, completely different project to be faster ( at least not in less than few years ). Same for stability BTW. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
Mladen Turk wrote: From Costin Manolache Sent: 6. sijeanj 2004 8:11 To: [EMAIL PROTECTED] Subject: Re: Jk2 object model jean-frederic clere wrote: Costin Manolache wrote: I remember some time ago Mladen (?) was suggesting to use C++ for jk2 instead of the pseudo-OO programming. I am -1 for using C++... And wondering why you want to use C++. I don't actually want to use C++ - I'm just a bit unhappy with the reinventing the wheel object model in jk2, and I was wondering if any alternatives have been discussed. Me too... The JK2 IMO is a pretty dead project. Henri tried to boost that forcing the APR as a default, we did some work, but it is agin stalled. IMO for the majority of the people the JK is sufficient enough. Using APR in JK would perhaps make it the same as JK2. There are few big differences in JNI handling - the in-process for jk1 is even slower than out-of-process, and didn't work with tc4. There is also a lot of jmx-like management and monitoring that I think is quite usefull. But you are right - jk / jk2 is probably good enough, no major itch to triger big changes. That's not necesarily bad. As I see it, most of the people are looking at JK2 as an enhancement over the JK, but in the real life there is not much technological difference. We still have a same packet communication between them (that hasn't changed conceptually from jserv). Well, it hasn't changed since RPC :-) You have 2 programs communicating, there aren't too many ways to do it. What's important is we figured that in-process with JNI is faster using packet communication. SWT figured it's faster using ints and byte[] - which is the other solution to avoid the really bad performance of jni ( and strings ). I'm interested if jk2 could plug into more applications - there aren't that many generic connectors. KDE has one specialized for konqueror, and mozilla has one - both are mostly for applet support, with xconnect hardly used ( and I heard pretty slow ). If jk2 would support (XP)COM or gtk object model - it may be possible to access and control various desktop application with some simple web-like requests. What I would like to see is something different in approach to the problem of integration. So I was wondering if jk2 or something similar could be used as a connector into apps like mozilla or evolution ( or any other desktop app ) and allow access to the services and info inside. Something simmilar I woud say :-). Starting from scratch is allways a bad idea ( IMO ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 06, 2004 11:06 PM Subject: Re: Jk2 object model Mladen Turk wrote: From Costin Manolache Sent: 6. sijeanj 2004 8:11 To: [EMAIL PROTECTED] Subject: Re: Jk2 object model jean-frederic clere wrote: Costin Manolache wrote: I remember some time ago Mladen (?) was suggesting to use C++ for jk2 instead of the pseudo-OO programming. I am -1 for using C++... And wondering why you want to use C++. I don't actually want to use C++ - I'm just a bit unhappy with the reinventing the wheel object model in jk2, and I was wondering if any alternatives have been discussed. Me too... The JK2 IMO is a pretty dead project. Henri tried to boost that forcing the APR as a default, we did some work, but it is agin stalled. IMO for the majority of the people the JK is sufficient enough. Using APR in JK would perhaps make it the same as JK2. There are few big differences in JNI handling - the in-process for jk1 is even slower than out-of-process, and didn't work with tc4. There is also a lot of jmx-like management and monitoring that I think is quite usefull. But you are right - jk / jk2 is probably good enough, no major itch to triger big changes. That's not necesarily bad. As I see it, most of the people are looking at JK2 as an enhancement over the JK, but in the real life there is not much technological difference. We still have a same packet communication between them (that hasn't changed conceptually from jserv). Well, it hasn't changed since RPC :-) You have 2 programs communicating, there aren't too many ways to do it. What's important is we figured that in-process with JNI is faster using packet communication. SWT figured it's faster using ints and byte[] - which is the other solution to avoid the really bad performance of jni ( and strings ). I'm interested if jk2 could plug into more applications - there aren't that many generic connectors. KDE has one specialized for konqueror, and mozilla has one - both are mostly for applet support, with xconnect hardly used ( and I heard pretty slow ). If jk2 would support (XP)COM or gtk object model - it may be possible to access and control various desktop application with some simple web-like requests. The big problem that I see is that currently jk2 uses 'abstract classes' to enable it to handle the fact that that the 'implementing class' needs to control I/O (reading the Request, writing the Response). This doesn't fit well with other frameworks. IMHO, this part would need to be re-writen to work on something more like a Listener model (certainly required for a COM implementation :). However, this may mean a performance hit when using the standard Apache/IIS/SunOne modules. What I would like to see is something different in approach to the problem of integration. So I was wondering if jk2 or something similar could be used as a connector into apps like mozilla or evolution ( or any other desktop app ) and allow access to the services and info inside. Something simmilar I woud say :-). Starting from scratch is allways a bad idea ( IMO ). Costin - 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: Jk2 object model
-Original Message- From: Bill Barker Sent: 7. sijeanj 2004 9:22 To: Tomcat Developers List Subject: Re: Jk2 object model I'm interested if jk2 could plug into more applications - there aren't that many generic connectors. KDE has one specialized for konqueror, and mozilla has one - both are mostly for applet support, with xconnect hardly used ( and I heard pretty slow ). If jk2 would support (XP)COM or gtk object model - it may be possible to access and control various desktop application with some simple web-like requests. The big problem that I see is that currently jk2 uses 'abstract classes' to enable it to handle the fact that that the 'implementing class' needs to control I/O (reading the Request, writing the Response). This doesn't fit well with other frameworks. IMHO, this part would need to be re-writen to work on something more like a Listener model (certainly required for a COM implementation :). However, this may mean a performance hit when using the standard Apache/IIS/SunOne modules. I was allways looking at a JK2 from that perspective, meaning, enabling it to embed the TC inside web server (acting like a COM proxy). What I was thinking is to pull all the AJP logic and configuration from C to Java, leaving only JNI to comunicate with that new proxy. The client Java part would be able in that case to constuct the AJP messages in case of out-of the process server, or what ever comunication channel. Since this changes the things conceptualy, I see this as a new product living together with JK. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
Rather than look at different architectures for implementing a web server connector to Tomcat I would rather focus on improving the connector. Digging into jk2 has been on my list of things to do but I haven't had time yet. mod_jk 1.2 with Apache 2 is working well enough for me. I like the concept of JMX in JK2 for the purpose of application monitoring. Some things that could be improved whether in jk or jk2 are: Switching jk to use APR everywhere possible to make portability easier between operating systems. Develop a way to use a global connection pool to Tomcat. The current way connectors are allocated where they are tied to the httpd process use up too many resources with idle connections. One idea I had was to follow the model used by Apache 2 for mod_cgid when using the worker MPM. mod_cgid runs as a separate process which the httpd process communicates with to execute CGI's. We could use the same model but have the process spawn threads for handling requests being forwarded to Tomcat. This would make the most efficient use of the connectors to Tomcat and allow us to do more sophisticated load balancing by tracking information in this process for each worker's performance. Regards, Glenn On Wed, Jan 07, 2004 at 09:52:06AM +0100, Mladen Turk wrote: -Original Message- From: Bill Barker Sent: 7. sije?anj 2004 9:22 To: Tomcat Developers List Subject: Re: Jk2 object model I'm interested if jk2 could plug into more applications - there aren't that many generic connectors. KDE has one specialized for konqueror, and mozilla has one - both are mostly for applet support, with xconnect hardly used ( and I heard pretty slow ). If jk2 would support (XP)COM or gtk object model - it may be possible to access and control various desktop application with some simple web-like requests. The big problem that I see is that currently jk2 uses 'abstract classes' to enable it to handle the fact that that the 'implementing class' needs to control I/O (reading the Request, writing the Response). This doesn't fit well with other frameworks. IMHO, this part would need to be re-writen to work on something more like a Listener model (certainly required for a COM implementation :). However, this may mean a performance hit when using the standard Apache/IIS/SunOne modules. I was allways looking at a JK2 from that perspective, meaning, enabling it to embed the TC inside web server (acting like a COM proxy). What I was thinking is to pull all the AJP logic and configuration from C to Java, leaving only JNI to comunicate with that new proxy. The client Java part would be able in that case to constuct the AJP messages in case of out-of the process server, or what ever comunication channel. Since this changes the things conceptualy, I see this as a new product living together with JK. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
On Tue, Jan 06, 2004 at 11:50:32AM +0100, Mladen Turk wrote: Me too... The JK2 IMO is a pretty dead project. Henri tried to boost that forcing the APR as a default, we did some work, but it is agin stalled. Could someone put a big warning statment on the web site about this? Honestly, 90% of the questions on #tomcat are jk/jk2 related and nobody seems to get the idea that jk2 is broken and shouldn't be used in production. Both jk and jk2 do seem largely un-manned from an outsider's perspective. I've had a couple patches in bugzilla for a long while. Maybe tonight I'll try to generate some patches to docs to improve the site and reduce #tomcat questions. But I'm less motivated as I've moved companies and don't actively use jk/jk2. -- [EMAIL PROTECTED] Some people have a way with words, while others... erm... thingy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
jean-frederic clere wrote: Costin Manolache wrote: I remember some time ago Mladen (?) was suggesting to use C++ for jk2 instead of the pseudo-OO programming. I am -1 for using C++... And wondering why you want to use C++. I don't actually want to use C++ - I'm just a bit unhappy with the reinventing the wheel object model in jk2, and I was wondering if any alternatives have been discussed. I was looking over the code, and while I still remember some of it :-) I can't stop wondering if it's the best choice. It is an improvement over jk, at least from a java - OO perspective, and I don't remember any other valid option at that time ( Mozilla XPCOM, glib, C++ and open office OO model each had issues ). C++ or COM-style query interface are a bit more standard, and it may be nice if jk2 would be able to integrate with a wider set of applications ( and using the same object model helps ). Right now integration is probably the thing I'm most interested in - i.e. communication between different applications and components. Jk2 is of course pretty specialized to web-like applications - however a lot of things can interoperate using this http request/response model ( web services ? ). So I was wondering if jk2 or something similar could be used as a connector into apps like mozilla or evolution ( or any other desktop app ) and allow access to the services and info inside. Costin Did anything got discussed/decided about this or the low-level model ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
From Costin Manolache Sent: 6. sijeanj 2004 8:11 To: [EMAIL PROTECTED] Subject: Re: Jk2 object model jean-frederic clere wrote: Costin Manolache wrote: I remember some time ago Mladen (?) was suggesting to use C++ for jk2 instead of the pseudo-OO programming. I am -1 for using C++... And wondering why you want to use C++. I don't actually want to use C++ - I'm just a bit unhappy with the reinventing the wheel object model in jk2, and I was wondering if any alternatives have been discussed. Me too... The JK2 IMO is a pretty dead project. Henri tried to boost that forcing the APR as a default, we did some work, but it is agin stalled. IMO for the majority of the people the JK is sufficient enough. Using APR in JK would perhaps make it the same as JK2. As I see it, most of the people are looking at JK2 as an enhancement over the JK, but in the real life there is not much technological difference. We still have a same packet communication between them (that hasn't changed conceptually from jserv). What I would like to see is something different in approach to the problem of integration. So I was wondering if jk2 or something similar could be used as a connector into apps like mozilla or evolution ( or any other desktop app ) and allow access to the services and info inside. Something simmilar I woud say :-). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 04, 2004 11:44 PM Subject: Jk2 object model I remember some time ago Mladen (?) was suggesting to use C++ for jk2 instead of the pseudo-OO programming. Did anything got discussed/decided about this or the low-level model ? The only suggestion I remember like this is mine to use Xerces-C (and it was heavily rejected :). I'm not really in favor of paying the cost for C++ in the critical code when the current implementation works well. About the only thing it doesn't have is multiple inheritance (which, if it comes up, I'd rather do a COM-style QueryInterface, since it won't come up much). Costin - 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: Jk2 object model
Bill Barker a écrit : - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 04, 2004 11:44 PM Subject: Jk2 object model I remember some time ago Mladen (?) was suggesting to use C++ for jk2 instead of the pseudo-OO programming. Did anything got discussed/decided about this or the low-level model ? The only suggestion I remember like this is mine to use Xerces-C (and it was heavily rejected :). I'm not really in favor of paying the cost for C++ in the critical code when the current implementation works well. About the only thing it doesn't have is multiple inheritance (which, if it comes up, I'd rather do a COM-style QueryInterface, since it won't come up much). I'd like we don't start C++ in such area for many reasons, including the fact the Apache codebase is not C++ but just good old C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
Costin Manolache wrote: I remember some time ago Mladen (?) was suggesting to use C++ for jk2 instead of the pseudo-OO programming. I am -1 for using C++... And wondering why you want to use C++. Did anything got discussed/decided about this or the low-level model ? Costin - 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]
