bloritsch 2003/01/23 20:34:18
Added: fortress/src/xdocs cli.xml servlet.xml swing.xml
Log:
update docs
Revision Changes Path
1.1 jakarta-avalon-excalibur/fortress/src/xdocs/cli.xml
Index: cli.xml
===================================================================
<?xml version="1.0"?>
<document>
<header>
<title>Excalibur Fortress - CLI Applications</title>
<authors>
<person name="The Avalon Documentation Team"
email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<s1 title="Command Line Tools">
<p>
Command Line Tools are the class of tools or applications that are
run from a command shell. Typical examples are the ANT build tool,
Turbine Maven, Apache Forrest, etc. They have a definite begining
and a definite end. As a result, we don't have to do any trickery
with threads or synchronizing the startup and shutdown of the
container.
</p>
<p>
A typical example of creating a Fortress CLI application will follow
the pattern outlined below:
</p>
<source>
<![CDATA[
public int main(String [] args)
{
// You would have to implement the referenced method here...
FortressConfig config = configWithArgs( args );
ContainerManager cm = new DefaultContainerManager( config.getContext() );
ContainerUtil.initialize( cm );
// Get the root container and use it
MyCLIContainer container = (MyCLIContainer) cm.getContainer();
container.performAction(args);
// Clean up after ourselves
ContainerUtil.dispose( cm );
}
]]>
</source>
<p>
As you can see, there are three major portions of working with
Fortress: startup, useage, and shutdown; The Startup and shutdown
portions are not likely to change at all. What will change is how
you plan on interacting with your container.
</p>
</s1>
</body>
</document>
1.1 jakarta-avalon-excalibur/fortress/src/xdocs/servlet.xml
Index: servlet.xml
===================================================================
<?xml version="1.0"?>
<document>
<header>
<title>Excalibur Fortress - Servlet Applications</title>
<authors>
<person name="The Avalon Documentation Team"
email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<s1 title="Swing Based Applications">
<p>
Servlet based applications are viewed on the web. Examples of these
types of Java projects are Jakarta Turbine, and Apache Cocoon.
Servlets have their own lifecycle, so it is rather easy to tie the
life of a container to the life of a servlet.
</p>
<p>
Servlet based applications can either tie the Avalon container to
a Servlet or bind it to JNDI. The advantage of binding it to JNDI is
better resource management because the container is not being torn
down and rebuilt periodically. The disadvantage is that there is no
standard way of doing it in your Servlet container. Most of the time
we bind the container to a Servlet like the following code:
</p>
<source>
<![CDATA[
public class MyAvalonServlet implements HttpServlet
{
private MyServletContainer m_container;
private ContainerManager m_containerManager;
/**
* Initializes Servlet and creates a <code>ServletContainer</code> instance
*
* NOTE: this is the servlet init code.
*
* @exception ServletException if an error occurs
*/
public void init()
throws ServletException
{
super.init();
try
{
final FortressConfig config = new FortressConfig();
config.setContainerClass(
"org.apache.excalibur.fortress.examples.servlet.ServletContainer" );
config.setContextDirectory( "./" );
config.setWorkDirectory( "./" );
config.setContainerConfiguration(
"resource://org/apache/excalibur/fortress/examples/servlet/ServletContainer.xconf" );
config.setLoggerManagerConfiguration(
"resource://org/apache/excalibur/fortress/examples/servlet/ServletContainer.xlog" );
config.setRoleManagerConfiguration(
"resource://org/apache/excalibur/fortress/examples/servlet/ServletContainer.roles" );
m_containerManager = new DefaultContainerManager( config.getContext() );
ContainerUtil.initialize(m_containerManager);
m_container = (ServletContainer)m_containerManager.getContainer();
}
catch( Exception e )
{
throw new ServletException( "Error during initialization", e );
}
}
/**
* Pass all servlet requests through to container to be handled. In a more
* complex system, there could be multiple containers that handle different
* requests, or a main controlling container with subcontainers for different
* requests.
*
* @param request a <code>ServletRequest</code> instance
* @param response a <code>ServletResponse</code> instance
* @exception IOException if an IO error occurs
* @exception ServletException if a servlet error occurs
*/
public void service( ServletRequest request, ServletResponse response )
throws IOException, ServletException
{
m_container.handleRequest( request, response );
}
/**
* Disposes of container manager and container instance.
*
* NOTE: This is the Servlet destruction callback
*/
public void destroy()
{
ContainerUtil.dispose(m_containerManager);
}
}
]]>
</source>
</s1>
</body>
</document>
1.1 jakarta-avalon-excalibur/fortress/src/xdocs/swing.xml
Index: swing.xml
===================================================================
<?xml version="1.0"?>
<document>
<header>
<title>Excalibur Fortress - Swing Applications</title>
<authors>
<person name="The Avalon Documentation Team"
email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<s1 title="Swing Based Applications">
<p>
Swing applications are those applications that have a lovely graphical
interface for you to interact with. When you are done with the
application, you close it and are done with it. Some examples of a
Swing based application include Apache JMeter, JEdit, and Avalon
Instrument Client.
</p>
<p>
Swing applications are very similar to CLI based applications in the
way they are set up and torn down. What differs is that the GUI runs
in a different set of threads, so the main routine has to wait until
the GUI is done. There are two strategies to do that. The first is
to extend the DefaultContainer and use that to enclose your Swing
based JFrame and implement the Runnable interface. The second is to
manage the Swing GUI separately, but give your container or its
ServiceManager to the Swing code to interact with.
</p>
<s2 title="Extending DefaultContainer">
<p>
If we extend the DefaultContainer, our main method will look pretty
much the same:
</p>
<source>
<![CDATA[
public int main(String [] args)
{
// You would have to implement the referenced method here...
FortressConfig config = configWithArgs( args );
ContainerManager cm = new DefaultContainerManager( config.getContext() );
ContainerUtil.initialize( cm );
// Get the root container and use it
((MySwingContainer) cm.getContainer()).run();
// Clean up after ourselves
ContainerUtil.dispose( cm );
}
]]>
</source>
<p>
The extensions to DefaultContainer that you do are different for
each application. However, they will have some common elements.
Here is an excerpt from both the Swing example and the Viewer
example included in CVS.
</p>
<source>
<![CDATA[
public class MySwingContainer extends DefaultContainer implements Runnable
{
JFrame m_frame = new JFrame();
// skipping non relevant parts
public void run()
{
while ( m_frame.isVisible() )
{
try
{
Thread.sleep(1000);
}
catch (InterruptedException ie)
{
// you can either ignore the exception or you can
// close the application. Remove the next line
// if you don't want to end the application:
m_frame.setVisible( false );
}
}
}
}
]]>
</source>
</s2>
<s2 title="Passing Container to Swing">
</s2>
</s1>
</body>
</document>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
