When you start porting an application which contains Servlets watch out for lines using functions from the ServletContext class.
The methods getResource() and getResourceAsStream() take a path parameter. This path allows you to access files in your web application directory structure like "WEB-INF/config.xml".
Using these methods within Tomcat gives you a false sense of security as it silently allows path names without a starting "/". This is contrary to the J2EE API documentation which clearly states that "The path must begin with a "/" and is interpreted
as relative to the current context root."
OC4J very strictly follows the API documentation and specifications and therefore requires the starting "/".
Conclusion: Don't forget the starting "/" if you want to access files with the ServletContext class. It makes your life easier no matter which Servlet container you use.
« New PMD with rule to detect possible J2EE problem | Main | Just a test »
Porting from Tomcat to OC4J
Search All Blogs
Google Search
About This Entry
This page contains a single entry from the blog posted on June 25, 2006 3:37 PM.
The previous post in this blog was New PMD with rule to detect possible J2EE problem.
The next post in this blog is Just a test.
Many more can be found on the main index page or by looking through the archives.
Comments (2)
What a pitty that the RI is wrong in this regard. I wonder how the RI has passed the TCK ;-)
Posted by Behrang | June 25, 2006 8:21 PM
Posted on June 25, 2006 20:21
Some other gotchas:
-JNDI path names are different. OC4J doesn't usually use the "java:env/" prefix, instead using JNDI names that are simpler, like "jdbc/somePool".
-the load on startup option for servlets in web.xml is not interpreted as yes/no, like it is in tomcat. 0 means no, and any other number specifies a cardinal order, in case you want to specify exactly in which order servlets load. This is a remnant from orion.
-Be careful if you're using Tapestry for webapps. For oc4j versions prior to 10.1.3, you'll need to modify hivemind source to deal with a problem with how Oracle interprets jndi prefixes. For 10.1.3, you'll need to override Oracle's default XML parser, because it's broken and won't read Tapestry config files properly. Something to do with the broken parser having problems with Apache digester.
My advice: run! we've had nothing but odd problems associated with oc4j (especially when run as part of the full AS package).
Posted by Anonymous | June 26, 2006 1:08 PM
Posted on June 26, 2006 13:08