Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-356

Make socket binding interface and port values available for use in property subsitution

    XMLWordPrintable

Details

    • Feature Request
    • Resolution: Won't Do
    • Major
    • None
    • None
    • Management
    • None

    Description

      See linked dev list thread for an example use case (remote socket binding used in an driver-specific JDBC URL).

      Some gotchas noted on the thread that need to be resolved:

      A tricky thing to deal with is interfaces and socket bindings are
      actually on-demand services. They aren't resolved until they are
      demanded. Nothing in this connection-url scenario would demand the
      socket binding, so it won't be resolved, and until it's resolved no
      system property could be set.

      That could be handled by adding an "auto-start" attribute on the
      socket-binding config. Not particularly intuitive though.

      Another thing to deal with is interface resolution. With the exception
      of the "<loopback address="127.0.0.4"/> criteria Scott added, resolving
      an interface means finding a NIC on the machine that matches the
      criteria. If that can't be done, it's an error condition. To avoid that
      there would need to be some new criteria added (e.g.
      <remote-inet-address value="10.0.0.53"/>) or an attribute added to the
      existing inet-address criteria (e.g. <inet-address value="10.0.0.53"
      local="false"/>. (There is a separate JIRA for this issue: AS7-1614)

      A minor issue relates to changing the configuration of a socket binding.
      Basically, we try and track whether you've used a particular
      SocketBinding service to open a socket; if not we let you change the
      binding config without requiring a server restart or reload. This
      connection-url stuff won't use the SocketBinding service to create a
      socket, so the binding will be editable at runtime with no
      reload/restart required. But there's no dependency relationship between
      the binding and the datasource, so that change is not going to be
      reflected in the datasource. This is just an example of the general
      problem with using system properties as an injection mechanism.

      I don't think this last point is a blocker, it just requires documentation.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              bstansbe@redhat.com Brian Stansberry
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: