<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <tt><br>
    </tt>
    <div class="moz-cite-prefix"><tt>On 08/01/18 10:04 PM, Brian
        Stansberry wrote:</tt><tt><br>
      </tt></div>
    <blockquote type="cite"
cite="mid:CAPhbRDag-6tBj7+dS_ew7x0-nvbj2bt7HMyY1sDdbTJyN4v7fQ@mail.gmail.com">
      <div dir="ltr"><tt>On Mon, Jan 8, 2018 at 10:08 AM, David Lloyd </tt><tt><span
            dir="ltr">&lt;<a href="mailto:david.lloyd@redhat.com"
              target="_blank" moz-do-not-send="true">david.lloyd@redhat.com</a>&gt;</span></tt><tt>
          wrote:</tt><tt><br>
        </tt>
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><tt><span
                  class="">On Mon, Jan 8, 2018 at 9:41 AM, Brian
                  Stansberry<br>
                  &lt;<a href="mailto:brian.stansberry@redhat.com"
                    moz-do-not-send="true">brian.stansberry@redhat.com</a>&gt;
                  wrote:<br>
                  &gt; On Mon, Jan 8, 2018 at 9:25 AM, David Lloyd &lt;<a
                    href="mailto:david.lloyd@redhat.com"
                    moz-do-not-send="true">david.lloyd@redhat.com</a>&gt;
                  wrote:<br>
                </span></tt><tt><span class="">&gt;&gt; I guess I wasn't
                  too clear.  I didn't mean to say there was some other<br>
                  &gt;&gt; way to detect the type.  I meant to say that
                  the type determination<br>
                  &gt;&gt; should be done *before* the overridden
                  runtime name is applied, not<br>
                  &gt;&gt; after.<br>
                  &gt;<br>
                  &gt; I'm confused now. :)<br>
                  <br>
                </span></tt><tt>Isn't this entire thread about the
                ability to use the "runtime-name"</tt><tt><br>
              </tt><tt>
                attribute to override the actual file name of the JAR? 
                I'm simply</tt><tt><br>
              </tt><tt>
                stating that the type probably should be based on the
                name of the</tt><tt><br>
              </tt><tt>
                content file, not the runtime-name.</tt><tt><br>
              </tt><tt><span class="HOEnZb"><font color="#888888"><br>
                  </font></span></tt></blockquote>
            <div><tt><br>
              </tt></div>
            <div><tt>Gotcha.</tt></div>
            <div><tt><br>
              </tt></div>
            <div><tt>We don't reliably know the name of the content
                file. For unmanaged content we should, but for managed
                content when the user adds the deployment they provide a
                stream or a url (or in theory a ModelType.BYTES
                ModelNode). It's possible to add an optional param to
                the add ops to pass in a suffix and then our standard
                clients could provide that if they are able to figure it
                out. But if that wasn't provided it would still be down
                to the suffix of the runtime name.</tt></div>
          </div>
        </div>
      </div>
    </blockquote>
    <tt>So it looks like there's no easy way to either mandate the
      suffix for runtime name, either as a new param or for the value of
      runtime-name param (backward compatibility issues), nor is there a
      credible way to get access or infer the suffix of the deployment
      for managed deployments.<br>
    </tt><tt><br>
    </tt>
    <blockquote type="cite"
cite="mid:CAPhbRDag-6tBj7+dS_ew7x0-nvbj2bt7HMyY1sDdbTJyN4v7fQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><tt><br>
              </tt></div>
            <div><tt>I also have a vague memory of some of the EE stuff
                (i.e. not our DUP code) being driven by suffixes. IOW
                even if our DUPs didn't need to get type info from the
                suffix, something in EE might. I don't recall the
                details of this though; something about default values
                of EE application and module names. Perhaps the DUPs
                could be adapted to deal with that, or perhaps not.</tt></div>
          </div>
        </div>
      </div>
    </blockquote>
    <tt>I suspect it was the EJB JNDI name requirements, which rely on
      the deployment's suffix (.ear specifically) to decide whether or
      not to use a "app-name" portion in the JNDI name for the EJB [1].
      So yes, currently, runtime-name without a suffix affects this
      semantics too. I guess, given how rarely anyone has reported this
      so far, not many use runtime-name without a (proper) suffix.<br>
      <br>
      [1]
<a class="moz-txt-link-freetext" href="https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EjbJndiBindingsDeploymentUnitProcessor.java#L111">https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EjbJndiBindingsDeploymentUnitProcessor.java#L111</a><br>
      <br>
      -Jaikiran <br>
    </tt>
  </body>
</html>