Creating JSPs and Servlets in CFMX

Many may have missed that one of the cool new things in CFMX is that it allows integration of JSPs and servlets, meaning (for
one thing) that you can actually place them within the CFMX environment and run them, as well as pass control to them, share variables, andmore.

For instance, (in the Enterprise Edition only), you can place a JSP page in your CFMX web application directories right alongside your CF templates and calling it with a URL just like CFM page (using .jsp for the extension of course in the file name and the URL).

And servlets can be run as well, by placing them in the WEB-INF\classes directory and then calling them with:

http://yourdomain[:port]/servlet/ServletClassName

Those familiar with Servlets may know that sometimes you don't want to use the /servlet/ approach. You can create a virtual mapping instead by editing the file
[CFusionMXhome]\runtime\servers\default\SERVER-INF\default-web.xml.

To create a mapping for a servlet named SimpleServlet residing in the cfusionmx\wwwwroot\WEB-INF\classes directory, for instance, so that it could be called as /simple, just put the following in between the <web-app> element tags of that file:

<servlet>
<servlet-name>SimpleServlet</servlet-name>
<servlet-class>SimpleServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>SimpleServlet</servlet-name>
<url-pattern>/Simple</url-pattern>
</servlet-mapping>

For more details on this sort of configuration, as well as on how to write and compile JSPs and servlets, see any good JSP/servlet book (including the fine JRun docs at livedocs.macromedia.com).

Those familiar with mapping virtual paths for servlets may also know that you can disabling the "servletinvoker". That's done by editing the file cfusionmx\runtime\servers\default\SERVER-INF\default-web.xml and commenting out the servlet definition for the ServletInvoker servlet.

One interesting aside is that while the Professional edition of CFMX specifically prevents execution of JSPs, it does not prevent execution of Servlets (of course, under the covers, CFML templates get converted to servlets in CFMX, so it may seem like there's no choice but that it should support them). But my reading of a few CFMX documents and the "edition comparison" suggests that running JSPs and servlets is an Enterprise-only feature. Be aware if running on Pro. Don't make any design/architecture decisions based solely on the fact that it "works", if it's against the license. I've reported this observation to Macromedia and am awaiting word.

Beware of case in calling Java CFX custom tags

When calling a Java CFX custom tag in CFMX, it is now critical that the case of the tagname in the call to the tag (as in ) match the actual case of the tag as defined in the CF Administrator. This is a change of behavior from CF5 and is not mentioned in the docs on calling Java CFX custom tags (Chapter 12 of the "Developing ColdFusion MX Applications with CFML" book).

While it has indeed always been true in 4.52, 5, and MX that the case of the classname as specified in the Administrator had to match the name of the actual .class file, you could use any case for the call to the custom tag as in . Now, the case of the call must match the name specified in the Administrator as well. This could cause a problem for old code during migration, especially for any situations where the same tag is called using different "case" in multiple templates.

Updates on problems with J2EE Sessions

I mentioned recently that I'd done an article in the CFDJ on using J2EE sessions. Since then, I've learned of a few challenges that can make working with them difficult in certain circumstances.

First, when you enable J2EE sessions, CFMX no longer creates the variables session.cfid and session.cftoken. If you're using those to attempt to persist sessions when (or in case) cookies aren't supported, those values are no longer available once you enable J2EE sessions.

You might think to try to use the available session.URLToken variable instead (or cookie.jsessionid, which does exist on the server while the page is being executed). Unfortunately, nether of these will work.

CFMX can only receive a jsessionid on a URL if it's appended after the filename and extension as ;jsessionid=nn, a format that was discussed in the article. This is the reason for the URLSessionFormat function, which was also discussed in the article. But that has problems as well.

I had mentioned in the article that the new URLSessionFormat would, when when using J2EE sessions (and when the browser does not present the JsessioID cooke), cause the resulting URL it generates to appear in the format templatename.cfm;JSESSIONID=8030949691025145133137. Note that the JSessionID is appended to the filename separated by a semicolon, rather than to the query string.

I added that "Still, when that's happened, the URL has functioned as expected."

Well, I was doing testing at the time on the built-in CFMX web server. I've since discovered that if you're doing this on an IIS web server, the use of the ;jsessionid after the filename causes a 404 file not found. This is disappointing.

If you use J2EE session variables and are working under an IIS web server, don't use the URLSessionFormat, at least until this problem is resolved by MM (or MS).

And that's not all. If you enable J2EE sessions and then use CFLOCATION, and a browser executes the page but doesn't support cookies or doesn't present the JsessionID such as on the visitor's first visit, CFMX will append the ;jsessionid after the filename and extension as discussed in the article. That's great for the built-in CFMX web server.

Unfortunately, if the redirection is to an IIS server (whether yours or another), the request will fail. Even using the ADDToken="no" won't stop it doing this.

Either MM needs to address this, or Microsoft needs to change IIS to allow this sort of URL.

And for final clarification, in case you missed it above, this issue of how URLSessionFormat or CFLOCATION determines whether to append the needed sessionid info is done not based on whether the browser supports cookies or not (CF can't really tell that), but it's simply a question of whether the expected sessionid cookie is passed: if J2EE sessions are enabled, it looks for a JSessionID cookie, if they're not, then it looks for the CFID and CFTOKEN cookies.

Not only will they not be present in a browser that doesn't support cookies but also they won't be there on the very first page that the user visits even if they do support cookies. These issues above could bit you then.

Restarting the CFMX Service

Many may know that when starting and stopping services in Win2k and WinXP, there are a set of buttons at the top of the Services window similar to stop (square) and play (sideways triangle) buttons on a VCR. Some maybe hadn't noticed that there's also an icon that combines them both, effecting a "restart service" in a single step, with a combination of a square and a triangle as its icon.

But as nifty as that "restart" button is, I've found that sometimes trying to use it with CFMX has caused problems. Sometimes the process of stopping and then starting the service takes quite a while, and It seems that perhaps there's a time limit that that restart interface is willing to wait before complaining that it took too long. I could be wrong. But I've gone to using the stop and then start buttons instead and it seems to have helped. Still, it's occasionally still taking too long to start the service and still the OS complains that it couldn't start it.

I've recently switched to using the command line "net stop" and "net start" commands instead, in the hopes that there's no time limit in their responding. For those not familiar with this, you can run the following from the command line, or create a shortcut or batch file, executing the following lines:

net start "ColdFusion MX Application Server"

and

net stop "ColdFusion MX Application Server"

I'll see if this stops the problem of having the other start/stop approach seemingly timeout.

If anyone has more information about this apparent timeout challenge, let me know.