This is a beta release of the Winstone Servlet Container. The homepage for this project is
at 'http://winstone.sourceforge.net'
Author: Rick Knowles (contact details below)
It is not intended to be a completely fully functional J2EE style servlet container (by this I mean supporting extraneous APIs unrelated to Servlets, such as JNDI, JavaMail, EJBs, etc) - this is left to Tomcat, Jetty, Resin, JRun, Weblogic et al.
Sometimes you want just a simple servlet container - without all the other junk - that just goes. This is where Winstone is best suited.
The original goals in writing Winstone were:
Winstone is the name of a rather large Jamaican man a friend of mine met one night, while he was out clubbing in the Roppongi area of Tokyo. He (my friend) was a little liquored up at the time, and when Winstone suggested they head to "this really cool club" he knew, he didn't think anything was wrong. It wasn't until Winstone led him down a dark stairwell and dropped his trousers that my friend clued in and ran like hell.
It was too good a story to let die, so I named this project Winstone so that said friend will continue to be reminded of it. Heheheh ....
As of v0.8.1, all other files are dual-licensed, under either the Lesser GNU Public License (LGPL) as described in LICENSE-LGPL.txt, or the Common Development and Distribution License (CDDL) as decribed in LICENSE-CDDL.txt. Until v0.8, the license used was the GNU Public License (GPL).
The goal of dual-licensing is to make Winstone as attractive as possible to distributors of commercial webapps, while ensuring everyone benefits from any improvements. The CDDL allows free distribution with any commercial applications, while distribution with a GPL licensed webapp is also possible under the LGPL. If you are unclear about which license applies to an application you wish to distribute or sell, please contact me.
I'm open to help from anyone who's willing to help me meet the above goals for Winstone. Just mail me at the list (winstone-devel AT lists DOT sourceforge DOT net)
To build Winstone, unpack the tree:
To run it:
Winstone looks for a config file
This is just intended as a handy feature for people who want to cache regular startup options, rather than using batch files.
So, for example, if you had a directory /usr/local/webapps which contained sub-directories ROOT and test, if you executed
From v0.8, if you need multiple hosts (sometimes called name-based virtual hosting), there is a new option
The directory name becomes the host name: that is, a directory named "www.blah.com" will only serve requests with the host header www.blah.com, unless it is the default host. If a directory named "default" is found, it becomes the default host. If no default directory is found, the first directory in the list (alphabetically) becomes the default host.
The controlPort is disabled by default. If you choose not to enable it, the only way to shut Winstone down is to kill the process (either by Ctrl-C or kill command).
from http://winstone.sourceforge.net/
------------------------------------------------
It is not intended to be a completely fully functional J2EE style servlet container (by this I mean supporting extraneous APIs unrelated to Servlets, such as JNDI, JavaMail, EJBs, etc) - this is left to Tomcat, Jetty, Resin, JRun, Weblogic et al.
Sometimes you want just a simple servlet container - without all the other junk - that just goes.
This is where Winstone is best suited.
You could find some documentation and support on this site: http://intelligents-ia.com/index.php/category/technique/Winstone )
The original goals in writing Winstone were:
He actually stopped developing and supporting Winstone, due to other projects. Since then, with his permission, we take the support of this "small" project that has titillate our neurons.
We hope that our little fingers instill enough magic in this project so that you are likely to use it.
from https://code.google.com/p/winstone/
---------------------------------------------------------
Put simply, what this means for Tomcat is that it’s starting to look like a pretty bloated stack. Developers no longer require a servlet engine that provides logging, naming/directory services, connection pooling, a security container, etc. In fact, they are now keen to embed the servlet engine in their own applications (directly, or via OSGI) just to provide a servlet handler. In this regard, Tomcat is overkill. It even weighs down development time with its large-memory footprint, both in terms of the JVM and the actual file system. Is there an alternative? Increasingly, judging from my own discussions with colleagues and discussions like this at stackoverflow.com, Java web developers have been turning to an open-source server called Jetty.
Following convention, Winstone will run at port 8080 by default (you can override this by passing in your preferred port number as a run-time variable). In line with the current vogue to bypass JSP development altogether, Winstone ships with JSP support disabled, but this (and a myriad other settings you might want to use) can be toggled by using a simple local key-value pair properties file. This is all clearly documented at the project site. Additionally, if you’re a Maven user, you can simply include Winstone in your project using this pom declaration:
<dependency>
<groupId>net.sourceforge.winstone</groupId>
<artifactId>winstone</artifactId>
<version>0.9.10</version>
</dependency>
My favorite feature of Winstone is the ease at which it can be embedded in to your application. You may want to do this to give your application a web server front end and/or servlet engine, or embed a server in your test scripts. Either way, you can do this in just four lines of code:
Map config = new HashMap();
config.put(“webroot”, “webapps/my-killer-app/”);
Launcher.initLogger(config);
Launcher winstone = new Launcher(config);
I have yet to test Winstone in a production setting, or anything other than my development laptop, but I am sold on it as a development tool at the very least. In addition to the base settings it ships with, it has these keys capabilities, which suggest it will fit a wide range of needs beyond pure servlet compilation:
I am keen to see how Winstone performs as I expand my use of it, and I look forward to benchmarking its performance on a production-grade machine. For now, I am very happy to have found such a lightweight and user-friendly servlet engine for my development needs. I am also eager to hear from developers who have or want to use Winstone in their projects, so please feel free to comment on this post.
from http://www.netwhisperer.com/2011/07/18/introducing-winstone-an-ultra-lightweight-alternative-to-tomcat-and-jetty/
Author: Rick Knowles (contact details below)
What is Winstone ?
Winstone is a servlet container that was written out of a desire to provide servlet functionality without the bloat that full J2EE compliance introduces.It is not intended to be a completely fully functional J2EE style servlet container (by this I mean supporting extraneous APIs unrelated to Servlets, such as JNDI, JavaMail, EJBs, etc) - this is left to Tomcat, Jetty, Resin, JRun, Weblogic et al.
Sometimes you want just a simple servlet container - without all the other junk - that just goes. This is where Winstone is best suited.
The original goals in writing Winstone were:
- Supply fast, reliable servlet container functionality for a single webapp per server
- Keep the size of the core distribution jar as low as possible (currently 166KB)
- Keep configuration files to an absolute minimum, using command line options to optionally override sensible compiled in defaults.
- Eventually compile with GCJ to make a 3-4Meg windows exe for local development/deployment of servlets. This has not happened yet, because of some GCJ class loading problems.
- Optionally support JSP compilation using Apache's Jasper. (http://jakarta.apache.org)
Why is it called Winstone ?
The short version (because the long version is way too politically incorrect) is as follows:Winstone is the name of a rather large Jamaican man a friend of mine met one night, while he was out clubbing in the Roppongi area of Tokyo. He (my friend) was a little liquored up at the time, and when Winstone suggested they head to "this really cool club" he knew, he didn't think anything was wrong. It wasn't until Winstone led him down a dark stairwell and dropped his trousers that my friend clued in and ran like hell.
It was too good a story to let die, so I named this project Winstone so that said friend will continue to be reminded of it. Heheheh ....
License
The Web-App DTD files (everything in the src/javax/servlet/resources and src/javax/servlet/jsp/resources folders) are covered by the licenses described at the top of each file (usually as licensed by Sun Microsystems).As of v0.8.1, all other files are dual-licensed, under either the Lesser GNU Public License (LGPL) as described in LICENSE-LGPL.txt, or the Common Development and Distribution License (CDDL) as decribed in LICENSE-CDDL.txt. Until v0.8, the license used was the GNU Public License (GPL).
The goal of dual-licensing is to make Winstone as attractive as possible to distributors of commercial webapps, while ensuring everyone benefits from any improvements. The CDDL allows free distribution with any commercial applications, while distribution with a GPL licensed webapp is also possible under the LGPL. If you are unclear about which license applies to an application you wish to distribute or sell, please contact me.
Contacting the Author
You can contact me through the Winstone development list at sourceforge (winstone-devel AT lists DOT sourceforge DOT net). If you have any general comments or questions about Winstone please mail me on that list - I'll try to start a faq soon.I'm open to help from anyone who's willing to help me meet the above goals for Winstone. Just mail me at the list (winstone-devel AT lists DOT sourceforge DOT net)
Using Winstone
If you want to build from source code, you will need to download and install Apache Maven (v1.x). The following instructions assume you have already installed Maven and have the maven shell script in your path (to get Maven, see http://maven.apache.org/).To build Winstone, unpack the tree:
tar zxf winstone-src-0.9.10.tar.gz
Then build it:cd winstonemaven clean jar
The winstone.jar file will be in the target directory after the build is complete.To run it:
java -jar target/winstone-0.9.10.jar --webroot=<location of webroot> (+ other options)
- OR - java -jar target/winstone-0.9.10.jar --warfile=<location of warfile> (+ other options)
- OR - java -jar target/winstone-0.9.10.jar --webappsDir=<location of webapps directory> (+ other options)
- OR - java -jar target/winstone-0.9.10.jar --hostsDir=<location of hosts directory> (+ other options)
Command-line options:
Syntax:
java -jar winstone-0.9.10.jar [--option=value] [--option=value] etc
Required options: either --webroot OR --warfile OR --webappsDir OR --hostsDir
--webroot = set document root folder.
--warfile = set location of warfile to extract from.
--webappsDir = set directory for multiple webapps to be deployed from
--hostsDir = set directory for name-based virtual hosts to be deployed from
Other options:
--javaHome = Override the JAVA_HOME variable
--toolsJar = The location of tools.jar (default is JAVA_HOME/lib/tools.jar)
--config = load configuration properties from here(if supplied).
--prefix = add this prefix to all URLs. (eg http://host/prefix/etc).
--commonLibFolder = folder for additional jar files. Default is ./lib
--logfile = redirect winstone log messages to this file
--logThrowingLineNo = show the line no that logged the message (slow). Default is false
--logThrowingThread = show the thread that logged the message. Default is false
--debug = set the level of debug msgs (1-9). Default is 5 (INFO level)
--httpPort = set the http listening port. -1 to disable, Default is 8080
--httpListenAddress = set the http listening address. Default is all interfaces
--httpDoHostnameLookups = enable host name lookups on http connections. Default is false
--httpsPort = set the https listening port. -1 to disable, Default is disabled
--httpsListenAddress = set the https listening address. Default is all interfaces
--httpsDoHostnameLookups = enable host name lookups on https connections. Default is false
--httpsKeyStore = the location of the SSL KeyStore file. Default is ./winstone.ks
--httpsKeyStorePassword = the password for the SSL KeyStore file. Default is null
--httpsKeyManagerType = the SSL KeyManagerFactory type (eg SunX509, IbmX509). Default is SunX509
--ajp13Port = set the ajp13 listening port. -1 to disable, Default is 8009
--ajp13ListenAddress = set the ajp13 listening address. Default is all interfaces
--controlPort = set the shutdown/control port. -1 to disable, Default disabled
--handlerCountStartup = set the no of worker threads to spawn at startup. Default is 5
--handlerCountMax = set the max no of worker threads to allow. Default is 300
--handlerCountMaxIdle = set the max no of idle worker threads to allow. Default is 50
--directoryListings = enable directory lists (true/false). Default is true
--useJasper = enable jasper JSP handling (true/false). Default is false
--useServletReloading = enable servlet reloading (true/false). Default is false
--preferredClassLoader = override the preferred webapp class loader.
--useInvoker = enable the servlet invoker (true/false). Default is true
--invokerPrefix = set the invoker prefix. Default is /servlet/
--simulateModUniqueId = simulate the apache mod_unique_id function. Default is false
--useSavedSessions = enables session persistence (true/false). Default is false
--usage / --help = show this message
Cluster options:
--useCluster = enable cluster support (true/false). Default is false
--clusterClassName = Set the cluster class to use. Defaults to SimpleCluster class
--clusterNodes = a comma separated list of node addresses (IP:ControlPort,IP:ControlPort,etc)
JNDI options:
--useJNDI = enable JNDI support (true/false). Default is false
--containerJndiClassName = Set the container wide JNDI manager class to use. Defaults to ContainerJNDIManager
--webappJndiClassName = Set the web-app JNDI manager class to use. Defaults to WebAppJNDIManager
--jndi.resource.<name> = set the class to be used for the resource marked <name>
--jndi.param.<name>.<att> = set an attribute <att> for the resource marked <name>
Security options:
--realmClassName = Set the realm class to use for user authentication. Defaults to ArgumentsRealm class
--argumentsRealm.passwd.<user> = Password for user <user>. (for ArgumentsRealm)
--argumentsRealm.roles.<user> = Roles for user <user> (comma-separated) (for ArgumentsRealm)
--fileRealm.configFile = File containing users/passwds/roles. Only valid for the FileRealm realm class
Access logging:
--accessLoggerClassName = Set the access logger class to use for user authentication. Defaults to disabled
--simpleAccessLogger.format = The log format to use. Supports combined/common/resin/custom (SimpleAccessLogger only)
--simpleAccessLogger.file = The location pattern for the log file(SimpleAccessLogger only)
Configuration file
You don't really need a config file, but sometimes it's handy to be able to use the same settings each time without running through the command history.Winstone looks for a config file
winstone.properties in the current directory (or in the location
specified with --config) at startup. It loads the properties in this file, overrides them with any
supplied command line properties, and then starts itself.This is just intended as a handy feature for people who want to cache regular startup options, rather than using batch files.
Deployment choices
The simplest way to use winstone is with a single webapp. To do this, just supply the warfile or webroot directory as an argument:java -jar winstone.jar <webroot or warfile>, (this method auto-detects the type) orjava -jar winstone.jar --webroot=<webroot>, orjava -jar winstone.jar --warfile=<warfile>
--webappsDir switch, to which you pass a
directory that contains multiple warfiles/webroots.java -jar winstone.jar --webappsDir=<dir containing multiple webroots>
So, for example, if you had a directory /usr/local/webapps which contained sub-directories ROOT and test, if you executed
java -jar winstone.jar --webappsDir=/usr/local/webapps, you would
find that the test folder would act as a webroot for requests prefixed with /test, while
other requests would go to the webapp in the ROOT folderFrom v0.8, if you need multiple hosts (sometimes called name-based virtual hosting), there is a new option
--hostsDir. This acts in a similar way to the --webappsDir switch,
but it defines an extra level of sub-directories, the top being a per-host directory and the second a
per-webapp directory as with --webappsDir.The directory name becomes the host name: that is, a directory named "www.blah.com" will only serve requests with the host header www.blah.com, unless it is the default host. If a directory named "default" is found, it becomes the default host. If no default directory is found, the first directory in the list (alphabetically) becomes the default host.
java -jar winstone.jar --hostsDir=<dir containing multiple host directories>
Caveats
As a result of the design goals, there are some things Winstone doesn't do:- There are currently three connectors supplied with Winstone:
- An internal HTTP connector - allows plain HTTP/1.1 connections only
- An internal HTTPS connector - allows HTTP/1.1 connections over SSL
- An AJP13 connector - allows connection to Apache/IIS/iPlanet, etc
- HttpSession support is cookie-based only (no URL rewriting). URL rewriting introduces a lot of unnecessary complex request processing, and given that browser cookie support is common these days (and no-one I know actually uses URL rewriting), I plan not to implement this.
- The messages are all in English only. Resource bundles are used, but no translations yet.
Security Warning
If you enable the controlPort, be aware that there is no password protection at all on this port. Anyone who can get access to this port can stop or restart the server. I plan to add some simple authentication to this at some point, but I'll wait until someone asks for it.The controlPort is disabled by default. If you choose not to enable it, the only way to shut Winstone down is to kill the process (either by Ctrl-C or kill command).
from http://winstone.sourceforge.net/
------------------------------------------------
What is Winstone ?
Winstone is a servlet container that was written out of a desire to provide servlet functionality without the bloat that full J2EE compliance introduces.It is not intended to be a completely fully functional J2EE style servlet container (by this I mean supporting extraneous APIs unrelated to Servlets, such as JNDI, JavaMail, EJBs, etc) - this is left to Tomcat, Jetty, Resin, JRun, Weblogic et al.
Sometimes you want just a simple servlet container - without all the other junk - that just goes.
This is where Winstone is best suited.
You could find some documentation and support on this site: http://intelligents-ia.com/index.php/category/technique/Winstone )
The original goals in writing Winstone were:
- Supply fast, reliable servlet container functionality for a single webapp per server
- Keep the size of the core distribution jar as low as possible
- Keep configuration files to an absolute minimum, using command line options to optionally override sensible compiled in defaults.
- Optionally support JSP compilation using Apache's Jasper. (http://jakarta.apache.org)
Why is it called Winstone ?
The initial versions of Winstone were created by Rick Knowles (The homepage for this project is at 'http://winstone.sourceforge.net').He actually stopped developing and supporting Winstone, due to other projects. Since then, with his permission, we take the support of this "small" project that has titillate our neurons.
We hope that our little fingers instill enough magic in this project so that you are likely to use it.
from https://code.google.com/p/winstone/
---------------------------------------------------------
Introducing Winstone, an ultra-lightweight alternative to Tomcat and Jetty
Recently, my frustration with Tomcat and Jetty set me off Googling for possible alternatives. After some searching, I came across a relatively new open-source servlet engine called Winstone. I think this server may well be a great replacement for both Tomcat and Jetty, at the very least as a development tool. Before I delve in to more detail on Winstone, let me share a little background on Java servlet engines, and my particular issues with Tomcat and Jetty.1. Brief History of Java Servlet Engines
Websites built on Java technology require not just a web server, but also a servlet engine to invoke and run the Java code that renders the site’s front end (“servlets”). Java websites sometimes also require a full stack of services beyond basic page rendering (messaging, state management, resource directories, etc.), in which case a fully stacked application server is needed, but the core of all Java websites is the servlet engine. The early days of Java Web development in the late 90s and early 2000s was built on servlet engine offerings from large enterprise vendors like IBM, WebLogic and Sun (both now Oracle). However, in the last five years or so, an open-source alternative to these products emerged in the form of Apache Tomcat. Tomcat is now on version 7 and it’s fair to say it has been a massive success in terms of both developer mind share and large-scale enterprise deployments.2. The Problems with Tomcat
Tomcat’s strength lies in its maturity (road-tested by thousands of IT shops) and its simplicity. The Tomcat installation consists of a handful of XML configuration files, and a library of open-source code. It also has evolved over time to support the most common web development requirements such as Apache/IIS integration, HTTPS support, single sign-on, and clustering. However, Web development has evolved at a greater rate than Tomcat has, and the role of the servlet engine has been much reduced in Java Web code written today. Modern Web development not only relies more heavily on client-side scripting, but even on the back-end, servlets are often relegated to mere ‘controller’ roles—routing requests to HTML-templating engines (Freemarker, Velocity) or component-rendering engines (GWT, Wicket) rather than processing the requests themselves and rendering a response. The sum of this evolution is that the legacy lynchpin of Java Web development, the Java Server Page, has been marginalized, and as a consequence so has the role of the servlet engine. What Java Web developers require now is a servlet engine that acts a service within the application purely to process servlet request/response cycles and little else (much like a database service or a logging service within an application, each provides a single purpose). Increasingly, the servlet engine is no longer the all-encompassing runtime framework of Java-based websites. Ideally, it’s ‘just’ a cohesive and modular component of the application runtime. It’s singular, but essential, responsibility is to parse HTTP requests and route them to the appropriate sub-service.Put simply, what this means for Tomcat is that it’s starting to look like a pretty bloated stack. Developers no longer require a servlet engine that provides logging, naming/directory services, connection pooling, a security container, etc. In fact, they are now keen to embed the servlet engine in their own applications (directly, or via OSGI) just to provide a servlet handler. In this regard, Tomcat is overkill. It even weighs down development time with its large-memory footprint, both in terms of the JVM and the actual file system. Is there an alternative? Increasingly, judging from my own discussions with colleagues and discussions like this at stackoverflow.com, Java web developers have been turning to an open-source server called Jetty.
3. Jetty Has a Steep Learning Curve
Jetty is an elegantly designed servlet engine with a modular architecture that lends itself to both simple and sophisticated use cases. It also has a smaller footprint than Tomcat, and has a reputation for being faster at both page rendering and general server processing. Indeed, it definitely seems to bootstrap/redeploy much faster than Tomcat in my ad hoc testing (my current Tomcat development instance takes four seconds to bootstrap itself or redeploy a webapp, and this is with much redundant configuration removed). Jetty is also vastly easier to embed in your application than Tomcat, requiring about six lines of code, instead of the 15 or so needed to get Tomcat setup in your application as a singleton service. However, after a week or so of trying to use Jetty (v7) in a variety of use cases, I felt I spent a lot of time chasing my tail. Here are my main gripes with Jetty:- Poor documentation, often missing or incomplete.
- Confusing product ownership, with the original developers Mortbay passing it over to the Eclipse organization between releases 6 and 7. A lot of features and functionality straddle these two releases and its can be very confusing to figure out which to use.
- The modular, expandable nature of Jetty means that its a composite of many library files and many XML configuration files. This is architecturally elegant, but makes basic configuration points difficult to track down
4. Introducing Winstone
Winstone is at version 0.9, and available here. It has simple but complete documentation at that site, and the whole server is contained in just one small JAR file download with a shallow dependency graph. Compare this with the multitude of JAR files required to run Tomcat and/or Jetty, even in simple embedded mode. It gets better; to run your Java web application(s) with Winstone, you simply invoke the Winstone JAR file from the command line, passing in the location of your webapp(s) exploded directory or JAR file as a parameter. Here is an example: java -jar winstone.jar --webroot [your-exploded-war-base-directory-or-war-file-location]Following convention, Winstone will run at port 8080 by default (you can override this by passing in your preferred port number as a run-time variable). In line with the current vogue to bypass JSP development altogether, Winstone ships with JSP support disabled, but this (and a myriad other settings you might want to use) can be toggled by using a simple local key-value pair properties file. This is all clearly documented at the project site. Additionally, if you’re a Maven user, you can simply include Winstone in your project using this pom declaration:
<dependency>
<groupId>net.sourceforge.winstone</groupId>
<artifactId>winstone</artifactId>
<version>0.9.10</version>
</dependency>
My favorite feature of Winstone is the ease at which it can be embedded in to your application. You may want to do this to give your application a web server front end and/or servlet engine, or embed a server in your test scripts. Either way, you can do this in just four lines of code:
Map config = new HashMap();
config.put(“webroot”, “webapps/my-killer-app/”);
Launcher.initLogger(config);
Launcher winstone = new Launcher(config);
I have yet to test Winstone in a production setting, or anything other than my development laptop, but I am sold on it as a development tool at the very least. In addition to the base settings it ships with, it has these keys capabilities, which suggest it will fit a wide range of needs beyond pure servlet compilation:
- HTTPS support
- JAAS support
- Apache/JK support
- Cluster support
- Hot-redeploy of servlet classes
- JNDI support
- HTTP control ports provided for starting/stopping the server remotely
I am keen to see how Winstone performs as I expand my use of it, and I look forward to benchmarking its performance on a production-grade machine. For now, I am very happy to have found such a lightweight and user-friendly servlet engine for my development needs. I am also eager to hear from developers who have or want to use Winstone in their projects, so please feel free to comment on this post.
from http://www.netwhisperer.com/2011/07/18/introducing-winstone-an-ultra-lightweight-alternative-to-tomcat-and-jetty/
