You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Ate Douma <at...@douma.nu> on 2005/03/01 04:16:11 UTC
Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
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-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
[Results]
Posted by 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-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by reda bendiar <re...@gmail.com>.
>I'd like to vote on dropping Tomcat 4 support!
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Hema Menon <me...@gmail.com>.
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 <ga...@gmail.com> 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: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hema Menon
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Gaurav Vaish <ga...@gmail.com>.
> > 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: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Andreas Ernst <ae...@ae-online.de>.
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: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Raphaël Luta <ra...@aptiwan.com>.
Ate Douma wrote:
>
>
> David Sean Taylor wrote:
>
>> 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.
>>
>>
>>
>> +1 to drop 4.1 support
>
> +1
>
>> +1 to fix 5.5 support before dropping 4.1
>
> +1 too
> ... which I can say easily now as have 5.5.8 support ready right now ;-)
>
way cool :)
> My refactored codebase can be deployed on both Tomcat 5.0.28 and 5.5.8
> using JDK 1.4.2_04 (I don't have JDK 5 installed yet and probably won't
> for a while)
> with only one build.properties change:
> org.apache.jetspeed.catalina.version.major = 5.5
>
> I'm in the process of cleaning up the mess in my codebase and then I'll
> create a new branch and check it in (still have to figure out how to do
> that though).
>
I can help you out if you need it...
--
Raphaël Luta - raphael.luta@aptiwan.com
Aptiwan, l'intelligence du réseau - http://www.aptiwan.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
> 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.
>
>
> +1 to drop 4.1 support
+1
> +1 to fix 5.5 support before dropping 4.1
+1 too
... which I can say easily now as have 5.5.8 support ready right now ;-)
My refactored codebase can be deployed on both Tomcat 5.0.28 and 5.5.8
using JDK 1.4.2_04 (I don't have JDK 5 installed yet and probably won't for a while)
with only one build.properties change:
org.apache.jetspeed.catalina.version.major = 5.5
I'm in the process of cleaning up the mess in my codebase and then I'll
create a new branch and check it in (still have to figure out how to do that though).
Regards, Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by David Sean Taylor <da...@bluesunrise.com>.
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.
+1 to drop 4.1 support
+1 to fix 5.5 support before dropping 4.1
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Gaurav Vaish <ga...@gmail.com>.
> bug in Tomcat 5 is really painful. IMO we should coordinate with
> Pluto and aim for the same platform support.
I second Raphaël on coordinating with Pluto.
IMHO, we should consider it a high(er) priority issue. or there are
any oppositions?
Remarks most welcome.
Oh! Better we spin off an independent thread on Pluto issue.
--
Cheers,
Gaurav Vaish
http://www.mastergaurav.org
http://mastergaurav.blogspot.com
--------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Raphaël Luta <ra...@apache.org>.
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.
>
I agree with Randy +1 to drop Tomcat 4 if we fix 5.5 at the same time.
Jetspeed needs to runs correctly on at least 1 platform and the session
bug in Tomcat 5 is really painful. IMO we should coordinate with
Pluto and aim for the same platform support.
It seems to me 5.5 is the way to go as primary, fully functional target
and 5.0.x secondary target with some known issues.
Also before committing the patch to the main CVS, you could create a branch
and commit your new deployment code there. That would enable us to test it
in many deployment situations with no risk of breaking the main CVS.
--
Raphael Luta - raphael@apache.org
Apache Jetspeed - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Ate Douma <at...@douma.nu>.
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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Ate Douma <at...@douma.nu>.
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
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Roger Ruttimann <ro...@apache.org>.
+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
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Randy Watler <wa...@wispertel.net>.
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
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Ate Douma <at...@douma.nu>.
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
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
+1 on dropping 4.1 support.
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-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
--
"Great minds discuss ideas. Average minds discuss events. Small minds discuss people." - Admiral Hyman Rickover
*******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEdit, Website Content Management *
* <http://www.openedit.org> *
*******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Shinsuke SUGAYA <sh...@yahoo.co.jp>.
+1 to drop 4.1
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
>
__________________________________
Let's Celebrate Together!
Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/so2005/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Ate Douma <at...@douma.nu>.
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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
[Results]
Posted by 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
RE: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Shah Amit <am...@hotmail.com>.
I am fine with tomcat 4 support discontinued.
Thanks,
Amit
----Original Message Follows----
From: Ate Douma <at...@douma.nu>
Reply-To: "Jetspeed Developers List" <je...@jakarta.apache.org>
To: Jetspeed Developers List <je...@jakarta.apache.org>, Jetspeed
Users List <je...@jakarta.apache.org>
Subject: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Date: Tue, 01 Mar 2005 04:16:11 +0100
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-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
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Marvin Malkowski Jr <ma...@linuxgames.com>.
+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 <at...@douma.nu> wrote:
>> And, if there are no big objections, I'd like to
>> vote on dropping Tomcat 4 support!
>>
>
>
> +1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
-----------------------------------------------------------------
Marvin Malkowski Jr.
-----------------------------------------------------------------
marv@linuxgames.com
http://www.linuxgames.com/
-----------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: Jetspeed-2: Drop support for Tomcat 4...? Please comment/vote!
Posted by Marina <pp...@yahoo.com>.
--- Ate Douma <at...@douma.nu> wrote:
> And, if there are no big objections, I'd like to
> vote on dropping Tomcat 4 support!
>
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org