Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

4.0->5.0 migration

Status
Not open for further replies.

siberian

Programmer
Sep 27, 2003
1,295
US
Hi all-
I am in the final stages of building an app that is running on tomcat 4.0 (latest). Is moving to 5.0 seamless or are there significant configuration changes? Any specific gotchas?

My config is very basic, the only configuration thing I am doing is a JNDI datasource in the server.xml file.

Tx

 
I've just ported our company (finally!) from 3.3 to 5.0.19 with no real problems .. cannot see any problems from 4>5.
 
Was it a 'port' or just a re-deployment? What aspects did you find most troublesome to port over?

Tx!
 
'port' as in - we used to run our site through 3.3 (a deployed war), and we reconfigured for v5.

We actually used to run tomcat3.3 through JBoss2.4, so the hardest thing was setting up the new login mechanisms to use filters ans so on instead of JBoss validation. We also decided to not use tomcat5's connection pooling as it was not seen as good enough, so I wrote a JMX connection pool which I guess was 'hassle', but its not really an issue for porting to v5 if you go with the default pooling.
The web.xml spec has also changed since v3.3, so that needed tweaking, but nothing major.

Apart from that, it was just a case of dumping jars in a different directory and firing it up.
 
Great info! Tx.

Can I ask why the default pooling was not considered adequate? I'm coming from a mod_perl background so the nuances of this new world are important for me.

Tx!
 
Several reasons for writing our own pool :

- tomcat pool could not be started/stopped without an app server restart.
- tomcat pool did not support SQL transaction logging (from calling Java objects), which is useful for stats and debug etc
- tomcat pool does not automatically close resultsets/statements etc if a developer forgets to.
- tomcat pool can not be administered/managed dybnamically
- tomcat pool does not queue connection requests if the pool is full up

and also many other reasons ...
 
I've seen those as well, glad its not only me :)

Thanks sedj

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top