ViewVC logotype

Contents of /libjpf-java/trunk/jdocs/tutorial.jxp

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1601 - (show annotations)
Sat Feb 28 23:28:19 2009 UTC (12 years, 5 months ago) by gregoa
File size: 16947 byte(s)
[svn-inject] Forking libjpf-java source to Trunk
1 <%
2 // Java Plug-in Framework (JPF)
3 // Copyright (C) 2004 - 2006 Dmitry Olshansky
4 // $Id$
5 %>
6 <%
7 include("/functions.ijxp");
9 printHeader("Tutorial");
10 printMenu("tutorial");
11 %>
12 <div class="content">
13 <h1>JPF Usage Tutorial (Demo application explained)</h1>
14 <h3>Introduction</h3>
15 <p>This tutorial is a detailed description of JPF Demo Application (JPF-Demo, <a href="http://sourceforge.net/project/showfiles.php?group_id=110394&package_id=121489">available for download</a>). It is aimed for developers to get them quick start with JPF. <em>Please note:</em> this is not a Java Swing application developers tutorial; this tutorial also demonstrates the only one approach in JPF usage and not cover all possible usage scenarios.</p>
16 <p>It is recommended to download JPF-Demo source code also and install it as project into your favorite Java IDE. Look at <a href="ide.html">detailed instructions</a> on how to configure JPF based project in various Java IDE.</p>
17 <p>JPF-Demo is a GUI application that is designed with "Toolbox" metaphor in mind. The main application window is kind of container for "tools" - a small (ore huge :) utility applications of any kind that are developed as JPF plug-ins (or set of plug-ins).</p>
18 <p><img src="resources/images/jpf-demo-codecolorer-tool.png" width="617" height="428" border="0" alt="JPF-Demo - Code Colorer Tool" /></p>
19 <p>On the screen shot you can see a "Code Colorer Tool" - an utility which gets java source text on it's input and transforms it to HTML text with syntax highlighting. This particular function is implemented using open-source Java2Html library (GPL, <a href="http://www.java2html.de" target="_new">Java2Html Homepage</a>).</p>
20 <h3>Application structure</h3>
21 <p>File system structure of the application looks like this:</p>
23 +- data/
24 +- lib/
25 | +- commons-logging.jar
26 | +- jpf.jar
27 | +- jpf-boot.jar
28 | +- jpf-tools.jar
29 | +- jxp.jar
30 | +- log4j.jar
31 +- logs/
32 +- plugins/
33 +- boot.properties
34 +- log4j.properties
35 +- run.bat
36 +- run.sh
37 </pre>
38 <p>Here are the explanation:</p>
39 <dl>
40 <dt>data</dt>
41 <dd>Folder, where plug-ins can store their configurations and other data files.</dd>
42 <dt>lib</dt>
43 <dd>Libraries that are required for application start, here are JPF libraries and libraries for logging support (they are used also by JPF itself).</dd>
44 <dt>logs</dt>
45 <dd>Log files come here</dd>
46 <dt>plugins</dt>
47 <dd>This is repository folder for JPF plug-ins.</dd>
48 <dt>boot.properties</dt>
49 <dd>Application start up configuration file.</dd>
50 <dt>run.*</dt>
51 <dd>Application start up scripts.</dd>
52 </dl>
53 <p>Component structure of the application can be represented by the following diagram.</p>
54 <p><img src="resources/images/jpf-demo-diagram.png" width="394" height="320" border="0" alt="JPF-Demo Application Diagram" title="JPF-Demo Application Diagram" /></p>
55 <h3>Application boot</h3>
56 <p>To perfrm application start, the <code>run</code> script makes call of entry point of JPF Boot library - <code>org.java.plugin.boot.Boot.main(String[])</code> method. This method reads configuration from <code>boot.properties</code> file, initializes JPF runtime and loads all our plug-ins from <code>plugins</code> folder. Finally it calls our <code>org.jpf.demo.toolbox.core</code> plug-in because we specify that in configuration.</p>
57 <p>From this point the application control logic moves entirely into plug-in <code>org.jpf.demo.toolbox.core</code>, which we can name as, like in Eclipse, "application plug-in". The plug-in class for plug-in <code>org.jpf.demo.toolbox.core</code> extends special abstract class <code>org.java.plugin.boot.ApplicationPlugin</code> from the JPF Boot library. Thus we allow JPF boot code to call our specific boot logic.</p>
58 <h3>Core plug-in</h3>
59 <p>As almost any JPF plug-in, <code>org.jpf.demo.toolbox.core</code> consists of two parts: the manifest file and the plug-in specific Java code. We'll look through them separately.</p>
60 <h5>Plug-in manifest</h5>
61 <p>Plug-in manifest is an XML syntax file created according to <a href="dtd.html">plug-in DTD</a>. The root tag of XML is:</p>
62 <pre>&lt;plugin id="org.jpf.demo.toolbox.core" version="0.0.4"
63 class="org.jpf.demo.toolbox.core.CorePlugin"&gt;</pre>
64 <p>Here we state that the plug-in ID is "org.jpf.demo.toolbox.core" and the version identifier is "0.0.2". We also declare that our plug-in have a "plug-in class" <code>org.jpf.demo.toolbox.core.CorePlugin</code> so that JPF runtime can initialize our plug-in properly. The "plug-in class" is an optional element of plug-in declaration and can be omitted if your plug-in doesn't need any code to be executed during plug-in activation. But this is not our case because this particular plug-in is an application entry point and have to show application GUI when it is activated.</p>
65 <p>The next manifest element is libraries declaration:</p>
66 <pre>&lt;runtime&gt;
67 &lt;library id="core" path="classes/" type="code"&gt;
68 &lt;export prefix="*"/&gt;
69 &lt;/library&gt;
70 &lt;library type="resources" path="icons/" id="icons"&gt;
71 &lt;export prefix="*"/&gt;
72 &lt;/library&gt;
73 &lt;/runtime&gt;</pre>
74 <p>Here we define that all Java code from this plug-in is placed into "classes/" folder within plug-in context (home) folder. We also declare that all classes and packages (*) from this plug-in are visible to other plug-ins so that they can use our code freely. We also declare a resources folder "icons/" and also made it visible to other plug-ins.</p>
75 <p>The last part of manifest is most interesting and this is most powerful feature of JPF (as for Eclipse) that makes our application extremely extendible. This is extension point declaration:</p>
76 <pre>&lt;extension-point id="Tool"&gt;
77 &lt;parameter-def id="class"/&gt;
78 &lt;parameter-def id="name"/&gt;
79 &lt;parameter-def id="description" multiplicity="none-or-one"/&gt;
80 &lt;parameter-def id="icon" multiplicity="none-or-one"/&gt;
81 &lt;/extension-point&gt;</pre>
82 <p>With this we declare that our plug-in expose a point where it can be extended by any other plug-in. We call this point as "Tool" and explain that extension to this point will be represented as a "tab" in application GUI. Any plug-in that contribute to this extension point should provide several parameters that will be used to present plug-in in application and communicate with it. We define four parameters for this extension point:</p>
83 <dl>
84 <dt>class</dt>
85 <dd>This is required parameter of type String that should contain full Java class name. The contract for that class will be described bellow.</dd>
86 <dt>name</dt>
87 <dd>The name of tool to be shown as "tab name" on GUI.</dd>
88 <dt>description</dt>
89 <dd>The tool description to be shown as "tab hint" on GUI. This is optional parameter.</dd>
90 <dt>icon</dt>
91 <dd>Path to resource with tool icon. This is optional parameter.</dd>
92 </dl>
93 <p>Now we are ready to implement logic for our core plug-in.</p>
94 <h5>Plug-in code</h5>
95 <p>As you remember, we've declared in plug-in manifest, that we'll provide plug-in class <code>org.jpf.demo.toolbox.core.CorePlugin</code>. So we did. Usually, we have to extend JPF's abstract class <code>org.java.plugin.Plugin</code> and implement two methods, the framework runtime will call during plug-in life cycle: <code>protected void doStart() throws Exception;</code> and <code>protected void doStop() throws Exception;</code>. But in our case, we have to extend <code>org.java.plugin.boot.ApplicationPlugin</code> class, because we are developing "application plug-in". Our implementation of those two methods from <code>org.java.plugin.Plugin</code> will be empty. The real purpose of this plug-in class is to provide "entry point" method from <code>org.java.plugin.boot.ApplicationPlugin</code> that is called from JPF Boot library and do all the magic.</p>
96 <p>The main duty of our plug-in class is to create and show application GUI. We also want to implement support logic for extension point, defined in manifest. The main trick here is to organize GUI logic efficiently. The main principle is to activate other plug-ins as late as possible and take maximal information from extension declarations. That's why we define so many parameters in extension point declaration. We are building GUI as "set of tabs with lazy initialization of components". Look at JPF-Demo source code for details. The most interesting place is communication with plug-in framework to get all extensions that are "connected" to our extension point:</p>
97 <pre>ExtensionPoint toolExtPoint =
98 getManager().getRegistry().getExtensionPoint(
99 getDescriptor().getId(), "Tool");
100 for (Iterator it = toolExtPoint.getConnectedExtensions()
101 .iterator(); it.hasNext();) {
102 Extension ext = (Extension) it.next();
103 JPanel panel = new JPanel();
104 panel.putClientProperty("extension", ext);
105 Parameter descrParam = ext.getParameter("description");
106 Parameter iconParam = ext.getParameter("icon");
107 URL iconUrl = null;
108 if (iconParam != null) {
109 iconUrl = getManager().getPluginClassLoader(
110 ext.getDeclaringPluginDescriptor())
111 .getResource(iconParam.valueAsString());
112 }
113 tabbedPane.addTab(
114 ext.getParameter("name").valueAsString(),
115 (iconUrl != null) ? new ImageIcon(iconUrl) : null,
116 panel, (descrParam != null) ?
117 descrParam.valueAsString() : "");
118 }</pre>
119 <p>The next interesting place here is the contract that we are defining for extension class. Here we state that "class" parameter, specified in extension declaration should refer to a Java class that implements interface <code>org.jpf.demo.toolbox.core.Tool</code>, defined in our plug-in. We also explain that objects of this class will be instantiated using default empty constructor. We also promise that method <code>init</code> will be called once during extension life cycle. Here the code that implements described concept:</p>
120 <pre>// Activate plug-in that declares extension.
121 getManager().activatePlugin(
122 ext.getDeclaringPluginDescriptor().getId());
123 // Get plug-in class loader.
124 ClassLoader classLoader = getManager().getPluginClassLoader(
125 ext.getDeclaringPluginDescriptor());
126 // Load Tool class.
127 Class toolCls = classLoader.loadClass(
128 ext.getParameter("class").valueAsString());
129 // Create Tool instance.
130 tool = (Tool) toolCls.newInstance();
131 // Initialize class instance according to interface contract.
132 tool.init(toolComponent);</pre>
133 <p>From this point we can distribute our application and wait when someone write plug-ins for it :) But we don't have time, let's do this job by ourselves and create several plug-ins that add tools to our box.</p>
134 <h3>Code colorer plug-in</h3>
135 <p>In this section I'll explain in details how to create a plug-in that add a tool to our box. As you already know, to achieve this, we have to implement an extension to extension point "Tool", defined in plug-in "org.jpf.demo.toolbox.core". As before we split explanation into two parts: plug-in manifest description and plug-in code comments.</p>
136 <h5>Plug-in manifest</h5>
137 <p>The root tag of manifest XML file should already be familiar to you:</p>
138 <pre>&lt;plugin id="org.jpf.demo.toolbox.codecolorer" version="0.0.5"&gt;</pre>
139 <p>You see that plug-in ID is "org.jpf.demo.toolbox.codecolorer" and plug-in class is absent because we don't need any code to be executed during plug-in start/stop.</p>
140 <p>The next section of manifest is new for us:</p>
141 <pre>&lt;requires&gt;
142 &lt;import plugin-id="org.jpf.demo.toolbox.core"/&gt;
143 &lt;/requires&gt;</pre>
144 <p>Here we define that our plug-in depends on plug-in "org.jpf.demo.toolbox.core" and may use it's exported code and resources and may also contribute to extension points defined there.</p>
145 <p>The libraries declarations are more expensive here as we are planning to use third party library among our own code.</p>
146 <pre>&lt;runtime&gt;
147 &lt;library id="codecolorer" path="classes/" type="code"/&gt;
148 &lt;library id="java2html" path="lib/java2html.jar"
149 type="code"&gt;
150 &lt;doc caption="Java2html Library by Markus Gebhard"&gt;
151 &lt;doc-ref path="docs/java2html"
152 caption="java2html library"/&gt;
153 &lt;/doc&gt;
154 &lt;/library&gt;
155 &lt;library type="resources" path="icons/" id="icons"/&gt;
156 &lt;/runtime&gt;
157 </pre>
158 <p>You see that we defined code library "java2html" that points to a JAR file "lib/java2html.jar" and also provide reference to documentation for this library (this is just for example, but would be good rule to provide documentation for every plug-in manifest element). Note also that we are not exported any code or resources as we suppose to use them within this plug-in only.</p>
159 <p>The last manifest element defines an extension. This is the main purpose of this plug-in.</p>
160 <pre>&lt;extension plugin-id="org.jpf.demo.toolbox.core"
161 point-id="Tool" id="codeColorerTool"&gt;
162 &lt;parameter id="class"
163 value="org.jpf.demo.toolbox.codecolorer.CCTool"/&gt;
164 &lt;parameter id="name" value="Code Colorer Tool"/&gt;
165 &lt;parameter id="description"
166 value="Tool to colorize source code text"/&gt;
167 &lt;parameter id="icon" value="codecolorer.png"/&gt;
168 &lt;/extension&gt;</pre>
169 <p>As you can see, we give the ID to our extension as "codeColorerTool" and specified extension class as "org.jpf.demo.toolbox.codecolorer.CCTool". Bellow you'll see that this class fully conforms to contract, defined for "Tool" extension point. Now the JPF can automatically perform integrity check for our two plug-ins and warn if we miss something in declarations.</p>
170 <h5>Plug-in code</h5>
171 <p>Code part of "org.jpf.demo.toolbox.codecolorer" plug-in consists of two classes. The class <code>org.jpf.demo.toolbox.codecolorer.CCTool</code> implements interface <code>org.jpf.demo.toolbox.core.Tool</code> and thus conforms to a contract for "Tool" extension point. The method <code>init</code> from this interface in our case simply creates tool GUI and adds it to given Swing container as it's child. Class <code>org.jpf.demo.toolbox.codecolorer.CodeColorer</code> is the internal plug-in class that do all the job. The code for that class is taken from Java2Html's class <code>de.java2html.Java2HtmlApplication</code> with small non-significant modifications. I'll not comment this code here. Refer to JPF-Demo source code and <a href="http://www.java2html.de" target="_new">Java2Html Homepage</a> for details.</p>
172 <p>Notice as easy it was to add a tool as plug-in to our Toolbox! The most part of plug-in is a tool logic itself and not "plug-in support" logic. The JPF and core plug-in do the job for us!</p>
173 <h3>Other plug-ins</h3>
174 <p>There are two other plug-ins bundled with JPF-Demo application. First is <strong>Plug-in Browser Tool</strong>.</p>
175 <p><img src="resources/images/jpf-demo-pluginbrowser-tool.png" width="617" height="428" border="0" alt="JPF-Demo - Plug-in Browser Tool" /></p>
176 <p>This plug-in allows you to load any number of plug-ins and investigate their structure and dependencies. Note that plug-ins are loaded with separate instance of plug-in registry and not activated by demo application, they are even not visible for it. The main purpose of this plug-in is to demonstrate how to "instrument plug-ins with JPF" and provide rudimentary tool to look at plug-ins structure.</p>
177 <p>Another plug-in is <strong>Database Browser Tool</strong>.</p>
178 <p><img src="resources/images/jpf-demo-dbbrowser-tool.png" width="617" height="428" border="0" alt="JPF-Demo - Database Browser Tool" /></p>
179 <p>The purpose of this plug-in is not to demonstrate how to work with JDBC in Java but how it is possible to provide more extensibility to you Java application. Actually "DB Browser" is not just a plug-in but a set of plug-ins. First, "org.jpf.demo.toolbox.dbbrowser", implements "Tool" providing extension for "Tool" extension point and maintains DB browser GUI. Next, this plug-in defines it's own extension point "Database" giving possibility for other plug-ins to plug into this "DB Browser". Actually, the "org.jpf.demo.toolbox.dbbrowser" plug-in don't know anything about any particular database. All DB specifics are abstracted as extension point (and several interfaces) and actually implemented in other plug-ins. Look at plug-in source code for details.</p>
180 <h3>What's next?</h3>
181 <p>Hope this article gives you a basic understanding of main principles that forms JPF and applications using it. Now you can try to apply those to your tasks or form your own approach in development with JPF.</p>
182 <p>Feel free to ask your questions in <a href="http://sourceforge.net/forum/?group_id=110394">public JPF forum</a>. You are also welcome to share your ideas and use cases with others. This will definitely help to improve JPF and make it popular framework for building extremely flexible applications.</p>
183 </div>
184 <%
185 printFooter();
186 %>

  ViewVC Help
Powered by ViewVC 1.1.26