On Sep 12, 2016, at 10:48 AM, Alessio Soldano
<asoldano(a)redhat.com> 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 <asoldano(a)redhat.com> 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/679fad6e3f9244f1c1caf7507...
>>>> [3]
>>>>
https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox...
>>>>
>>>> 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
>>> wildfly-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Alessio Soldano
>> Web Service Lead, JBoss
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>>
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