Openfire simple tutorial

Introduction

The plug-in is used to enhance the openfire function. This document is a developer guide for creating plug-ins.

Structure of a plug-in

The plug-in is stored in the plug-in openfirehome directory. When a jar or war plug-in file is deployed, it is automatically decompressed and installed. The file structure in the plug-in directory is as follows:

Plug-in Structure

Myplugin/
|-Plugin. xml plug-in definition file
|-Readme.html: The plug-in of the optional readme file, which is displayed to the end user
|-Changelog.html: The plug-in for modifying files, which is displayed to end users.
|-Icon_small.gif optional small (16x16) icons and plug-ins (or PNG files)
|-Icon_large.gif (large (32x32) icons and plug-ins (PNG files can also be used)
| Classes/resource plug-in requirements (that is, attribute files)
|-Database/Optional database architecture file, you need plug-ins
|-I18n/plug-in international language configuration.
|-Lib/your plug-in jar package
|-Web Resource Management Console integration, if any
|-WEB-INF/
|-Web. xml: the Web. xml contains JSP compilation entries
|-Web-custom.xml optional custom servlets in user-defined Web. xml
|-Images/directory for storing image files

Plug-ins in the web directory must be added to the openfire console. Further details are as follows.

The main plug-in class specified in the plugin. xml file. The sample file may look like this:

Sample plugin. xml

<? XML version = "1.0" encoding = "UTF-8"?> <Plugin> <! -Required plug-in Classes

-->

<Class> org. example. exampleplugin </class> <! -- Plug-in metadata -->

<Name> example plugin </Name> <description> This is an example plugin. </description> <author> jive software </author> <version> 1.0 </version> <date> 07/01/2006 </date> <URL> http://www.igniterealtime.org/projects/openfire/plugins.jsp </URL> <minserverversion> 3.0.0 </minserverversion> <licensetype> GPL </licensetype> <! -- Management Console entry -->

<Adminconsole> <! -- More on this below --> </adminconsole> </plugin> this metadata field can be set in the plugin. xml file:

· Name-plug-in name.

· Description-Description of the plug-in.

· Author of author-plug-in.

· Version-version of the plug-in.

· Date-release date, for example, January 1, July 1, 2006.

· URL-plug-in URL.

· Minserverversion-Minimum openfire version

· Databasekey-if the plug-in requires its own data table, the databasekey content should be set up with a primary schema name (usually a plug-in with the same name ). The database architecture file is a plug-in that is placed in the database directory for each supported database. For example, the schema file "foo" will be called "foo_mysql. SQL" and "foo_oracle. SQL". We recommend that you use your table prefix, to avoid conflicts with other applications installed in the same database. The script should be used in the ofversion table. Such architecture version information can be tracked, for example:

Insert into ofversion (name, Version) values ('foo', 0); databaseversion-database version number (if the database mode is defined ). The new plug-in and database architecture should begin in the version. If you need to update future plug-in versions, these updates can define the upgrade database directory in the created subdirectory as each version. For example, the directories database/upgrade/1 and database/upgrade/2 will contain scripts, for example, "foo_mysql. SQL" and "foo_oracle. SQL" contain related databases for each version change. Each script should update the information ofversion table in the version, for example:

Update ofversion set version = 1 where name = 'foo ';

· Parentplugin-parent layer plug-in (as the "foo. Jar" plug-in of "foo ). When a plug-in has a parent plug-in, the plug-in class loader will be used instead of creating a new class loader. This allows the plug-in to work more closely together. The child plug-in does not affect its parent plug-in.

· "Licensetype": displays the license agreement, which is used by the plug-in. Valid values:

O "commercial cial": Commercial ": the plug-in is a commercial license agreement released under.

O "GPL": "General Public License": the plug-in is released using the GNU Public License (GPL ).

O "Apache": the Apache license released by the plug-in.

O "internal": (internal) the plug-in is an organization for internal use and will not be reassigned.

O "other": (Others) the release of agrement under the license does not belong to other categories. The details of the license agreement should be described in the plug-in.

If the license type is not set, this is assumed to be another.

Some additional files can be provided in the plug-in for more information to end users (all placed in the main plug-in directory ):

· Readme.html-optional plug-in for the self-report file, which will be displayed to the end user.

· Changelog.html-optional File Modification plug-in, which will be displayed to the end user.

· Icon_small.png-optional small (16x16) icon-related plug-ins. Or yes. GIF file.

· Icon_large.png-optional large (32x32) icon-related plug-ins. Or yes. GIF file.

Interface from the openfire API as well as have a default (no argument) contructor. Your plug-in class must execute the plug-in interface from the openfire API and have a default (No parameter) contructor. Interface Method to initialize and destroy the plug-in.

Sample plug-in execution

Package Org. example; import Org. jivesoftware. openfire. container. plugin; import Org. jivesoftware. openfire. container. pluginmanager; import Java. io. file;/*** a sample plugin for openfire. */public class exampleplugin implements plugin {public void initializeplugin (pluginmanager manager, file plugindirectory) {// your code

} Public void destroyplugin () {// your code

} General plugin best practices General Plug-in best practices

When you select a software package named your plug-in, we recommend that you select some unique you and/or your organization to help avoid conflicts as much as possible. For example, if everyone goes to org. example. pluginname, even if pluginname is different, you may start serving class names that conflict here and there. Especially when working and clustering.

.

Modify Management Console

The plug-in can be used to add tags, segments, and the Web Page Management Console. There are several steps to complete this:

· The first <adminconsole/> must be added to the plugin. xml file.

· JSP files must be compiled and implemented by the class path plug-in. An assembly file in Web. XML, which contains JSP servlet entries must be put into the plug-in under the webpage/directory. Note: openfire build scripts can assist in compiling JSPs and creating web. XML files. This is a detailed description.

· The JSP page required for any image must be in the webpage/image/directory. Only GIF and PNG images are supported.

Some of the <adminconsole/> plug-in. xml defines additional labels, section and Project Management Console framework. The sample plugin. xml file may look as follows:

Sample plugin. xml

<? XML version = "1.0" encoding = "UTF-8"?>

<Plugin>

<! -- Main plug-in class -->

<Class> org. example. exampleplugin </class>

<! -- Management Console entry -->

<Adminconsole>

<Tab id = "mytab" name = "example" url = "my-plugin-admin.jsp" Description = "click to manage...">

<Sidebar id = "mysidebar" name = "My plugin">

<Item id = "My-plugin" name = "My plugin admin"

Url = "my-plugin-admin.jsp"

Description = "click to administer settings for my plugin"/>

</Sidebar>

</TAB>

</Adminconsole>

</Plugin>

In this example, we define a new tag "example", a tool column "my plug-ins", and a webpage "my plug-ins ". We have registered the admin. jsp page. You can overwrite existing tags and segments. The project uses the existing ID attribute values to define them in your <adminconsole>.

Management Console Best Practices

When there are several best practices, consider changing the openfire console through a plug-in. The general theme is that the seamless integration plug-in should:

· Integrate to existing labels and sidebar sections as long as they may not be created by yourself. Only a very important new feature that creates new tags.

· Do not use the plug-in name, Tag, sidebars, or project. For example, a project called "Gateway plug-in" may also be called "Gateway Settings ".

· Try to comply with the existing User Interface Management Console on your custom plug-in webpage.

· There is no need to create a console to view plug-in metadata. Instead, let openfire inform users about the plug-in installation and provide plug-in management.

Writing webpage management console

Openfire uses the sitemesh framework to decorate the webpage management console. The globally defined decoration applies to each web page for final output, as shown in the following figure:

It is easy to create webpages with sitemesh. You only need to create a valid HTML page and then use the relay tag to transmit the indication sitemesh. When rendering the output, sitemesh will use the instructions you provide to make decoration of any content on your HTML webpage. The following meta tags can be used:

· Pageid-ID page, which must comply with the XML described above in the Import Management Console. Either pageid or subpageid must be specified.

· Subpageid-the ID group page, which must comply with the XML in the import management console as described above. The Group webpage is used for administrative activities involving the parent page number. For example, edit or delete a specific group. Either pageid or subpageid must be specified.

· Extraparams (optional)-additional parameters should be passed through the webpage. For example, you can delete a group of Possible IDs on a webpage. The parameter must be URL encoded.

· Decoration (optional)-overwrite the website used for sitemesh decoration. Decoration is not named and will provide simple web pages without decoration.

The following HTML code snippet shows a valid webpage:

Example

<HTML>

This may turn your plug-in into multiple languages (i18n ). To do this, use the following program:

· Create a plug-in the root directory of the "i18n" directory.

· Purchase each resource file and use % [plugin_name] % _ i18n "_" language ". properties ". Attribute naming convention, where the name of [plugin_name] is in the plug-in directory. See the translation guide to learn more about resource packages.

· String Conversion in your JSP file refers to the international key. For example:

<% @ Taglib uri = "http://java.sun.com/jstl/core_rt" prefix = "C" %>

<% @ Taglib uri = "http://java.sun.com/jstl/fmt_rt" prefix = "FMT" %>

...

<FMT: Message key = "Some. Key. Name"/>

· Use localeutils class in your Java file for internationalization:
Org. jivesoftware. util. localeutils. getlocalizedstring ("Some. Key. Name", "[plugin_name]");

· International plugin. xml file in the format of $ (leaf:
<Sidebar id = "gateways" name = "$ {plugin. Sidebar. name}" Description = "$ {plugin. Sidebar. Description}">
<Description >$ {plugin. Description} </description>

Use openfire to build scripts

Creating scripts in openfire will help you build and develop plug-ins. It looks like the plugin Development Directory format is as follows:

Plug-in Structure

Myplugin/|-plugin. xml <-plug-in definition file

|-Readme.html <-plug-in self-report file

|-Changelog.html <-logs modified by the plug-in

|-Icon_small.gif <-thumbnail

(16x16) |-icon_large.gif <-Image

(32x32) |-classes/<-resource plug-in requirements (that is, attribute files)

|-Lib/<-Package

|-Src/|-database <-optional database script plug-in

|-Java <-plug-in's

Java source code

|-Com |-mycompany |-*. Java |-web |-*. jsp <-JSP page

|-Images/<-Image File

|-WEB-INF |-web. xml <-optional file Customization

Servlets can be registered

The build script will compile the source file and JSPs, and establish a valid plug-in structure and JAR file. Deploy the source distribution under the src/plug-in directory in your plug-in directory, and then use ant plugins to build your plug-in.

The plug-in of any JAR file should be placed in the lib directory in the compilation. These jar files will also be copied to a part of the build process of the lib directory generated by the plug-in.

If you create a src/web/WEB-INF/Web. XML, register the servlets initialization to start the plug-in. Only the registered Servlet and Servlet are reflected in the web. xml file. Note: This function is used to merge and execute the JSP assembly process generated in the web. xml file of your custom web. xml file.

Execute your plug-in

The plug-in completely enters the openfire API. This provides a great deal of flexibility, and what plug-ins can do. However, there are several integration points, which are the most common:

Register a plug-in as an integral part. The component receives all data packets to a specific subdomain. For example, test_component.example.com. Therefore, packets sent to the joe@test_component.example.com are delivered to the component. Note that a subdomain is defined as a child domain of a component-independent DNS entry. All XMPP protocol routes use the master server domain (example.com in the preceding example) at the socket level, and the subdomain is only used for the XMPP protocol server for routing.
Register a plug-in as iqhandler. The IQ processing responds to the names and namespaces of the special elements of the IQ package. The following code snippet demonstrates how to register an iqhandler:
Iqhandler myhandler = new myiqhander (); iqrouter = xmppserver. getinstance (). getiqrouter (); iqrouter. addhandler (myhandler );

Register a plug-in as packetinterceptor to receive all data packets through the system and selectively reject them. For example, an intercept can deny all emails or carry a banner who is not review the flag.
You can store the methods for setting the openfire attribute using jiveglobals. getproperty (string) and jiveglobals. setproperty (string, string. Let your plug-in property listener listen to change its nature and execute the org. jivesoftware. util. propertyeventlistener method. You can register your plug-in as a listener using the propertyeventdispatcher. addlistener (propertyeventlistener) method. Be sure to register your plug-in as the audience in your plug-in's destroyplugin () method.
Plug-in FAQs

Can I deploy a plug-in directory instead of a jar?

No. The jar or war file must be deployed for all plug-ins. When a jar or war of the plug-in does not exist, openfire assumes that the file has been deleted, and the user wants to destroy the plug-in, so it also deletes the directory.

What is the plug-in License Agreement?

Since openfire is an open-source GPL license, any plug-in developed countries must also release or compatible open-source licenses under the GPL license if you distribute plug-ins to other organizations. This is in violation of the license agreement to create plug-in distribution not open source. Please visit jive software if you need different authorization terms openfire right, including creating commercial plug-ins.

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/heyi1214/archive/2009/05/26/4218201.aspx