Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Roger Ruttimann wrote: +1 to drop Tomcat 4 if we fix 5.5 at the same time. Tomcat 5.5.8 already works without a hitch if you check out branch deployment-refactoring! You only have to set org.apache.jetspeed.catalina.version.major = 5.5 (and point org.apache.jetspeed.server.home to a Tomcat 5.5.8 installation of course). Check it out to see for yourself. You can find further info about this branch at http://issues.apache.org/jira/browse/JS2-210 I'd like to call a vote somewhere next week for merging those changes back into the HEAD branch. We will try to do a M2 release end of this month and I definitely would like to see this be part of it. But, I haven't had much reactions yet so if you or anyone else might have an hour or so for testing, please do! Regards, Ate Randy Watler wrote: Ate/All, Yes, 4.1 is certainly painful when it comes to deployment. I can verify most of what Ate has outlined here. +1 to drop 4.1. Ate, are you also working on getting 5.5 functional? I suppose it would be good to do that before/while we deprecate 4.1 support. Randy Ate Douma wrote: Something I forgot to add: I will try to upload a preliminary patch for http://issues.apache.org/jira/browse/JS2-210 tomorrow which for testing purposes only and which of course will only work with Tomcat 5.0.28 (or higher). Regards, Ate Ate Douma wrote: Dear developer team and users, I've been working the last two weeks (off and on) on a new and much simplified deployment implementation for Jetspeed-2 which builds mainly on official Servlet specification (2.3) features. See JIRA: http://issues.apache.org/jira/browse/JS2-210 I expect that with this solution, deployment for Application servers other than Tomcat will become much easier to implement and support. I've got this working already beautifully on Tomcat 5 (5.0.28) and with a few nice side-effects too: - the Jetspeed-2 context isn't fixed at /jetspeed any more - multiple layout portlet applications can be deployed/used at the same time for both see: http://issues.apache.org/jira/browse/JS2-182 http://issues.apache.org/jira/browse/JS2-172 - no more temporarily expanded wars in the java.io.tmpdir to workaround classloading issues - much quicker startup To be honest, my refactoring isn't finished yet and some features currently available will have to be reimplemented (differently) like undeployment. But I can't get the redeployment working flawlessly under Tomcat 4.1 (tested with 4.1.30 and 4.1.31). Tomcat 4 won't always release certain jars in deployed applications when doing an undeployment or redeployment while this is no problem with Tomcat 5.0. Furthermore, auto redeployment of war files isn't available at all in Tomcat 4: you need to use the TomcatManager to remove an existing application first (which sometimes fails) before a new application can tried to be deployed again. And then, There are other serious problems with Tomcat 4 too like no separate sessions for the portal and portlet applications (which is a *serious* security breach and the foremost reason I myself won't use Tomcat 4 for Portals anymore). The Pluto Team won't even use Tomcat 5.0 anymore and require Tomcat 5.5.7 or higher because Tomcat 5.0 also has a session bug in which a Portlet Application and its Web application don't share the same session when invoked independently (as they should according to the portlet specification). Both the development of Tomcat 4 and Tomcat 5.0 has largely come to an end, except for really nasty bugs, but the onces I described above aren't regarded as such by the Tomcat team :-( Al in all, to me the question right now is: do we really, really need to keep supporting Tomcat 4. For my deployment refactorings it poses a problem I don't have time left to further investigate (nor do I have any hope it *can* be resolved). As long as we need to support Tomcat 4, I can't commit my changes... I'd like to hear from both team members and users who absolutely require Tomcat 4 support for Jetspeed-2 and why. And, if there are no big objections, I'd like to vote on dropping Tomcat 4 support! Please comment, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote! [Results]
I've counted 12 +1 votes so far for dropping Tomcat 4.1 support (5 team members/ 7 users), with 4 votes under the condition Tomcat 5.5 support should be provided first. No 0 or -1 votes. I committed my changes to the deployment-refactoring, which includes Tomcat 5.5 support, for everyone to review and test. See: http://issues.apache.org/jira/browse/JS2-210?page=comments#action_60016 If those changes are merged in CVS HEAD, Tomcat 4.1 support will be dropped. Regards, Ate Ate Douma wrote: Dear developer team and users, I've been working the last two weeks (off and on) on a new and much simplified deployment implementation for Jetspeed-2 which builds mainly on official Servlet specification (2.3) features. See JIRA: http://issues.apache.org/jira/browse/JS2-210 I expect that with this solution, deployment for Application servers other than Tomcat will become much easier to implement and support. I've got this working already beautifully on Tomcat 5 (5.0.28) and with a few nice side-effects too: - the Jetspeed-2 context isn't fixed at /jetspeed any more - multiple layout portlet applications can be deployed/used at the same time for both see: http://issues.apache.org/jira/browse/JS2-182 http://issues.apache.org/jira/browse/JS2-172 - no more temporarily expanded wars in the java.io.tmpdir to workaround classloading issues - much quicker startup To be honest, my refactoring isn't finished yet and some features currently available will have to be reimplemented (differently) like undeployment. But I can't get the redeployment working flawlessly under Tomcat 4.1 (tested with 4.1.30 and 4.1.31). Tomcat 4 won't always release certain jars in deployed applications when doing an undeployment or redeployment while this is no problem with Tomcat 5.0. Furthermore, auto redeployment of war files isn't available at all in Tomcat 4: you need to use the TomcatManager to remove an existing application first (which sometimes fails) before a new application can tried to be deployed again. And then, There are other serious problems with Tomcat 4 too like no separate sessions for the portal and portlet applications (which is a *serious* security breach and the foremost reason I myself won't use Tomcat 4 for Portals anymore). The Pluto Team won't even use Tomcat 5.0 anymore and require Tomcat 5.5.7 or higher because Tomcat 5.0 also has a session bug in which a Portlet Application and its Web application don't share the same session when invoked independently (as they should according to the portlet specification). Both the development of Tomcat 4 and Tomcat 5.0 has largely come to an end, except for really nasty bugs, but the onces I described above aren't regarded as such by the Tomcat team :-( Al in all, to me the question right now is: do we really, really need to keep supporting Tomcat 4. For my deployment refactorings it poses a problem I don't have time left to further investigate (nor do I have any hope it *can* be resolved). As long as we need to support Tomcat 4, I can't commit my changes... I'd like to hear from both team members and users who absolutely require Tomcat 4 support for Jetspeed-2 and why. And, if there are no big objections, I'd like to vote on dropping Tomcat 4 support! Please comment, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
--- Ate Douma [EMAIL PROTECTED] wrote: And, if there are no big objections, I'd like to vote on dropping Tomcat 4 support! +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
+1 Though please insure that Tomcat 5.0 is support though. Some of us do not consider Java 5.0 a stable release yet. On Mar 2, 2005, at 5:38 AM, Marina wrote: --- Ate Douma [EMAIL PROTECTED] wrote: And, if there are no big objections, I'd like to vote on dropping Tomcat 4 support! +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Marvin Malkowski Jr. - [EMAIL PROTECTED] http://www.linuxgames.com/ - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Ate Douma schrieb: I'd like to hear from both team members and users who absolutely require Tomcat 4 support for Jetspeed-2 and why. And, if there are no big objections, I'd like to vote on dropping Tomcat 4 support! +1 Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
And, if there are no big objections, I'd like to vote on dropping Tomcat 4 support! +1 -- Cheers, Gaurav Vaish http://www.mastergaurav.org http://mastergaurav.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
I'd like to vote on dropping Tomcat 4 support! +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
I see no reason to stick with Tomcat 4. Another vote to drop 4! Hema On Tue, 1 Mar 2005 15:26:23 +0530, Gaurav Vaish [EMAIL PROTECTED] wrote: And, if there are no big objections, I'd like to vote on dropping Tomcat 4 support! +1 -- Cheers, Gaurav Vaish http://www.mastergaurav.org http://mastergaurav.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- ~~ Hema Menon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
And, if there are no big objections, I'd like to vote on dropping Tomcat 4 support +1 -Original Message- From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 9:40 PM To: Jetspeed Users List Cc: Jetspeed Developers List Subject: Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote! Something I forgot to add: I will try to upload a preliminary patch for http://issues.apache.org/jira/browse/JS2-210 tomorrow which for testing purposes only and which of course will only work with Tomcat 5.0.28 (or higher). Regards, Ate Ate Douma wrote: Dear developer team and users, I've been working the last two weeks (off and on) on a new and much simplified deployment implementation for Jetspeed-2 which builds mainly on official Servlet specification (2.3) features. See JIRA: http://issues.apache.org/jira/browse/JS2-210 I expect that with this solution, deployment for Application servers other than Tomcat will become much easier to implement and support. I've got this working already beautifully on Tomcat 5 (5.0.28) and with a few nice side-effects too: - the Jetspeed-2 context isn't fixed at /jetspeed any more - multiple layout portlet applications can be deployed/used at the same time for both see: http://issues.apache.org/jira/browse/JS2-182 http://issues.apache.org/jira/browse/JS2-172 - no more temporarily expanded wars in the java.io.tmpdir to workaround classloading issues - much quicker startup To be honest, my refactoring isn't finished yet and some features currently available will have to be reimplemented (differently) like undeployment. But I can't get the redeployment working flawlessly under Tomcat 4.1 (tested with 4.1.30 and 4.1.31). Tomcat 4 won't always release certain jars in deployed applications when doing an undeployment or redeployment while this is no problem with Tomcat 5.0. Furthermore, auto redeployment of war files isn't available at all in Tomcat 4: you need to use the TomcatManager to remove an existing application first (which sometimes fails) before a new application can tried to be deployed again. And then, There are other serious problems with Tomcat 4 too like no separate sessions for the portal and portlet applications (which is a *serious* security breach and the foremost reason I myself won't use Tomcat 4 for Portals anymore). The Pluto Team won't even use Tomcat 5.0 anymore and require Tomcat 5.5.7 or higher because Tomcat 5.0 also has a session bug in which a Portlet Application and its Web application don't share the same session when invoked independently (as they should according to the portlet specification). Both the development of Tomcat 4 and Tomcat 5.0 has largely come to an end, except for really nasty bugs, but the onces I described above aren't regarded as such by the Tomcat team :-( Al in all, to me the question right now is: do we really, really need to keep supporting Tomcat 4. For my deployment refactorings it poses a problem I don't have time left to further investigate (nor do I have any hope it *can* be resolved). As long as we need to support Tomcat 4, I can't commit my changes... I'd like to hear from both team members and users who absolutely require Tomcat 4 support for Jetspeed-2 and why. And, if there are no big objections, I'd like to vote on dropping Tomcat 4 support! Please comment, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
