Openfire Plugin Developer's Guide

sponsored links
Introduction

Openfire features plug-ins are enhanced. This document is a guide to developers to create plug-ins.

The structure of a plug-in

Plug-ins Plug-ins openfireHome stored in the directory. When deploying a plug-in jar or war file, it will automatically unzip to install. The document in the plug-in directory structure is as follows:

Plug-in structure

myplugin /
| - Plugin.xml plugin definition file
| - Readme.html Optional plug-ins readme file, it will be displayed to end-users
| - Changelog.html Optional plug-ins to modify the file, it will be displayed to the end-user
| - Icon_small.gif optional small (16x16) icon and plug-ins (may also be a PNG file)
| - Icon_large.gif Optional large (32x32) icon and plug-ins (may also be a PNG file)
| Classes / resources required plug-ins (ie, property documents)
|-Database / optional database architecture document, you need to plug-ins
|-I18n / plug configuration language internationalization.
|-Lib / your plugin jar package
|-Web resources integrated management console, and if so
| - WEB-INF /
| - Web.xml generated web.xml containing compiled JSP entries
|-Web-custom.xml optional user-defined custom web.xml in servlets
|-Images / picture file storage directory

web directory of plug-ins exist, need to add to the Openfire Admin Console. Further details are as follows.

Plugin.xml file in the main plug-in type. Sample file may look as follows:

Sample plugin.xml

<?xml version="1.0" encoding="UTF-8"?>
<plugin>
      <! Requires plug-in class  -->
      <class>org.example.ExamplePlugin</class>
   
      <!--  Plugin 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>

The meta-data fields can be set in the plugin.xml file:

Name - the name of plug-ins.

Description - description of plug-ins.

Author - the author of plug-ins.

Version - the version of the plug-ins.

Date - such as release date July 1, 2006.

Url - web site plug-ins.

MinServerVersion - minimum Openfire version

DatabaseKey - if plug-ins required its own data sheet, the databaseKey architecture should be the establishment of a principal name (usually the same name are plug-ins). Database architecture document for each supported database, then placed in the database plug-ins directory. For example, "foo", file will be called the architecture "foo_mysql.sql", "foo_oracle.sql" and so on, we propose to you that your table prefix of, in order to avoid possible conflicts with other applications installed on the same database. Table ofVersion script should be entered using the key, this version of the architecture can track information, such as:

INSERT INTO ofVersion (name, version) VALUES ( 'foo', 0); databaseVersion - database version number (if the database schema definition). The new plug-ins with the database architecture should begin in the version. If in the future versions of required plug-ins updates, these updates can be defined to create a subdirectory in the upgrading of the database directory for each version. For example, the directory will contain database/upgrade/1 and database/upgrade/2 script, such as "foo_mysql.sql" and "foo_oracle.sql" contained in the relevant databases, for each version change. Each script should be updated versions of Table ofVersion information, such as:

UPDATE ofVersion set version = 1 where name = 'foo';

ParentPlugin - Father layer plug-in (as a "foo" of the "foo.jar" plug-ins). When a plug-Have a parent plug-in, plug-in class loader will be used to rather than set up a new class loader. This allows plug-ins work together more closely. Sub-plug-plug-ins will not affect his father.

"LicenseType": display the license agreement, the plug-ins are from. Valid values are as follows:

o "commercial": commercial "commercial": Plug-ins are released under the commercial license agreement.

o "gpl": "General Public License": the use of plug-ins released GNU Public License (GPL).

o "apache": The Apache plug-in permits issued.

o "internal": (internal) plug-ins are for internal use only of an organization and will not be re-distributed.

o "other": (other) plug-ins are released under the license agrement does not belong to one of the other categories. The details of the license agreement should be in the plug-in readme.

If the license type is not set, it is assumed that the other.

Some extra documents are available in the plug-ins provide more information to end-users (all placed in the main plug-ins directory):

Readme.html - optional plug-ins readme file, it will show to end-users.

Changelog.html - optional plug-ins to modify the file, it will show to end-users.

Icon_small.png - Optional small (16x16) icon associated plug-ins. Can also be yes. GIF file.

Icon_large.png - Optional large (32x32) icon associated plug-ins. Can also be yes. GIF file.

interface from the Openfire API as well as have a default (no argument) contructor. your plug-in type must be implemented Plug-ins Interface from the Openfire's API , And has a default (no parameters) contructor. Plug-in interface to initialize and destroy methods of plug-ins.

Sampling plug-in implementation of

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 best practices in general plug-ins

