Category: Java/.NET Runtime
Are there special considerations for ASP.NET applications?
Yes, there are. We have dealt with two main problem areas in this respect:
On the security side, many mixed language applications run fine as a stand-alone process but they don't work when integrated into a web application hosted by IIS. This is usually due to IIS and .NET imposing different security levels to hosted web applications than to applications that are executing from the local file system. You will wish to deploy your jar files to a directory that can be read and you'll need to make sure that IIS grants the privileges that your Java types will need.
This issue is further complicated by the fact that the .NET developer might not be 100% familiar with the runtime privileges that are required by the Java API that is being used. We recommend granting all privileges during deployment debugging to see whether the problems you are experiencing are due to insufficient privileges. Once you know that you have a privilege issue, you can use standard security debugging techniques to figure out the minimally required set of privileges and configure that set.
Iterative debugging is another problematic area. When you're developing a stand-alone application iteratively, you usually go through many change/build/run cycles. You make your change, build, and test the change immediately.
This iterative approach is much more difficult when your Java classes are being hosted by IIS. As described in the architecture guides, a JVM is loaded (explicitly or on-demand) for the lifetime of the CLR process. This is not problematic in the case of a stand-alone application; in fact, that's usually exactly what you want. In the case of your ASP.NET application, the process is not the code that you're writing but IIS. This means that once the JVM has successfully been loaded into IIS, you can't load it again. It also means that Java types that have been loaded into the JVM will remain there until IIS is restarted.
Take this into account when you're developing iteratively. There's currently very little we can do to improve this characteristic. It is based on the way that Java has been designed and implemented.
When trying to figure out, why a page that uses Java types does not render, it often helps to set the trace level and a trace file. If you're using a web.config file, you use the following elements:
<add key="TraceLevel" value="TraceInfo" /> <add key="TraceFile" value="<a file that can be written to>" />
Normally, IIS will not grant you write privileges to random directories, so you'll need to configure write access for the specified log file before you can see anything.