| ||||||||||
Resin 3.1 Documentation Examples Changes Overview Installation Configuration Quercus SOA/IoC JSP Servlets and Filters Admin (JMX) EJB Amber Security Performance Hessian XML and XSLT Third-party Troubleshooting/FAQ tags Common Tasks Relax Schema howto Config FAQ Scrapbook DB Scrapbook |
Where is the configuration GUI, and the GUI for deploying web-apps and new virtual hosts?Resin deliberately does not include any kind of GUI for deployment or management. Or philosophy is:
Where can I find the .rnc files that Resin uses for validating configuration files?The .rnc files used by Resin for validation are in
Can I precompile JSP's?See JSP Compilation. How can I disable directory listings?Directory listing is performed by a servlet named `directory'. The standard resin.conf contains a definition of that servlet: <web-app-default> ... <servlet servlet-name="directory" servlet-class="com.caucho.servlets.DirectoryServlet"/> Directory listing is disabled by removing or commenting out this definition. <web-app-default> ... <!-- disabled: <servlet servlet-name="directory" servlet-class="com.caucho.servlets.DirectoryServlet"/> --> What impact does always-save-session have on performance?always-save-session has a significant impact on performance. When using always-save-session, Resin can't know if an internal bean value has changed, so the session is serialized with every request. That's a pretty significant amount of work, depending on how much is stored in the session. It is far more efficient to design the session to avoid the need for always-save-session, so session values are only saved once and then are read-only. You can avoid always-save-session if you call setAttribute() each time the session state changes. If your web application calls session.setAttribute("key",value) everytime you change the object, then Resin can intercept that call and realize that the session needs to be written to the distributed store again. Resin 3.0 is a little more efficient thatn Resin 2.1. Resin 3.0 compares the crc sum of the serialization; it compares the crc value of the serialization of current session objects with the objects in the backing store, and if there is no change the session is not written.
|