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

[Darran Lofthouse]

On 01/09/16 01:23, Brian Stansberry wrote:
>
>> On Aug 31, 2016, at 6:12 PM, Jason T. Greene <jason.greene at redhat.com> wrote:
>>
>>
>>
>>> On Aug 31, 2016, at 4:51 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>
>>>
>>>> For example the GWT app could be mostly client side, with no GWT-RPC
>>>
>>> That part is still involves a deployment though, right? Even if it’s just like HAL and just static files, making it downloadable means either a deployment or some custom integration into the undertow subsystem. The alternative is to make it a special context on the management http interace like we do for the HAL console. Or one way or the other make it part of HAL. But my impression of this app is despite the bit of integration into HAL, it’s not really a “management” app and is meant to be usable outside of HAL. A "dev-ops" admin may use it, hence the integration with HAL, or a “dev" may use it, but a classic “ops” admin is not going to use it and we don’t want to force the “dev” user to be given admin permissions in order to use it.
>>>
>>> If the downloadable part is a deployment but also an patchable official part of the software we for sure don’t want it deployed via the deployments/ folder.
>>
>> By deployment I was referring to going through the deployment process, and registered as a deployment node, in order to start. With client side JS it's just static files and trivial to install wherever is desired. For example, the subsystem could register a handler as part of the server, or the web services subsystem could register a handler as part of a *user* deployment (a special opt in sub URL) or it could be a direct HAL plugin, or yet another app on 9990 and thus usable on a DC.
>>
> Yes. I went to dinner before getting a chance to reply to myself saying I didn’t want to distract from your main point about how to integrate, since I realized that if all the “deployment” part was was serving static files, having the subsystem integrate a simple handler into the webserver is a perfectly good approach.
>
>> As to roles, sure I doubt a standard admin would do much with this. I could maybe see  an operator perhaps verifying service functionality, or perhaps troubleshooting. It definitely seems more of a development use case. In a pure client side solution you aren't really introducing the need for a permission per se because it runs straight from the client browser, with no management API interaction other than discovering the port.
>>
>
> True. We’d need to restructure how the “9090” interface is set up though. Now it’s the “http management” interface with a single security realm. If it became something more general purpose with different security policies for different contexts that would require a different config style

I wouldn't worry too much about security realms as they are deprecated 
and TBH will make everyone's life easier if no new resource make use of 
them.

The replacement security architecture is however better suited to having 
different authentication policies for different entry points to the 
server and even if those entry points end up calling a common back end 
we have formal support for security domain to security domain identity 
propagation / transformation.

Add to that using the same security architecture for applications and 
management makes it much easier to mix and match as well.

>
>> On the other hand i suspect this relies on CXF to generate the client side messages, so perhaps it would be a complex transition.
>>
>> -Jason
>>
>