Tiny Java Web Server and Servlet Container

aka Miniature JWS

European quality software made in USA

(with security update, J2EE deployment, JSP,  and  J2EE without application server)

If a solution seems to be too complicated,
then it means that a simpler alternative was overlooked.

Download
  1. Introduction
  2. Features
  3. History
  4. Competitors
  5. Design
  6. Configuration
  7. J2EE deployment
  8. App server services (JNDI, DataSource)
  9. Embedded usage
  10. Embeddable application
  11. Mobile and appliance usage
  12. Virtual hosting configuration
  13. Proxied usage
  14. Download
  15. Build
  16. Applications
  17. VM
  18. Support
  19. Versions
  20. Copyright
  21. Contact

Introduction

The Miniature Java Web Server includes most of functionality of real Web Servers including a servlet container capability. The server is pretty small as in Java code as in result byte code. General purpose of the Web server is running and debugging servlets. However, it can be used as a regular web server for sites with low to medium load. I found also very convenient shipping a servlet based product including this server, so a user can start a product just after unwrapping. You can try a web site hosted on this server under Linux. This web server also works on PDA like Sharp Zaurus LS5xxx, or on Windows CE based handhelds when JVM installed. It gives additional flexibility for your PDA, since using file upload and download servlet can simplify file synchronization and provide control of your PDA from web.

Testimonies

Using tjws with WebServices as a "RMI"/RPC protocol, and with HTTPS on
top, this is gold! Thanks!

I've downloaded TJWS and it looks like exactly what I’ve been looking for to use as a local web server to generate a web application.

I'm using the miniature java webserver on
my zaurus.
I wrote a few servlets for it and I'm very happy with how it performs.

TJWS was the only thing out there I found I could use as a library, programmatically within unit tests. Thanks for a great library.

Features and Benefits

  • About 95Kb footprint (TJWS is the smallest one, like 5 times less in comparison to competitors LWS and Jetty, more than twice less than Winstone)
  • Very fast and reliable, it performs better than some C/C++ based web servers, 10% faster than Apache 2.x 
  • Can scale to thousands connections, clustering configuration is about of development
  • Perfect solution for web interfaced applications
  • Standard J2EE servlet deployment for .war packaged applications
  • Simple configuration, no hundreds of config parameters
  • Flexible JSP support
  • Limited JSDK 2.5 support
  • built for Java 6 with intelligent downgraded support for Java 2

History

I was looking for a web server with sources to debug some servlets at the end of 1998. One of my findings was ACME Java Web Server. It was pretty good, but supported only JSDK 1.x and JDK 1.02. Since my servlets required a bit more, I have added support for contemporary versions of JDK and JSDK. I just continued adding more features and providing bug fixes after. The current version is mostly compatible with the latest servlet container  specification (2.5). 

Competitors

Main competitors for TJWS are Winstone, LWS, and Jetty. TJWS can successfully compete with more established and reputable servers as Tomcat. Main benefits of TJWS are simplicity and size.

Design

Modular design used for TJWS. It gives flexibility of creation different configurations with exactly required features. A heart of TJWS is light weight servlet container. A set of predefined servlets extends functionality of the container transferred it to a web server or/and application server. Predefined servlets can be eliminated or redefined for more flexibility.

Selecting or not J2EE deployment gives an extra flexibility in a final size of a deployed application. Like for an embeddable or a mobile application is possible to use Java Personal Profile 1.x compatible  servlet container module. For less critical in size deployment is possible to use J2EE deployment module and JSP module. Note that  a standard JSP support is provided by GNU JSP 0.9. This version is very old and restrictive. So for contemporary JSP specification is possible to use GNU JSP 1.0 or Jasper.. Base module, JSP, and J2EE deployment modules have sizes 95K, 20K, and 59K correspondingly. More advanced version of GNU JSP 1.0 provider has size 67K, and  Jasper's size is about 580K. App server services module adds 42kb.

Configuration

Most of server configuration is based on command line arguments. The arguments can be processed from a file as well. Additional configuration values can be provided over files. J2EE deployed application are configured based on standard web.xml deployment descriptor.

Command line parameters

All command line parameters start with '-' (dash) and most of them have a value part. Here they are:

p specifies port number served by TJWS, default value is 80 for non secure and 443 for secure configuration, for example -p 8080
t specifies name of throttles definition file. It allows to reduce speed accessing to particular files and improve overall performance of a server. An example of this file can look like:

