| mohideen.com > Blog > Archive > August 27, 2003 | Home | Photos | Blog | About Me |
|
This is a critical question for somebody who is evaluating an open source framework to use on their web application project that eventually needs to be hosted online. Your budget may limit you to a shared virtual hosting plan, which means you have to work within the constraints of the infrastructure the ISP provides. Let's say you know that your ISP provides an Apache web server and Tomcat for JSP/Servlet hosting. But you still want to know if your favorite framework will run on this ISP. The ISP website does not mention anything about this, so you turn to the framework's website. But most open source framework websites are not clear on this question. Although they do provide some information, it is in the form of a very short list of ISPs they know that support the technology in question. Guess what, your ISP is not on that list! The correct and more informative way to answer this question is by specifying what is required of the ISP in order to run the framework. Try this for a straight and simple answer - "Any web application container that supports Servlet 2.3 and JSP 1.2. Just copy your entire web application, including the framework jars in the lib directory, to the target server". Now, you know that the Tomcat 4.1.27 on your ISP is sufficient for your needs and you can start testing the framework. Of course, if your ISP officially supports the framework, in the sense that the jar files required for the framework are available globally, then you don't need to deploy those jars with your web application. They will be visible to your application, if Tomcat has been setup properly. Your web application is much smaller now and you can save on allotted disk space. But, please note, it is recommended that you not depend on a shared component, because you are locked to the version that is installed. Only your ISP can upgrade to a newer version, or worse still, they may upgrade without notice one day and your existing app might break because of some incompatibilities in the newer version! A safe approach is to deploy all the dependent jars with your application so you have control over which version your program will use. You are still locked to the web server and servlet container version installed, but that is a necessary evil. Posted by nmohideen | TrackBackComments
Post a comment
|
|