> 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]
