Monday, December 03, 2007

Open Source Projects

Open source is great for the community and for the developers behind the projects. It gives the developer(s) publicity and it also gives the developer(s) an opportunity to garner feedback from the community. I appreciate all the work that goes into open source and in an effort to improve a large portion of open source projects, notably frameworks that are out there, I want to bring up context roots. For all practical purposes context roots generally should not make a difference but I've now run into multiple projects that require modifications to work in an environment that runs on a context root other than /. When possible I make fixes and contact authors of the issue. Its not terribly difficult to fix generally but I have had experience that authors were not even aware of context roots. Since this has occurred multiple times I just want to try to make people aware of context roots and and explain them (I may over simplify this but I'd rather over simplify than over complicate).

To keep it simple I'll limit this explanation to deploying ColdFusion as a WAR file. When you deploy a JEE application to an application server each application lives in its own directory. The context root is (in many app servers) the name of the containing directory. So if I deploy my ColdFusion application as cfusion.war (this contains my CFML and the CFML engine) the context root is cfusion. Now if I want to visit the administrator I would visit, http://sam.pl/cfusion/CFIDE/administrator/index.cfm. Note the /cfusion/, this is the context root. Now on the flip side if I am in a ColdFusion page and want to use cfinclude to include that same CFM I would do <cfinclude template="/CFIDE/administrator/index.cfm">, note the lack of the context root. Generally context roots do not rear their ugly head, the most common place I see issues arise is when pages attempt to include static assets in HTML. You see things like an application is deployed to /wwwroot/myproject/ and static assets are referenced like /myproject/css/default.css. The fix is simple enough, #getPageContext().getRequest().getContextPath()#/myporject/css/default.css. There are other issues I've seen when projects try to calculate the paths, generally resulting in {path including WAR directory}\{context-root (put here by framework generally}\{path to project}. Most of these issues can be overcome by using expandPath() and other built-in functions. Hopefully this helps a couple of open source contributors that may not have been hip to context roots.

No comments: