search JMRI:

Development tools

• Getting the code via CVS
• CVS FAQs
• Building with Ant
• Building with NetBeans
• Building with XCode
• Building with Eclipse
• Building with JBuilder

Structure

• Introduction
• Application Structure
• Names and Naming
• Code Structure Patterns
• Swing Structure
• External Connection Structure
• Threads
• Use of XML
• Web Site
• JavaDocs
  • Name Index
  • Packages
  • Class heirarchy

Techniques and Standards

• Recommended Practices
• Continuous Integration
• Internationalization
• Logging & Error Handling
• Unit testing with JUnit
• Documentation with JavaDoc and UML
• Run the FindBugs static analysis tool
• Providing help with JavaHelp
• Portable Filename Method
• XML Persistance

How To

• Extend with Plugins
• Add a New Type
• Add a New System

Functional Info

• Turnout Feedback
• Network Connections
• How the startup scripts work

Background Info

• Technology Roadmap
• Survey of JVM Capabilities
• Usage Poll, Spring 2007

JMRI: System Structure

Historically, systems weren't arranged this way, so existing code may not be a good example.

Want to expose very little above the jmrix package.

Basic core is communications code, often a "TrafficManager"

Tools should go in a swing sub-package

Specific connection types for a single protocol can go in subdirectories.

Role of ConnectionConfig, SystemConnectionMemo

Deprecated ActiveFlag

Initialization Sequence

This section describes the LocoNet implementation of the new (2010) configuration system. "NN" refers to e.g. the locobuffer, pr3 or similar connection-specific class.

1. jmri.jmrix.loconet.NN.configurexml.ConnectionConfigXml is invoked by the configurexml mechanism when the specific class is named in an XML input file.
2. The ConnectionConfigXml object is a child of the jmri.jmrix.configurexml.AbstractConnectionConfigXml class, which invokes the getInstance() method of it (not a static method) in its load() method to load the "adapter" member variable with a specific *Adapter class, e.g. MS100Adapter.
3. Later, after the port is (hopefully) up, AbstractConnectionConfigXml invokes the Adapter's configure() method.
4. That Adapter configure() method does, in order (this has now been refactored into LocoNetSystemConnectionMemo itself, so this list has to be reordered)
   1. sets up Packetizer/port/etc as needed
   2. configureCommandStation() from LnPortController
   3. configureManagers() from LnPortController, but overridden in e.g. PR3Adapter.
   4. does any other initialization of it's own, e.g. startThreads()

      At this point, the system is basically up and ready for operation.

   5. Finally, a jmri.jmrix.loconet.LocoNetSystemConnectionMemo object is created and registered with the InstanceManager.
5. Later, jmri.jmrix.ActiveSystemsMenu and/or jmri.jmrix.SystemsMenu wants to create user menus, and finds the LocoNetSystemConnectionMemo object in the InstanceManager
6. The menu code asks that specific SystemConnectionMemo object to create and return the menu. It does so, in the process connecting each Action to itself so that the individual tools will be able to connect to the proper e.g. TrafficController, SlotMonitor, etc.
7. When an Action is fired later on, the invoked class(es) enquire of the LocoNetSystemConnectionMemo when they need a resource, instead of referring to an instance() method in the resource's class.

To adapt a type, e.g. Turnout:

1. Basic manager needs to have getSystemPrefix in addition to letter
2. ProxyManager has to check for system prefix, not letter

---