portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Date Fri, 04 Mar 2005 08:00:21 GMT


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


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