Choose the name of the package for your plug-ins, we recommend that you select a number of unique to you and / or your organization to help as much as possible to avoid conflict. For example, if each person go with org.example.PluginName, even if PluginName are different, you may start running into some conflicts here and there, the class name. Especially when working with the cluster.

.

Modify management console

Plug-ins can add tags, section, and page management console. There are several steps to accomplish this:

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

JSP document must be prepared and implemented by the plug-in classpath. The compilation of the Arab-Israeli web.xml file, which contains the JSP servlet entries must be put to the page / directory under the plug-ins. Note: Openfire script can be set up to assist in the preparation and the creation of web.xml in JSPs. This is described in detail below.

Any images required for JSP pages must live in the pages / images / directory. Only GIF and PNG images support.

<adminconsole /> Part of the definition of plugin.xml extra tags, branches and project management framework console. Sample plugin.xml file may look as follows:

Sample plugin.xml

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

<plugin>

<! - Main plugin class ->

<class> org.example.ExamplePlugin </ class>

<! - Management console entries ->

<adminconsole>

<tab name="Example" url="my-plugin-admin.jsp" description="Click to manage...">

<sidebar name="My Plugin">

<item 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 section "my plug-ins" and a page "My Plug-management." We have already registered, admin.jsp plug-ins page. You can overwrite the existing label, section, item ID using the existing property values in their own definition of <adminconsole>.

Management Console Best Practices

There are several best practices, the need to consider changes to Openfire Admin Console through a plug-in. The general subject are seamlessly integrated plug-ins should:

Integrated into the existing tags and sidebar sections whenever possible instead of creating your own. Only create new tag a very important new features.

Do not use "plug-in" the name, tag, sidebars and projects. For example, has a project called "gateway plug-in", or it may be the so-called "Gateway Settings."

Try to comply with the existing user interface management console in your custom plug-ins page.

There is no need to set up a management console to enter the view meta-data plug-ins. Instead, let Openfire inform users about the plug-in installation, and provides plug-ins management.

Writing pages Management Console

Openfire use Sitemesh Decorative framework of the management console page. Global definition of the decoration applied to each page so that the final outputs, such as the following chart:

Set up web pages, and are Sitemesh easy. As long as the HTML page to create an effective, then the use of meta tags to send instructions Sitemesh. When rendering the output, Sitemesh will use the instructions provided by you, so that the decoration of any content, in your HTML page. The following meta tags can be used to:

PageID - the ID of the page, which must comply with the management console entry in the XML described above. PageID subPageID either or must be specified.

SubPageID - the ID group page, which must comply with the management console entry in the XML described above. Sub-page for the administrative acts relating to the parent page ID. For example, to edit or delete a particular group. PageID subPageID either or must be specified.

ExtraParams (optional) - extra parameters, should be through the web page. For example, in one group pages may delete the ID Group. Parameters must be URL encoded.

Decoration (optional) - overwrite the page to use Sitemesh decoration. Decoration is not named, will be able to provide a simple page is not decoration.

The following HTML code segment shows an effective website:

Example

<html>
     <head>
         <title>My Plugin Page</title>
   
         <meta name="pageID" content="myPluginPage"/>
     </head>
     <body>
 Body here  !
     </body>
     </html>

Plug-ins you use in the localization

This may put you into various languages of the plug-ins (i18n). To do this, use the following procedure:

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

Resource file for each purchase, and use% [plugin_name]% _i18n "_" language ". Properties". Property "naming convention, where [plugin_name] are the names of plug-ins directory. See Translation Guide Details about the Resource Kit.

Convert a string in your JSP document 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" />

Internationalization of Java in your document using LocaleUtils class:
org.jivesoftware.util.LocaleUtils.getLocalizedString ( "some.key.name", "[plugin_name]");

Internationalization plugin.xml file in your use of $ (leaf) format:
<sidebar name="${plugin.sidebar.name}" description="${plugin.sidebar.description}">
<description> $ (plugin.description) </ description>

Use Openfire build script

In Openfire script will help you set up the establishment and development of plug-ins. It looks to develop plug-ins directory of the following format:

Plug-in structure

myplugin/
 |- plugin.xml        <- Plug-ins definition file  
 |- readme.html       <- Plugin Readme file  
 |- changelog.html   <- A plugin to modify the log  
 |- icon_small.gif   <-  Thumbnail pictures  (16x16) 
|- icon_large.gif   <- Picture  (32x32) 
   |- classes/           <- The plug-in needed resources (that is, the properties file)  
 |- lib/                <-  Package  
 |- src/
       |- database        <- Optional database scripting plug-in  
       |- java             <-  Plug-in Java source code  
       |     |- com
       |         |- mycompany
       |             |- *.java
       |- web
           |- *.jsp            <- jsp Page  
           |- images/         <-  Picture files  
           |- WEB-INF
               |- web.xml      <- Optional file custom servlets can register  

Build script will compile the source files and JSPs, and the establishment of an effective plug-in structure and JAR files. Put your plug-in directory src / plugins directory of the source distribution, and then use ant plugins to build your plug-ins.

Any plug-ins required JAR files should be placed in the compilation of the directory lib. These

  • 20:57
  • Browser (15)
  • Comments (0)
  • Category: Openfire
  • Related recommend


Comments


Comment


Openfire Plugin Developer's Guide


zyjwy02

  • View: 11478 times
  • Gender:
  • From: Canton
  • Details book
Search this blog


Recent visitors

dlboy

wuxuping

NewTamato

skying007

>> More Visitors

Blog Categories
  • All blog (42)
  • Technical Digest (35)
  • Living Diary (0)
  • Flex (2)
  • Openfire (3)


Other classification
  • My Favorites (7)
  • My Forum Posts (3)
  • Me the essence of a good paste (0)


Recently joined the circle of
  • struts2


Archive
  • 2009-02 (1)
  • 2009-01 (8)
  • 2008-12 (4)
  • More archives ...


Latest Comments
  • ClassLoader mechanism to understand
    Yes! ! Study, it is best to scan each and every trip is also about Translations
    - By neusoft
  • ExtJS DWR Spring Qiangqiang together ...
    How can download ah? LZ
    - By wyyacyy
  • JVM tuning Summary (transgenic)
    Good article, ORZ
    - By yumi301
  • By the model to talk about the principle of object-oriented ...
    Model is a collection of experience in problem-solving methods for exploration
    - By picnic
  • Aptana Ajax libraries plugin --- EXT ...
    Aptana already has this plug-ins. why is it necessary to hand-written or if the effect of the Komodo IDE ...
    - By smellcode


Comments list
  • JVM tuning Summary (transgenic)
  • By the model to talk about the principles of object-oriented as much as using combination of the use of following ...
  • ClassLoader mechanism to understand
  • Cairngorm
  • JavaScript and the DOM operation jQuery





Statement: JavaEye article copyright belong to the author, are protected by law. Without the written permission of the author may not be reproduced. If the consent of the author are reproduced, it is necessary to identify the article hyperlink form original source and authors.
© 2003 -2009 JavaEye.com. All rights reserved. Shanghai jiong resistant computer software Co., Ltd. [ ICP 05023328 ]

  • del.icio.us
  • StumbleUpon
  • Digg
  • TwitThis
  • Mixx
  • Technorati
  • Facebook
  • NewsVine
  • Reddit
  • Google
  • LinkedIn
  • YahooMyWeb

Related Posts of Openfire Plugin Developer's Guide

  • Process migration from tomcat to websphere changes

    Process migration from tomcat to websphere changes Because customers use the web application server software used by different what tomcat5, tomcat6, websphere5.1, websphere6.1, weblogic8, and so on, and the software used inconsistent standards, ibm's

  • JAVA EE JSP_JNDI

    dsfdsa http://lindows.javaeye.com/admin/blogs/213348 Tomcat 6 with the connection pool data source configuration http://www.blogjava.net/ec2008/archive/2008/07/19/216063.html project: test Driver path: D: \ workspace \ test \ WebRoot \ WEB-INF \ lib ...

  • Hibernate.cfg.xml configuration file (including the primary key generation strategy Introduction)

    Hibernate.cfg.xml configuration file: <? xml version = "1.0" encoding = "utf-8"?> <! DOCTYPE hibernate-configuration PUBLIC "- / / Hibernate / Hibernate Configuration DTD / / EN" "hibernate-configuration-2.0.dtd

  • The EJB3 Persistence

    EJB3 persistence with Hibernate is very similar to the mechanism: Environment: Server: JBOSS5.0 Database: MySQL5.0 1. Set up a data source First of all, in jboss-5.0.0.GA \ server \ default \ deploy, the establishment of a database used to connect the dat

  • Servlet brief introduction

    Servlet brief introduction: Servlet is a small application server Are used to complete the B / S architecture, the client requests the response to treatment Platform independence, performance, able to run thread Servlet API for Servlet provides the s ...

  • Spring2.0 + hibernate3.1 + log4j + mysql demo

    applicationContext.xml Non-attachment jar package, necessary friends can send an email to todd.liangt @ gmail.com

blog comments powered by Disqus
Recent
Recent Entries
Tag Cloud
Random Entries