[wildfly-dev] question 2 sec boot time of WISE

[Alessio Soldano]

Il 13/09/2016 00:27, Stuart Douglas ha scritto:
> 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's functionality to cover this?
oh, didn'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.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.

>
> 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's directly, as I don't 
> know if we really need the abstraction any more.
What do you mean, directly doing the same that WebHostService does with 
the Undertow api in a service of mine?

Thanks
Alessio

>
> Stuart
>
> On Mon, Sep 12, 2016 at 10:59 PM, Alessio Soldano <asoldano at redhat.com 
> <mailto:asoldano at redhat.com>> wrote:
>
>     I've invested some hours of Sunday on hacking a prototype doing
>     more or
>     less what I explained below; see [1] . It builds using latest wise
>     snapshots, which are on nexus, anyway the changes I applied to
>     wise-gui
>     are [2]
>     In particular, there's a service [3] that starts the webapp
>     programmatically; there's no more war deployment, the app is split
>     into
>     3 modules plus few plain contents (html, js, css) in /wise.
>     I see no sensible change in boot time compared to when there's no wise
>     susbystem.
>     Any comments? shall we spend a bit of time cleaning up the
>     prototype and
>     sending a PR with this new approach?
>
>     Thanks
>     Alessio
>
>     [1]
>     https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox
>     <https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox>
>     [2]
>     https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701
>     <https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701>
>     [3]
>     https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77
>     <https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77>
>
>     Il 05/09/2016 00:20, Alessio Soldano ha scritto:
>     > Il 31/08/2016 20:51, Jason Greene ha scritto:
>     >>> 1. lazy deployment of the utility
>     >> 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.
>     > I've thought about this a bit tonight...yes, the wise.war could be
>     > exploded, its classes moved into the subsystem and the gtw and
>     wise core
>     > jars left as external libs in their own modules. As for the lazy
>     start,
>     > how about a service in the new wise subsystem that uses the WebHost
>     > service to start the servlet app (would need to provide it with a
>     > classloader including the required external libs mentioned
>     before)? That
>     > could be triggered (on/off) by operations in the subsystem. Then the
>     > user would basically have to enable the gui using management
>     (hal, cli).
>     >
>     > Cheers
>     > Alessio
>     >
>     >
>
>
>     --
>     Alessio Soldano
>     Web Service Lead, JBoss
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>


-- 
Alessio Soldano
Web Service Lead, JBoss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160913/f7028d95/attachment.html