|
![]() |
![]()
Make sure you try the following:
Before you ask any questions on the list, you should be able to answer the following questions:
If you don't answer these questions in your mail, the mail will probably be ignored. Victor A. Salaman writes: This may sound elementary... But check for these common pitfalls:
After you do this, execute httpd.exe and see what pops up....
Try looking at . If this fails, IIS can't use the iis_srun.dll plugin. The problem is probably one of the following:
When the Resin ISAPI filter detects a JSP page or servlet, it rewrites the URL to . IIS will then execute iis_srun.dll as an ISAPI extension. If your virtual site is missing the directory, IIS can't find the ISAPI extension.
The particular error message is something like:
The servlet runner process needs to be started. In resin1.1/bin the srun executable will start the servlet runner. The srun executable will start Java and wait for connections from the web server.
The web server (IIS or Apache) and the servlet runner (srun), need to find the web pages. The resin.conf file configures srun. You need to add a 'app-dir' property, to tell srun where to look for the root directory.
If you're running Resin with IIS or Apache, the web server might not know how to handle *.jsp files. On Apache, the httpd.conf needs to add Resin. On IIS, the IIS configuration needs to dispatch *.jsp files to srun_iis.dll. Both may need restarting to see the changes. To test if this is the problem, stop the srun executable. If you browse http://localhost/test.jsp, you should get the 'Cannot connect to servlet runner' message.
You'll get this exception if you try to start two Resin instances using the same port. You'll need to stop the first one. On Unix, the dramatic way of stopping Resin is to kill the wrapper.pl script:
First, look at the standard installation and check the HelloWorld example. The HelloWorld source is in . Resin will automatically compile that source when running the demo and put the class in the same directory.If you change the app-dir to /usr/local/apache/htdocs, servlets and beans will belong in /usr/local/apache/htdocs/WEB-INF/classes. Until you get your first servlets working, don't try to create your own web-apps. When you do start working with web-apps, look at the guest book examples to see where beans and servlets belong. You can also change the default location with the directive.Application jars belong in and standard libraries, like JDBC drivers, belong in the global classpath. In general, you should put standard libraries in the global classpath. Resin has several equivalent methods to add a jar to the classpath:
Only the last two will be automatically reloaded when the class or jar changes. For the first two, you'll need to restart Resin. You can see Resin's global classpath by starting it with the -verbose option:
You must restart Resin to pick up the new classpath. When using the Win32 Resin, you must quit the Resin application. Just pressing the stop and start buttons will not suffice.
On Win32, Resin and Caucho JSP try to find Java in the following order:
The error message might be something like:
Resin can write debugging information to standard output or to any file. To add debugging information add a directive to the resin.conf file.
Resin has a delay for testing updated servlets and JSP pages. The configuration variable for both is 'class-update-interval' in resin.conf. It's an application-level variable. The default is 15 seconds. So Resin will only check every 15 seconds for an updated page. You can set this value to 0 for development work.
If you want Resin to check servlets for updates every hour, your resin.conf might look like:
The JRE does not contain a Java compiler. You either need to get the JDK or use another compiler. To configure another compiler use:
For debugging, it is crucial to get proper line numbers. Unfortunately, Java JITs (just-in-time compilers) remove the line numbers. For development we recommend you turn jit compiling off. Start the server with the JIT compiler turned off. On Unix you can use:
This appears to be an Apache 1.3.9 bug. The loader configuration is missing from apxs (usually in /usr/local/apache/bin/apxs). For Solaris, the configuration should look like:
For debugging, it is crucial to get proper line numbers. Unfortunately, Java JITs (just-in-time compilers) remove the line numbers. For development we recomment you turn jit compiling off. On unix, start the server as:
This is only supported in Resin 1.1.b1 and later. 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.
This is especially important if you want to use a different
workspace for development than deployment. Just call the
First check that the class is in the right location. In the standard configuration, Java classes belong in . If you're using Resin's autocompilation, the Java source file must be in the same location.If you're using the automatic compilation, check that the in the *.java file matches its location.
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:
Your JDBC driver must be in the global classpath. Both Resin's DBPool and the JDBC mechanism can only load classes in the global classpath. Since WEB-INF/lib and WEB-INF/classes use special class loaders, neither JDBC nor Resin's DBPool can find them.
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 .
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:
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.
On Linux, each native thread is displayed as a separate process by 'ps -auxw'. Don't worry, those processes are extremely lightweight.
Eric Hansen writes: A lot of people have been asking about a suitable debugging environment for resin. I have been using JPadPro with the updated version of jdb. (I found that the jdb.exe that ships with the JDKs 1.1.8 and 1.2.2 do not like all the classloading that happens in a servlet engine.) Instead, try using the JavaTM Platform Debugger Architecture (JPDA) http://www.javasoft.com/products/jpda/. Just unzip the executables, dlls, and docs files in some directory. I chose c:\jdb. My project class files are in: c:\local, my resin1.1 files are in: c:\resin1.1, and jdk1.2.2 files are in c:\jdk1.2.2. To start up the debugger issue the following command (you may need additional classfiles in the classpath, etc.):
You can access the webserver at: http://localhost/ or http://localhost:8080/, etc. depending on the port number you picked. You should be able to issue the usual jdb commands. Check the list of commands by doing: help or ? at the jdb> prompt. I use jdb with JPadPro (http://www.modelworks.com). It has some built-in scripts to work with jdb. It is tailored to work with the jdb that ships with the JDK, which has a slightly different response syntax from the JPDA version of jdb. Since all of JPadPro's commands are written in JavaScript, you can easily modify the commands to parse the different command/response syntax in JPDA. Or you could even modify the jdb code to have it issue similar commands, since JPDA ships with source code for jdb. However, it's probably easiest to modify the JavaScript. (Check in Tools/Java/JDK/Debugger/*, including onBreakPointHit, setBreakPoint.) I modified setBreakPoint, for example, to look like this:
This is because the old version of jdb issued the syntax: "Breakpoint set...", and the new one issues the command "Set breakpoint request...". You get the picture. A similar formula should bear fruit for Visual Cafe, although they have their own proprietary debugger.
Eric Hansen writes: PROBLEM:Have you ever received a cryptic Exception message like this in your error logging due to an error in a JSP page: ???
SOLUTION:You need to change your catch routine. There is a method in ServletException called getRootCause(). This allows the developer of the servlet engine/JSP engine to embed a regular Exception inside a ServletException, which gets carried along for the ride.
(logMessage is some logging routine you write to do logging... Could also be System.err.println...) I was finding it quite difficult to debug JSP pages because I couldn't see what the underlying Exception was, just the ServletException which gets thrown from the JSP. The above modification (or something similar) exposes it. I figure other people might have the same problem.
<servlet-mapping url-pattern='/' servlet-name='myServlet'/> This has a different effect from . will have priority over extension mappings like , while has the lowest priority.
Arun Jamwal writes: I have used Weblogic's type 2 JDBC driver (formerly known as FastForward) on two big projects. Oracle's type 4 JDBC driver was crashing against a big query...and type 2 couldn't be used with M$ VM. Weblogic bundles these drivers with Tengah but you can ask them just for the JDBC drivers.... I had used Openlink's type 3 JDBC drivers too (about 2.5+ years ago) but I didn't like them much. PS: Check out these links for more info:
http://www.beasys.com/products/weblogic/drivers.html
Mattias Nilsson writes: Here's the code I use for dumping exceptions on JSP pages
Unfortunately, the Servlet API doesn't have a call to get the application's class loader. With Resin 1.1.b6, you can use
Other symptoms are that sessions are killed on each request. This may occur if your *.java files have a date in the future. When the *.class is compiled, it will have an date before the *.java. So Resin will think it's old and recompile on the next request. This may occur, for example, if you work on NT and use Linux as a fileserver and the two clocks aren't properly synchronized. The only solution is to synchronize the clocks for both machines.
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 the and of the deleting cookie must match the browser's cookie. By default, Resin sends and no domain.If you set a cookie header explicitly, you may need to call .
You can pass them on the command line like: . You don't need to escape . If you're on Unix, you can also add them to srun.sh or httpd.sh in the variable. You may need to quote the assignment:
In the resin.conf, add an directive using for the exception type. The location must be an absolute path understandable to your web server. For example, since the web server will display this message, you can't forward to a jsp file.
Use the directive. For example, to grab images from /home/images/*, use:
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:
Scott Ferguson writes: Since my experience with XSLT is only with simple examples, you'll want to take it with a shaker of salt. And, of course, it really depends on the application. Some applications are a perfect fit for XSLT and others should avoid it. For what it's worth, here's my current thinking on XSLT. XSLT is a very new technology; the spec was only finished in December. There really hasn't been enough time for people to discover what works and what doesn't work. Be very careful of new technologies, especially radical new technologies. Even Java, which has turned out to be a great language, was a disaster in the 1.0.2 timeframe, and Java on the client is still less-than-optimal and applets are nightmarish. When C++ was the hot new thing, many projects jumped full into C++ implementations and created huge unmanageable disasters. Now, I'm not suggesting that you avoid XSLT entirely, just that you be careful in using it and avoid placing it at the center of your architecture. I'd suggest you limit XSLT to places where it's a clear win. Otherwise you can waste lots of time coming up with the perfect tag library or debugging an architecture that will turn out, in hindsight, to have been an anti-design pattern. Here some useful areas I've found helpful:
So my approach, if I were starting a project, would be to select either straight JSP or servlet->JSP templates as a basic architecture, depending on the actual project needs. I'd replace JSP with XTP, but only use a defaultcopy.xsl and a header.xsl stylesheet. So far, this use of XTP is essentially identical to JSP. Only after common idioms and formatting kruft start filling up the JSP and become error-prone would I put them into the stylesheet. With XSLT such a new technology, a waterfall-style "design before you implement" approach is likely to get you into lots of trouble with XSLT. I'd avoid putting lots of Java code in the stylesheets. Put them in beans instead. Debugging Java code that comes from stylesheets into a JSP file is hard. Really hard. Your mileage will vary. Any discussion of XSLT architecture will be theoretical until several full-sized projects succeed with XSLT and several fail.
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:
You can also use a link checker spider to traverse your website to hit all the pages you want to precompile.
|