question 2 sec boot time of WISE

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: question 2 sec boot time of WISE

Brian Stansberry

> On Sep 12, 2016, at 10:48 AM, Alessio Soldano <[hidden email]> wrote:
>
> Il 12/09/2016 17:43, Brian Stansberry ha scritto:
>> What you are doing in wise-sandbox is different from what would be involved with adding a context to the management interface. It’s integrating using the WebHost concept, which then brings in EE related APIs (servlets etc.)
> :)
>>
>> For what you’re doing to be proper, undertow would need to agree to expose WebHost as a proper capability and agree to support the entire API as a reliable contract.
> OK, just note that webservices subsystem already relies on WebHost almost the same way to support JAX-WS Endpoint.publish() API and XTS integration ;-)
>

That’s good. My comment above is kind of a general one. Where we have custom integrations between parts of the server those should be turned into proper capability-defined contracts. For sure we should do that before adding new ones. At a glance this WebHost stuff looks quite amenable to that since it’s a separate SPI from undertow. It may just be a matter of documenting the capability in https://github.com/wildfly/wildfly-capabilities and adding a small bit to undertow to expose it properly as a capability.

>> To integrate with the management interface we’d need to develop a different contract
> Is this option anything we are going to actually explore?

Not any time in the next few months, no.

>
> Cheers
> Alessio
>
>
>>
>>
>>> On Sep 12, 2016, at 10:12 AM, Alessio Soldano <[hidden email]> wrote:
>>>
>>> Hi Darran,
>>> thanks for the feedback, but I'm not sure I really understand what you
>>> mean, can you give us few more details / explanations?
>>>
>>> Thanks
>>> Alessio
>>>
>>> Il 12/09/2016 16:50, Darran Lofthouse ha scritto:
>>>> Once a subsystem is adding it's own web app programatcially does make me
>>>> think we can't be far off being able to dynamically register it on the
>>>> HTTP management interface (Standalone Mode), so rather than updating the
>>>> configuration model for the management interface the additional context
>>>> is defined in the subsystem that added it.
>>>>
>>>> On 12/09/16 13:59, Alessio Soldano 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
>>>>> [2]
>>>>> https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701
>>>>> [3]
>>>>> 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
>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> --
>>> Alessio Soldano
>>> Web Service Lead, JBoss
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: question 2 sec boot time of WISE

Stuart Douglas
In reply to this post by Alessio Soldano
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?

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.

Stuart

On Mon, Sep 12, 2016 at 10:59 PM, Alessio Soldano <[hidden email]> 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
[2]
https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701
[3]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[2]
https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701
[3]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
Alessio Soldano
Web Service Lead, JBoss

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: question 2 sec boot time of WISE

Stuart Douglas


On Tue, Sep 13, 2016 at 8:44 AM, Alessio Soldano <[hidden email]> wrote:
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?

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).

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.

Stuart

 

Thanks
Alessio



Stuart

On Mon, Sep 12, 2016 at 10:59 PM, Alessio Soldano <[hidden email]> 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
[2]
https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701
[3]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
Alessio Soldano
Web Service Lead, JBoss


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: question 2 sec boot time of WISE

Tristan Tarrant
In reply to this post by Darran Lofthouse
On 12/09/16 17:26, Darran Lofthouse wrote:
> But say the subsystem could obtain a reference to the HTTP management
> interface, after creating the app it could register it as a new context
> on the management interface and be accessible on port 9990.

Having the ability to register custom handlers on the management
interface is something we need. Is there a tracking Jira ?

Tristan

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: question 2 sec boot time of WISE

Brian Stansberry

> On Sep 13, 2016, at 8:12 AM, Tristan Tarrant <[hidden email]> wrote:
>
> On 12/09/16 17:26, Darran Lofthouse wrote:
>> But say the subsystem could obtain a reference to the HTTP management
>> interface, after creating the app it could register it as a new context
>> on the management interface and be accessible on port 9990.
>
> Having the ability to register custom handlers on the management
> interface is something we need. Is there a tracking Jira ?
>

https://issues.jboss.org/browse/WFCORE-1742

> Tristan
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12