<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 13, 2016 at 8:44 AM, Alessio Soldano <span dir="ltr">&lt;<a href="mailto:asoldano@redhat.com" target="_blank">asoldano@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <div>Il 13/09/2016 00:27, Stuart Douglas ha
      scritto:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>How are you going to handle security? At the moment WebHost
          does not really allow you to set security domains etc. Are you
          planning on expanding it&#39;s functionality to cover this?<br>
        </div>
      </div>
    </blockquote></span>
    oh, didn&#39;t notice that, I expected to setup security providing the
    same conf options that were in web.xml/jboss-web.xml in the war
    deployment. This said, I see that
    io.undertow.servlet.api.<wbr>DeploymentInfo has that stuff, so I assume
    it should be possible to expand WebHostService and
    WebDeploymentBuilder a bit, similarly to what I did for supporting
    welcome pages.<span class=""><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>BTW in many ways WebHost is a bit of a legacy artifact. It
          was introduced back when we supported both JBoss Web and
          Undertow. It may end up being better to just use Undertow
          API&#39;s directly, as I don&#39;t know if we really need the
          abstraction any more.<br>
        </div>
      </div>
    </blockquote></span>
    What do you mean, directly doing the same that WebHostService does
    with the Undertow api in a service of mine?<br></div></blockquote><div><br></div><div>I am more thinking about exposing the Undertow DeploymentInfo API directly, although I guess you would still need something similar to the WebHost service to provide integration with security domain etc (as that is provided by the Undertow subsystem, not Undertow itself).<br><br></div><div>Basically to add support for security we are going to need some way of specifying the constraints etc, which the DeploymentInfo API already does. It seems kind of silly to duplicate this.<br></div><div><br></div><div>Stuart<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <br>
    Thanks<span class="HOEnZb"><font color="#888888"><br>
    Alessio</font></span><div><div class="h5"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        Stuart<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Mon, Sep 12, 2016 at 10:59 PM,
          Alessio Soldano <span dir="ltr">&lt;<a href="mailto:asoldano@redhat.com" target="_blank">asoldano@redhat.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;ve
            invested some hours of Sunday on hacking a prototype doing
            more or<br>
            less what I explained below; see [1] . It builds using
            latest wise<br>
            snapshots, which are on nexus, anyway the changes I applied
            to wise-gui<br>
            are [2]<br>
            In particular, there&#39;s a service [3] that starts the webapp<br>
            programmatically; there&#39;s no more war deployment, the app is
            split into<br>
            3 modules plus few plain contents (html, js, css) in /wise.<br>
            I see no sensible change in boot time compared to when
            there&#39;s no wise<br>
            susbystem.<br>
            Any comments? shall we spend a bit of time cleaning up the
            prototype and<br>
            sending a PR with this new approach?<br>
            <br>
            Thanks<br>
            Alessio<br>
            <br>
            [1]<br>
            <a href="https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox" rel="noreferrer" target="_blank">https://github.com/wildfly/wil<wbr>dfly/compare/master...asoldano<wbr>:wise-sandbox</a><br>
            [2]<br>
            <a href="https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701" rel="noreferrer" target="_blank">https://github.com/asoldano/wi<wbr>se-gwt-gui/commit/679fad6e3f92<wbr>44f1c1caf7507434dff0fbfe5701</a><br>
            [3]<br>
            <a href="https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77" rel="noreferrer" target="_blank">https://github.com/wildfly/wil<wbr>dfly/compare/master...asoldano<wbr>:wise-sandbox#diff-0623bdf83c3<wbr>d80b3ba52d0b82f89efc7R77</a><br>
            <div>
              <div><br>
                Il 05/09/2016 00:20, Alessio Soldano ha scritto:<br>
                &gt; Il 31/08/2016 20:51, Jason Greene ha scritto:<br>
                &gt;&gt;&gt; 1. lazy deployment of the utility<br>
                &gt;&gt; What did you have in mind? This sounds tricky.
                You could perhaps have the subsystem register an http
                handler that dynamically installs the server, but if you
                are going that far it’s best to just register the
                components directly as part of the subsystem than in a
                deployment.<br>
                &gt; I&#39;ve thought about this a bit tonight...yes, the
                wise.war could be<br>
                &gt; exploded, its classes moved into the subsystem and
                the gtw and wise core<br>
                &gt; jars left as external libs in their own modules. As
                for the lazy start,<br>
                &gt; how about a service in the new wise subsystem that
                uses the WebHost<br>
                &gt; service to start the servlet app (would need to
                provide it with a<br>
                &gt; classloader including the required external libs
                mentioned before)? That<br>
                &gt; could be triggered (on/off) by operations in the
                subsystem. Then the<br>
                &gt; user would basically have to enable the gui using
                management (hal, cli).<br>
                &gt;<br>
                &gt; Cheers<br>
                &gt; Alessio<br>
                &gt;<br>
                &gt;<br>
                <br>
                <br>
                --<br>
                Alessio Soldano<br>
                Web Service Lead, JBoss<br>
                <br>
                ______________________________<wbr>_________________<br>
                wildfly-dev mailing list<br>
                <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
                <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/wildfly-dev</a></div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <p><br>
    </p>
    <pre cols="72">-- 
Alessio Soldano
Web Service Lead, JBoss</pre>
  </div></div></div>

</blockquote></div><br></div></div>