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

[Rostislav Svoboda]

Hi.

Can be WISE pulled back in, but do not include the subsystem definition into standard standalone*.xml ?
WISE would be made available via cli - subsystem add+enable

Future / wish: "Enable WISE" button in webconsole to have even better experience than just CLI
  - e.g. WISE button near ws subsystem configuration + runtime information

Future (probably/maybe far far away): Redesign of integration based on conclusions from the discussion about integration approaches for cases like this.

Rostislav

----- Original Message -----
> 
> 
> 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
> >>
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev