Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote! [Results]

[Ate Douma <at...@douma.nu>]

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: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
> 
> 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org