1. Client-Specific Source Code

• SwingCE / GUI Clients (Swing-based GUI) – Can reuse GUIToolkit components

• SilentCE / CLI Clients – Use CLIToolkit for silent mode development

2. Toolkits (Shippable JARs)

• GUIToolkit.jar – Contains Swing components like MainFrame, TabbedPane, TreeViewPanel, ConsoleView, PopupMenu

• CLIToolkit.jar – CLI task handlers such as GenerateConfig, ListServers, Execute, MoveTask, etc.

3. Functional Toolkit (Shared Core Library)

• Business logic shared by GUI and CLI:

  • WebSphere / WebLogic platform helpers

  • Profile Creation / Upgrade

  • Task Execution

  • Read/Write to XML

4. Final Artifacts

• GUI and CLI clients are packaged with their respective toolkits + the shared functional toolkit as a end product.

One of the biggest strengths of the Dual Mode Toolkit is that it allows clients to reuse core building blocks while still plugging in their own custom pieces.

Think of it like this: the toolkit gives you a strong foundation (the frame, the structure, and the rules of the game), and the client only needs to bring in their own “furniture” (the actual menu, views, and task panels).

Below is a sample example (Note: The class names, methods, arguments, and variable names shown here are illustrative. They may not reflect the actual implementation in the toolkit, but the logic and design pattern remain the same.) : 

What’s happening here?

• The client creates a ClientFrame by extending the toolkit’s BaseFrame.

• Instead of writing the whole frame setup from scratch, the client just plugs in their own UI components (menu, profileViewLeft, taskViewRightUpper, taskViewRightLower).

• The heavy lifting — things like layout, event handling, and overall structure — is already handled by the toolkit.

This way, clients get the best of both worlds:

• A ready-made, consistent framework from the toolkit.

• The flexibility to design their own menus, views, and tasks that match their product needs.

Over time, clients can extend more toolkit classes (like panels, popup menus, or wizards) to build a fully customized Configuration Manager — without ever reinventing the wheel.

Just like the GUI toolkit, the Command-Line Toolkit also gives clients a ready-made foundation to build on — but this time for CLI (Command-Line Interface) interactions.

Instead of reinventing argument parsing, command routing, and mapping logic, the toolkit provides base classes. Clients simply extend them and plug in their own behavior.

Here’s a simple example (Note: The class names, methods, arguments, and variable names shown here are illustrative. They may not reflect the actual implementation in the toolkit, but the logic and design pattern remain the same.):

What’s happening here?

• ClientCommand extends BaseCommand
  This means all the command-line plumbing (argument handling, execution flow, error handling) is already baked into the toolkit. The client doesn’t need to re-write it.

• Arguments args
  The Arguments class is like the command-line brain. It contains:

  • The list of arguments and parameters passed by the user.

  • Utility methods to check which command is being processed.

  • Hooks to proceed with the right action accordingly.

• Mapper mapper
  The Mapper is an abstract class that clients must extend. Its role is to:

  • Accept the Arguments object.

  • Define different types of application server profiles.

  • Provide a description list for each property.

By doing this, clients can leverage all the toolkit’s base functionality while injecting their own logic for product-specific commands.

Think of it as a “template method” pattern in action — the framework defines the structure, while the client fills in the details.

Conclusion:

The Configuration Manager Tool with its Dual Mode Toolkit offers a flexible and extensible way for enterprises to configure and manage application server profiles. By supporting both GUI-based interactions for intuitive usage and CLI-based toolkits for automation and scripting, it empowers clients to adopt the mode that best suits their operational needs.

Clients can extend core classes like BasePanel in the GUI toolkit or BaseCommand in the CLI toolkit, passing their own arguments and mapping logic to achieve tailored behaviour while still benefiting from the underlying framework. This balance between standardized base components and client-driven extensibility is what makes the tool powerful.

In essence, the dual toolkit approach ensures that whether a client prioritizes usability, automation, or integration into existing workflows, the Configuration Manager Tool adapts seamlessly. The architecture not only reduces redundancy and effort but also promotes scalability, maintainability, and long-term adaptability in enterprise environments.