Top 10 Downloads
  Last 15 New Files
  Web Links
  Last 15 New Tips
  NLM Programming
  Admins Club

SUPLA System
Internet of Things

Installation and Administration

Polish Forum SUSE

Who's Online

 There are currently,
6 guest(s)
that is (are) online.

Technical Information

Back to List of Categories

Technical Information about
  A Beginner's Guide to LDAP Development
  Changing Time SourceType for a 4.X server
  Common Dsrepair switches - with explanations
  Deactivating Anonymous LDAP Logins
  DSMaint -PSE (Replacing Crashed Server)
  DSRepair: Is It Overused?
  Fixing ConsoleOne Refresh Problems
  Generic Design for an iManager Plugin
  Generic Design of iManager Plugin - Part 2
  Getting ConsoleOne Running on Red Hat 9
  LDAP Directory Service: Novell eDirectory
  NMAS and Kerberos
  Removing a Crashed Server from the NDS Tree
  The DSREPAIR Utility
  Timesync Config, Issues and Definitions
  Understanding eDirectory and Clustering
  Universal Password and Containers

Technical Information
 Generic Design for an iManager Plugin

Printer-friendly version

22 Dec 2004


Many plugins have a huge Class which extends, executes and implements all handlers. There are a host of Utility files which are copied for every plugin.


  • Introduce layers.
  • Implement Design patterns in this existing design.
  • Arrive at a generic design which can be used for any plugin development. Maximize reuse.
  • Come out of Method handlers - Procedure Oriented programming to Object handlers - Object Oriented Programming.
  • Allow easy code generation from plugin specification.

Existing design has a controller class which is tightly coupled to all details. To write a new plugin, a lot of changes are required.

So, the new Controller is designed for minimal responsibilities. The class which extends dev.Task has these responsibilities

  1. Implement Execute, it is the purpose of this class
  2. Handle Should Run, as it is the first Expert to get the HttpServletRequest

What needs to be done in the execute?
Execute should make this task a Controller.
Execute should send the request to next controller based on a criteria.

Criteria may be the JSP page which submitted the form.
Hence execute diverts the request to Page Handler. Task Controller has all pages in the Task. So every page when added to the plugin results in a LOC addition only in task controller.

Should divert the request to Button/Action Handler. PageHandler has all action Handlers for a page. An action is a submitting action in browser. It may be OK, CANCEL, REFRESH… All actions need not be user-generated, there may be periodic REFRESH done by JavaScript thread. Every action requires 1 LOC addition only to the PageHandler.

Needs to do some action, involving state change and error handling.
Action handlers consider state information and invoke appropriate workers.

Performs a specific task. After the task, sets the Next JSP page. ActionHandlers exist in Application layer, while workers are in Domain layer.

This chain of responsibility design needs to answer these Qs:

Who is responsible to maintain state?
Where is session specific info stored?
How are the handlers made thread safe?

What may be session specific info
-Task context, tree logged in, user logged in, server logged in, browser info
These can be handled by a SessionHandler which creates a SessionBean.
SessionHandler should be called by dev.Task.

Obviously, state is maintained in SessionBean by Handlers-Workers.

We make handlers thread safe by creating different sessions for different threads.

All the Workers will have a lot of common responsibility.
These should be part of a singleton Utils.
Design should ensure that everything in Utils is stateless.

Session Bean is visible to all handlers and workers, in plugin terms, it is the PanelInfo. Session bean removes global variables in classes in Application layer. It provides a way for session tracking.

Error handling
The worker handles the error and abstracts as WorkCannotBePerformed
Handler handles the error and abstracts as RequestCannotBeHandled
Pagehandler further abstracts the error as PageSubmissionCannotBeHandled
dev.Task further abstracts as TaskExecutionFailed

So, we do not see a NullPointerException, but which action in which page by what task caused the null pointer exception.

This is the Exception pattern

Thus the generic design applies
Chain of responsibility


A session in a plugin is different from HttpSession. Every invocation of task may start a new session. This may be from same browser/client.

Hence SessionBean needs some identification for this task's session.

Every JSP page has 3 hidden parameters:

  1. pageid
  2. actionid
  3. sessionid

This should be present in every request, response of task.

Instead of making servlets get created for every request, all state information should be stored in Session Bean.

I am presenting a DeleteContainer task, which uses this generic design:

All handlers are singletons, never 2 instances of any handler is created.
Workers can run in threads, so that handler does not hang.

All workers are stateless; all state information is passed in SessionBean which is not shown.

Since 2003

Portal posiada akceptację firmy Novell Polska
Wszystkie materiały dotyczące produktów firmy Novell umieszczono za zgodą Novell Polska
Portal has been accepted by the Novell Polska
All materials concerning products of Novell firm are placed with Novell Polska consent.
NetWare is a registered trademark of Novell Inc. in the United States and other countries.
Windows is a trademark or a registered trademark of Microsoft Corporation in the United States and other countries.
Sybase is a registered trademark of Sybase Inc. in the United States of America.
Other company and product names are trademarks or registered trademarks of their respective owners.