Deployment & Configuration
About
This section documents the deployment and configuration possibilities of this library.
Overview
For using this library you will principally need to understand and work with two elements:
- Configuration of important library provided elements
- Development of an application specific shell class
Configuration
When deployed, telnetd will create the following set of important and configurable instances:
The Daemon
TelnetD is a Singleton that will take care of loading and instantiating all required elements including logging.
The unified configuration file specifies all the configuration required for startup, except for logging. It is documented in more detail here.
The ShellManager
The ShellManager is a singleton that will take care of loading and providing shell instances.
The configuration file specifies a special section for the shells that are available as well as their implementing classes. Once you have written an implementation for a shell, this section needs to be updated.
The TerminalManager
The TerminalManager is a singleton that will take care of loading and providing instances of terminal type specific terminal implementations (e.g. ansi, vt100, xterm etc.).
The configuration file specifies in a special section the terminals that are available, their aliases as well as their implementing classes.
Listeners
Listeners will take care about accepting and managing connections.
For each listener defined in the configuration file there should be a related configuration section that specifies connection and connection management properties.
Logging Configuration
telnetd is now using the Jakarta Commons-Logging library and is delivered per default with log4j. The distribution contains a simple config file for console logging, but you might want to take a look at the Commons-Logging User Guide.
Implementing a Shell class
The actual link between your application and the telnet daemon library is a shell implementation.
The incoming connection will start with a configured login shell (see listeners configuration),
that could for example authenticate the user.
A shell should basically take care about interpreting the user input (i.e. executing commands) and handle connection
events (which allows your application to react on a broken connection etc.).
To help you with implementing the I/O, the library provides you with classes for doing I/O (including colors etc.). Probably you will want to take a look at the toolkit classes, which are somewhat inspired by (but not based on) NEWT (Not Erik's Windowing Toolkit), a library for building applications with text based interfaces ontop of Slang (if it does not ring a bell, it's the TUI we knew from old RedHat version's text installation).
I think it should be possible to implement reasonable TUI's even in Java. If you doubt, probably search Google (you'll find some way to use ncurses via JNI, jcurzez and CHARVA, which probably can somehow be adapted to work over the given I/O).
You should take a look at the shell implementation tutorial.
Many people have asked about cmd.exe and bash implementations. Well, probably you might want to look for Java shell implementations (which indeed exist) and adapt the code to run over the given I/O. Unfortunately most have never realized that it would be interesting to use their shells simply via a given InputStream and OutputStream (or Reader respectively Writer).
by Dieter Wimberger
