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

On 01/09/16 01:23, Brian Stansberry wrote: > >> On Aug 31, 2016, at 6:12 PM, Jason T. Greene <jason.greene(a)redhat.com&gt; >> wrote: >> >> >> >>> On Aug 31, 2016, at 4:51 PM, Brian Stansberry >>> <brian.stansberry(a)redhat.com&gt; 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 >> > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev