+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: [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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]