Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacek Laskowski wrote: > > Am I reading it correctly that in CTR when a committer vetoed a > commit, it *ought to* be backed out *as soon as it's happened* and > discussed afterwards before being committed again? No, the rules for handling a veto don't really change. The person who made the commit is generally given a chance to back it out hirself first. Someone else reverting it quickly should only happen if it's egregiously broken and keeping multiple aspects of development from moving forward. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ85c3prNPMCpn3XdAQIgSAQArMo3zqBGf1HpUGmriSw4GTf+C7EpvOu8 Kel6u8SivOlRz4eFlynbK6TZHRNp+XYCdC/RvO/eP33BXpfly9Q3U/CTtJ0mZP8G woNvx+6vd25RLD+09lo+hxathvOUp7sJMIhYY4FKTk0PcwHT5nIVuW2PHoPYMTcN Vzv/kmS+iqI= =Tu3I -END PGP SIGNATURE-
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Jacek Laskowski wrote: 2006/1/16, Rodent of Unusual Size <[EMAIL PROTECTED]>: Under CTR, any change can get committed at any time, although major ones are supposed to follow the RTC model. Committers need to ask themselves whether the commit will spark controversy; if so, they should follow RTC and get support first. ... The advantage of CTR is prototyping speed. Its disadvantages are less-assured quality and community divisiveness. Its enemy is ego. Since criticism occurs after code has been committed, personal investment is greater and defensiveness higher. Developers are typically less aware of each others' work. I believe it is safe to say that Geronimo has been operating in CTR mode, but I think the specifics and ground rules may not have been spelt out, or need to be again. Is this the way in which the majority wants to continue to proceed? Hi Ken, Am I reading it correctly that in CTR when a committer vetoed a commit, it *ought to* be backed out *as soon as it's happened* and discussed afterwards before being committed again? I think we're operating this way and dispate the recent issue it works well. Jacek, I think that this strategy is in place for seriously disasterous checkins. If after backing out someone else's change, you can clearly demonstrate that it introduced a show-stopping bug and that your only reasonable option was to back it out immediately, before it prevented everyone else from getting on with their work, then I think you would be justified. If on the other hand, after the event, it is clear that the change was to a rarely used area of the code, that would only impact the developers working directly upon it, that it did not introduce any show-stopper and that, when invited to, you failed to demonstrate that the change broke anything, then I think you would have a very hard time justifying your actions. In this case, I think the sensible course of action is to explain to the owner of the code, what your issues with it are, discuss them in an open forum with your peers, reach consensus and then make further changes on top of the original to take you to the place where you have all decided to go. So, I don't think it is so much whether you adhere to a particular methodology, but that you apply it sensibly. Jules #kenP-)} -- Jacek Laskowski http://www.laskowski.org.pl -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
2006/1/16, Rodent of Unusual Size <[EMAIL PROTECTED]>: > Under CTR, any change can get committed at any time, although > major ones are supposed to follow the RTC model. Committers > need to ask themselves whether the commit will spark controversy; > if so, they should follow RTC and get support first. ... > The advantage of CTR is prototyping speed. Its disadvantages > are less-assured quality and community divisiveness. Its > enemy is ego. Since criticism occurs after code has been > committed, personal investment is greater and defensiveness > higher. Developers are typically less aware of each others' > work. > > I believe it is safe to say that Geronimo has been operating > in CTR mode, but I think the specifics and ground rules may > not have been spelt out, or need to be again. Is this the > way in which the majority wants to continue to proceed? Hi Ken, Am I reading it correctly that in CTR when a committer vetoed a commit, it *ought to* be backed out *as soon as it's happened* and discussed afterwards before being committed again? I think we're operating this way and dispate the recent issue it works well. > #kenP-)} -- Jacek Laskowski http://www.laskowski.org.pl
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Alan D. Cabrera wrote: I am of the strong opinion of releasing new features in a patch release is a bad idea. This should go in 1.1.0. I think that we should feature freeze 1.1.0 at the end of this month. I agree with you, Alan, but the change did not add a new feature. WADI was integrated in 1.0, but there were issues with this integration that were not fixed. My change resolved these issues and at the same time unified the way that Jetty and Tomcat integrated with WADI. Jules Regards, Alan Jules Gosnell wrote, On 1/16/2006 3:01 AM: Here is my penniesworth : Users want clustering - I get mails everyday Users do not expect that a 1.0 release will contain a complete clustering solution - they have realistic expectations. We have a chance with the 1.0, now 1.0.1 release, to mark certain areas as 'technology preview' and use these to demonstrate emerging Geronimo technologies to our user-base. This is one of the ways that Open Source projects traditionally generate interest and reach out to new potential developers. All aspects of clustering in Geronimo are going to require considerable work, and this is our chance to show our users that we are involved in at least some of these areas and invite them to contribute. I crafted my last change to make as few alterations to 1.0 as possible. It was called 'unacceptable', as far as I can tell, because it did not go far enough. Now we are saying that we only want minimal change between 1.0 and 1.0.1 - so what is it to be ? A clearly defined subset of WADI fnality will 'work' by the time 1.0.1 is released. If we work towards the necessary integration now, then we will have a while to discuss it and get it in, if we don't, then it will again be termed too precipitous, we will miss 1.0.1 and the current fragmented approach to web clustering will persist in Geronimo, impacting on a growing number of users. Jules Jan Bartel wrote: David, To paraphrase what you said (if I understand correctly), the choices are to either back clustering out of geronimo for the 1.0.1 release and work on it for a future release, or to make minimal changes to it to make it work in geronimo as is. I think it's unlikely that there will be a significant rush to production with a 1.0 release of geronimo, so there is probably a bit of latitude for less-than-optimal functioning in terms of 2nd order functionality such as clustering if it were to be left in. It would be good to get Jules' input on the state of WADI on this point. However, if we leave clustering in the way it is implemented at the moment, then the disadvantages are: 1. clustering is enabled differently for tomcat and jetty and a basic tenet of geronimo is to make the webcontainers interchangeable 2. clustering is enabled in the webapp descriptors instead of the container 3. users that use the 1.0.1 clustering will have to change each webapp to use it on future releases. If we roll forward again to the most recent clustering changes: 1. clustering interface is uniform for both tomcat and jetty 2. clustering is enabled in the container 3. no geronimo webapp descriptor changes necessary Of course, the most recent changes are not the final clustering solution, so there would be changes to the container plans in the future (eg in 1.1). But changes to the plans could probably be expected for any geronimo services between releases, no? I don't like the option of leaving the clustering with per-webapp geronimo descriptor configuration because it's just simply the wrong way to do it and will be a pain in the neck for users when we change to a better way in future releases. I think it would be better to take clustering out than to release 1.0.1 with it like it is. So, the two options I see for 1.0.1 are: 1. take the clustering out and release in 1.1 after more discussion 2. leave clustering in, roll forward again and fix any issues I really don't have a preference either way - I think both are meritworthy. regards Jan I think that it would be better to work on clustering in head and not try to hurry to get something that we know will change and has not been well tested into 1.0.1. I have no experience with actual clustering. Will people who want to use it expect something well tested and stable? Will they be willing to work off snapshot builds to pick up the latest fixes? What would the reaction be to something that only sort of works in an official release? thanks david jencks On Jan 14, 2006, at 3:46 AM, Jules Gosnell wrote: OK, Folks - here is how I see it - Everyone knows that they are right and the other guy is wrong. Result - DEADLOCK - everyone loses. Solution - release locks, back off, coordinate, retry. Releasing locks involves us all making concessions : I suggest - Jan, Greg and I conceded that Jeff could have been more involved in discussion before this change went in. Jeff concedes that Jan, Greg and I should
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
On Jan 16, 2006, at 12:38 PM, Geir Magnusson Jr wrote: Rodent of Unusual Size wrote: I believe it is safe to say that Geronimo has been operating in CTR mode, but I think the specifics and ground rules may not have been spelt out, or need to be again. Is this the way in which the majority wants to continue to proceed? I believe that most Apache projects are fundamentally CTR. I can only think of one, httpd, that is RTC. Is that right? And Derby, IIRC. -David
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Geir Magnusson Jr wrote: > > I believe that most Apache projects are fundamentally CTR. I can only > think of one, httpd, that is RTC. Is that right? httpd operated in RTC for a number of years, before opening up to CTR in 1997 (I think, maybe 1998). AFAIK, it runs CTR only on the main lines now. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ8wMkprNPMCpn3XdAQJU7AP+LCYAEVljxVtINw4ZcQs05nEYItDTc5N7 KufEmQRLUQ0glYPClcIuAbxA3K4d7yho0StJ612mDMtWPHIbkZ8Nmqpiw9Lxa7+9 VLr0PD2oXpqw4dUnzvbOhwQZUt73j4S/aig43I7Ywi9YtgHhI+JsoC+dy0NNDdzT BHBZl/4ZHA0= =oK2r -END PGP SIGNATURE-
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Rodent of Unusual Size wrote: I believe it is safe to say that Geronimo has been operating in CTR mode, but I think the specifics and ground rules may not have been spelt out, or need to be again. Is this the way in which the majority wants to continue to proceed? I believe that most Apache projects are fundamentally CTR. I can only think of one, httpd, that is RTC. Is that right? geir
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Jencks wrote: > I agree with Jeff that this change is unsatisfactory but I'm not as > sure as he is that backing it out is necessary, perhaps we can move > forward to an acceptable solution instead. It is permissible for HEAD to be broken. This is development, after all; committing only perfect code is an unreasonable goal. > I also am not so sure that this magnitude of change needs prior > discussion on the list. I've frequently made larger changes without > discussion of my specific code. I've also broken lots of stuff at > various times. Let's all come into agreement on the development model, then. Apache historically has use two distinct models, called Review Then Commit (RTC) and Commit Then Review (CTR). Under the RTC model, all changes -- except to docco or minor bug fixes -- need to be reviewed and garner at least three +1 votes before being committed. Giving a +1 means you've applied the patch and tested it yourself. If a patch doesn't get the requisite number of positive votes, it doesn't get committed. Under CTR, any change can get committed at any time, although major ones are supposed to follow the RTC model. Committers need to ask themselves whether the commit will spark controversy; if so, they should follow RTC and get support first. The advantages of RTC are code quality and team building. Nothing goes in that hasn't been tested by at least three people. The primary disadvantage is that its conservative approach tends to slow down development. Its enemies are self-interest and apathy; supporters need to lobby for their work to be tested, and all developers need to remember that they're dependent upon one another. The advantage of CTR is prototyping speed. Its disadvantages are less-assured quality and community divisiveness. Its enemy is ego. Since criticism occurs after code has been committed, personal investment is greater and defensiveness higher. Developers are typically less aware of each others' work. I believe it is safe to say that Geronimo has been operating in CTR mode, but I think the specifics and ground rules may not have been spelt out, or need to be again. Is this the way in which the majority wants to continue to proceed? - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ8vmHJrNPMCpn3XdAQKGGwQA2dI23/BqrrzV0pBrUVJLsp00gOKIFMst 3ad2Dek5+pQW5cBn1bjLE8eDL8fk4nGRXKp+BZWYQkhEFmEHnCVSPZLvh8Ij31aj 70drBEGY1fS49cUuEDyhs4xLm3IE+DJ5tq1PA6kGsC3rSn/DF9+VTc+kiEq/evLu 1TLm3gWtEYM= =x+HN -END PGP SIGNATURE-
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
I am of the strong opinion of releasing new features in a patch release is a bad idea. This should go in 1.1.0. I think that we should feature freeze 1.1.0 at the end of this month. Regards, Alan Jules Gosnell wrote, On 1/16/2006 3:01 AM: Here is my penniesworth : Users want clustering - I get mails everyday Users do not expect that a 1.0 release will contain a complete clustering solution - they have realistic expectations. We have a chance with the 1.0, now 1.0.1 release, to mark certain areas as 'technology preview' and use these to demonstrate emerging Geronimo technologies to our user-base. This is one of the ways that Open Source projects traditionally generate interest and reach out to new potential developers. All aspects of clustering in Geronimo are going to require considerable work, and this is our chance to show our users that we are involved in at least some of these areas and invite them to contribute. I crafted my last change to make as few alterations to 1.0 as possible. It was called 'unacceptable', as far as I can tell, because it did not go far enough. Now we are saying that we only want minimal change between 1.0 and 1.0.1 - so what is it to be ? A clearly defined subset of WADI fnality will 'work' by the time 1.0.1 is released. If we work towards the necessary integration now, then we will have a while to discuss it and get it in, if we don't, then it will again be termed too precipitous, we will miss 1.0.1 and the current fragmented approach to web clustering will persist in Geronimo, impacting on a growing number of users. Jules Jan Bartel wrote: David, To paraphrase what you said (if I understand correctly), the choices are to either back clustering out of geronimo for the 1.0.1 release and work on it for a future release, or to make minimal changes to it to make it work in geronimo as is. I think it's unlikely that there will be a significant rush to production with a 1.0 release of geronimo, so there is probably a bit of latitude for less-than-optimal functioning in terms of 2nd order functionality such as clustering if it were to be left in. It would be good to get Jules' input on the state of WADI on this point. However, if we leave clustering in the way it is implemented at the moment, then the disadvantages are: 1. clustering is enabled differently for tomcat and jetty and a basic tenet of geronimo is to make the webcontainers interchangeable 2. clustering is enabled in the webapp descriptors instead of the container 3. users that use the 1.0.1 clustering will have to change each webapp to use it on future releases. If we roll forward again to the most recent clustering changes: 1. clustering interface is uniform for both tomcat and jetty 2. clustering is enabled in the container 3. no geronimo webapp descriptor changes necessary Of course, the most recent changes are not the final clustering solution, so there would be changes to the container plans in the future (eg in 1.1). But changes to the plans could probably be expected for any geronimo services between releases, no? I don't like the option of leaving the clustering with per-webapp geronimo descriptor configuration because it's just simply the wrong way to do it and will be a pain in the neck for users when we change to a better way in future releases. I think it would be better to take clustering out than to release 1.0.1 with it like it is. So, the two options I see for 1.0.1 are: 1. take the clustering out and release in 1.1 after more discussion 2. leave clustering in, roll forward again and fix any issues I really don't have a preference either way - I think both are meritworthy. regards Jan I think that it would be better to work on clustering in head and not try to hurry to get something that we know will change and has not been well tested into 1.0.1. I have no experience with actual clustering. Will people who want to use it expect something well tested and stable? Will they be willing to work off snapshot builds to pick up the latest fixes? What would the reaction be to something that only sort of works in an official release? thanks david jencks On Jan 14, 2006, at 3:46 AM, Jules Gosnell wrote: OK, Folks - here is how I see it - Everyone knows that they are right and the other guy is wrong. Result - DEADLOCK - everyone loses. Solution - release locks, back off, coordinate, retry. Releasing locks involves us all making concessions : I suggest - Jan, Greg and I conceded that Jeff could have been more involved in discussion before this change went in. Jeff concedes that Jan, Greg and I should have been involved in discussion before he backed the change out. We all agree to overlook all current technical differences. We all agree to put aside whatever bad feelings may have arisen from this incident. OK - locks released, backing-off complete. Now, coordination : WADI side : I will downgrade t
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Genender wrote: > > I have backed out the change you made. If a change has been vetoed, but the veto's validity is under challenge, it's not a good thing for the vetoer to go ahead and revert the change anyway after the challenge has been made. It's not wicked bad, but it's not good. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ8vCVJrNPMCpn3XdAQJeeQP/WuSTXysb4z8V0YLgAO6XhaKQse0MOzLY PnKf4mghWl1n09vqYCj8RhCeBuGclB7pigI63UJO5O7IMBmqQq1JE+ey94ciuHJt 61T8JOHJiS3YVghy/evY6tN3s7CZSarR5xQ98YLX9gHDkTgrfpP/tyghpwa1ppua Jd7EaTAARmw= =OX8Q -END PGP SIGNATURE-
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Jacek Laskowski wrote: 2006/1/16, Jules Gosnell <[EMAIL PROTECTED]>: I crafted my last change to make as few alterations to 1.0 as possible. It was called 'unacceptable', as far as I can tell, because it did not go far enough. Now we are saying that we only want minimal change between 1.0 and 1.0.1 - so what is it to be ? A clearly defined subset of WADI fnality will 'work' by the time 1.0.1 is released. If we work towards the necessary integration now, then we will have a while to discuss it and get it in, if we don't, then it will again be termed too precipitous, we will miss 1.0.1 and the current fragmented approach to web clustering will persist in Geronimo, impacting on a growing number of users. Hi Jules, I'm a complete newbie in the area of clustering, but the discussion has kept me thinking about its merit and influence on the current codebase. Would you please point out the revision number where I could look at and judge yourself how much impact it could incur? Is r368344 the revision to look at? Yes. You will see very little in the change itself. I just integrates some other code (WADI - wadi.codehaus.org), an HttpSession (in this case) clustering solution. The change should have no impact unless the flag is set in a webapp's WEB-INF/web.xml, in which case it endeavours to set up a parameterisable SessionManager within the webcontainer (Jetty or Tomcat). Jules Jacek -- Jacek Laskowski http://www.laskowski.org.pl -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
2006/1/16, Jules Gosnell <[EMAIL PROTECTED]>: > I crafted my last change to make as few alterations to 1.0 as possible. > It was called 'unacceptable', as far as I can tell, because it did not > go far enough. Now we are saying that we only want minimal change > between 1.0 and 1.0.1 - so what is it to be ? > > A clearly defined subset of WADI fnality will 'work' by the time 1.0.1 > is released. If we work towards the necessary integration now, then we > will have a while to discuss it and get it in, if we don't, then it will > again be termed too precipitous, we will miss 1.0.1 and the current > fragmented approach to web clustering will persist in Geronimo, > impacting on a growing number of users. Hi Jules, I'm a complete newbie in the area of clustering, but the discussion has kept me thinking about its merit and influence on the current codebase. Would you please point out the revision number where I could look at and judge yourself how much impact it could incur? Is r368344 the revision to look at? Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Here is my penniesworth : Users want clustering - I get mails everyday Users do not expect that a 1.0 release will contain a complete clustering solution - they have realistic expectations. We have a chance with the 1.0, now 1.0.1 release, to mark certain areas as 'technology preview' and use these to demonstrate emerging Geronimo technologies to our user-base. This is one of the ways that Open Source projects traditionally generate interest and reach out to new potential developers. All aspects of clustering in Geronimo are going to require considerable work, and this is our chance to show our users that we are involved in at least some of these areas and invite them to contribute. I crafted my last change to make as few alterations to 1.0 as possible. It was called 'unacceptable', as far as I can tell, because it did not go far enough. Now we are saying that we only want minimal change between 1.0 and 1.0.1 - so what is it to be ? A clearly defined subset of WADI fnality will 'work' by the time 1.0.1 is released. If we work towards the necessary integration now, then we will have a while to discuss it and get it in, if we don't, then it will again be termed too precipitous, we will miss 1.0.1 and the current fragmented approach to web clustering will persist in Geronimo, impacting on a growing number of users. Jules Jan Bartel wrote: David, To paraphrase what you said (if I understand correctly), the choices are to either back clustering out of geronimo for the 1.0.1 release and work on it for a future release, or to make minimal changes to it to make it work in geronimo as is. I think it's unlikely that there will be a significant rush to production with a 1.0 release of geronimo, so there is probably a bit of latitude for less-than-optimal functioning in terms of 2nd order functionality such as clustering if it were to be left in. It would be good to get Jules' input on the state of WADI on this point. However, if we leave clustering in the way it is implemented at the moment, then the disadvantages are: 1. clustering is enabled differently for tomcat and jetty and a basic tenet of geronimo is to make the webcontainers interchangeable 2. clustering is enabled in the webapp descriptors instead of the container 3. users that use the 1.0.1 clustering will have to change each webapp to use it on future releases. If we roll forward again to the most recent clustering changes: 1. clustering interface is uniform for both tomcat and jetty 2. clustering is enabled in the container 3. no geronimo webapp descriptor changes necessary Of course, the most recent changes are not the final clustering solution, so there would be changes to the container plans in the future (eg in 1.1). But changes to the plans could probably be expected for any geronimo services between releases, no? I don't like the option of leaving the clustering with per-webapp geronimo descriptor configuration because it's just simply the wrong way to do it and will be a pain in the neck for users when we change to a better way in future releases. I think it would be better to take clustering out than to release 1.0.1 with it like it is. So, the two options I see for 1.0.1 are: 1. take the clustering out and release in 1.1 after more discussion 2. leave clustering in, roll forward again and fix any issues I really don't have a preference either way - I think both are meritworthy. regards Jan I think that it would be better to work on clustering in head and not try to hurry to get something that we know will change and has not been well tested into 1.0.1. I have no experience with actual clustering. Will people who want to use it expect something well tested and stable? Will they be willing to work off snapshot builds to pick up the latest fixes? What would the reaction be to something that only sort of works in an official release? thanks david jencks On Jan 14, 2006, at 3:46 AM, Jules Gosnell wrote: OK, Folks - here is how I see it - Everyone knows that they are right and the other guy is wrong. Result - DEADLOCK - everyone loses. Solution - release locks, back off, coordinate, retry. Releasing locks involves us all making concessions : I suggest - Jan, Greg and I conceded that Jeff could have been more involved in discussion before this change went in. Jeff concedes that Jan, Greg and I should have been involved in discussion before he backed the change out. We all agree to overlook all current technical differences. We all agree to put aside whatever bad feelings may have arisen from this incident. OK - locks released, backing-off complete. Now, coordination : WADI side : I will downgrade the log.info to a log.debug I will remove the axion dependency. I will resubmit the change as a patch to Jan and Jeff. Jetty/Tomcat side : Jan and Jeff will take this patch, and all relevant input. If they feel that they need further discussion, t
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Lets make something clear here... There are two facets of clustering in Geronimo right now. WADI and Tomcat clustering. The Tomcat clustering uses the Tomcat clustering objects and GBeans and they work and have been tested including a full howto in Confluence: http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Clustering+Example I am completely open to making WADI available in 1.0.1, and will be happy to go along with it being a 1.1 release if that is consensus. I support it in its entirety and where needed. But I do not believe the Tomcat objects should be removed and should be categorized differently, as these have been confirmed as working and ready for use. So when we talk about clustering, I think we need to be more succinct in stating which clustering we are talking about. Jeff Jan Bartel wrote: > David, > > To paraphrase what you said (if I understand correctly), the choices are > to either back clustering out of geronimo for the 1.0.1 release and work > on it for a future release, or to make minimal changes to it to make it > work > in geronimo as is. > > I think it's unlikely that there will be a significant rush to > production with a 1.0 release of geronimo, so there is probably a bit of > latitude for less-than-optimal functioning in terms of 2nd order > functionality such as clustering if it were to be left in. It would be > good to get Jules' input on the state of WADI on this point. > > However, if we leave clustering in the way it is implemented at the > moment, then the disadvantages are: > 1. clustering is enabled differently for tomcat and jetty and a basic > tenet of geronimo is to make the webcontainers interchangeable > 2. clustering is enabled in the webapp descriptors instead of the container > 3. users that use the 1.0.1 clustering will have to change each webapp > to use it on future releases. > If we roll forward again to the most recent clustering changes: > 1. clustering interface is uniform for both tomcat and jetty > 2. clustering is enabled in the container 3. no geronimo webapp > descriptor changes necessary > > Of course, the most recent changes are not the final clustering > solution, so there would be changes to the container plans > in the future (eg in 1.1). But changes to the plans could probably be > expected for any geronimo services between releases, no? > > I don't like the option of leaving the clustering with per-webapp > geronimo descriptor configuration because it's just simply the > wrong way to do it and will be a pain in the neck for users when > we change to a better way in future releases. I think it would be better > to take clustering out than to release 1.0.1 with it like it is. > > So, the two options I see for 1.0.1 are: > > 1. take the clustering out and release in 1.1 after more discussion > 2. leave clustering in, roll forward again and fix any issues > > I really don't have a preference either way - I think both are meritworthy. > > regards > Jan > > > > > >> I think that it would be better to work on clustering in head and not >> try to hurry to get something that we know will change and has not >> been well tested into 1.0.1. I have no experience with actual >> clustering. Will people who want to use it expect something well >> tested and stable? Will they be willing to work off snapshot builds >> to pick up the latest fixes? What would the reaction be to something >> that only sort of works in an official release? >> >> thanks >> david jencks >> >> >> On Jan 14, 2006, at 3:46 AM, Jules Gosnell wrote: >> >>> OK, Folks - here is how I see it - >>> >>> Everyone knows that they are right and the other guy is wrong. >>> >>> Result - DEADLOCK - everyone loses. >>> >>> Solution - release locks, back off, coordinate, retry. >>> >>> Releasing locks involves us all making concessions : >>> >>> I suggest - >>> >>> Jan, Greg and I conceded that Jeff could have been more involved in >>> discussion before this change went in. >>> Jeff concedes that Jan, Greg and I should have been involved in >>> discussion before he backed the change out. >>> We all agree to overlook all current technical differences. >>> We all agree to put aside whatever bad feelings may have arisen from >>> this incident. >>> >>> OK - locks released, backing-off complete. >>> >>> Now, coordination : >>> >>> WADI side : >>> >>> I will downgrade the log.info to a log.debug >>> I will remove the axion dependency. >>> I will resubmit the change as a patch to Jan and Jeff. >>> >>> Jetty/Tomcat side : >>> Jan and Jeff will take this patch, and all relevant input. >>> If they feel that they need further discussion, they will have it. >>> They will implement a simple, unified solution to the issue for all >>> existing cases and get it in to Geronimo 1.0.1 >>> >>> >>> I simply want a speedy, painless resolution so we can continue forward. >>> >>> If everyone else is happy with these terms, then here is my '+1' >>> >>> >>> Jules >>>
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
David, To paraphrase what you said (if I understand correctly), the choices are to either back clustering out of geronimo for the 1.0.1 release and work on it for a future release, or to make minimal changes to it to make it work in geronimo as is. I think it's unlikely that there will be a significant rush to production with a 1.0 release of geronimo, so there is probably a bit of latitude for less-than-optimal functioning in terms of 2nd order functionality such as clustering if it were to be left in. It would be good to get Jules' input on the state of WADI on this point. However, if we leave clustering in the way it is implemented at the moment, then the disadvantages are: 1. clustering is enabled differently for tomcat and jetty and a basic tenet of geronimo is to make the webcontainers interchangeable 2. clustering is enabled in the webapp descriptors instead of the container 3. users that use the 1.0.1 clustering will have to change each webapp to use it on future releases. If we roll forward again to the most recent clustering changes: 1. clustering interface is uniform for both tomcat and jetty 2. clustering is enabled in the container 3. no geronimo webapp descriptor changes necessary Of course, the most recent changes are not the final clustering solution, so there would be changes to the container plans in the future (eg in 1.1). But changes to the plans could probably be expected for any geronimo services between releases, no? I don't like the option of leaving the clustering with per-webapp geronimo descriptor configuration because it's just simply the wrong way to do it and will be a pain in the neck for users when we change to a better way in future releases. I think it would be better to take clustering out than to release 1.0.1 with it like it is. So, the two options I see for 1.0.1 are: 1. take the clustering out and release in 1.1 after more discussion 2. leave clustering in, roll forward again and fix any issues I really don't have a preference either way - I think both are meritworthy. regards Jan I think that it would be better to work on clustering in head and not try to hurry to get something that we know will change and has not been well tested into 1.0.1. I have no experience with actual clustering. Will people who want to use it expect something well tested and stable? Will they be willing to work off snapshot builds to pick up the latest fixes? What would the reaction be to something that only sort of works in an official release? thanks david jencks On Jan 14, 2006, at 3:46 AM, Jules Gosnell wrote: OK, Folks - here is how I see it - Everyone knows that they are right and the other guy is wrong. Result - DEADLOCK - everyone loses. Solution - release locks, back off, coordinate, retry. Releasing locks involves us all making concessions : I suggest - Jan, Greg and I conceded that Jeff could have been more involved in discussion before this change went in. Jeff concedes that Jan, Greg and I should have been involved in discussion before he backed the change out. We all agree to overlook all current technical differences. We all agree to put aside whatever bad feelings may have arisen from this incident. OK - locks released, backing-off complete. Now, coordination : WADI side : I will downgrade the log.info to a log.debug I will remove the axion dependency. I will resubmit the change as a patch to Jan and Jeff. Jetty/Tomcat side : Jan and Jeff will take this patch, and all relevant input. If they feel that they need further discussion, they will have it. They will implement a simple, unified solution to the issue for all existing cases and get it in to Geronimo 1.0.1 I simply want a speedy, painless resolution so we can continue forward. If everyone else is happy with these terms, then here is my '+1' Jules Jeff Genender wrote: Hi Jules. A few comments. First, you made changes without discussing them on the dev lists. As per the discussions in the past, both Aaron and David Jencks, as well as I threw in our .02 on how to integrate the clustering. I would appreciate you discuss code ideas and changes that have such a drastic impact on the Geronimo code base. Here are the issues with your check in: 1) I explained before for Jetty, and obviously now I need to do it for Tomcat, a -1 on Axion as a dependency. There should not be any web application dependencies injected at the container level. This means there is a severe architectural issue with WADI when we are injecting these dependencies into the container. 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the distributablesession manager in the TomcatContainer. Hardcoding a pluggable session engine is very bad, and defeats the pluggability of a configuration that we requested. 3) You placed log.info() in the code, and Aaron worked pretty hard to clean those up. 4) Your integration of setting the manager
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
On Sat, 14 Jan 2006, David Jencks wrote: > What would the reaction be to something > that only sort of works in an official release? IMHO all features all features in a production release should be usable. It's not a problem if the functionality is limited, as long as it works.
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
I think this is a major step towards resolving this issue, thanks Jules. I would like however to start a discussion about whether these changes should go into 1.0.1. I will freely admit that I thought that clustering features were crammed into 1.0 at the last minute without adequate testing and discussion and that the results have been unsatisfactory and we would be better off without them in 1.0. I apologize for not objecting at the time. Here are some factors that I think must be weighed in a decision about whether to include changes to clustering in 1.0.1 or 1.1: - when will 1.1 come out. The longer off it is, the more pressure to get something available sooner. - the purpose of 1.0.1: essential bugfix or development free for all - whether the immediate changes proposed for 1.0.1 will change any interfaces or deployment descriptors used in 1.0 - whether the proposed interfaces for 1.0.1 are expected to be stable or will change again for 1.1 - if the clustering changes go into 1.0.1, will they actually be production ready or at least as stable/usable as the rest of 1.0.1 Here is what I think about these factors: - I want 1.1 to come out fairly soon, in about 3 months after 1.0. That should mean a feature freeze in perhaps 6 weeks. - I want 1.0.1 to only fix severe problems in 1.0 and avoid changing any interfaces/ deployment descriptors - AFAICT the proposals for clustering involve changing how it is set up in 1.0, both interfaces and plans. - Based on the work so far I don't think we will have an acceptable stable solution for the interfaces and plans for 1.0.1 - I have no idea how stable clustering functionality might be. AFAIK it has not been tested much if at all yet. I think that it would be better to work on clustering in head and not try to hurry to get something that we know will change and has not been well tested into 1.0.1. I have no experience with actual clustering. Will people who want to use it expect something well tested and stable? Will they be willing to work off snapshot builds to pick up the latest fixes? What would the reaction be to something that only sort of works in an official release? thanks david jencks On Jan 14, 2006, at 3:46 AM, Jules Gosnell wrote: OK, Folks - here is how I see it - Everyone knows that they are right and the other guy is wrong. Result - DEADLOCK - everyone loses. Solution - release locks, back off, coordinate, retry. Releasing locks involves us all making concessions : I suggest - Jan, Greg and I conceded that Jeff could have been more involved in discussion before this change went in. Jeff concedes that Jan, Greg and I should have been involved in discussion before he backed the change out. We all agree to overlook all current technical differences. We all agree to put aside whatever bad feelings may have arisen from this incident. OK - locks released, backing-off complete. Now, coordination : WADI side : I will downgrade the log.info to a log.debug I will remove the axion dependency. I will resubmit the change as a patch to Jan and Jeff. Jetty/Tomcat side : Jan and Jeff will take this patch, and all relevant input. If they feel that they need further discussion, they will have it. They will implement a simple, unified solution to the issue for all existing cases and get it in to Geronimo 1.0.1 I simply want a speedy, painless resolution so we can continue forward. If everyone else is happy with these terms, then here is my '+1' Jules Jeff Genender wrote: Hi Jules. A few comments. First, you made changes without discussing them on the dev lists. As per the discussions in the past, both Aaron and David Jencks, as well as I threw in our .02 on how to integrate the clustering. I would appreciate you discuss code ideas and changes that have such a drastic impact on the Geronimo code base. Here are the issues with your check in: 1) I explained before for Jetty, and obviously now I need to do it for Tomcat, a -1 on Axion as a dependency. There should not be any web application dependencies injected at the container level. This means there is a severe architectural issue with WADI when we are injecting these dependencies into the container. 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the distributablesession manager in the TomcatContainer. Hardcoding a pluggable session engine is very bad, and defeats the pluggability of a configuration that we requested. 3) You placed log.info() in the code, and Aaron worked pretty hard to clean those up. 4) Your integration of setting the manager (no matter what) is a direct clash with the Jules, I am giving a complete -1 of checkin of 368344. These are all for technical reasons. Please back out these changes, and bring this discussion to the Geronimo lists as this needs some significant discussion for implementation. I would appreciate that you please involve the Apach
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
My comments inline... Greg Wilkins wrote: Jules Gosnell wrote: I suggest - Jan, Greg and I conceded that Jeff could have been more involved in discussion before this change went in. +1 We all agree to overlook all current technical differences. I don't think "overlook" is the right word. Continue discussing would be better. See below. Continue discussing is better. Life is iteration. We all agree to put aside whatever bad feelings may have arisen from this incident. I am deeply dissappointed that the conversation degenerated as it did. More so that neither the participants nor the community were able to publicly or privately disarm the thread. As I'm no stranger to such threads - I'd really appreciate if third parties could point out publicly or private where I went wrong and why my words were seen as attacks? But yes +1 lets move on. Since you asked for feedback. Personally, I probably contacted Jeff offline first to see what was up and try to ensure that I understood his issues. At that point I think documenting and moving on with the list would have worked. I know we want to work in the public but it seemed based on Jeff's response that perhaps a quick "offline" chat could have avoided the public debate. Anyway, hindsight is 20-20. WADI side : ... I will resubmit the change as a patch to Jan and Jeff. Jetty/Tomcat side : Jan and Jeff will take this patch, and all relevant input. If they feel that they need further discussion, they will have it. They will implement a simple, unified solution to the issue for all existing cases and get it in to Geronimo 1.0.1 Actually, before trying the patch again, I think we need to back off a little bit more and get the requirements straight. ie what is it that we are trying to achieve for 1.0.1 My understanding was that there were two goals: 1) make clustering work in the release. +1 to this. What "work" means to me is that any outstanding issues related to clustering not working are addressed. Improved documentation would be useful for the users too. 2) Unified clustering configuration that allows an unmodified web app to be deployed on g-jetty and g-tomcat. I think this is more of a 1.1 issue. I think the items that would need to be surfaced for 1.0.1 is how large are the changes and how close to complete are they. Many people have expressed that 1.0.1 should go out "in a few weeks" so I expect that this is more fit and finish rather than significant new function. Hopefully we all agree that 1) is a requirement and i think Jules should open a JIRA to capture that some things were broken in 1.0 and need to be fixed for 1.0.1 However, I'm not so sure we agree on the need for 2) in 1.0.1 and I think that has been the cause of much of the disagreement. It appears that to achieve 2) may require either some compromises (eg clustering configs in container plans) or significant work (create share stand alone clustering plan). I think that removing differences between Jetty and tomcat is a high priority and that we can accept some compromises to unify things for 1.0.1, as that will halve any breakage needed for 1.1 etc. Thus I do think that 2) is a requirement - but others may disagree I think 2 is important but not required. The only holdback here from my perspective is how will this affect users going from 1.0.1 to 1.1 and on. If there is going to be a large disruption if we don't do this in 1.0.1 and a fix is available and simply needs to be tested then I think we can consider for 1.0.1. My gut tells me to wait but I don't have enough info. regards
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
+1 On Jan 14, 2006, at 4:46 AM, Jules Gosnell wrote: OK, Folks - here is how I see it - Everyone knows that they are right and the other guy is wrong. Result - DEADLOCK - everyone loses. Solution - release locks, back off, coordinate, retry. Releasing locks involves us all making concessions : I suggest - Jan, Greg and I conceded that Jeff could have been more involved in discussion before this change went in. Jeff concedes that Jan, Greg and I should have been involved in discussion before he backed the change out. We all agree to overlook all current technical differences. We all agree to put aside whatever bad feelings may have arisen from this incident. OK - locks released, backing-off complete. Now, coordination : WADI side : I will downgrade the log.info to a log.debug I will remove the axion dependency. I will resubmit the change as a patch to Jan and Jeff. Jetty/Tomcat side : Jan and Jeff will take this patch, and all relevant input. If they feel that they need further discussion, they will have it. They will implement a simple, unified solution to the issue for all existing cases and get it in to Geronimo 1.0.1 I simply want a speedy, painless resolution so we can continue forward. If everyone else is happy with these terms, then here is my '+1' Jules Jeff Genender wrote: Hi Jules. A few comments. First, you made changes without discussing them on the dev lists. As per the discussions in the past, both Aaron and David Jencks, as well as I threw in our .02 on how to integrate the clustering. I would appreciate you discuss code ideas and changes that have such a drastic impact on the Geronimo code base. Here are the issues with your check in: 1) I explained before for Jetty, and obviously now I need to do it for Tomcat, a -1 on Axion as a dependency. There should not be any web application dependencies injected at the container level. This means there is a severe architectural issue with WADI when we are injecting these dependencies into the container. 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the distributablesession manager in the TomcatContainer. Hardcoding a pluggable session engine is very bad, and defeats the pluggability of a configuration that we requested. 3) You placed log.info() in the code, and Aaron worked pretty hard to clean those up. 4) Your integration of setting the manager (no matter what) is a direct clash with the Jules, I am giving a complete -1 of checkin of 368344. These are all for technical reasons. Please back out these changes, and bring this discussion to the Geronimo lists as this needs some significant discussion for implementation. I would appreciate that you please involve the Apache way and open discussions on the lists before doing this sort of thing in the future. Again, I will CC the G lists to make this clear, that I would like this change backed out. Jeff Jules Gosnell wrote: Here is a list of outstanding issues associated with this work: - ActiveMQ's shutdown hook seems to trigger when Geronimo is shutdown, removing AMQ before WADI - WADI doesn't like this. I have added a property to the node.sh script which suppresses this behaviour. I will document it in the Getting Started doc. - There 'may' be issues with nodes finding each other, when a Geronimo node is introduced into a WADI cluster - investigating. - Jeff - you should look over the changes and make sure that they do not impact on any other TC fn-ality. They were done with Emacs, so the formatting may be offensive. Please feel free to make them your own and bring any issues back to the list. The WADIGBean, is no longer used, so you may want to remove this from the repo. - Jan and Jeff - since this config is now done on the container bean and not in the geronimo-web.xml, you may no longer need to implement your own geronimo-web.xml schemas (I haven't looked very closely at TC). You may want to consider this and perhaps lose them. - In order to get the same webapp to work in all containers (tomcat5[05], jetty[56], geronimo-[tomcat/jetty], jboss-tomcat), I had to move deps back to Geronimo container-level. These include Axion, which I know will upset Jeff. As I have stated before, WADI's dependence on Axion is easily removed. If Jeff or anyone wants to look at replacing it with Derby, it is fine with me, as long as they do some testing and confirm that having created a session on a single node and restarted it, the session survives (if the DB is still running). This needs to be tested on all supported containers. Axion was used because it is an in-VM DB (so imposes no further integration dependencies on the Getting Started stuff and is useful for unit-testing) and was in use by Geronimo at the time. So I suggest that any replacement needs to also be able to run in-vm aswell. As we go further and move WADI's actual configuration from the app to the contai
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Here are a couple of simple suggestions for moving this discussion forward:
1) Please make sure to have as many discussions as possible in public
on the dev@ mailing list and make sure to summarize offline
discussions as soon as possible after they have occurred.
2) Please create JIRA issues identifying any and all issues. Use these
issues as the place to document ongoing work and attach patches for
review before committing to SVN.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
+1. This is really great stuff. Jeff Jules Gosnell wrote: > OK, Folks - here is how I see it - > > Everyone knows that they are right and the other guy is wrong. > > Result - DEADLOCK - everyone loses. > > Solution - release locks, back off, coordinate, retry. > > Releasing locks involves us all making concessions : > > I suggest - > > Jan, Greg and I conceded that Jeff could have been more involved in > discussion before this change went in. > Jeff concedes that Jan, Greg and I should have been involved in > discussion before he backed the change out. > We all agree to overlook all current technical differences. > We all agree to put aside whatever bad feelings may have arisen from > this incident. > > OK - locks released, backing-off complete. > > Now, coordination : > > WADI side : > > I will downgrade the log.info to a log.debug > I will remove the axion dependency. > I will resubmit the change as a patch to Jan and Jeff. > > Jetty/Tomcat side : > Jan and Jeff will take this patch, and all relevant input. > If they feel that they need further discussion, they will have it. > They will implement a simple, unified solution to the issue for all > existing cases and get it in to Geronimo 1.0.1 > > > I simply want a speedy, painless resolution so we can continue forward. > > If everyone else is happy with these terms, then here is my '+1' > > > Jules > > > Jeff Genender wrote: > >> Hi Jules. >> >> A few comments. First, you made changes without discussing them on the >> dev lists. >> >> As per the discussions in the past, both Aaron and David Jencks, as well >> as I threw in our .02 on how to integrate the clustering. I would >> appreciate you discuss code ideas and changes that have such a drastic >> impact on the Geronimo code base. Here are the issues with your check >> in: >> >> 1) I explained before for Jetty, and obviously now I need to do it for >> Tomcat, a -1 on Axion as a dependency. There should not be any web >> application dependencies injected at the container level. This means >> there is a severe architectural issue with WADI when we are injecting >> these dependencies into the container. >> >> 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the >> distributablesession manager in the TomcatContainer. Hardcoding a >> pluggable session engine is very bad, and defeats the pluggability of a >> configuration that we requested. >> >> 3) You placed log.info() in the code, and Aaron worked pretty hard to >> clean those up. >> >> 4) Your integration of setting the manager (no matter what) is a direct >> clash with the >> >> Jules, I am giving a complete -1 of checkin of 368344. These are all >> for technical reasons. Please back out these changes, and bring this >> discussion to the Geronimo lists as this needs some significant >> discussion for implementation. I would appreciate that you please >> involve the Apache way and open discussions on the lists before doing >> this sort of thing in the future. >> >> Again, I will CC the G lists to make this clear, that I would like this >> change backed out. >> >> Jeff >> >> >> Jules Gosnell wrote: >> >> >>> Here is a list of outstanding issues associated with this work: >>> >>> - ActiveMQ's shutdown hook seems to trigger when Geronimo is shutdown, >>> removing AMQ before WADI - WADI doesn't like this. I have added a >>> property to the node.sh script which suppresses this behaviour. I will >>> document it in the Getting Started doc. >>> >>> - There 'may' be issues with nodes finding each other, when a Geronimo >>> node is introduced into a WADI cluster - investigating. >>> >>> - Jeff - you should look over the changes and make sure that they do not >>> impact on any other TC fn-ality. They were done with Emacs, so the >>> formatting may be offensive. Please feel free to make them your own and >>> bring any issues back to the list. The WADIGBean, is no longer used, so >>> you may want to remove this from the repo. >>> >>> - Jan and Jeff - since this config is now done on the container bean and >>> not in the geronimo-web.xml, you may no longer need to implement your >>> own geronimo-web.xml schemas (I haven't looked very closely at TC). You >>> may want to consider this and perhaps lose them. >>> >>> - In order to get the same webapp to work in all containers >>> (tomcat5[05], jetty[56], geronimo-[tomcat/jetty], jboss-tomcat), I had >>> to move deps back to Geronimo container-level. These include Axion, >>> which I know will upset Jeff. As I have stated before, WADI's dependence >>> on Axion is easily removed. If Jeff or anyone wants to look at replacing >>> it with Derby, it is fine with me, as long as they do some testing and >>> confirm that having created a session on a single node and restarted it, >>> the session survives (if the DB is still running). This needs to be >>> tested on all supported containers. Axion was used because it is an >>> in-VM DB (so imposes no further integration dependencies on
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Jules Gosnell wrote: > I suggest - > Jan, Greg and I conceded that Jeff could have been more involved in > discussion before this change went in. +1 > We all agree to overlook all current technical differences. I don't think "overlook" is the right word. Continue discussing would be better. See below. > We all agree to put aside whatever bad feelings may have arisen from > this incident. I am deeply dissappointed that the conversation degenerated as it did. More so that neither the participants nor the community were able to publicly or privately disarm the thread. As I'm no stranger to such threads - I'd really appreciate if third parties could point out publicly or private where I went wrong and why my words were seen as attacks? But yes +1 lets move on. > WADI side : >... > I will resubmit the change as a patch to Jan and Jeff. > > Jetty/Tomcat side : > Jan and Jeff will take this patch, and all relevant input. > If they feel that they need further discussion, they will have it. > They will implement a simple, unified solution to the issue for all > existing cases and get it in to Geronimo 1.0.1 Actually, before trying the patch again, I think we need to back off a little bit more and get the requirements straight. ie what is it that we are trying to achieve for 1.0.1 My understanding was that there were two goals: 1) make clustering work in the release. 2) Unified clustering configuration that allows an unmodified web app to be deployed on g-jetty and g-tomcat. Hopefully we all agree that 1) is a requirement and i think Jules should open a JIRA to capture that some things were broken in 1.0 and need to be fixed for 1.0.1 However, I'm not so sure we agree on the need for 2) in 1.0.1 and I think that has been the cause of much of the disagreement. It appears that to achieve 2) may require either some compromises (eg clustering configs in container plans) or significant work (create share stand alone clustering plan). I think that removing differences between Jetty and tomcat is a high priority and that we can accept some compromises to unify things for 1.0.1, as that will halve any breakage needed for 1.1 etc. Thus I do think that 2) is a requirement - but others may disagree regards
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
OK, Folks - here is how I see it - Everyone knows that they are right and the other guy is wrong. Result - DEADLOCK - everyone loses. Solution - release locks, back off, coordinate, retry. Releasing locks involves us all making concessions : I suggest - Jan, Greg and I conceded that Jeff could have been more involved in discussion before this change went in. Jeff concedes that Jan, Greg and I should have been involved in discussion before he backed the change out. We all agree to overlook all current technical differences. We all agree to put aside whatever bad feelings may have arisen from this incident. OK - locks released, backing-off complete. Now, coordination : WADI side : I will downgrade the log.info to a log.debug I will remove the axion dependency. I will resubmit the change as a patch to Jan and Jeff. Jetty/Tomcat side : Jan and Jeff will take this patch, and all relevant input. If they feel that they need further discussion, they will have it. They will implement a simple, unified solution to the issue for all existing cases and get it in to Geronimo 1.0.1 I simply want a speedy, painless resolution so we can continue forward. If everyone else is happy with these terms, then here is my '+1' Jules Jeff Genender wrote: Hi Jules. A few comments. First, you made changes without discussing them on the dev lists. As per the discussions in the past, both Aaron and David Jencks, as well as I threw in our .02 on how to integrate the clustering. I would appreciate you discuss code ideas and changes that have such a drastic impact on the Geronimo code base. Here are the issues with your check in: 1) I explained before for Jetty, and obviously now I need to do it for Tomcat, a -1 on Axion as a dependency. There should not be any web application dependencies injected at the container level. This means there is a severe architectural issue with WADI when we are injecting these dependencies into the container. 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the distributablesession manager in the TomcatContainer. Hardcoding a pluggable session engine is very bad, and defeats the pluggability of a configuration that we requested. 3) You placed log.info() in the code, and Aaron worked pretty hard to clean those up. 4) Your integration of setting the manager (no matter what) is a direct clash with the Jules, I am giving a complete -1 of checkin of 368344. These are all for technical reasons. Please back out these changes, and bring this discussion to the Geronimo lists as this needs some significant discussion for implementation. I would appreciate that you please involve the Apache way and open discussions on the lists before doing this sort of thing in the future. Again, I will CC the G lists to make this clear, that I would like this change backed out. Jeff Jules Gosnell wrote: Here is a list of outstanding issues associated with this work: - ActiveMQ's shutdown hook seems to trigger when Geronimo is shutdown, removing AMQ before WADI - WADI doesn't like this. I have added a property to the node.sh script which suppresses this behaviour. I will document it in the Getting Started doc. - There 'may' be issues with nodes finding each other, when a Geronimo node is introduced into a WADI cluster - investigating. - Jeff - you should look over the changes and make sure that they do not impact on any other TC fn-ality. They were done with Emacs, so the formatting may be offensive. Please feel free to make them your own and bring any issues back to the list. The WADIGBean, is no longer used, so you may want to remove this from the repo. - Jan and Jeff - since this config is now done on the container bean and not in the geronimo-web.xml, you may no longer need to implement your own geronimo-web.xml schemas (I haven't looked very closely at TC). You may want to consider this and perhaps lose them. - In order to get the same webapp to work in all containers (tomcat5[05], jetty[56], geronimo-[tomcat/jetty], jboss-tomcat), I had to move deps back to Geronimo container-level. These include Axion, which I know will upset Jeff. As I have stated before, WADI's dependence on Axion is easily removed. If Jeff or anyone wants to look at replacing it with Derby, it is fine with me, as long as they do some testing and confirm that having created a session on a single node and restarted it, the session survives (if the DB is still running). This needs to be tested on all supported containers. Axion was used because it is an in-VM DB (so imposes no further integration dependencies on the Getting Started stuff and is useful for unit-testing) and was in use by Geronimo at the time. So I suggest that any replacement needs to also be able to run in-vm aswell. As we go further and move WADI's actual configuration from the app to the container-level, these issues will disappear and WADI will be able to be hooked to whatever persistance mechanism is shipped in Geronim
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Jeff, I really can't understand your -1, let alone the backing out of the changes, nor all of the hullabaloo. It is quite straightforward: in 1.0 WADI did not work in Tomcat nor Jetty. Unfortunate and disappointing, but true. Period. We have made minimal changes to make it work in the 1.0.1 bug-fix release, and started to move us toward a container-based configuration solution (which all of us agree on) instead of a per-webapp configuration solution (which all of us agree is not desirable). So we are actually all in agreement! There is much more work to be done on the architecture as we all know, but that is something for a 1.1 release, not another rushed solution for the 1.0.1 bugfix release (and rushing is what caused us both to miss the 1.0 deadline). I really feel you have attacked me inappropriately and quite wrongly over this Axion jar issue. You said: Greg, based on the fact that I -1'd Jan's inclusion of Axion on 1/5, and it was never tended too, am I to believe the same would have occurred here? If you think I should have waited a few days, then perhaps I could have. But based on past history with you guys and handling -1s, I don't think it was unreasonable for me to think that you weren't going to remove it. Its now a full week (1/5-1/12) after the -1, and it has not been removed. How long is a reasonable time to wait for you to back out -1s? If you check the SVN log you will find this: r366693 | janb | 2006-01-07 09:19:14 +0100 (Sat, 07 Jan 2006) | 2 lines removing axion and special activemq wadi versions and therefore jgenenders' codehaus repository from repo list I did this shortly after I replied to your email of 6th January. Here is what I said to you: Jeff, Thanks for that, I will remove the unnecessary ones. I wasn't sure whether the activemq WADI version was needed or not, so thanks for clarifying that. I will fix up Geronimo tomorrow. cheers Jan And I did exactly just that - removed Axion (and the WADI-3.2 of activemq). So can we just leave the accusations aside, put the code back in place, and get on with working together to ensure the code works and addresses all immediate concerns, or otherwise we will miss the 1.0.1 deadline too. sincerely, Jan I sat in the room with Jules and Jan for three days while they worked on this. They certainly were discussing all the threads about this and they tried several times for a more minimal solution (name spaces etc.) but nothing else proved workable. That, in and of itself is the problem Greg. Lets bring this out on the lists, not in a room with Jules, Jan, and yourself. Jules said, "Jan and Greg are staying with me for a few days, starting monday. We will go through the integration together and keep the list up to date with any issues that we find." He never brought the discussion as he stated, and then followed it up today (1/12) with: "Jan and I have just refactored the Geronimo Jetty and Tomcat integrations to take the same approach to the installation of a 3rd party session manager, to ease the integration of WADI. This is now checked in on Geronimo's trunk." Where was the list up to date on discussion of what you have found, relative to the requests we made previously on the lists about what we want to see in the integration? Am I missing something here? So they moved one aspect of the config out of the WEB-INF and as a result they were able to get a webapp deployed on a mixed cluster of geronimo-jetty and geronimo-tomcat - HOORAY! Great...lets chat about it...I am all for open discussion on this! Lets see what they came up with...and work with the ideas into something that is a good solution for the team and community! But I wouldn't say the change (one aspect) was that simple from an impact perspective, Greg. They deserve thanks for a good achievement and some peer review to help them improve it. The certainly don't deserve unilateral action to erase their work and send every body back to square -1. Peer review? And where did that occur? See the above comments about Jules working with you on this, then checking it all in. I saw no peer review. Remember, this is an Apache project (Geronimo)...you should be sharing info with the community. Nobody said it wasn't a valiant attempt, nor that the intentions weren't good. Based on the Axion issues, one of my -1s has nothing to do with intentions, it has to do with putting the database hard coded dependency in the container. That is a serious architectural flaw. I -1'd that on the Jetty side as well. If you needed to try things out...and get a review afterwards, why didn't you just cut a quick branch and show off your changes? Nobody would have -1d that. I agree with David that the session manager configuration should be moved again to a clustering GBean, but that does not mean that we should move it back to WEB-INF while we wait for a better solution. This was a minimal solution that can be put in pla
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Jeff, Can you please calm down? I'm trying to discuss your concerns, but you appear to be taking offence that I'm doing so? These are not my changes - I'm just an interested observer on this one trying to interpret the arguments that have been put forward! > Greg, based on the fact that I -1'd Jan's inclusion of Axion on 1/5, and > it was never tended too, Your concern was address. Jan removed the dependency and put the jar back into the webapp. But that was for a per webapp clustering solution. It has generally been discussed an agreed to move towards a per container clustering configuration. > As for Axion being used to persist the session and is a container > dependency, I disagree...lets look at where axion is being used in WADI: As far as I understand it, axion is used to persist the session. There has been plenty of discussion about this and if it is appropriate or not. At the very least WADI should probably be changed to use derby which is now used by geronimo. But as of today, axion is a dependency of WADI and we want WADI to be a container rather than a webapp service. If what you say is true - that it is not a dependency, then just remove the dependency 9rather than everything) and it should work! I think you will find that wadi does not work without it. > The hard code of the wadi manager... It is not hard coded. It is just a reasonable default value and it is loosely coupled as it is just a class name.The commit removed a real hard dependency on WADIGBean so the change is less coupled to wadi! > the Axion dependency, Discussed to death. You initial -1 was address when we went back to a per-app config. It is a container dependency and so it has been moved. Now you may argue that WADI could use persistence services in a better way - but that is an issue for WADI not geronimo. > lack of pluggable configuration, The configuration is pluggable. Only the default is hard coded. > lack of ability to set Clustering options (properties) at the clustering > component level. Yes we all agree that a clustering GBean is needed for configuration. It will be the place to have lots of clustering options configured. If you think you can get this done by 1.0.1 - then great! you can then take the session managers config out of the container plans. > I think we have been through this. Lets stop this nonsense and move > forward on an open discussion with David Jencks' thread. I think if we > can concentrate on the positive aspects, we can get this properly going. I don't understand. David commented in this thread? The issues and suggestions he raised are being discussed? > Lets move on guys...we all should be moving forward here and stop > dwelling on this. I'm sorry Jeff, but just because you have -1'd a commit does not mean that the discussion is over and that these changes will never go in. Unless it is understood why you did your -1, then how is anybody going to proceed. Alternately, you could post some proposals or code of your own as to how to fix the change or how to achieve the results some other way? And finally again - I just don't understand your tone and why you are so worked up - its just configuration for -sake?
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Jeff Genender wrote: First off...lets get over this...DJ has a great thread open. I really don't want to continue this discussion as its wasting all of our time. Comments in line...and this is it for responding to this nonsense...time to move on...ok? Jeff, you cannot, on the one hand, accuse people of not discussing things with you and, on the other, dismiss their comments as "nonsense". Jules Greg Wilkins wrote: Jeff Genender wrote: I am sorry Jules, I am -1 on the change and I stand firm on that. Jeff, I don't understand your total -1, nor the fact that you actually backed out the change before anybody could reply to your email. Greg, based on the fact that I -1'd Jan's inclusion of Axion on 1/5, and it was never tended too, am I to believe the same would have occurred here? If you think I should have waited a few days, then perhaps I could have. But based on past history with you guys and handling -1s, I don't think it was unreasonable for me to think that you weren't going to remove it. Its now a full week (1/5-1/12) after the -1, and it has not been removed. How long is a reasonable time to wait for you to back out -1s? I sat in the room with Jules and Jan for three days while they worked on this. They certainly were discussing all the threads about this and they tried several times for a more minimal solution (name spaces etc.) but nothing else proved workable. That, in and of itself is the problem Greg. Lets bring this out on the lists, not in a room with Jules, Jan, and yourself. Jules said, "Jan and Greg are staying with me for a few days, starting monday. We will go through the integration together and keep the list up to date with any issues that we find." He never brought the discussion as he stated, and then followed it up today (1/12) with: "Jan and I have just refactored the Geronimo Jetty and Tomcat integrations to take the same approach to the installation of a 3rd party session manager, to ease the integration of WADI. This is now checked in on Geronimo's trunk." Where was the list up to date on discussion of what you have found, relative to the requests we made previously on the lists about what we want to see in the integration? Am I missing something here? So they moved one aspect of the config out of the WEB-INF and as a result they were able to get a webapp deployed on a mixed cluster of geronimo-jetty and geronimo-tomcat - HOORAY! Great...lets chat about it...I am all for open discussion on this! Lets see what they came up with...and work with the ideas into something that is a good solution for the team and community! But I wouldn't say the change (one aspect) was that simple from an impact perspective, Greg. They deserve thanks for a good achievement and some peer review to help them improve it. The certainly don't deserve unilateral action to erase their work and send every body back to square -1. Peer review? And where did that occur? See the above comments about Jules working with you on this, then checking it all in. I saw no peer review. Remember, this is an Apache project (Geronimo)...you should be sharing info with the community. Nobody said it wasn't a valiant attempt, nor that the intentions weren't good. Based on the Axion issues, one of my -1s has nothing to do with intentions, it has to do with putting the database hard coded dependency in the container. That is a serious architectural flaw. I -1'd that on the Jetty side as well. If you needed to try things out...and get a review afterwards, why didn't you just cut a quick branch and show off your changes? Nobody would have -1d that. I agree with David that the session manager configuration should be moved again to a clustering GBean, but that does not mean that we should move it back to WEB-INF while we wait for a better solution. This was a minimal solution that can be put in place in time for 1.0.1. We don't have time to create a clustering module before then. Greg, I think the point here is we all need to discuss this before doing this. The Apache way, remember? If you all discussed this openly, perhaps the config could be built by now, yes? As for the axion dependancy, I do believe this is a container dependancy. Axion is being used to persist the session - which is a web container function, not a webapp function. We had discussed this and I thought you had agreed with me on this point - that we should not have to put WADI dependancies into WEB-INF/lib of the apps so they can be clustered. Greg, that is a complete fabrication of the truth. I am sorry Greg, I never agreed with Axion being in the container. I did agree with the ability to inject the clustering as a pluggable configuration at the container or context level. That is as far as I agreed. If we need a connector (READ: RAR) to be used for the database, then this is fine...its a pluggable component. But as a hard
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
OK, I am back. David Jencks wrote: I agree with Jeff that this change is unsatisfactory but I'm not as sure as he is that backing it out is necessary, perhaps we can move forward to an acceptable solution instead. I have to ask - on what grounds is it unsatisfactory ? If backing out is unecessary, how do you propose moving forwards, now that this has been done ? I also am not so sure that this magnitude of change needs prior discussion on the list. I've frequently made larger changes without discussion of my specific code. I've also broken lots of stuff at various times. Jeff has still to demostrate that something has been broken. Having two competing configuration mechanisms instead of three does not constitute 'breakage', but iteration towards one single mechanism. It may be that I have broken something. If this is the case, I would apologise and endevour to fix it immediately. One thing I insist on is that it be possible to run geronimo with no clustering support whatsoever, including no clustering classes anywhere in the geronimo system. I believe this means that each clustering system has to be installed as a configuration. Doing this right now as the first step will I think help focus the rest of the componentization. This involves splitting the Jetty and TC configs into local and clustered and associated refactoring. Ultimately this is where I would like to be aswell, but I think it unlikely to happen in time for 1.0.1. All I am trying to do is to get a Geronimo/Jetty/Tomcat/WADI solution, that has as little impact as possible, in place before 1.0.1. I don't understand the requirements very well, I hope for some answers: - do we need to support running more than one clustering system with a particular web container instance (e.g. JettyContainerImpl gbean instance)? I'm hoping "no" If we pursue the direction that has been discussed, then per-app and per-container configs will be possible. Per-container config will allow the container to specify a single default clustering solution, but apps would be free to override this with their own specific solution. IIUC we are installing clustering as a session manager. Perhaps I don't understand the code but it looks to me as if the jetty code at least is creating a new instance for each web app. I can't believe this is an acceptable strategy for all clustering implementations. For instance, I would think if you have a bunch of web apps doing cross-context dispatch you would want them all to share a session manager. I think we want the possibility of installing a single container wide session manager or per-app session managers. I believe that I also mentioned this in one of the discussion threads., but this requirement did not make it onto my mental roadmap for 1.0.1. Is it really plausible to rely on the distributable tag in the spec dd to turn on clustering? Presence of the tag in the web.xml indicates the apps requirement to the container to be clustered. I would think a further tag in our plan should be needed. If the app did not override (via some future extension) the container's choice of clustering solution, then the container's default solution would be implemented. Here's what I propose: We define a SessionManagerFactory interface, and for each clustering technology provide an implementation as a gbean.You can get a local and a distributed session manager from this interface. The runtime configuration for the clustering includes this gbean. Each web app context gets a reference to this gbean and gets the appropriate session manager when it starts. The web app context knows if it is supposed to be local or distributed so it can ask for the right session manager. We have a deploy time configuration for each clustering technology also. This at least supplies the gbean reference to the runtime gbean, and can also install a runtime gbean in the configuration under construction. In this way the clustering technology can decide on whether one session manager is shared, a factory that always returns unconfigured new instances is needed, or if each web app needs a specially configured session manager. If this isn't clear, I'll be happy to try to clarify. No, it is quite clear - it is pretty close to a long-term suggestion which I made in conclusion to my 'geronimo-web.xml' thread: "...Perhaps a SessionManagerFactoryGBean could be used on a per-server basis to create individual SessionManagers (for each app) that can then share further server-wide resources ?" I was simply trying to come up with a short-term solution to tide us over 1.0.1 before we sat down and went for the whole enchillada. Jules thanks david jencks On Jan 12, 2006, at 7:54 AM, Jeff Genender wrote: I didn't finish #4..sorry... 4) Your integration of setting the manager (no matter what) is a direct clash with
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
First off...lets get over this...DJ has a great thread open. I really don't want to continue this discussion as its wasting all of our time. Comments in line...and this is it for responding to this nonsense...time to move on...ok? Greg Wilkins wrote: > Jeff Genender wrote: >> I am sorry Jules, I am -1 on the change and I stand firm on that. > > Jeff, > > I don't understand your total -1, nor the fact that you actually backed > out the change before anybody could reply to your email. Greg, based on the fact that I -1'd Jan's inclusion of Axion on 1/5, and it was never tended too, am I to believe the same would have occurred here? If you think I should have waited a few days, then perhaps I could have. But based on past history with you guys and handling -1s, I don't think it was unreasonable for me to think that you weren't going to remove it. Its now a full week (1/5-1/12) after the -1, and it has not been removed. How long is a reasonable time to wait for you to back out -1s? > > I sat in the room with Jules and Jan for three days while they worked on > this. > They certainly were discussing all the threads about this and they tried > several times for a more minimal solution (name spaces etc.) but > nothing else proved workable. That, in and of itself is the problem Greg. Lets bring this out on the lists, not in a room with Jules, Jan, and yourself. Jules said, "Jan and Greg are staying with me for a few days, starting monday. We will go through the integration together and keep the list up to date with any issues that we find." He never brought the discussion as he stated, and then followed it up today (1/12) with: "Jan and I have just refactored the Geronimo Jetty and Tomcat integrations to take the same approach to the installation of a 3rd party session manager, to ease the integration of WADI. This is now checked in on Geronimo's trunk." Where was the list up to date on discussion of what you have found, relative to the requests we made previously on the lists about what we want to see in the integration? Am I missing something here? > > So they moved one aspect of the config out of the WEB-INF and as a result > they were able to get a webapp deployed on a mixed cluster of geronimo-jetty > and geronimo-tomcat - HOORAY! Great...lets chat about it...I am all for open discussion on this! Lets see what they came up with...and work with the ideas into something that is a good solution for the team and community! But I wouldn't say the change (one aspect) was that simple from an impact perspective, Greg. > > They deserve thanks for a good achievement and some peer review to > help them improve it. The certainly don't deserve unilateral action > to erase their work and send every body back to square -1. Peer review? And where did that occur? See the above comments about Jules working with you on this, then checking it all in. I saw no peer review. Remember, this is an Apache project (Geronimo)...you should be sharing info with the community. Nobody said it wasn't a valiant attempt, nor that the intentions weren't good. Based on the Axion issues, one of my -1s has nothing to do with intentions, it has to do with putting the database hard coded dependency in the container. That is a serious architectural flaw. I -1'd that on the Jetty side as well. If you needed to try things out...and get a review afterwards, why didn't you just cut a quick branch and show off your changes? Nobody would have -1d that. > > I agree with David that the session manager configuration should be moved > again to a clustering GBean, but that does not mean that we should move it > back > to WEB-INF while we wait for a better solution. This was a minimal solution > that can be put in place in time for 1.0.1. We don't have time to create > a clustering module before then. Greg, I think the point here is we all need to discuss this before doing this. The Apache way, remember? If you all discussed this openly, perhaps the config could be built by now, yes? > > As for the axion dependancy, I do believe this is a container dependancy. > Axion is being used to persist the session - which is a web container > function, not a webapp function. We had discussed this and I thought you > had > agreed with me on this point - that we should not have to put WADI > dependancies > into WEB-INF/lib of the apps so they can be clustered. Greg, that is a complete fabrication of the truth. I am sorry Greg, I never agreed with Axion being in the container. I did agree with the ability to inject the clustering as a pluggable configuration at the container or context level. That is as far as I agreed. If we need a connector (READ: RAR) to be used for the database, then this is fine...its a pluggable component. But as a hard code, its simply wrong. As for Axion being used to persist the session and is a container dependency, I disagree...lets look at where axion is being used in WADI: ./m
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Jeff Genender wrote: > I am sorry Jules, I am -1 on the change and I stand firm on that. Jeff, I don't understand your total -1, nor the fact that you actually backed out the change before anybody could reply to your email. I sat in the room with Jules and Jan for three days while they worked on this. They certainly were discussing all the threads about this and they tried several times for a more minimal solution (name spaces etc.) but nothing else proved workable. So they moved one aspect of the config out of the WEB-INF and as a result they were able to get a webapp deployed on a mixed cluster of geronimo-jetty and geronimo-tomcat - HOORAY! They deserve thanks for a good achievement and some peer review to help them improve it. The certainly don't deserve unilateral action to erase their work and send every body back to square -1. I agree with David that the session manager configuration should be moved again to a clustering GBean, but that does not mean that we should move it back to WEB-INF while we wait for a better solution. This was a minimal solution that can be put in place in time for 1.0.1. We don't have time to create a clustering module before then. As for the axion dependancy, I do believe this is a container dependancy. Axion is being used to persist the session - which is a web container function, not a webapp function. We had discussed this and I thought you had agreed with me on this point - that we should not have to put WADI dependancies into WEB-INF/lib of the apps so they can be clustered. Of you 4 points, which is the one that is driving your -1? Ie, if point 4) is address (not clashing with tomcat clustering), is that sufficient? I do think that 1,2 and 3 have been addressed and none seam worth a -1 in any case. regards
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
DJ, Thanks for beginning this thread...I think this is a great forum to discuss it. My discomfort with the changes is I think it placed it in a worse state than we had it. Again, its my discomfort and wish to stand by my -1 on it. I cannot equate this to your checkins David, because you typically do have a fair amount of open discussion into what you are doing before making the change. History will attest to that ;-) With that said, lets use this thread to move forward this discussion..so I am glad its here. So lets start with the big question... How do we want to see a clustering component integrated? Do we want this from a configuration/assembly level that allows for an import of this at a plan level? Whats the best way to allow injection at the container level, the host level, and the context level? How do we support multiple clustering components taht have many configuration options? Thanks, Jeff David Jencks wrote: > I agree with Jeff that this change is unsatisfactory but I'm not as sure > as he is that backing it out is necessary, perhaps we can move forward > to an acceptable solution instead. > > I also am not so sure that this magnitude of change needs prior > discussion on the list. I've frequently made larger changes without > discussion of my specific code. I've also broken lots of stuff at > various times. > > One thing I insist on is that it be possible to run geronimo with no > clustering support whatsoever, including no clustering classes anywhere > in the geronimo system. I believe this means that each clustering > system has to be installed as a configuration. Doing this right now as > the first step will I think help focus the rest of the componentization. > > I don't understand the requirements very well, I hope for some answers: > > - do we need to support running more than one clustering system with a > particular web container instance (e.g. JettyContainerImpl gbean > instance)? I'm hoping "no" > > IIUC we are installing clustering as a session manager. Perhaps I don't > understand the code but it looks to me as if the jetty code at least is > creating a new instance for each web app. I can't believe this is an > acceptable strategy for all clustering implementations. For instance, I > would think if you have a bunch of web apps doing cross-context dispatch > you would want them all to share a session manager. I think we want the > possibility of installing a single container wide session manager or > per-app session managers. > > Is it really plausible to rely on the distributable tag in the spec dd > to turn on clustering? I would think a further tag in our plan should be > needed. > > Here's what I propose: > > We define a SessionManagerFactory interface, and for each clustering > technology provide an implementation as a gbean.You can get a local > and a distributed session manager from this interface. The runtime > configuration for the clustering includes this gbean. Each web app > context gets a reference to this gbean and gets the appropriate session > manager when it starts. The web app context knows if it is supposed to > be local or distributed so it can ask for the right session manager. > > We have a deploy time configuration for each clustering technology > also. This at least supplies the gbean reference to the runtime gbean, > and can also install a runtime gbean in the configuration under > construction. In this way the clustering technology can decide on > whether one session manager is shared, a factory that always returns > unconfigured new instances is needed, or if each web app needs a > specially configured session manager. > > > > If this isn't clear, I'll be happy to try to clarify. > > thanks > david jencks > > > On Jan 12, 2006, at 7:54 AM, Jeff Genender wrote: > >> I didn't finish #4..sorry... >> >> 4) Your integration of setting the manager (no matter what) is a direct >> clash with the Tomcat clustering components (GBeans). We need a more >> unified approach to selecting a clustering component. >> >> Jeff Genender wrote: >>> Hi Jules. >>> >>> A few comments. First, you made changes without discussing them on the >>> dev lists. >>> >>> As per the discussions in the past, both Aaron and David Jencks, as well >>> as I threw in our .02 on how to integrate the clustering. I would >>> appreciate you discuss code ideas and changes that have such a drastic >>> impact on the Geronimo code base. Here are the issues with your >>> check in: >>> >>> 1) I explained before for Jetty, and obviously now I need to do it for >>> Tomcat, a -1 on Axion as a dependency. There should not be any web >>> application dependencies injected at the container level. This means >>> there is a severe architectural issue with WADI when we are injecting >>> these dependencies into the container. >>> >>> 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the >>> distributablesession manager in the TomcatContainer. Hard
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
David Jencks wrote: I agree with Jeff that this change is unsatisfactory but I'm not as sure as he is that backing it out is necessary, perhaps we can move forward to an acceptable solution instead. thank-you, David. I also am not so sure that this magnitude of change needs prior discussion on the list. I've frequently made larger changes without discussion of my specific code. I've also broken lots of stuff at various times. Thank-you again. One thing I insist on is that it be possible to run geronimo with no clustering support whatsoever, including no clustering classes anywhere in the geronimo system. I believe this means that each clustering system has to be installed as a configuration. Doing this right now as the first step will I think help focus the rest of the componentization. I agree. I think that clustered and non-clustered servers should be available. The servers which were patched were already cluster-enable, we simply extended this fn-ality. I would +1 a move to separate clustered from non-clustered configurations. I don't understand the requirements very well, I hope for some answers: - do we need to support running more than one clustering system with a particular web container instance (e.g. JettyContainerImpl gbean instance)? I'm hoping "no" I would have to say yes, because we need to be able to plug in WADI or the alternative TC approach. I don't expect to need to be able to run different approaches concurrently, but I would expect that some clusters might run one and some the other. IIUC we are installing clustering as a session manager. Perhaps I don't understand the code but it looks to me as if the jetty code at least is creating a new instance for each web app. I can't believe this is an acceptable strategy for all clustering implementations. For instance, I would think if you have a bunch of web apps doing cross-context dispatch you would want them all to share a session manager. I think we want the possibility of installing a single container wide session manager or per-app session managers. I did mention this in one of the discussion threads. I think I said that my 'jury was still out' :-). If/when it comes in, I will happily refactor to accomodate my findings. The change in question is not an attempt to resolve all the worlds problems, but to get working WADI integrations into Geronimo-1.0.1 as simply as possible. Is it really plausible to rely on the distributable tag in the spec dd to turn on clustering? I would think a further tag in our plan should be needed. This is exactly what the spec mandates. Once clustering is turned on, you have the opportunity to configure it to you hearts delight, but the choice of whether or not the app is distributable rests with the app. Here's what I propose: We define a SessionManagerFactory interface, and for each clustering technology provide an implementation as a gbean.You can get a local and a distributed session manager from this interface. The runtime configuration for the clustering includes this gbean. Each web app context gets a reference to this gbean and gets the appropriate session manager when it starts. The web app context knows if it is supposed to be local or distributed so it can ask for the right session manager. I have to go out right now. I will look at your suggestion first thing tomorrow morning and come back with comments, Jules We have a deploy time configuration for each clustering technology also. This at least supplies the gbean reference to the runtime gbean, and can also install a runtime gbean in the configuration under construction. In this way the clustering technology can decide on whether one session manager is shared, a factory that always returns unconfigured new instances is needed, or if each web app needs a specially configured session manager. If this isn't clear, I'll be happy to try to clarify. thanks david jencks On Jan 12, 2006, at 7:54 AM, Jeff Genender wrote: I didn't finish #4..sorry... 4) Your integration of setting the manager (no matter what) is a direct clash with the Tomcat clustering components (GBeans). We need a more unified approach to selecting a clustering component. Jeff Genender wrote: Hi Jules. A few comments. First, you made changes without discussing them on the dev lists. As per the discussions in the past, both Aaron and David Jencks, as well as I threw in our .02 on how to integrate the clustering. I would appreciate you discuss code ideas and changes that have such a drastic impact on the Geronimo code base. Here are the issues with your check in: 1) I explained before for Jetty, and obviously now I need to do it for Tomcat, a -1 on Axion as a dependency. There should not be any web application dependencies injected at the container level. This means there is a severe architectural issue with WADI
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Jeff Genender wrote: I am sorry Jules, I am -1 on the change and I stand firm on that. My comments below...however, we need open discussion on the G lists as well as consensus agreement to what you are trying to do in Geronimo. Lets try to open up the discussion for everyone to view and discuss. Jules Gosnell wrote: Jeff Genender wrote: Hi Jules. A few comments. First, you made changes without discussing them on the dev lists. There has been lots of discussion over the past week or two on both geronimo-dev and wadi-dev - I took this, along with my own findings when I looked at the code, and further offline discussion with Jan and Greg as we were making the changes, into account. As I have clearly stated, if you don't like the way it has been done, it is only an iteration towards a final solution and you are welcome to contribute codewise. It is a major step forwards as it unifies the way that this is done between both containers, and further allows the use of clustering solutions other than WADI. I am sorry, but I don't agree. I don't see how you can. The threads are clearly available to anyone who wants to browse the archives: geronimo-dev/wadi-dev - "Re: geronimo-web.xml, container-config, container-specific namespaces" wadi-dev: "geronimo integrations...", "WADI configuration..." I think the area that I was working on was pretty well broadcast and that you could have mentioned that this was an opportune moment to unify not only the two disparate approaches to WADI, but also the alternative Tomcat clustering components. As per the discussions in the past, both Aaron and David Jencks, as well as I threw in our .02 on how to integrate the clustering. I would appreciate you discuss code ideas and changes I was involved in the recent threads (I started them and stoked them) and did discuss these issues. Please check the archive. To say that I was not open to discussion is not a tenable position. that have such a drastic impact on the Geronimo code base. Drastic ? It extends Geronimo to be able to run the WADI demo webapp, with no impact whatsoever on any non-distributable webapp. With web app dependencies ion the container. Yes, that is drastic. I repeat. WADI configuration is moving along a discussed and agreed course towards per-container as opposed to per-app configuration. WADI currently requires this dep (although it should not be hard to remove it and replace it with another DB as I have clearly indicated). The fact that it is a container-dep should put this point to bed. Here are the issues with your check in: 1) I explained before for Jetty, and obviously now I need to do it for Tomcat, a -1 on Axion as a dependency. There should not be any web application dependencies injected at the container level. This means there is a severe architectural issue with WADI when we are injecting these dependencies into the container. It is no longer an app dep - it is a container dep. The decision to use WADI is now made by the container, and as stated in my mail to the list, the config which determines this will soon move from the app to the container. Then why is Axion necessary? Its only use is at the web application level by my perusal of the WADI code...and testing classes at core. see my previous comments about per-app vs per-container config/deps. I have also invited you to work on removing this dep from WADI. When we have fully moved to incubator, I would be glad to work on this code. why not just fix it at codehaus - you have commit - or send me a patch and I will do it. 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the distributablesession manager in the TomcatContainer. Hardcoding a pluggable session engine is very bad, and defeats the pluggability of a configuration that we requested. Jeff, please take the time to read, run and understand the code before judging it. Jules, I did. I looked at the code and was not happy with how you integrated it and it completely defied the input you got from 3 other Geronimo committers. Lets start over and open up the discussion on the Geronimo lists so the G folks can get their input. I would be more than happy to start this discussion. No, you didn't Jeff - otherwise you would have understood that this was only a default value and could be trivially overriden in the container's plan. Behaviour for non-distributable webapps has NOT been changed. Behaviour for distributable webapps has been usefully defaulted. Please see the code extracts below. As stated in my mail, a sensible default distributable session manager is hardcoded. This is overridable in the tomcat or jetty plan. This is a pretty standard way of doing things and means that any session manager, not just WADI may now be selected. This is a great step forward over the previous version where an important metho
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
I agree with Jeff that this change is unsatisfactory but I'm not as sure as he is that backing it out is necessary, perhaps we can move forward to an acceptable solution instead. I also am not so sure that this magnitude of change needs prior discussion on the list. I've frequently made larger changes without discussion of my specific code. I've also broken lots of stuff at various times. One thing I insist on is that it be possible to run geronimo with no clustering support whatsoever, including no clustering classes anywhere in the geronimo system. I believe this means that each clustering system has to be installed as a configuration. Doing this right now as the first step will I think help focus the rest of the componentization. I don't understand the requirements very well, I hope for some answers: - do we need to support running more than one clustering system with a particular web container instance (e.g. JettyContainerImpl gbean instance)? I'm hoping "no" IIUC we are installing clustering as a session manager. Perhaps I don't understand the code but it looks to me as if the jetty code at least is creating a new instance for each web app. I can't believe this is an acceptable strategy for all clustering implementations. For instance, I would think if you have a bunch of web apps doing cross-context dispatch you would want them all to share a session manager. I think we want the possibility of installing a single container wide session manager or per-app session managers. Is it really plausible to rely on the distributable tag in the spec dd to turn on clustering? I would think a further tag in our plan should be needed. Here's what I propose: We define a SessionManagerFactory interface, and for each clustering technology provide an implementation as a gbean.You can get a local and a distributed session manager from this interface. The runtime configuration for the clustering includes this gbean. Each web app context gets a reference to this gbean and gets the appropriate session manager when it starts. The web app context knows if it is supposed to be local or distributed so it can ask for the right session manager. We have a deploy time configuration for each clustering technology also. This at least supplies the gbean reference to the runtime gbean, and can also install a runtime gbean in the configuration under construction. In this way the clustering technology can decide on whether one session manager is shared, a factory that always returns unconfigured new instances is needed, or if each web app needs a specially configured session manager. If this isn't clear, I'll be happy to try to clarify. thanks david jencks On Jan 12, 2006, at 7:54 AM, Jeff Genender wrote: I didn't finish #4..sorry... 4) Your integration of setting the manager (no matter what) is a direct clash with the Tomcat clustering components (GBeans). We need a more unified approach to selecting a clustering component. Jeff Genender wrote: Hi Jules. A few comments. First, you made changes without discussing them on the dev lists. As per the discussions in the past, both Aaron and David Jencks, as well as I threw in our .02 on how to integrate the clustering. I would appreciate you discuss code ideas and changes that have such a drastic impact on the Geronimo code base. Here are the issues with your check in: 1) I explained before for Jetty, and obviously now I need to do it for Tomcat, a -1 on Axion as a dependency. There should not be any web application dependencies injected at the container level. This means there is a severe architectural issue with WADI when we are injecting these dependencies into the container. 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the distributablesession manager in the TomcatContainer. Hardcoding a pluggable session engine is very bad, and defeats the pluggability of a configuration that we requested. 3) You placed log.info() in the code, and Aaron worked pretty hard to clean those up. 4) Your integration of setting the manager (no matter what) is a direct clash with the Jules, I am giving a complete -1 of checkin of 368344. These are all for technical reasons. Please back out these changes, and bring this discussion to the Geronimo lists as this needs some significant discussion for implementation. I would appreciate that you please involve the Apache way and open discussions on the lists before doing this sort of thing in the future. Again, I will CC the G lists to make this clear, that I would like this change backed out. Jeff Jules Gosnell wrote: Here is a list of outstanding issues associated with this work: - ActiveMQ's shutdown hook seems to trigger when Geronimo is shutdown, removing AMQ before WADI - WADI doesn't like this. I have added a property to the node.sh script which suppresses this behaviour. I
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
I am sorry Jules, I am -1 on the change and I stand firm on that. My comments below...however, we need open discussion on the G lists as well as consensus agreement to what you are trying to do in Geronimo. Lets try to open up the discussion for everyone to view and discuss. Jules Gosnell wrote: > Jeff Genender wrote: > >> Hi Jules. >> >> A few comments. First, you made changes without discussing them on the >> dev lists. >> >> >> > There has been lots of discussion over the past week or two on both > geronimo-dev and wadi-dev - I took this, along with my own findings when > I looked at the code, and further offline discussion with Jan and Greg > as we were making the changes, into account. > > As I have clearly stated, if you don't like the way it has been done, it > is only an iteration towards a final solution and you are welcome to > contribute codewise. It is a major step forwards as it unifies the way > that this is done between both containers, and further allows the use of > clustering solutions other than WADI. I am sorry, but I don't agree. > >> As per the discussions in the past, both Aaron and David Jencks, as well >> as I threw in our .02 on how to integrate the clustering. I would >> appreciate you discuss code ideas and changes >> > I was involved in the recent threads (I started them and stoked them) > and did discuss these issues. Please check the archive. To say that I > was not open to discussion is not a tenable position. > >> that have such a drastic >> impact on the Geronimo code base. > Drastic ? It extends Geronimo to be able to run the WADI demo webapp, > with no impact whatsoever on any non-distributable webapp. With web app dependencies ion the container. Yes, that is drastic. > >> Here are the issues with your check in: >> >> 1) I explained before for Jetty, and obviously now I need to do it for >> Tomcat, a -1 on Axion as a dependency. There should not be any web >> application dependencies injected at the container level. This means >> there is a severe architectural issue with WADI when we are injecting >> these dependencies into the container. >> >> > It is no longer an app dep - it is a container dep. The decision to use > WADI is now made by the container, and as stated in my mail to the list, > the config which determines this will soon move from the app to the > container. > Then why is Axion necessary? Its only use is at the web application level by my perusal of the WADI code...and testing classes at core. > I have also invited you to work on removing this dep from WADI. > When we have fully moved to incubator, I would be glad to work on this code. >> 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the >> distributablesession manager in the TomcatContainer. Hardcoding a >> pluggable session engine is very bad, and defeats the pluggability of a >> configuration that we requested. >> >> > Jeff, please take the time to read, run and understand the code before > judging it. Jules, I did. I looked at the code and was not happy with how you integrated it and it completely defied the input you got from 3 other Geronimo committers. Lets start over and open up the discussion on the Geronimo lists so the G folks can get their input. I would be more than happy to start this discussion. > > As stated in my mail, a sensible default distributable session manager > is hardcoded. This is overridable in the tomcat or jetty plan. This is a > pretty standard way of doing things and means that any session manager, > not just WADI may now be selected. This is a great step forward over the > previous version where an important method signature included the > WADIGBean type, which restricted distributable webapps to WADI and not > other possible alternatives. I don't agree. There should be no hard coding at all. I also don't like the > >> 3) You placed log.info() in the code, and Aaron worked pretty hard to >> clean those up. >> >> > I shall downgrade the level - apologies to Aaron - as I stated, this > code is only an iteration towards a finished product. > >> 4) Your integration of setting the manager (no matter what) is a direct >> clash with the >> >> > with the. what ? With the Manager. > >> Jules, I am giving a complete -1 of checkin of 368344. These are all >> for technical reasons. Please back out these changes, and bring this >> discussion to the Geronimo lists as this needs some significant >> discussion for implementation. I would appreciate that you please >> involve the Apache way and open discussions on the lists before doing >> this sort of thing in the future. >> >> > Of the three reasons that you have given 2 are completely mistaken and > one is trivial - in my book, insufficient technical argument for the > rejection of a significant enhancement. I am sorry , I don't agree. > >> Again, I will CC the G lists to make this clear, that I would like this >> change backed out. >> >> > In conclusion m
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
see inline - I ommitted one further technical benefit of my approach: Jules Gosnell wrote: Jeff Genender wrote: Hi Jules. A few comments. First, you made changes without discussing them on the dev lists. There has been lots of discussion over the past week or two on both geronimo-dev and wadi-dev - I took this, along with my own findings when I looked at the code, and further offline discussion with Jan and Greg as we were making the changes, into account. As I have clearly stated, if you don't like the way it has been done, it is only an iteration towards a final solution and you are welcome to contribute codewise. It is a major step forwards as it unifies the way that this is done between both containers, and further allows the use of clustering solutions other than WADI. As per the discussions in the past, both Aaron and David Jencks, as well as I threw in our .02 on how to integrate the clustering. I would appreciate you discuss code ideas and changes I was involved in the recent threads (I started them and stoked them) and did discuss these issues. Please check the archive. To say that I was not open to discussion is not a tenable position. that have such a drastic impact on the Geronimo code base. Drastic ? It extends Geronimo to be able to run the WADI demo webapp, with no impact whatsoever on any non-distributable webapp. Here are the issues with your check in: 1) I explained before for Jetty, and obviously now I need to do it for Tomcat, a -1 on Axion as a dependency. There should not be any web application dependencies injected at the container level. This means there is a severe architectural issue with WADI when we are injecting these dependencies into the container. It is no longer an app dep - it is a container dep. The decision to use WADI is now made by the container, and as stated in my mail to the list, the config which determines this will soon move from the app to the container. I have also invited you to work on removing this dep from WADI. 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the distributablesession manager in the TomcatContainer. Hardcoding a pluggable session engine is very bad, and defeats the pluggability of a configuration that we requested. Jeff, please take the time to read, run and understand the code before judging it. As stated in my mail, a sensible default distributable session manager is hardcoded. This is overridable in the tomcat or jetty plan. This is a pretty standard way of doing things and means that any session manager, not just WADI may now be selected. This is a great step forward over the previous version where an important method signature included the WADIGBean type, which restricted distributable webapps to WADI and not other possible alternatives. 3) You placed log.info() in the code, and Aaron worked pretty hard to clean those up. I shall downgrade the level - apologies to Aaron - as I stated, this code is only an iteration towards a finished product. 4) Your integration of setting the manager (no matter what) is a direct clash with the with the. what ? Jules, I am giving a complete -1 of checkin of 368344. These are all for technical reasons. Please back out these changes, and bring this discussion to the Geronimo lists as this needs some significant discussion for implementation. I would appreciate that you please involve the Apache way and open discussions on the lists before doing this sort of thing in the future. Of the three reasons that you have given 2 are completely mistaken and one is trivial - in my book, insufficient technical argument for the rejection of a significant enhancement. Again, I will CC the G lists to make this clear, that I would like this change backed out. In conclusion my change should remain for the following technical reasons. - it fixes something that was broken - it unifies two separate approaches into a single, more manageable approach, without sacrifice. - it moves us in an agreed direction (from per-app to per-container based configuration) - it is simpler than what it replaces - it frees us from requirements for an extra GBean and divergent Jetty and Tomcat geronimo-web.xml schemas. - it is more flexible than the code that it replaces - it allows selection of ANY session manager, NOT JUST WADI, as was previously the case. - it is small. - it coordinates the use of the tag in the web.xml with the selection of a clustered, as opposed to non-clustered session manager - a further useful enhancement. Jules On the non-technical side of things: - preceding this change, possible solutions were discussed on relevant dev lists at length. - 3 Geronimo/WADI committers were involved in and agreed on the final minutiae of the change. - by fixing, simplifying and unifying the WADI/Geronimo integration, this changes brings significant benefit to Geronimo. If there are aspects of the chan
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Jeff Genender wrote: I didn't finish #4..sorry... 4) Your integration of setting the manager (no matter what) is a direct clash with the Tomcat clustering components (GBeans). We need a more unified approach to selecting a clustering component. OK - this is finally a useful point. Questions : - does my change prevent the use of alternative Tomcat clustering components ? - if so, how - I will fix it ? Jules Jeff Genender wrote: Hi Jules. A few comments. First, you made changes without discussing them on the dev lists. As per the discussions in the past, both Aaron and David Jencks, as well as I threw in our .02 on how to integrate the clustering. I would appreciate you discuss code ideas and changes that have such a drastic impact on the Geronimo code base. Here are the issues with your check in: 1) I explained before for Jetty, and obviously now I need to do it for Tomcat, a -1 on Axion as a dependency. There should not be any web application dependencies injected at the container level. This means there is a severe architectural issue with WADI when we are injecting these dependencies into the container. 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the distributablesession manager in the TomcatContainer. Hardcoding a pluggable session engine is very bad, and defeats the pluggability of a configuration that we requested. 3) You placed log.info() in the code, and Aaron worked pretty hard to clean those up. 4) Your integration of setting the manager (no matter what) is a direct clash with the Jules, I am giving a complete -1 of checkin of 368344. These are all for technical reasons. Please back out these changes, and bring this discussion to the Geronimo lists as this needs some significant discussion for implementation. I would appreciate that you please involve the Apache way and open discussions on the lists before doing this sort of thing in the future. Again, I will CC the G lists to make this clear, that I would like this change backed out. Jeff Jules Gosnell wrote: Here is a list of outstanding issues associated with this work: - ActiveMQ's shutdown hook seems to trigger when Geronimo is shutdown, removing AMQ before WADI - WADI doesn't like this. I have added a property to the node.sh script which suppresses this behaviour. I will document it in the Getting Started doc. - There 'may' be issues with nodes finding each other, when a Geronimo node is introduced into a WADI cluster - investigating. - Jeff - you should look over the changes and make sure that they do not impact on any other TC fn-ality. They were done with Emacs, so the formatting may be offensive. Please feel free to make them your own and bring any issues back to the list. The WADIGBean, is no longer used, so you may want to remove this from the repo. - Jan and Jeff - since this config is now done on the container bean and not in the geronimo-web.xml, you may no longer need to implement your own geronimo-web.xml schemas (I haven't looked very closely at TC). You may want to consider this and perhaps lose them. - In order to get the same webapp to work in all containers (tomcat5[05], jetty[56], geronimo-[tomcat/jetty], jboss-tomcat), I had to move deps back to Geronimo container-level. These include Axion, which I know will upset Jeff. As I have stated before, WADI's dependence on Axion is easily removed. If Jeff or anyone wants to look at replacing it with Derby, it is fine with me, as long as they do some testing and confirm that having created a session on a single node and restarted it, the session survives (if the DB is still running). This needs to be tested on all supported containers. Axion was used because it is an in-VM DB (so imposes no further integration dependencies on the Getting Started stuff and is useful for unit-testing) and was in use by Geronimo at the time. So I suggest that any replacement needs to also be able to run in-vm aswell. As we go further and move WADI's actual configuration from the app to the container-level, these issues will disappear and WADI will be able to be hooked to whatever persistance mechanism is shipped in Geronimo by default. - Jan & Jeff , you may want to consider pushing some of this session manager selection code up into a shared GeronimoWebContainer abstraction so that you don't both end up maintaining similar but diverging code... - I may have overlooked a couple of issues. If I come across them, I shall post them. Further work on Geronimo integration : - more testing - make a new WADI release and update geronimo-trunk to use it - look at applying diffs to a G1.0 tree and producing a binary patch for 1.0 distros. - update website and release it Jules Jules Gosnell wrote: Guys, Jan and I have just refactored the Geronimo Jetty and Tomcat integrations to take the same approach to the installation of a 3rd party session manager, to ease the integration of WADI. This is now checked in on Geronimo's t
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Jeff Genender wrote: Hi Jules. A few comments. First, you made changes without discussing them on the dev lists. There has been lots of discussion over the past week or two on both geronimo-dev and wadi-dev - I took this, along with my own findings when I looked at the code, and further offline discussion with Jan and Greg as we were making the changes, into account. As I have clearly stated, if you don't like the way it has been done, it is only an iteration towards a final solution and you are welcome to contribute codewise. It is a major step forwards as it unifies the way that this is done between both containers, and further allows the use of clustering solutions other than WADI. As per the discussions in the past, both Aaron and David Jencks, as well as I threw in our .02 on how to integrate the clustering. I would appreciate you discuss code ideas and changes I was involved in the recent threads (I started them and stoked them) and did discuss these issues. Please check the archive. To say that I was not open to discussion is not a tenable position. that have such a drastic impact on the Geronimo code base. Drastic ? It extends Geronimo to be able to run the WADI demo webapp, with no impact whatsoever on any non-distributable webapp. Here are the issues with your check in: 1) I explained before for Jetty, and obviously now I need to do it for Tomcat, a -1 on Axion as a dependency. There should not be any web application dependencies injected at the container level. This means there is a severe architectural issue with WADI when we are injecting these dependencies into the container. It is no longer an app dep - it is a container dep. The decision to use WADI is now made by the container, and as stated in my mail to the list, the config which determines this will soon move from the app to the container. I have also invited you to work on removing this dep from WADI. 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the distributablesession manager in the TomcatContainer. Hardcoding a pluggable session engine is very bad, and defeats the pluggability of a configuration that we requested. Jeff, please take the time to read, run and understand the code before judging it. As stated in my mail, a sensible default distributable session manager is hardcoded. This is overridable in the tomcat or jetty plan. This is a pretty standard way of doing things and means that any session manager, not just WADI may now be selected. This is a great step forward over the previous version where an important method signature included the WADIGBean type, which restricted distributable webapps to WADI and not other possible alternatives. 3) You placed log.info() in the code, and Aaron worked pretty hard to clean those up. I shall downgrade the level - apologies to Aaron - as I stated, this code is only an iteration towards a finished product. 4) Your integration of setting the manager (no matter what) is a direct clash with the with the. what ? Jules, I am giving a complete -1 of checkin of 368344. These are all for technical reasons. Please back out these changes, and bring this discussion to the Geronimo lists as this needs some significant discussion for implementation. I would appreciate that you please involve the Apache way and open discussions on the lists before doing this sort of thing in the future. Of the three reasons that you have given 2 are completely mistaken and one is trivial - in my book, insufficient technical argument for the rejection of a significant enhancement. Again, I will CC the G lists to make this clear, that I would like this change backed out. In conclusion my change should remain for the following technical reasons. - it fixes something that was broken - it unifies two separate approaches into a single, more manageable approach, without sacrifice. - it moves us in an agreed direction (from per-app to per-container based configuration) - it is simpler than what it replaces - it frees us from requirements for an extra GBean and divergent Jetty and Tomcat geronimo-web.xml schemas. - it is more flexible than the code that it replaces - it allows selection of ANY session manager, NOT JUST WADI, as was previously the case. - it is small. On the non-technical side of things: - preceding this change, possible solutions were discussed on relevant dev lists at length. - 3 Geronimo/WADI committers were involved in and agreed on the final minutiae of the change. - by fixing, simplifying and unifying the WADI/Geronimo integration, this changes brings significant benefit to Geronimo. If there are aspects of the change that you do not like, then we should simply work together, on top of the change, to resolve these issues. By backing out the change, you break something that is fixed and remove all the beneficial code that you did not have issues with. If there are small issues, su
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
I didn't finish #4..sorry... 4) Your integration of setting the manager (no matter what) is a direct clash with the Tomcat clustering components (GBeans). We need a more unified approach to selecting a clustering component. Jeff Genender wrote: > Hi Jules. > > A few comments. First, you made changes without discussing them on the > dev lists. > > As per the discussions in the past, both Aaron and David Jencks, as well > as I threw in our .02 on how to integrate the clustering. I would > appreciate you discuss code ideas and changes that have such a drastic > impact on the Geronimo code base. Here are the issues with your check in: > > 1) I explained before for Jetty, and obviously now I need to do it for > Tomcat, a -1 on Axion as a dependency. There should not be any web > application dependencies injected at the container level. This means > there is a severe architectural issue with WADI when we are injecting > these dependencies into the container. > > 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the > distributablesession manager in the TomcatContainer. Hardcoding a > pluggable session engine is very bad, and defeats the pluggability of a > configuration that we requested. > > 3) You placed log.info() in the code, and Aaron worked pretty hard to > clean those up. > > 4) Your integration of setting the manager (no matter what) is a direct > clash with the > > Jules, I am giving a complete -1 of checkin of 368344. These are all > for technical reasons. Please back out these changes, and bring this > discussion to the Geronimo lists as this needs some significant > discussion for implementation. I would appreciate that you please > involve the Apache way and open discussions on the lists before doing > this sort of thing in the future. > > Again, I will CC the G lists to make this clear, that I would like this > change backed out. > > Jeff > > > Jules Gosnell wrote: >> Here is a list of outstanding issues associated with this work: >> >> - ActiveMQ's shutdown hook seems to trigger when Geronimo is shutdown, >> removing AMQ before WADI - WADI doesn't like this. I have added a >> property to the node.sh script which suppresses this behaviour. I will >> document it in the Getting Started doc. >> >> - There 'may' be issues with nodes finding each other, when a Geronimo >> node is introduced into a WADI cluster - investigating. >> >> - Jeff - you should look over the changes and make sure that they do not >> impact on any other TC fn-ality. They were done with Emacs, so the >> formatting may be offensive. Please feel free to make them your own and >> bring any issues back to the list. The WADIGBean, is no longer used, so >> you may want to remove this from the repo. >> >> - Jan and Jeff - since this config is now done on the container bean and >> not in the geronimo-web.xml, you may no longer need to implement your >> own geronimo-web.xml schemas (I haven't looked very closely at TC). You >> may want to consider this and perhaps lose them. >> >> - In order to get the same webapp to work in all containers >> (tomcat5[05], jetty[56], geronimo-[tomcat/jetty], jboss-tomcat), I had >> to move deps back to Geronimo container-level. These include Axion, >> which I know will upset Jeff. As I have stated before, WADI's dependence >> on Axion is easily removed. If Jeff or anyone wants to look at replacing >> it with Derby, it is fine with me, as long as they do some testing and >> confirm that having created a session on a single node and restarted it, >> the session survives (if the DB is still running). This needs to be >> tested on all supported containers. Axion was used because it is an >> in-VM DB (so imposes no further integration dependencies on the Getting >> Started stuff and is useful for unit-testing) and was in use by Geronimo >> at the time. So I suggest that any replacement needs to also be able to >> run in-vm aswell. As we go further and move WADI's actual configuration >> from the app to the container-level, these issues will disappear and >> WADI will be able to be hooked to whatever persistance mechanism is >> shipped in Geronimo by default. >> >> - Jan & Jeff , you may want to consider pushing some of this session >> manager selection code up into a shared GeronimoWebContainer abstraction >> so that you don't both end up maintaining similar but diverging code... >> >> - I may have overlooked a couple of issues. If I come across them, I >> shall post them. >> >> Further work on Geronimo integration : >> >> - more testing >> - make a new WADI release and update geronimo-trunk to use it >> - look at applying diffs to a G1.0 tree and producing a binary patch for >> 1.0 distros. >> - update website and release it >> >> >> Jules >> >> >> >> Jules Gosnell wrote: >> >>> Guys, >>> >>> Jan and I have just refactored the Geronimo Jetty and Tomcat >>> integrations to take the same approach to the installation of a 3rd >>> party session manager, to ease the integration
