Skip navigation
All Places > Ignite Realtime Blog > Author: Ryan Graham

Ignite Realtime Blog

2 Posts authored by: Ryan Graham Champion

I'm excited to announce that my first article on Wildfire plugin development has been published. What originally started off as a blog post grew into something much larger (and longer), so at Matt's urging the content was reworked and a space for it on the Ignite Realtime site was carved out.


The article walks the reader throught the development of a "Message of the Day" plugin that will send users a greeting each time they sign-in to Wildfire. Over the course of the article a number of plugin specific API's are examined along with other, core Wildfire API's. The completed plugin is fully functional but leaves room for a number of additional features.


As always, any and all feedback is welcome.


See you on the forums,



One of the great things about using open source software is that if you want to alter the way an application works or add a feature you can jump right into the code and make all the changes you want. A down side to all this freedom is that if you make a change to the source and then awhile later a new version of the software comes out, you have to merge your changes in with the new version. Depending on the sort of changes you've made, this can be a real nightmare. One increasingly popular way to avoid this sort of hassle is by using plugins. What is a plugin? Wikipedia provides a pretty good description: "A plugin (or plug-in) is a computer program that interacts with a main (or host) application to provide a certain, usually very specific, function on-demand." Some programs that you might have heard of or be familiar with that use plugins are Elipse, Firefox and of course Wildfire and Spark.


This is the first in a series of articles that will explore what can be accomplished with the use of plugins for both Wildfire and Spark. Initially, I'll focus on Wildfire plugins, beginning with a couple of pointers to get the plugin development environment setup. Then over the course of the following articles, I'll discuss some of the more commonly used API's, develop a plugin or two and maybe even get a Spark plugin to talk to a Wildfire plugin.


Now, let's get started!


Download the Wildfire source


This one may seem like a no-brainer to some, but it's not entirely obvious that you need the Wildfire source in order to develop plugins. As an added bonus, included along with the Wildfire source is the source to all the existing open source plugins. I don't know about you, but when starting in an unfamiliar development I really appreciate having access to sample code that I can reference.


Kick the tires


Now that you have the source, work your way down to the src/plugins directory and look at how some of the plugins are put together in terms of both their structure and the code itself. Even though the plugins all share the same basic structure, they vary greatly in complexity and the API's that they use.  The registration plugin is probably the most basic, while the gateway plugin is by far the most complex.


Check out the documentation


As you may have noticed, the Wildfire source also contains a great deal of documentation. One of things I like to do is to bookmark the index.html page (located in documentation/docs directory) so that I can quick access the Plugin Developer Guide and Wildfire JavaDocs. And if you haven't already, I strongly recommend you read over the "Plugin Developer Guide" and "Building the Source" how-to's. There are two additional items not mentioned in either of these guides that will help speed up your plugin development. One, instead of executing the 'ant plugins' command which builds and deploys all the plugins use the 'ant -Dplugin=your_plugin plugin' command instead (replacing 'your_plugin' with the one plugin you want to build) which will only build and deploy the plugin you specified. And two, during the plugin development configure and use the wildfire-dev startup script (located in the target/wildfire/bin directory) to startup Wildfire. By using the script instead of the 'ant run' command you can edit your plugin source files and see the changes without having to redeploy your plugin. A potential gotcha to using this script when editing .jsp files is that you need to have a empty WEB-INF directory in the your_plugin/src/web directory. If the WEB-INF directory is not present your plugin will still load and you'll be able to view its .jsp pages but any changes you make to the source will not be re-compiled and you'll fill up your error log with  JasperExceptions.


All right, so now that we have some of basics out of the way, next time we'll be able to jump right in to some code. My hope is that this series of articles will be as beneficial and interactive as possible.  If there are any additional topics you'd like me to cover or if you have further questions regarding something I've written or indicated, please leave a comment or send me an email.


See you on the forums,

Ryan, aka ryang


Filter Blog

By date: By tag: