15
Replies
Charlie,
Screenshots from my IIS 7.5 server, showing both server level and website level ISAPI and CGI restrictions. They all seem to point to the correct DLL, even after several re-connections using the WS config tool. I did delete the extra ASP.net connectors, since I was fairly certain I don't need them. As an extra step, I did include .jsp into the URLScan.ini file as an accepted file extension, however, it didn't get the JSP file served.
Mike
Ok. Here’s another question: is this test jsp page in the docroot of the site? Or in a subfolder? Not that it should matter, but I’ve seen problems where even CF pages could run in one and not the other, so it could point out a different issue.
Also, did you create a new docroot for the test site? It seems so, from the screenshot. It’s just important to confirm, because in IIS 7, there is a web.config that can be placed by IIS the site docroot, and if both sites shared one docroot, they’d share one web.config, and that could explain even a new site still showing the problem of an old one. Still, I doubt that’s the issue here.
Next, if you’re really stumped, it may be worth reviewing the applicationhost.config (in windows\system32\inetserv\config) to confirm that all its references to “coldfusion” are right and as expected. That may not be trivial for one not familiar with what would look right or wrong, but I leave it as a clue if you’re feeling frisky. 
I’ll say, finally, that some problems like this turn out to be due to things one might never expect, or think to discuss in a back and forth on email or the forum like this. Sometimes there’s just no substitute for you having an experienced troubleshooter (like myself) sitting down with you (over the web, looking over your shoulder) to look over things with you. I do this sort of things with folks every day, and solved a problem just like this (not with jsp but with CF pages) just the other day.
If you may be interested in that sort of help, to expedite things, I’ll point out that I keep a list of such consultants in my CF411 site (of tools and resources), specifically at cf411.com/cfconsult.
But if you want to keep trying here, we can. I can’t be sure to always respond right away, but will if I can. And indeed maybe we may trigger a thought from someone else who may be watching, today or later in the week.
/charlie
Hi,
IIS can never directly support the use of JSP because it requires an add-on to run Java code in a JVM to Load, Instantiate, and Reflect on the JSP page. The same can be said for every other non-Java web server because they have to do the exact same thing as IIS (so it is a matter of bundling and not capability). Meanwhile, Java-based web servers can obviously directly support JSP, but they are usually VERY slow in raw speed in comparison to native code web servers like IIS or Apache for everything. In fact, you can say the exact same thing about ASPX pages - IIS can never directly support the use of ASPX pages because it requires an add-on to run .Net code in a CLR to Load, Instantiate, and Reflect on the ASPX page.
Tomcat works with web servers like Apache and IIS:
- Tomcat includes a web server written in Java.
- Since it is writtin in Java, Tomcat obviously can "natively" run a JSP or Servlet, which is basically another Java class to Load, Instantiate, and Reflect as far as Tomcat (i.e. Java) is concerned.
- All web servers that are NOT written in Java (like Apache and IIS) obviously cannot run JSP without first loading Java code in a JVM to Load, Instantiate, and Reflect on the JSP page, and this is exactly the functionality their respective add-ons/connectors give to these web servers.
Hope it helps
Thanks
VJ 
AdChoices