Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-15347 Subsystem code standardization
  3. WFLY-15385

Messaging subsystem code standardization

XMLWordPrintable

    • Icon: Sub-task Sub-task
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 25.0.0.Beta1
    • JMS
    • None

      1) Extension impls should not be constructing the ResourceDefinition tree. They should set up the root nodes, and then the ResourceDefinitions configure themselves and add their children. (An exception to this could be extensions that seek to reduce memory utilization by constructing the ResourceDefinition tree from the children working back to the root. Before any extension does that we should have a discussion of the best idioms for that so we don't end up with multiple varieties. But the existing cases I'm aware of of extensions constructing the tree in the Extension impl are not of this type; they are starting from the tree root and working to the leaves.)

      2) Custom implementations of functionality available from standard APIs should be replaced by use of the standard APIs. In particular:

      OperationContext.getCurrentAddress should be used in place of reading the address from the operation ModelNode
      OperationContext.getCurrentAddressValue should be used instead of manipulating the operation ModelNode or a PathAddress derived from it.
      ModelNode.asXXXOrNull should be used in place of custom code that does the same thing. There is a lot of this kind of code as most subsystems were written before asXXXOrNull was available.

      3) AttributeDefinition.resolveModelReference should be used when obtaining values passed to runtime services. (We already evaluated code for this, but double checking doesn’t hurt.)

      4) ResourceDefinitions that register write attribute handlers by looping through the attributes and instantiating an instance of the same handler class for each should aim to construct one handler instance outside the loop.

      5) Attributes that reference other resources must be backed by a capability and a credential reference.

      6) Stage.RUNTIME handlers that add dependencies on services from other subsystems should use the capability APIs for service wiring.

      7) Use of ModelNode.resolve in production subsystem code should be eliminated. In places where this is difficult (e.g. in xml parsers) we should discuss workarounds.

      8) Use of ModelNode.asXXX(defaultXXX), e.g. node.asBoolean(false) should replaced by plain asXXX() or asXXXorNull() in the typical cases where the node was obtained from a call to AttributeDefinition.resolveModelAttribute. The defaultXXX value should be specified as the default value of the AttributeDefinition. If that is done, the asXXX(defaultXXX) call is redundant.

      9) SimpleResourceDefinition subclasses should pass a Parameters object to the superclass constructor.

      10) Service wiring should move to the MSC 2 APIs. There may be cases where this may be problematic; if so those should be discussed.

              ehugonne1@redhat.com Emmanuel Hugonnet
              ehugonne1@redhat.com Emmanuel Hugonnet
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: