You can disable cookies in the resin.conf with a configuration like
The generated .java files are put in. By default, that's on Unix and on Windows.
Your jsp file must import the proper packages so Java can find the bean. Also, the bean should typically be in.
Also, if your bean has no package, you need to import the bean by name:
Resin has an optimization,, which assumes that your page is written in the same encoding as you're printing. That usually works, but some people write a page in one encoding, like and print it in . To make that work, you need to disable .
Here's an example page that would need to disable static-encoding:
A POST request with application/x-www-form-urlencoded doesn't contain any information about the character request. So Resin needs to use a set of heuristics to decode the form. Here's the order:
Resin uses the default character encoding of your JVM to read form data. To set the encoding to another charset, you'll need to change the resin.conf as follows:
Usually, this is a servlet extending HttpServlet and implementing doGet but not doPost. If you send a POST request, like a form, to a servlet that only implements doGet, you will get 405 resource not found.
Mattias Nilsson writes:
Here's the code I use for dumping exceptions on JSP pages
also very useful to include in error emails etc.
Normally, you can just grab the cookie from, call , and add the cookie to the Response.
One thing you may need to watch out for is that theand of the deleting cookie must match the browser's cookie. By default, Resin does not set .
If you set a cookie header explicitly, you may want to call.
To delete this cookie, you must call:
The vast majority of sites can completely ignore web-apps. If you're starting with Resin, use the default web-app and don't worry about it.
You'll only want to use web-apps when you want separate projects using the same web server. For example, on an ISP site, each user might get her own web-app. She can treat the web-app as if she had control over the whole web server starting at a URL prefix like.
A web-app is a generalization of a virtual host. With virtual hosts, each host pretends that it controls its own server when it really is sharing the server with other virtual hosts. A web-app extends this by creating virtual applications for a URL prefix.
Each web-app gets its own sessions, servlets, beans and static pages.
Remember, the browser doesn't know about your web-apps. It treats the web server as a single URL-space. This may cause you troubles if you use a standard directory structure like putting images in '/images/*'.
To see this problem, suppose you have a web-app called '/myproject'. Suppose you have a JSP page in the web-app called. The full URL will be . Your image reference should look like one of the following:
Usingwill fail because the browser will look for when you really want .
Unfortunately, all the browsers work differently. The following seems to be a consensus on the headers to set:
You can run Resin on a single page from the shell:
That will compile the JSP. When you next start Resin, the JSP file will already be available.
You can also use a link checker spider to traverse your website to hit all the pages you want to precompile.
The JVM has a number of limits on a method's code size. Most compilers won't tell you that you've exceeded the limit, so you'll see the error when Resin tries to load the compiled code. This can be especially troublesome if you use tag libraries heavily, because each tag generates a fairly large amount of code.
The only real solution is to break your pages into subpages using jsp:include. That may actually turn out to be an advantage because you can then use Resin's caching to improve the performance of those subpages.
You'll need to translate the URL to a real path using. Resin's current directory is which is normally not where you'll be storing data files. You can look up a real path based on the using or relative to the current URL using .
Nicolas Lehuen writes:
I'm running Resin 1.2.s000920 either on the Windows 2000 (JDK 1.3.0_01) or Solaris platform (JDK 1.2.2 + Hotspot 1.0.1). When POSTing forms with accents from IE 5.5 on Win2000 to the server running on Win2000, everything is allright. If the server runs on Solaris, I get '?' instead of the accentuated characters. I have read the FAQ about this, and tried to set the 'character-encoding' attribute of the http-server tag to 'ISO_8859_1' or '646' (which seems to be the default character encoding on the Solaris platform, as reported by the 'file.encoding' system property). I also tried setting the caucho.form.character.encoding attribute of the HttpRequest to ISO_8859_1. Nothing changes, on Solaris I always get '?' instead of accentuated characters.
Two questions, there :
Rogério Saran writes:
Nicolas, Solaris JVMs follows the default system locale for character output. A bug on some Solaris installers can damage the system default locale and leave it with invalid settings.
Check your settings with the "locale" console comand. It will probably not look "good", with lots of "C"s replacing valid settings. Just change /etc/default/init and make it look like:
You will nee to reboot the machine to make these settings valid for all running processes. If you don't want to restart the system you may also add the lines above to your Resin startup script - just set these environment variables before calling RESIN_HOME/bin/httpd.sh.
Nicolas Leheun writes:
Thanks to Rogério Saran, the solution of correctly defining the Solaris 5.7 locale thanks to the /etc/default/init file works fine. I just had to find out the fact that 'su -' was corrupting the locale configuration, whereas a simple 'su' does not. The '-' is meant to pass along the current user environment to the super-user, but it is not the case for the locale, at least in my version of Solaris 5.7 :(
Thanks also to Eric Arrive (a former colleague !) for his very interesting line, which I'll save immediatly as an excuse for not having a better solution than changing the default locale of the VM ! We're serving i-Mode also, don't ask me how I'll handle japanese form postings for the moment...
The servlet API doesn't have a good way of handling logout. (The authentication in the spec is really only partially thought-out.)
You can write a logout method that looks like:
Or you could invalidate the session. Invalidating the session will remove all information, including login information.
Until we come up with a way to get the authenticator object from a servlet, there's really no other way to deal with this.