portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Ruttimann <roger...@apache.org>
Subject Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Date Fri, 04 Mar 2005 00:08:13 GMT
 +1 to drop Tomcat 4 if we fix 5.5 at the same time.
 
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: jetspeed-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>


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


Mime
View raw message