# throttle file for tjws.sourceforge.net
*               100000  # limit total web usage to 2/3 of our T1
*.jpg|*.gif     50000   # limit images to 1/3 of our T1
*.mpg           20000   # and movies to even less
mediachest/*    20000   # MediaChest's pages are too popular
s specifies servlet properties file in old Sun's legacy form. An example of this file can look like:
servlet./app-bin/tree.code=rogatkin.servlet.Dispatcher
servlet./app-bin/tree.initArgs=properties=src\javaarchitect\servlet\treeview.properties
servlet./app-bin/chat.code=rogatkin.chatservlet.ChatServlet
servlet./app-bin/chat.initArgs=properties=C:\\Projects\\ChatServlet\\chatservlet.properties
servlet./app-bin/lunch.code=javaarchitect.servlet.mishka.Friday
servlet./app-bin/lunch.initArgs=properties=src\javaarchitect\servlet\mishka.properties
r specifies realm file. A format of this file looks like:
realmname=path,user:password
a specifies aliases definition file. Every line of the file specifies one alias entry starting from keyword from=webpath;dir=directory_in_filesysten_to_map, for example:
from=/;dir=src\javaarchitect\servlet\tree\resource
from=/pool;dir=data
b bind address, if your machine has several IP addresses, then you can specify which one to use
k backlog size, by default 50, but can't be less than 2
nohup server doesn't expect any terminal window, can be only killed to stop
c specifies web path of CGI scripts directory
e provides session timeout in minutes and can be negative. Negative value won't start session cleaning thread and will use a persistent session cookie
m limits max number of active sessions by a specified value, can't be less than 10. Default value is no limitation
l[ar][f format_string] specifies to log accesses with optionally logged user-agent and referer HTTP headers. When f modifier specified a format string has to follow which is a valid format string for java.text.MessageFormat class. Positions of parameters are:
  1. IP
  2. RFC 1413 identity
  3. Remote user
  4. Timestamp
  5. Request method
  6. Request Resource
  7. Request Protocol
  8. Result code
  9. Bytes transferred to client
  10. Local port
  11. Referer (if requested)
  12. User agent (if requested)
w provides web app deployer class name, by default used rogatkin.web.WarRoller
j JSP servlet class, org.gjt.jsp.JSPServlet is default; extra init parameters can be specified for JSP servlet; syntax of parameters is -class_name_perfix.param_name param_value; note that value can contain variables like %context% and %deploydir% substituted by actual values respectfully. Another substitution happens for %classloader% by a name of a servlet context attribute keeping an instance of a class loader used for a web application deployment (available from version 1.15). Version 1.22 and above introduced another variable %classpath% which substituted by class path used for loading servlet
nka no keep alive (server uses keep-alive by default)
kat keep alive timeout interval in seconds, default is 30
mka max number of a connection use in keep-alive
sp persistence for sessions, TJWS is capable storing sessions data in a portable format and reload them between restarts or nodes of a cluster. Do not use this option if sessions contain sensitive, not serializable, or bulky data
err allows to use own or standard error print stream. If there is no following parameter class name then used System.err as error print stream. If a parameter specified, then it's considered as a class name compatible for assignment to PrintStream. Such class will be instantiated and used for error redirection
out allows to define own class which will handle log needs. This class has to be assignment compatible with PrintStream. An attempt of instantiation of the class with default constructor happens at TJWS startup, so the class has to be available in startup class path. This class will handle err stream too unless -err option is specified. TJWS includes class Acme.Utils$DummyPrintStream for disabling any log printing. (since 1.26)
d Log file directory for default logging, System.getProperty("user.dir") is used by default (since 1.30)
z defines max number of created threads in a thread pool used for servicing requests. 20 used when the parameter not defined. 0 or negative - do not use thread pool
socketFactory specifies class name of socket factory and used for setting a secure connection. (deprecated since 1.30)

It accepts also any freely specified options in form -option_name option_value. Such options passed without checking to a custom server socket factory implementation and other modules of the server

acceptorImpl specifies a class name of a concerete Acceptor implementation. Default is Acme.Serve.SimpleAcceptor (since 1.31). See note above about processing additional connection parameters. Since 1.30
dataSource specifies a data source properties file location. Supported by rogatkin.app.Main run module. Since 1.30
This option is valid only for app server runner (class rogatkin.app.Main)
A property file can contain the following properties:
  • jndi-name (required) - under this name the data source will be registered in JNDI if name starts with jdbc, then prefix java:comp/env/ will be added when registered in JNDI.
  • driver-class - class name of JDBC driver
  • url - JDBC connection URL
  • user - connection user
  • password - connection password
  • pool-size - max number of allocated connections, 0 = no size limitation, -1 = no pool used
  • access-timeout - timeout in ms before getting an exception on connection request when no connections are available, 0 means wait forever
  • driver-class-path - defines class path to a driver archive and/or a connection validator class, unless they are already defined  in a boot classpath
  • prob-query - a query to run against a given connection to verify a validity, There are two predefined values IsValid and isClosed used for calling corresponding methods of  JDBC  connection  instead of a query. Note that  isValid() method is available in JDBC 3.
  • exception-handler- a class with static public boolean method validate and two parameters of type SQLException, and Connection returning false when the connection has to be discarded after the SQLException

TJWS processes several Java System level definitions in addition to command line arguments specified as JVM's -D arguments:

tjws.serve.log.encoding - this definition specifies encoding used for log messages, it can be very convenient to debug multi lingual web applications.

tjws.proxy.ssl - this definition specifies that server should process X-Forwarded-xxxx headers for calculation remote and server addresses. If value of the property 'y', then SSL is considered to be handled by proxy server. (Since 1.71)

java.protocol.handler.pkgs - this definition is used by SSL socket factories implementations to define a different protocol handler packages, than standard com.sun.net.ssl.internal.www.protocol

The following definitions are used by J2EE servlet/deployer module:

tjws.webappdir - specifies path to web application war files location for automatic deployment. By default TJWS_ROOT/webapps directory is used.

tjws.wardeploy.warname-as-context - see details below.

tjws.wardeploy.as-root[.virtual_host_name] - defines context name/war name used for deploying in root, e.g. -Dtjws.wardeploy.as-root=<app_context/war_name> If virtual host name part is presented, then it defines a fully qualified host name for which the root context is set. (Since 1.71)

tjws.virtual - defines deployment of web applications in virtual hosting environment.

When the definition is specified, TJWS J2EE web applications deployer looks in all subdirectories under automatic web application deployment directory and considers directory name as virtual host name and directory content as automatic web application deployment directory for corresponding virtual host.

For example:

           TJWS_ROOT/webapps
               www.doopper.com
                   doopper.war
                   webfolder.war
               www.7bee.org
                   sqlfair.war
                   webchat.war
               xumster.war
               jaddressbook.war


(Since 1.71)

class_name.debug - this definition is passed to JSP provider for allowing debug specified class name.

tjws.fileservlet.usecompression - this definition advises to compress text content response when a client can accept it. To make this suggestion per application, use tjws.webapp.<context_name>.compressresponse Since 1.31

tjws.wardeploy.dynamically - this definition advises J2EE deployer for monitoring .war files updates and redeploy corresponding applications without the server restart. Optional value of this definition specifies time interval in seconds between checkings. Since 1.50

tjws.webapp.context name.init.timeouts - specifies init timeout in seconds of corresponding web application by context name, use * if you need to define it for all contexts

tjws.webapp.debug - value yes turns on additional debug print outs for J2EE deployed apps

tjws.app.orb.arguments - this definition can provide comma separated parameters used for ORB initialization. Since 1.50

tjws.app.main - name of main class started with offering app server services. TJWS supports not only web applications, any desktop Java application can get benefist of app server services as JNDI and container managed JDBC connections. Since 1.50

tjws.app.main.classpath - class path for main application class specified as definition tjws.app.main, unless the main class can be resolved from boot class path. Since 1.50

tjws.app.main.striprightparam - specifies a position in command line arguments which have to be not passed to a main class defined in tjws.app.main. It gives flexibility of separate command line arguments used by launched application and app server services itself. Since 1.50

tjws.app.main.stripleftparam specifies a position to cut from left. See description of tjws.app.main.striprightparam. Since 1.50

Since TJWS has a long history it supports as a legacy way of deployment and configuration of servlets as a new .war based. The legacy deployment   uses property files, like servlets.properties and aliases.properties. J2EE way is based on .war and config.xml files. When a legacy way used, the server can keep a minimal configuration and run on JDK version started from 1.2 (Actually the current version has 9 JDK 1.4 dependencies which can be easily corrected if JDK 1.2 is a real requirement).

Security

Security becomes more important nowadays, so I decided to add SSL support to TJWS. Thanks JSSE for making that fairly easy. Here some tips how to install SSL support to the server.

There are two SSL supporting socket factories packaged with TJWS - Acme.Serve.SSLServerSocketFactory and rogatkin.web.DoubleHeadSocketFactory (available from v 1.17). First is recommended to use with core TJWS, when second with J2EE deployment module since it provides supporting http and https at the same time and requires Java 5. 7Bee script contains examples of usage both factories. To use first one type bee -Dsecure=true and for second bee -Ddoublehead=true. Additional command line parameters can be specified with each factory like :

  1. algorithm - encryption algorithm, SUNX509 when not specified
  2. clientAuth - requires client authorization, false when not specified
  3. keystoreFile - key store file path, user_home/.keystore by default
  4. keystorePass - key store password, empty string when not specified
  5. keystoreType - type of key store, Sun's JKS when not specified
  6. protocol - secure protocol, TLS when not specified
  7. backlog - backlog value, 1000 by default
  8. ifAddress - bind to specified address
  9. port - bind to specified port
  10. ssl-port  SSL port (only for DoubleHeadSocketFactory and rogatkin.web.DualSocketAcceptor )
  11. ssl-backlog backlog size (only for DoubleHeadSocketFactory and rogatkin.web.DualSocketAcceptor)

Note that some secure socket options will override options specified in a regular way.

You may also adding your own socket factory implementations. See the packaged socket factories as a reference implementation.

Starting from 1.30 Socket Factory concept was replaced by Acceptor. It allowed to use Selector based processing requests with 10% improved performance. Four concrete Acceptor implementations are available:

The author appreciates if you can share own implementations of Acceptor.

J2EE deployment

For J2EE deployment you need to make sure that war.jar is specified in classpath when you start the server. It will create webapps directory (configured location) where you can put your .war files for auto deployment. Deployment gets updated at startup absorbing any changes from source .war file, however all changes done in target deployment directory are preserved. TJWS can monitor also source .war changes during runtime when tjws.wardeploy.dynamically is specified, and redeploy application if changes were detected. server.xml isn't supported and most of server specific parameters have to be specified as command line arguments, or stored in a flat file as cmdparams. All examples of startup scripts are presented in directory bin of a distributive archive. Most of examples contain both ways of server configuration and application deployment. Note that deployment descriptor (web.xml) parameter display-name defines a context path of a deployed web application. If you want to have context path matching to .war name then add system property tjws.wardeploy.warname-as-context set to yes. For command line it will look like -Dtjws.wardeploy.warname-as-context=yes . (Since 1.24) To prevent application update at startup time you need to remove corresponding .war from deployment directory. It gives also a way to deploy web applications without .war just manually create web app directory structure. Check section 'Embeddable application' for more options of deployment and distribution of applications.

Supported web.xml deployment tags are:

App server services

TJWS includes app server services module. It takes some usable shape from version 1.50. There are two services offered:

For using these services app.jar has to be in class path, or/and used for starting the server. The bin directory includes an example of starting TJWS with app server services on. Data sources get configured from properties files specified as –dataSource command line option. JNDI properties as context factory and JNDI URL get pre-populated as rogatkin.app.SimpleJndi and http://localhost:1021 correspondingly, unless they are defined as system properties. JNDI is capable to register local and CORBA objects. First running JNDI takes care of JNDI master repository, and all following JNDI starts will be registered in the master repository. If the master repository's gone, then all clients won’t be capable to register own CORBA objects or access them, until the repository is back. There is no persistence for stored references, so you should do a defended programming and reregister references in case of crashing the master repository.

2.5 Deployment descriptor

Multiple URL patterns can be defined anywhere. Some other features are under consideration. Work on processing annotations in a servlet code started.

Jasper JSP provider integration

You can use Jasper JSP provider for servicing JSP pages inside an application. Since the original Jasper is a bit bulky for TJWS taste, it's recommended to strip it to a manageable size.  TJWS distribution includes instructions about modifying, build, and connection of Jasper in file jasper.html of webroot directory Both Jasper 5.x and 6.x (since 1.28) are supported.

Running it as a service on all Windows platforms

You can run the server of the version (>1.42/1.7) as Windows service. File servservice.exe added to the distribution. I wrote this service for JDK 1.4. It works without a change for Java 5 and 6. C source code of service implementation is included. A service starter considers that all TJWS files reside in the same directory specified at installation of the service. .jar files can be in sub directory lib. Command line parameters have to be specified in cmdparams file. Use -nohup switch to avoid a console read attempt. To get help line, run servservice.exe -help. Parameterless version of servservice.exe is considered as a service.

Note that arg[0] which supposes to give a fully qualified name of a service executable on some versions Windows ((like XP) doesn't do that. For this reason you have to specify a fully qualified path as the last parameter of an installation command. There is no requirements to have servservice.exe in the same directory where TJWS is. Here is an example of an installation command:
servservice.exe -install "C:\Project Files\tjws" "C:\Project Files\gnujsp\lib\jspengine.jar" TinyJavaWebServer TinyJavaWebServer "C:\Project Files\tjws\servservice\Debug\servservice.exe" -Dtjws.wardeploy.warname-as-context=yes

Embeddable application

Recently, a new type of application appeared on the market. After starting an application is launching a browser which represents its UI. This approach has many advantages and becomes more popular and wider used. The Miniature Java Web Server is a right tool for creation such kind of application. Download and double click JAR in Explorer or launch it from a terminal typing java -jar finesearch.jar, then point browser to http://localhost:8080/finesearch and enjoy the web interfaced application. Starting from version 1.21 TJWS includes a launcher of a .war packaged application from command line or a start script. The feature is very similar to used by Winstone.  Use:
java -jar webapplauncher.jar war_file_name [optional standard TJWS CLI parameters]
for example:
java -jar webapplauncher.jar "C:\Project Files\finesearch\finesearch_app\finesearch.war"
Note if extra command line arguments are not specified, then TJWS will try to discover them from cmdparams located in a working directory.
Version 1.22 and above makes launching Web UI application even more simpler. Web application .war can be packaged inside of TJWS .jar file allowing one click launch. To package web application .war with TJWS use target 'embedded' of 7Bee build tool and answer on few simple questions. For example:

C:\Project Files\tjws>bee embedded
Launcher's been built.
Enter command line arguments for app [-nohup -p 80]? -p 80
Enter application .war file location? C:\Project Files\finesearch\finesearch_app\finesearch.war
As result finesearch.jar is created in lib directory which is launchable using java -jar finesearch.jar
When JDK 6 is used you can get it running in system tray, use javaw for JAR launching.

System tray menu will contain an item for going directly to an application with web UI (since 1.24).
Use 7Bee target asembedded, when web application needs container provided JNDI and data sources. (since 1.50).
J2EE without application server

TJWS gives a good possibility to create enterprise class J2EE applications without an expensive and heavy weight application server. Aldan 3 library will take care of SOA registry, MVC servlet framework with template based presentation layer, data persistence and much more. Check out a demo of a real application based on this approach.

Embedded usage

TJWS can be successfully used as a part of another Java application.  Acme.Serve.Serve can be instantiated as a Java bean with following setting parameters in its public member arguments and log print stream in its public member logStream. Use method  addServlet(..) for adding servlets. Note that server will do nothing without servlets. Default file and cgi servlets can be added calling addDefaultServlets(...). Server can be started calling method serve() and stopped calling notifyStop(). Note that serve() doesn't exit until a server runs, so stopping  should be called from a separate thread, or serve() is ran in a separate thread.
A minimal application with embedded TJWS looks like:

public class Test {
	public static void main(String... args) {
		class MyServ extends Acme.Serve.Serve {
			// Overriding method for public access
                        public void setMappingTable(PathTreeDictionary mappingtable) { 
                              super.setMappingTable(mappingtable);
                        }
                        // add the method below when .war deployment is needed
                        public void addWarDeployer(String deployerFactory, String throttles) {
                              super.addWarDeployer(deployerFactory, throttles);
                        }
                };

		final MyServ srv = new MyServ();
 		// setting aliases, for an optional file servlet
                Acme.Serve.Serve.PathTreeDictionary aliases = new Acme.Serve.Serve.PathTreeDictionary();
                aliases.put("/", new java.io.File("C:\\temp"));
		//  note cast name will depend on the class name, since it is anonymous class
                srv.setMappingTable(aliases);
		// setting properties for the server, and exchangable Acceptors
		java.util.Properties properties = new java.util.Properties();
		properties.put("port", 80);
		properties.setProperty(Acme.Serve.Serve.ARG_NOHUP, "nohup");
		srv.arguments = properties;
		srv.addDefaultServlets(null); // optional file servlet
		srv.addServlet("/myservlet", new MyServlet()); // optional
		Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
			public void run() {
				try {
					srv.notifyStop();
				}catch(java.io.IOException ioe) {
					
				}
				srv.destroyAllServlets();
			}
		}));
		srv.serve();
	}
}
 

The File servlet without aliases definitions maps your file system directly to a web accessable one, so setting up aliases is recommended.

J2EE servlet deployment is possible in an embedded usage. You need to assure that JDK 1.5 or above is used and war.jar is in a class path of an application.
Add a line as below:

      ((Test$1)srv).addWarDeployer(null, null);

The default war deployer will look in directory "user.dir/webapss" and deploy all wars there. You can redefine a deploy repository by setting

System.setProperty("tjws.webappdir", newDeployDirectory);

prior of calling addWarDeployer()

Mobile and appliance usage

TJWS provenly runs on such PDA as Sharp Zaurus and Windows CE/Mobile devices as Dell Axim. Note that these PDAs run completely on different platfroms.
Run it on Zaurus

Zaurus version of the web server is JDK 1.1 compatible and distributed in a separate archive. Unzip distributive to CF card. Directory ws should be created. Insert the card to Zaurus and run terminal window. Type cd /mnt/cf/ws, then ./ws.sh. After few second you can see message on screen that the server is running on port 8080. Run opera and select URL http://localhost:8080. You should see a web page. Select URL http://localhost:8080/app/, then you should be able to browse your Zaurus file system. When your Zaurus connected to host PC over USB cradle or Wi-Fi card, you should be able to access this server remotely from PC browser using your Zaurus IP address. Mark this page for upcoming cool servlets. You can also try .ipk installation package, however it isn't tested well and no way to stop it unless using kill. You can try also the not Zaurus adopted version of the server on Zaurus, since Zaurus' Java has support of collection classes introduced in JDK 1.2. More information about Zaurus run is here.

Run it on WindowsCE based PDA

A base TJWS runs perfectly on PDAs under IBM's J9 VM. Make sure that you installed Personal Profile 1.1 VM to your PDA following IBM's instruction. In this case you can run TJWS out of the box, just copying webserver.jar and servlet.jat to your PDA. Use tjws.lnk for starting a server. You may need to edit it first to accommodate with J9 installation and location of .jar files. Note that J2EE deployment requires Java 5, when Personal Profile 1.1 is JDK 1.4.2 compatible. So J2EE deployment can't be used with J9 and you can exclude war.jar from copying to PDA. You should edit manually servlet.properties and classpath to deploy servlets. I recommend to use command line option -Xoptionsfile of J9 to place class path in a separate file, otherwise you can have difficulties to start VM properly with long names in class path. I do not recommend to use ex Jeode VM with the latest TJWS, since Jeode is Personal Profile 1.0 compatible.

Use TJWS as proxied

TJWS can be used with proxy servers. Definition tjws.proxy.ssl can be specified to correctly determinate remote host and access protocol.

To use Apache as a proxy server you can:

  1. make sure that mod_proxy enabled in httpd.conf
  2. add below directives in httpd.conf
       ProxyRequests On
       ProxyVia On
       ProxyPass /context_path/ http://tjws_host:/web_app_context/
       ProxyPassReverse /context_path/ http://tjws_host:/web_app_context/
    # for pushing authentication
       RewriteEngine on
       RewriteBase /
    
       RewriteCond %{REMOTE_USER} !=""
       RewriteRule .* - [E=E_USER:%{REMOTE_USER}]
    
       RequestHeader set my_new_header %{E_USER}e
    

Run it on iPhone?

There is a possibility to run it on iPhone. Currently iPhone runs Free BSD, so you can cross compile any open source Java VM and port in to iPhone. Now you can run TJWS there. Use any web application after, for example Apache Slide will give you access to iTunesDB, so you can update your music using WiFi.

Download

Please download (version 1.71)

Nightly build of 1.80 can be downloaded from here. (Last updated on Mar 7th, 10)

Jasper.jar with fixed EL resources.

Note: Base TJWS is Java 2 (JDK 1.2) compatible, SSL module requires extra classes introduced in JDK 1.3-1.4. J2EE war deployment requires Java 5 (JDK 1.5 or 1.6). If you would like to build a version, then you will need to download 7Bee Java based build tool. The env.xml assumes target 1.4 for TJWS and 1.6 for the rest. It may need being edited to provide SDK paths and targets. Modify variable 'j2ee target version' in env.xml to 1.5 to avoid using System tray feature of JDK 1.6. Since a build tool is a matter of personal taste, you can use any other favorite build tools.

Attention POSIX system users,  the distributive archive has access attribute not set, so execute chmod -R +rwx WebServer after unpackaging WebServer-nnn.zip

Zaurus version get here and .ipk version (use kill to stop)

Last changes history

Tested web applications

I use TJWS primary for my business, however I verified functionality of some popular web applications. Here is the list:

  1. Apache Slide (WebDav)
  2. jCVSWeb/jCVSServlet 1.41/1.01 (CVS web front-end)
  3. Pebble 2.2 (Blogger solution)
  4. DaveNPort 0.9.10 (Simba web front-end)
  5. Apache Axis2 1.0
  6. JASIG - single sign on service
  7. SimpleCaptcha
  8. Quercus™ (PHP engine)
  9. Apache Myfaces
  10. MetricStream ECP
  11. Google Web Toolkit (GWT)
  12. Stripes (JSP framework)
  13. Red5 (Streaming media server)
  14. OIOSAML.java SAML SSO servlet filter

Build Tool

TJWS is proudly built using most sophisticated Java build tool 7Bee. You can freely download 7Bee from here. If you hate sophistication with simplification, then you are free to use any available build tool for your platform. To build TJWS you will need to provide correct values for the following variables in env.xml:

  1. SERVLET_LIB - fully qualified path to servlet.jar or other lib/directory containing JSS classes
  2. SERVLET_SRC - fully qualified path to sources of JSS classes, used only for packaging text resources in launcher packaging and can be omitted, unless launcher has to be built
  3. SERVLET_BUILD - fully qualified path to binaries of classes of JSS, used only for packaging JSS in launcher packaging and can be omitted, unless launcher with JSP has to be built
  4. JSP_LIB - fully qualified path to jsp.jar or other lib/directory containing JSP API classes
Note: environment variables for versions prior 1.28 are slightly different.

JVMs

TJWS was tested with most popular JVMs under Windows, Linux, and Solaris platforms and also on mobile platforms as Sharp Zaurus and Windows CE.  Sun, IBM J9, BEA JRocket, and GNU VMs are capable to run TJWS.

Copyrights

The Miniature Java Web Server carries all copyrights of the original author as stated in the license you can find in any source file.

License

The Tiny Java Web Server inherited BSD like license from the original code, check any source file for details.

Support

I provide support of the server on voluntary basis. However server is so simple and stable that requirements in supporting shouldn't ever happen. Since we are still humans, you are always welcome to send a bug report, or an enhancement request. I also provide consulting service related to creating web 2.0 J2EE applications.

Discussion forum

Feel free also to share your concerns, questions, and discoveries in the Discussion forum.

Extra Bonus

Version of 1.07 and later includes some useful web applications packaged as .war files and deployed at first server run. To enjoy the applications just follow a link on a start page. If you do not want to have these applications deployed, just remove corresponding .war files from webapps directory before first server run.

Help wanted

I'm looking for developers to finish work on pending web.xml instructions and also adding tag library support. Another plan is adding SOAP/RPC support for easy SOA. SSI servlet is also waiting to be developed. There is no plan for EJB though.

Check also...

MediaChest Comprehensive tools to handle all media files as digital photos and  music

xBox - Bean box supporting XML serialization (do not confuse with proposed later java.beans.Encoder)

jAddressBook is an address book with a float XML format of addresses and another profile information, web 2 UI.

Refine your search result - a smart filter helping to narrow multi thousand result produced by popular search engines

Contact

Bugs, questions, and enhancement requests you can send to Dmitriy Rogatkin. I hope you enjoy using this server.