xml and xslt
features - resin and resin professional
Resin is a high-performance, scalable Java/PHP application server. We release two versions of Resin: an open source version under the GPL, and a professional version with enhanced performance, clustering, and reliability features.
Resin is provided in two versions, Resin Professional and Resin Open Source. Resin Professional adds features and enhancements commonly needed in a professional production environment. Resin Open Source is suitable for hobbyists, developers, and low traffic websites that do not need the performance and reliability enhancements of Resin Professional.
Resin Professional provides a number of reliability features, including automatic server restart, detection and restart of locked or stalled servers, and monitoring of JVM memory usage for applications with memory leaks.
Clustering provides the ability for multiple servers to appear as one server to clients. Clustering provides enhanced reliability and allows sites to scale up as server demand increases,
Clustering is supported with the standalone web server, Apache, and IIS.
Persistent and Distributed sessions
Persistent sessions guarantee that a server can restore the contents of the HttpSession object when it is restarted. Distributed sessions provide the ability for multiple servers in a cluster to share the values stored in the HttpSession.
Performance enhancing native code
Resin Professional includes a native code libary on both Windows and Unix platforms. Native code is used to provide significant performance benefits in areas like socket connections, keepalive connections, and file system access.
Resin Professional uses native code to link to the OpenSSL libraries, a much better and more efficient SSL solution than the Java facilities provided by JSSE.
HTTP proxy caching
Resin Professional provides a memory and disk based caching system for increased performance benefits. Server caching can speed dynamic pages to near-static speeds. Small but frequently accessed resources such as images and css files are cached in memory and served directly to the client, avoiding even a read from the disk.
Many pages require expensive operations like database queries but change infrequently. Resin can cache the results and serve them like static pages. Resin's caching will work for any servlet, including JSP and XTP pages.
Bandwidth costs are significant for many websites. The GzipFilter enables automatic compression of responses for browsers that support it. Use of the GzipFilter reduces bandwidth usage and may provide significant cost savings.
Secure Socket Layer (SSL) 3.0
Apache 2.0 and 2.2 integration
IIS 5 and IIS 6 integration
Resin uses its own IoC/Dependency Injection engine for all of its JavaEE configuration. With the new WebBeans (JSR-299) specification draft, Resin provides the same capabilities to application code. Components and singleton beans can be configured in the resin-web.xml for full XML configurability, or scanned for the class annotations for lightweight injection to match the style of the application.
Because Resin-IoC is fully integrated with Resin's EJB 3.0 support, all application components and beans can use EJB aspects such as @TransactionAttribute, @Stateless, @InterceptorClass, and @AroundInvoke.
The WebBeans IoC capabilities provide finely-controlled interception with @InterceptorType binding, and type-safe dependency-injection with @BindingType annotations. Testing with mock components are automatically supported with custom @ComponentType annotations.
Event handling is fully integrated with the WebBeans API using a flexible @Observes parameter attribute, enabling any bean or component to listen to any matching typed event thrown through the WebBeans Container interface.
Resin-managed classes are automatically enlisted in the IoC engine. So Servlets, Filters, application listener classes, remote objects, and EJBs can all use Resin-IoC capabilities without any additional configuration.
Resin includes Quercus, our PHP 5 implementation, written entirely in Java. Quercus is a reliable PHP, compiling to Java code and taking advantage of the JDK's JIT compiler for maximum performance. Because Quercus is in Java, it's security is far superior to a C implementation. The JVM automatically protects Quercus from stack overruns, pointer overflows, and third party C-modules.
And the performance is great. The compiled Quercus code is 4 to 6 times faster than raw, mod_php code. Even when compared with PHP accelerators, Quercus code is equal or slightly faster, depending on the application.
Quercus integrates tightly with Java, naturally since it is written in
Java. Resin-IoC applications can easily provide beans and components to
a Quercus/PHP presentation layer through a simple
With Quercus, Java sites have access to the PHP killer applications. For blogs, Quercus supports the extremely popular Wordpress. For wikis, Quercus supports MediaWiki, the engine behind Wikipedia.
Resin provides a robust connection pool for any JDBC 1, JDBC 2, or JDBC 3 database driver. Resin's database pools integrate with full 2-phase XA transaction capabilities. In addition, the database connections can use round robin load balancing and backup failover for increased performance and reliability.
Resin's EJB support is fully integrated with Resin-IoC and WebBeans. This integration means you can use only the EJB capabilities you need without the overhead of .ear packaging. (Although, .ears are fully supported.) A servlet, for example, can use EJB's @TransactionAttribute without any special packaging.
As web users are expecting dynamic responses from web sites, the server push HTTP processing model has become important. Also called Comet, server push sends event or streaming data from the server to the client without waiting for a client poll.
Resin's Comet support focuses on solving the concurrency issues around server push. Since the servlet is now responding to events from internal services as well as managing HTTP data, the synchronization issues become more complex. The Resin Comet API is designed to cleanly separate the concurrency roles, letting the servlet continue to operate as a single-threaded request, while letting the event services send asynchronous messages.
Resin's JSP implementation is tightly integrated with the JSTL and JSF implementations. Because of the tight binding, Resin can generate optimized JSP code, improving performance, reducing code size and reducing memory consumption.
Even JSP tag libraries can run faster with Resin's JSP. Resin bytecode-analyzes your tag libraries to determine which capabilities your actually using, and generates only that code necessary to run the features you're using.
The JSP implementation aggressively reuses your tag library instances, reducing memory consumption and improving performance. Because of Resin's reuse, application libraries must strictly follow the JSP tag specification.
Resin-IoC beans are always available through JSP EL expressions. This IoC integration means your custom components and beans are directly accessible to your HTML generating code.
Resin's JSTL works together with its JSP implementation to provide efficient, generated Java code. Since Resin's JSP is fully JSTL-aware, it can implement the JSTL tags directly in Java code, without involving the overhead of the JSTL tag libraries.
Since the servlet engine of Resin is built on a Resin-IoC foundation, servlets can use WebBeans dependency injection, event observation, and interception. Remember that Resin-IoC is fully integrated with its EJB support? By transitivity, Resin servlets automatically have access to EJB transaction aspects without any extra overhead.
Remote services are tied into servlet capabilities as well. Because remote services are URL-based, they naturally fit into the the familiar servlet processing model. There's no need to introduce complexities like standard EJB deployment or add extra frameworks just to expose a service as a URL.
Resin embedding is a lightweight facade over the core Resin server suitable for automated testing frameworks and IDE environments. With Resin's embedded testing interface, your tests can send HTTP requests directly to the server, skipping the overhead of TCP connections, and saving time on test setup and teardown.
The embedded API gives you hooks into Resin-IoC, so you can inject mock services into your tests, and still ensure that your application is tested in the full application server environment. Since integration testing uses the actual, deployment environment, elusive production bugs are easier to catch and destroy.
Resin remoting builds on the strengths of the Servlet architecture. As developers turn away from complicated remoting frameworks, the simplicity and elegance of the Servlet model becomes more appealing. Multithreaded, IoC-enabled, designed for HTTP and the web's URL architecture, well-known, well-documented, and well-integrated with application servers, the Servlet model has enjoyed phenomenal success.
Services expose remote APIs with the same interfaces and classes their clients will use, taking advantage of the Java compiler to enforce protocol compatiblity. Since Resin remoting protocols are available using a simple driver API based on Servlets, your services can choose the protocol to expose at deployment time, whether its a fast, binary wire-protocol like Hessian, or an XML-based wire-protocol like SOAP. Resin remoting clients select the wire-protocol matched with service API, and register with Resin-IoC/WebBeans, so application code can obtain the client proxy with simple, typed dependency injection.
The Resin watchdog service manages each Resin instance, allowing for graceful recovery and restart from critical server deadlocks and crashes. As a management capability, it offers a centralized interface for starting, stopping, and checking the status of multiple JVM instances. Because the watchdog is well-placed to gather information, it is responsible for management and logging of the server's debugging or warning messages.
For unix systems, the watchdog also improves system security. While the watchdog will run as the root user, Resin JVM instances run as low-authorization users, protecting your system from application bugs and security holes.
As a side benefit of the watchdog, JVM parameters like heap settings, agent configuration, remote JMX and system properties can be configured in the resin.conf itself. The watchdog can read the same resin.conf as the server itself, putting all configuration relevant to the server in one location.
For more complicated configurations like an ISP setting, the watchdog can use a separate configuration file readable only by root. The watchdog will launch Resin JVMs with assigned resin.conf files, ports, and user assignment, protecting each Resin JVM user from each other.
Resin's messaging focuses on simplifying the use and deployment of
messaging applications. At the core, a messaging system is really just
a queue with extra reliability and performance features like persistence,
transactions, and clustered distribution. So Resin provides
the standard queueing APIs like the JDK
On the receiving end,
Of course, the message listeners are can use all Resin-IoC capabilities,
including injecting JPA
Resin's transaction manager handles full two-phase XA transaction
suppport, including transaction logging for reliable transaction recovery.
The transaction capabilities are integrated throughout Resin, so your
databases, JCA connections, and EJBs work together. Since Resin's
Resin and Resin-Professional are tested and supported on the following operating systems:
Resin is known to work on the following operating systems:
Resin is used on these operating systems, however there may or may not be difficulties with Apache integration, and the JNI code that Resin uses to increase performance may not be available.