Grizzly Deployer (1.9.19) new features
It has been a while since a blog about Grizzly, I was too busy adding new features. The Grizzly Deployer's community grows and requested theses new features.
Here a quick list of the changes :
- Websockets support
- Watch folder
- Can starts without applications to deploy
- Can be embedded and extended easily
- and few bug fixes (thanks to the community)
A little overview or remainder of what is Grizzly Deployer
Grizzly Deployer is a bundle of Grizzly project that act as a web container. It will allow you to deploy applications (war, servlet).
Works fine for Comet, Atmosphere, JSP applications ... For more details, I suggest this link Introduction to the first release of Grizzly Deployer
First, lets take a look at the command line parameters.
Usage: com.sun.grizzly.http.servlet.deployer.GrizzlyWebServerDeployer -a, --application=[path] Application(s) path(s). Application(s) deployed can be : Servlet(s), war(s) and expanded war folder(s). To deploy multiple applications use File.pathSeparator Example : -a /app.war:/servlet/web.xml:/warfolder/ -p, --port=[port] Runs Servlet on the specified port. Default: 8080 -c, --context=[context] Force the context for a servlet. Only valid for servlet deployed using -a [path]/[filename].xml --dontstart=[true/false] Won't start the server. You will need to call the start method. Useful for Unit testing. Default : false --libraryPath=[path] Add a libraries folder to the classpath. You can append multiple folders using File.pathSeparator Example : --libraryPath=/libs:/common_libs --autodeploy=[path] AutoDeploy to each applications. You could add JSP support. Just add a web.xml that contains Jasper Example : --autodeploy=/autodeploy --webdefault=[path] webdefault to be used by all applications, can be file or dir with multipe web.xmls. If you want to add only one webdefault point it to web.xml file, If you want multiple files to be included put them in one dir and provide this location here. Example : --webdefault=webdefault.xml --cometEnabled=[true/false] Starts the AsyncFilter for Comet. You need to active this for comet applications. Default : false --websocketsEnabled=[true/false] Starts the AsyncFilter for Websockets. You need to active this for websockets applications. Default : false --forceWar=[true/false] Force war's deployment over a expanded folder. Will deploy the war instead of the folder. Default : false --ajpEnabled=[true/false] Enable mod_jk. Default : false --watchInterval=[seconds] Watch interval to scan for new applications to deploy in work folder. Default : -1 ; disabled --watchFolder=[path] Folder to scan for new applications to deploy in work folder Default : none
The first feature added was Websockets support. It can be enabled at command line by using the parameter --websocketEnabled=true . That will allow you to deploy Websocket applications.
This feature is interesting, because most of the web container have it. Grizzly Deployer will watch a specific folder to applications to deploy. When this feature was added, I remove the need to specify a application to deploy by command line.
To enable this feature you need to use the command line parameter --watchFolder=[path]. It can be used with this other parameter : --watchInterval=[seconds].
The parameter --watchInterval is used to create a watchdog that will monitor the watch folder. If the parameter --watchInterval is not present, when Grizzly Deployer starts, it will check
all applications that are in the watch folder at launch time and will deploy them, but it won't monitor the folder after that.
When both of theses parameters are used, it will create a watchdog that will deploy and undeploy application put in the watch folder, and remove from that folder. If you deploy an application at command line and put another application with the
same context name in the watch folder, the application in the watch folder won't be deploy twice.
Embedded Grizzly Deployer
Grizzly Deployer could already be embedded trough his API, but we got few feedback about to make it simplier. The problem wasn't the API, it just that most people will only use the main part of Grizzly Deployer : deploy a war.
So to make it easier and faster to implement, I did a little refactoring. We now have 2 main config classes we could use to launch an Embedded Grizzly Deployer : DeployerServerConfiguration and DeployableConfiguration.
That file is used to launch Grizzly Deployer. It contains the same command line parameters. In fact, at runtime, the command line parser use that classe.
GrizzlyWebServerDeployer deployer = new GrizzlyWebServerDeployer(); DeployerServerConfiguration conf = new DeployerServerConfiguration(); conf.cometEnabled = true; conf.watchFolder="C:/temp/webapps/"; conf.watchInterval=15; deployer.launch(conf);
Once grizzly Deployer is launched in your application, you can deploy a war later. For that, you use this class : DeployableConfiguration.
DeployableConfiguration warConfig = new DeployableConfiguration(); warConfig.location = "C:/temp/webapps/grizzly-jmaki.war"; deployer.deployApplication(warConfig);
You can follow me on Twitter.