Default is false, it is a potential dangerous operation and misbehaving programs can do harmfull things. (closing the underlying or continue using it when the guarded connection is already closed) Be carefull and only use when you need direct access to driver specific extentions.
NOTE: Do not close the underlying connection, only the original one.
Hence the fix which i proposed got rejected.
Tried with the different Tomcat version - 6.0.20, this Casting is working fine without adding any parameters in the XML files.
Could anyone help to clarify this?
Why it is working in 6.0.20 and not in 6.0.29 version?
And how to fix this issue in 6.0.29 version as well?
Most likely, it "worked" in 6.0.20 because of a bug that got fixed by release 6.0.29.
The whole reason for the rigamarole about Underlying Connection is because the actual JDBC Connection object that links to the Oracle server is not what gets returned from the connection pool. Instead what you get is a delegating extension class that mostly hands off all its method calls to the underlying (Oracle) Connection, except for the "close()" method, which simply returns the connection to the pool instead of actually severing the network linkage as the underlying Connection's close() method would.
There is really only one reason for obtaining the underlying Connection object, and that is so you can invoke methods that the underlying Connection object's driver provides that are not in the Java JDBC standards. While this can be useful, it is not something you want to do for trivial purposes. It locks you into a specific vendor, both in terms of the actual code, and in terms of where you can get support. Unless you absolutely, positively must, I don't recommend tying yourself to any vendor, even one as well-established as Oracle. You can never tell when someone in Accounting will balk at sending Larry Ellison another $100K and require you to dump your application on a PostgreSQL server instead, for example.
An IDE is no substitute for an Intelligent Developer.