CVS: jcontainer/loom/site/xdocs/guide/bdg creating-a-block.xml,1.6,1.7 making-loom-compatible-comps.xml,1.4,1.5 what-is-an-application-listener.xml,1.7,1.8
Peter Donald <pdonald-yCVjj/[email protected]> Wed, 3 Dec 2003 04:45:24 -0600
| Newsgroups | gmane.comp.java.jcontainer.cvs |
|---|---|
| Message-ID | <[email protected]> |
Update of /cvsroot/jcontainer/jcontainer/loom/site/xdocs/guide/bdg
In directory hogshead.codehaus.org:/tmp/cvs-serv21491/site/xdocs/guide/bdg
Modified Files:
creating-a-block.xml making-loom-compatible-comps.xml
what-is-an-application-listener.xml
Log Message:
Styled codebase
Index: creating-a-block.xml
===================================================================
RCS file: /cvsroot/jcontainer/jcontainer/loom/site/xdocs/guide/bdg/creating-a-block.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- creating-a-block.xml 3 Nov 2003 04:31:24 -0000 1.6
+++ creating-a-block.xml 3 Dec 2003 10:44:51 -0000 1.7
@@ -24,7 +24,8 @@
component. If a component implements the Contextualizable interface
it will be passed an instance of
<code>org.apache.avalon.phoenix.BlockContext</code> which is
- an extended version of <code>org.apache.avalon.Context</code>.
+ an extended version of
+ <code>org.apache.avalon.Context</code>.
Other than this minor change the container supports all the
Avalon lifecycle methods.
</p>
@@ -50,20 +51,20 @@
sample on how to use the task to generate metadata.
</p>
<source>
-<taskdef
+ <taskdef
name="generatemeta"
classname="org.jcontainer.loom.info.GenerateLoomDescriptorsTask">
- <classpath refid="maven-sar.class.path" />
- <classpath refid="dna-tools.class.path" />
- <classpath refid="metaclass.class.path" />
- <classpath refid="qdox.class.path" />
-</taskdef>
+ <classpath refid="maven-sar.class.path" />
+ <classpath refid="dna-tools.class.path" />
+ <classpath refid="metaclass.class.path" />
+ <classpath refid="qdox.class.path" />
+ </taskdef>
-<generatemeta dest="target/classes">
- <fileset dir="src/java">
- <include name="**/*.java"/>
- </fileset>
-</generatemeta>
+ <generatemeta dest="target/classes">
+ <fileset dir="src/java">
+ <include name="**/*.java"/>
+ </fileset>
+ </generatemeta>
</source>
</section>
<section name="Create the jar package">
Index: making-loom-compatible-comps.xml
===================================================================
RCS file: /cvsroot/jcontainer/jcontainer/loom/site/xdocs/guide/bdg/making-loom-compatible-comps.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- making-loom-compatible-comps.xml 17 Oct 2003 01:40:20 -0000 1.4
+++ making-loom-compatible-comps.xml 3 Dec 2003 10:44:51 -0000 1.5
@@ -1,70 +1,73 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<document>
- <properties>
- <title>Guide - Making components that are Loom compatible</title>
- <author email="[email protected]">Paul Hammant</author>
- </properties>
- <body>
- <section name="Introduction">
- <p>
+ <properties>
+ <title>Guide - Making components that are Loom compatible</title>
+ <author email="[email protected]">Paul Hammant</author>
+ </properties>
+ <body>
+ <section name="Introduction">
+ <p>
Quite often reusable components are made elsewhere. Apache has a number
of places where this activity is going on. While we get it right most of
the time, some components developed elsewhere are harder to use in Loom.
- </p>
- </section>
- <section name="Things to remember">
- <p>
+ </p>
+ </section>
+ <section name="Things to remember">
+ <p>
There are a number of common sense things to remember when making or
adapting a Java component to be reusable in Loom as block.
- </p>
- <subsection name="Beanification">
- <ul>
- <li>Have a public empty constructor for your main class</li>
- <li>Have setters for its configuration.</li>
- <li>Do not assume that the File is where dependancies are - people may reuse this in jars, applets etc.</li>
- <li>Divorce your main method (if appl) from your main class - Loom does not call main methods.</li>
- <li>Consider that the setup and initialization of the bean does not happen in the
+ </p>
+ <subsection name="Beanification">
+ <ul>
+ <li>Have a public empty constructor for your main class</li>
+ <li>Have setters for its configuration.</li>
+ <li>Do not assume that the File is where dependancies are - people may reuse this in jars, applets etc.</li>
+ <li>Divorce your main method (if appl) from your main class - Loom does not call main methods.</li>
+ <li>Consider that the setup and initialization of the bean does not happen in the
constructor - as a convenience to the user, have an initialize() method</li>
- <li>If the comp has start/stop functinality consider having start() and stop() methods.</li>
- <li>Try to avoid Singleton concepts. There could be multiple blocks in one sar using differnt (by design) instances of your bean</li>
- </ul>
- </subsection>
- <subsection name="Inversion of Control Pattern">
- <p>The IoC pattern is described <a href="http://avalon.apache.org/framework/guide-patterns-ioc.html">
- here</a>. This means for Loom avoiding static concepts including loggers.</p>
- </subsection>
- <subsection name="Separation of interface and implementation">
- <p>
- The separation of interface/implementation pattern is described <a href="http://avalon.apache.org/framework/guide-patterns-soii.html">here</a>.
+ <li>If the comp has start/stop functinality consider having start() and stop() methods.</li>
+ <li>Try to avoid Singleton concepts. There could be multiple blocks in one sar using differnt (by design) instances of your bean</li>
+ </ul>
+ </subsection>
+ <subsection name="Inversion of Control Pattern">
+ <p>The IoC pattern is described
+ <a href="http://avalon.apache.org/framework/guide-patterns-ioc.html">
+ here</a>. This means for Loom avoiding static concepts including loggers.
+ </p>
+ </subsection>
+ <subsection name="Separation of interface and implementation">
+ <p>
+ The separation of interface/implementation pattern is described
+ <a href="http://avalon.apache.org/framework/guide-patterns-soii.html">here</a>.
For Loom this means we can (if done completely) mount the implementation jar in place where hosted client components (beans, servlets etc) can use the API, but not see the implementation. We can also reimplement or wrap
bits of the implementation. For example we could write a pluggable implementation that could, for a certain API
journal some methods, but still delegate to the real implementation. Which pluggable implementation is used by Loom when it
boots is determined in assembly.xml of course.
- </p>
- </subsection>
- <subsection name="Opening up the API">
- <p>
+ </p>
+ </subsection>
+ <subsection name="Opening up the API">
+ <p>
Given that you have divided into interface and implementation, there are probably plenty of methods you
can put method in the interface you never though might be used. For example if you are making JDBC
compliant relational database, and it is a bean, you could easily think that the only use would be
clients via JDBC over sockets. Well, given that Loom can now mount the RDBMS block, it might want
to be reused by other blocks that other people have developed inside the the same SAR file. In that case
have beanlike methods of ...
- </p>
- <ol>
- <li>Database createDatabase(String name)</li>
- <li>Database cloneDatabase(String name)</li>
- </ol>
- <p>
+ </p>
+ <ol>
+ <li>Database createDatabase(String name)</li>
+ <li>Database cloneDatabase(String name)</li>
+ </ol>
+ <p>
.. might be useful. Just because you can only see a ServerSocket interface does not mean that others do.
- </p>
- </subsection>
- </section>
- <section name="Example compatible component">
- <p>
+ </p>
+ </subsection>
+ </section>
+ <section name="Example compatible component">
+ <p>
Below are an interface and implementation that are suitably separated, are beanlike and is in accordance
with the IoC pattern...</p>
-<source>
+ <source>
package examplecomp;
public interface WebServer {
void mountWar(String contextName, URL pathToWar);
@@ -96,9 +99,9 @@
// whatever.
}
}
-</source>
- <p>For standalone mode, it might be launched like so:</p>
-<source>
+ </source>
+ <p>For standalone mode, it might be launched like so:</p>
+ <source>
package examplecomp.main;
public class WebServerMain {
public static void main(String[] args) throws Exception {
@@ -109,9 +112,9 @@
ws.mountWar(args[1], new File(args[2]).toURL());
}
}
-</source>
- <p>When we are trying to run this in phoenix we might have this wrapper:</p>
-<source>
+ </source>
+ <p>When we are trying to run this in phoenix we might have this wrapper:</p>
+ <source>
package examplecomp.block;
public class WebServerBlock
extends AbstractLoggable
@@ -150,12 +153,12 @@
mWebServer.unMountWar(contextName);
}
}
-</source>
- <p>This basically shows the implementation wrapped and taking its configuration from the config.xml
+ </source>
+ <p>This basically shows the implementation wrapped and taking its configuration from the config.xml
that phoenix prefers from configuration. If the developer wanted they could ignore
that place of configuration and use their own config files. If the WebServer block were
being reused by another Loom block (say an EJB server), it might be like so:</p>
-<source>
+ <source>
package somebeanserver;
public class EJBBlock
extends AbstractLoggable
@@ -180,21 +183,21 @@
// whatever
}
}
-</source>
- </section>
- <section name="Misconceptions">
- <p>
+ </source>
+ </section>
+ <section name="Misconceptions">
+ <p>
The following are worth stating:
- </p>
- <ul>
- <li>You do not have to implement any Avalon interfaces to be
+ </p>
+ <ul>
+ <li>You do not have to implement any Avalon interfaces to be
reusable (wrap strategy) inside Avalon.</li>
- <li>Being Loom compatible is just as useful for whole servers as it is for small components.</li>
- <li>Being Loom compatible can be for tools that are intended for client-side as well as server use.</li>
- </ul>
- <p>
- </p>
- </section>
+ <li>Being Loom compatible is just as useful for whole servers as it is for small components.</li>
+ <li>Being Loom compatible can be for tools that are intended for client-side as well as server use.</li>
+ </ul>
+ <p>
+ </p>
+ </section>
- </body>
+ </body>
</document>
Index: what-is-an-application-listener.xml
===================================================================
RCS file: /cvsroot/jcontainer/jcontainer/loom/site/xdocs/guide/bdg/what-is-an-application-listener.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- what-is-an-application-listener.xml 17 Oct 2003 01:18:13 -0000 1.7
+++ what-is-an-application-listener.xml 3 Dec 2003 10:44:51 -0000 1.8
@@ -26,13 +26,14 @@
Like normal blocks, an application listener can be
<code>LogEnabled</code> and take configuration via
<code>Configurable</code>. The special feature
- is that it must implement <code>ApplicationListener</code>
+ is that it must implement
+ <code>ApplicationListener</code>
and implement the eight methods that are a consequence of
that. The following section in assembly.xml causes
instantiation of the application listener:
</p>
<source>
-<listener class="pkg.MyApplicationListener" name="a-suitable-name" />
+ <listener class="pkg.MyApplicationListener" name="a-suitable-name" />
</source>
</section>