Package jmri.managers

Class AbstractProvidingProxyManager<E extends NamedBean>

Type Parameters:
E - the supported type of NamedBean
All Implemented Interfaces:
PropertyChangeListener, EventListener, PropertyChangeFirer, PropertyChangeProvider, SilenceablePropertyChangeProvider, VetoableChangeFirer, VetoableChangeProvider, Manager<E>, Manager.ManagerDataListener<E>, ProvidingManager<E>, ProxyManager<E>
Direct Known Subclasses:
ProxyIdTagManager, ProxyLightManager, ProxyReporterManager, ProxySensorManager, ProxyTurnoutManager

public abstract class AbstractProvidingProxyManager<E extends NamedBean>
extends AbstractProxyManager<E>
implements ProvidingManager<E>
Implementation of a Manager that can serves as a proxy for multiple system-specific implementations.

Automatically includes an Internal system, which need not be separately added any more.

Encapsulates access to the "Primary" manager, used by default, which is the first one provided.

Internally, this is done by using an ordered list of all non-Internal managers, plus a separate reference to the internal manager and default manager.

  • Constructor Details

  • Method Details

    • provideNamedBean

      Locate via user name, then system name if needed. If that fails, create a new NamedBean: If the name is a valid system name, it will be used for the new NamedBean. Otherwise, the makeSystemName method will attempt to turn it into a valid system name. Subclasses use this to create provider methods such as getSensor or getTurnout via casts.
      name - the user name or system name of the bean
      an existing or new NamedBean
      IllegalArgumentException - if name is not usable in a bean
    • newNamedBean

      @Nonnull public E newNamedBean​(@Nonnull String systemName, String userName) throws IllegalArgumentException
      Return an instance with the specified user or system name.

      Lookup by UserName, then provide by System Name.

      Note that two calls with the same arguments will get the same instance; there is i.e. only one Sensor object representing a given physical sensor and therefore only one with a specific system or user name.

      This will always return a valid object reference for a valid request; a new object will be created if necessary. In that case:

      • If a null reference is given for user name, no user name will be associated with the NamedBean object created; a valid system name must be provided
      • If both names are provided, the system name defines the hardware access of the desired turnout, and the user address is associated with it.
      • If a matching UserName is located, that will be returned.
      • Else If a matching SystemName is located, that will be returned.
      • Else A New Bean will be created with the given System Name. The UserName will be added to the New Bean if no existing.
      Note that it is possible to make an inconsistent request if both addresses are provided, but the given values are associated with different objects. This is a problem, and we don't have a good solution except to issue warnings. This will mostly happen if you're creating NamedBean when you should be looking them up.

      If the System Name contains the start of a specified Manager, that will be used, else the default manager will be used.

      systemName - the system name
      userName - the user name
      requested NamedBean object (never null)
      See Also:
    • makeBean

      @Nonnull protected abstract E makeBean​(Manager<E> manager, @Nonnull String systemName, String userName) throws IllegalArgumentException
      Defer creation of the proper type to the subclass.
      manager - the manager to invoke
      systemName - the system name
      userName - the user name
      a bean
      IllegalArgumentException - if unable to make.