RE: Todo list for 4.0.2 b2
First Happy New Year to all of you. Just back from hollidays and start to dig into my ton of email, and so delayed some contributions like 4.0.2b1 RPM (will do the b2) and active participation on J-T-C (but there is today many great people working on it). Question : - Did jk from j-t-c for TC 4.0.2B2 will support load balancing ? I didn't see the use of getJvmRoute/setJvmRoute in latest TC 4.0 CVS. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Todo list for 4.0.2 b2
- Did jk from j-t-c for TC 4.0.2B2 will support load balancing ? I didn't see the use of getJvmRoute/setJvmRoute in latest TC 4.0 CVS. nope :( it's never been clear to me exactly what has to be done to support load balancing, so i've never attempted to add the functionality. and it's not something i use, so it obviously doesn't bubble up on my priority list :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
FYI: Based on previous discussions on this list, I've added setJvmRoute/JvmRoute to Engine (and StandardEngine) as part of the work I've been doing for distributed sessions. Not being a committer, nothing has been checked in. Tom Drake - Original Message - From: Kevin Seguin [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Thursday, January 10, 2002 4:59 AM Subject: RE: Todo list for 4.0.2 b2 | - Did jk from j-t-c for TC 4.0.2B2 will support load balancing ? |I didn't see the use of getJvmRoute/setJvmRoute in latest | TC 4.0 CVS. | | | nope :( | | it's never been clear to me exactly what has to be done to support load | balancing, so i've never attempted to add the functionality. and it's not | something i use, so it obviously doesn't bubble up on my priority list :) | | -- | To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] | For additional commands, e-mail: mailto:[EMAIL PROTECTED] | | | -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
On Thu, 10 Jan 2002, Tom Drake wrote: FYI: Based on previous discussions on this list, I've added setJvmRoute/JvmRoute to Engine (and StandardEngine) as part of the work I've been doing for distributed sessions. Can you send the patch for this one ? There are just 2 changes that are needed - the methods in Engine and about 2 lines of code in the session manager ( to check if vmRoute is set and if so add it to the session id ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
Remy, * Embbeded interface (my email Jan 7th, 18:51) -1, because it's an API change for cosmetic reasons only. In the head branch again then? It of course changes nothing if the class is not renamed. It is not for cosmetic reasons, it will help third party applications instantiate Catalina and cast to an interface. Easy and harmless. Only the core objects have interfaces. Embedded is a helper object, so it's not an interface. Just like Catalina is not an interface. By the way, I don't see how having an interface makes it easier to work with Catalina. The only useful thing with interfaces is if you want to extend or reimplement something, because of Java's lack of multiple inheritance. There's no point in doing something different in that object without changing the API, since it's not designed to let you do everything you could want with the Catalina internals (it's just a simple helper object with the functionality J2EE servers could want to embed Catalina). Also, if you only want to use Catalina as a service inside a bigger framework, you should use CatalinaService, not Embedded (and no, there's no need for an interface for that either ;-)). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
Remy, Only the core objects have interfaces. Embedded is a helper object, so it's not an interface. Just like Catalina is not an interface. By the way, I don't see how having an interface makes it easier to work with Catalina. The only useful thing with interfaces is if you want to extend or reimplement something, because of Java's lack of multiple inheritance. Not true. If you want to *secure* your impl from other code. You could use three schemes: 1) seperate classloaders for the interfaces and impl Catalina ImplOther Application* | | | System/Boot/Primordial Catalina 'interfaces' * that might want to invoke methods in Catalina via its interfaces. 2) Run the Object implementing the interfaces through a DynamicProxy generator, such that the Other Application cannot cast to the impl. 3) Combination of (1) and (2) to overcome introspection/serialization tricks for hacking. Also, if you only want to use Catalina as a service inside a bigger framework, you should use CatalinaService, not Embedded (and no, there's no need for an interface for that either ;-)). I will try with this. Two things though: 1) For exactly the same reason, it needs an interface. I *really* *need* an interface. 2) CatalinaService exposes less methods than Embedded. Way less. I guess the idea is that to add hosts and webapps, you should not being doing it inVM via method calls but via a connector. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
Remy, Only the core objects have interfaces. Embedded is a helper object, so it's not an interface. Just like Catalina is not an interface. By the way, I don't see how having an interface makes it easier to work with Catalina. The only useful thing with interfaces is if you want to extend or reimplement something, because of Java's lack of multiple inheritance. Not true. If you want to *secure* your impl from other code. You could use three schemes: If our helper object for embedding doesn't fit your needs, I suggest you write your own instead. It doesn't take long, and it will do what you want (including having an interface, so it fits into your virtual OS dream). There are real world users of the current Embedded class (including JBoss and the J2EE RI), and none of them would see any benefit about having an interface instead of object. Since I'd like to avoid unseless changes for the users and also keep the design simpler if I can, I will NOT change the current Embedded object to do what you propose, and I vote -1 to the associated patch. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
Remy, If our helper object for embedding doesn't fit your needs, I suggest you write your own instead. It doesn't take long, and it will do what you want (including having an interface, so it fits into your virtual OS dream). I am talking about Avalon (another Jakarta project). It is not a 'dream' We already have a third-party web server running in it - Hendrik Schreiber's most excellent 'Jo!'. It is quite embarrasing that we do not yet (but are so close) have Catalina running in it. There are real world users of the current Embedded class (including JBoss and the J2EE RI), and none of them would see any benefit about having an interface instead of object. Since I'd like to avoid unseless changes for the users and also keep the design simpler if I can, I will NOT change the current Embedded object to do what you propose, and I vote -1 to the associated patch. I am going ask ask you again, *Please* consider the merit for this, It is not unreasonable. The change is not useless as you say. I was not incorrect suggesting another reason for interface/impl separation (it was not new to you dude, it had just slipped your mind) was I?. It is such a small thing to do. Please dude. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
Remy, If our helper object for embedding doesn't fit your needs, I suggest you write your own instead. It doesn't take long, and it will do what you want (including having an interface, so it fits into your virtual OS dream). I am talking about Avalon (another Jakarta project). It is not a 'dream' We already have a third-party web server running in it - Hendrik Schreiber's most excellent 'Jo!'. It is quite embarrasing that we do not yet (but are so close) have Catalina running in it. There are real world users of the current Embedded class (including JBoss and the J2EE RI), and none of them would see any benefit about having an interface instead of object. Since I'd like to avoid unseless changes for the users and also keep the design simpler if I can, I will NOT change the current Embedded object to do what you propose, and I vote -1 to the associated patch. I am going ask ask you again, *Please* consider the merit for this, It is not unreasonable. The change is not useless as you say. I was not incorrect suggesting another reason for interface/impl separation (it was not new to you dude, it had just slipped your mind) was I?. It is such a small thing to do. Please dude. And why don't you want to write your own wrapper (I doubt Embedded is adapted to your use case anyway), and put it in the Avalon tree ? That's why I do with the various Catalina wrappers Slide has, and it doesn't cause any problems. Also, not having separated interfaces and implementations doesn't prevent from running under Avalon, it only removes the inter-application security, which isn't very useful (unless you have a Java mail server which routinely tries to hack your Java web server using its internal Java APIs). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
Remy, And why don't you want to write your own wrapper (I doubt Embedded is adapted to your use case anyway), and put it in the Avalon tree ? That's why I do with the various Catalina wrappers Slide has, and it doesn't cause any problems. Also, not having separated interfaces and implementations doesn't prevent from running under Avalon, it only removes the inter-application security, which isn't very useful (unless you have a Java mail server which routinely tries to hack your Java web server using its internal Java APIs). OK, I'll just write a wrapper that exposes no methods to other 'blocks' If we are being asked to use CatalinaService instead of Embedded, then there were no useful (internally published) methods available anyway. As such if there are no methods to expose there is no need for *any* interface/impl separation. Therefore I can go ahead as is with the currently available Catalina (I guess). Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
Remy, And why don't you want to write your own wrapper (I doubt Embedded is adapted to your use case anyway), and put it in the Avalon tree ? That's why I do with the various Catalina wrappers Slide has, and it doesn't cause any problems. Also, not having separated interfaces and implementations doesn't prevent from running under Avalon, it only removes the inter-application security, which isn't very useful (unless you have a Java mail server which routinely tries to hack your Java web server using its internal Java APIs). OK, I'll just write a wrapper that exposes no methods to other 'blocks' If we are being asked to use CatalinaService instead of Embedded, then there were no useful (internally published) methods available anyway. As such if there are no methods to expose there is no need for *any* interface/impl separation. Therefore I can go ahead as is with the currently available Catalina (I guess). It's not as simple as that. Catalina and CatalinaService both create standard Tomcat servers. The Embedded interface OTOH will create a deploy-it-yourself Tomcat; you'll have to define your own config files, and it may not behave like a standard Tomcat. Since I doubt it's what you want anyway, I'd say you should take CatalinaService and extend it (and add an interface to it, of course). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
On Wed, 9 Jan 2002, Paul Hammant wrote: Date: Wed, 09 Jan 2002 12:55:14 + From: Paul Hammant [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Todo list for 4.0.2 b2 Remy, If our helper object for embedding doesn't fit your needs, I suggest you write your own instead. It doesn't take long, and it will do what you want (including having an interface, so it fits into your virtual OS dream). I am talking about Avalon (another Jakarta project). It is not a 'dream' We already have a third-party web server running in it - Hendrik Schreiber's most excellent 'Jo!'. It is quite embarrasing that we do not yet (but are so close) have Catalina running in it. There are real world users of the current Embedded class (including JBoss and the J2EE RI), and none of them would see any benefit about having an interface instead of object. Since I'd like to avoid unseless changes for the users and also keep the design simpler if I can, I will NOT change the current Embedded object to do what you propose, and I vote -1 to the associated patch. I am going ask ask you again, *Please* consider the merit for this, It is not unreasonable. The change is not useless as you say. I was not incorrect suggesting another reason for interface/impl separation (it was not new to you dude, it had just slipped your mind) was I?. It is such a small thing to do. Please dude. Paul, this needs to be turned around as well. *Please* consider that what you are asking for has a very substantial backwards compatibility cost -- making this change would mean it's impossible to have compiled Java code that works with both 4.0.1 and 4.0.2, because the class inheritance of the Embedded class would change. We just went through this trying to undo the poor factoring of org.apache.net.ServerSocketFactory -- in the end, we had to undo an obviously beneficial change for this reason. It is not appropriate to break binary compatibility in the 4.0 branch. Breaking it between 4.0 and 4.1-dev is not necessarily as absolute, but the penalty is still severe. Regards, - Paul H Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
Craig, Paul, this needs to be turned around as well. *Please* consider that what you are asking for has a very substantial backwards compatibility cost -- making this change would mean it's impossible to have compiled Java code that works with both 4.0.1 and 4.0.2, because the class inheritance of the Embedded class would change. We just went through this trying to undo the poor factoring of org.apache.net.ServerSocketFactory -- in the end, we had to undo an obviously beneficial change for this reason. Sorry dude, I was only considering the rolling forward of features. I did not realise that 4.0.1 was still a factor. I thought that the additon of an interface (without renaming anything) was completely safe. I stand corrected. It is not appropriate to break binary compatibility in the 4.0 branch. Breaking it between 4.0 and 4.1-dev is not necessarily as absolute, but the penalty is still severe. I'll check back again in some months. For now, I'll put my must sepserate interface and impl' axe away and let you dude get on with the flagship effort. Keep up the good work... Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
Remy Maucherat wrote: Hi, Here goes the list: - Tag the JK + util directories in j-t-c with some tag (Costin proposed jk_14) - Build the corresponding JK binaries - Write some documentation about the new auto-configuration mechanism (but it can wait until 4.0.2 Final) - Update the AJP page in the docs with other changes for AJP 1.4, if any - Tag the warp directories in j-t-c (JF or Pier can you do that ?) Sure, but it would be nice to review the bugs before... (I need time to do that). - Build the corresponding mod_webapp binaries You mean native code?... I need help for that... (I think I am able to provide Solaris 5.8/5.7 and ReliantUnix). - And of course build the main binaries and upload them According to Costin, JK 1.4 is ready or almost ready. If it's not done yet, is it doable by the end of the week ? Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
Remy, Kevin, Jena-Frederic, Bill, Craig et al, Could we also do... * the jar split (my email Jan 7th, 14:28) * Embbeded interface (my email Jan 7th, 18:51) Regards, - Paul H Hi, Here goes the list: - Tag the JK + util directories in j-t-c with some tag (Costin proposed jk_14) - Build the corresponding JK binaries - Write some documentation about the new auto-configuration mechanism (but it can wait until 4.0.2 Final) - Update the AJP page in the docs with other changes for AJP 1.4, if any - Tag the warp directories in j-t-c (JF or Pier can you do that ?) - Build the corresponding mod_webapp binaries - And of course build the main binaries and upload them According to Costin, JK 1.4 is ready or almost ready. If it's not done yet, is it doable by the end of the week ? Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
Remy, Kevin, Jena-Frederic, Bill, Craig et al, Could we also do... * the jar split (my email Jan 7th, 14:28) No, sorry, some people depend on the binary distribution packaging. Will do it in the HEAD branch. * Embbeded interface (my email Jan 7th, 18:51) -1, because it's an API change for cosmetic reasons only. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
Remy, * Embbeded interface (my email Jan 7th, 18:51) -1, because it's an API change for cosmetic reasons only. In the head branch again then? It of course changes nothing if the class is not renamed. It is not for cosmetic reasons, it will help third party applications instantiate Catalina and cast to an interface. Easy and harmless. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Todo list for 4.0.2 b2
Here goes the list: - Tag the JK + util directories in j-t-c with some tag (Costin proposed jk_14) - Build the corresponding JK binaries i've successfully built and used the following, and can provide binaries if necessary (all jk1, btw): - iis connector - netscape connector on solaris 2.6 (upwards compatible with 2.6+) - Write some documentation about the new auto-configuration mechanism (but it can wait until 4.0.2 Final) - Update the AJP page in the docs with other changes for AJP 1.4, if any - Tag the warp directories in j-t-c (JF or Pier can you do that ?) - Build the corresponding mod_webapp binaries - And of course build the main binaries and upload them According to Costin, JK 1.4 is ready or almost ready. If it's not done yet, is it doable by the end of the week ? to the best of my knowledge, the jk (a.k.a. jk1) code, including some 1.4 functionality, is stable. i think it's the jk2 code that costin is still working on. and i think jk2 will be experimental or alpha at best for 4.0.2. -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Todo list for 4.0.2 b2
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 07, 2002 3:55 PM Subject: Todo list for 4.0.2 b2 Hi, Here goes the list: - Tag the JK + util directories in j-t-c with some tag (Costin proposed jk_14) - Build the corresponding JK binaries - Write some documentation about the new auto-configuration mechanism (but it can wait until 4.0.2 Final) I've been meaning to do this, but I've got a lot of (non-Tomcat) stuff on my plate this week. Might not be able to make it for B2. - Update the AJP page in the docs with other changes for AJP 1.4, if any - Tag the warp directories in j-t-c (JF or Pier can you do that ?) - Build the corresponding mod_webapp binaries - And of course build the main binaries and upload them According to Costin, JK 1.4 is ready or almost ready. If it's not done yet, is it doable by the end of the week ? Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
