Right, so the big issue is we have had a long standing policy to: a) Avoid adding any significant time to boot, as that was a major goal of AS7+ b) To not include shipped app server functionality in deployments. This is partly because of (a), since scanning and discovery and deployment chain processing has a cost that is unnecessary for code that is part of the server itself. However, it’s also because solutions that require deployments limit the integration quality of the system. Some examples of (b) include 1) EJB is required, but there is likely no error indicating that EJB isn’t present, the annotated class will just be ignored. 2) The deployment being listed in the user’s view of deployments, which is only supposed to represent what the user interacts with 3) A mandatory port hand-off in the UI flow Another option to throw out there, is we could keep this as-is and put it into wildfly-extras. 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. That would add 63% to the boot time so not really a good option. That might be acceptable. However, is there a reason it’s a deployment in the first place? I mean I can understand keeping it as a deployment to decouple it from the server, but once you are making it part of the server itself, why not integrate it that way. For example the GWT app could be mostly client side, with no GWT-RPC, and the backend debugging facilities could be extra components registered during web service deployment. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

For that one I don’t think the intent was any kind of *.conf. I read it more as “a standalone.xml variant like the existing docs/examples/configs/standalone-xts.xml used to show usage of the xts subsystem”. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat

Jason, I’m going to cut-and-paste parts of your post and respond to them that way as it helps me have a logical flow. 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. Agreed. If we keep it as a deployment installed by a subsystem we need a proper notion of a system-deployment or something like that. Roughly a) separate tree in the management model; looks like the deployment tree in terms of child resources, e.g. /sysystem-deployment=foo.war/subsystem=undertow etc but it’s not mixed in with the normal deployments b) Any API to add/remove/deploy/undeploy is private, not published in the read-resource-description output. Meant for internal use. c) Handled in terms of deployment processing like a normal deployment, but the DeploymentUnit has a flag or attachment so DUPs can know it’s a system deployment. So, for example we don’t complain about use of private/unsupported/deprecated modules. The first integration of wise resulted in a bunch of log warns that for sure would need to be made to go away. This can be mitigated with good use of capabilities and requirements; the resource that makes something available is a capability and it requires other things it needs. I say “mitigated” not “solved” because it’s still possible that the detailed configs of required capabilitiles would not be compatible with the deployment’s needs. Yeah, that’s kind of ugly. I think it’s the result of trying to integrate a more “dev” tool into a more “admin” tool. > On Aug 31, 2016, at 1:51 PM, Jason Greene <jason.greene(a)redhat.com&gt; wrote: > > >> On Aug 30, 2016, at 11:15 AM, Rebecca Searls <rsearls(a)redhat.com&gt; wrote: >> >> >> Wise was pulled from wfly because it was adding 2 sec to boot time.   >> Wise is a utility with a GWT interface. It was added to wfly as an extension. >> It is provided as a WAR file. >> >> Is there any more detail of the boot of this app? > > Right, so the big issue is we have had a long standing policy to: > > a) Avoid adding any significant time to boot, as that was a major goal of AS7+ > b) To not include shipped app server functionality in deployments. This is partly because of (a), since scanning and discovery and deployment chain processing has a cost that is unnecessary for code that is part of the server itself. However, it’s also because solutions that require deployments limit the integration quality of the system. > > Some examples of (b) include > >> >> >> Here are a few options we have thought of. >> What would be the best way to address this so that the user can have access to this tool? >> > > Another option to throw out there, is we could keep this as-is and put it into wildfly-extras. > >> 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. > >> 2. Only provide it in standalone-full.xml > > That would add 63% to the boot time so not really a good option. > >> 3. Handle it the way xts subsystem was with a standalone-xis conf > > That might be acceptable. > > However, is there a reason it’s a deployment in the first place? I mean I can understand keeping it as a deployment to decouple it from the server, but once you are making it part of the server itself, why not integrate it that way. For example the GWT app could be mostly client side, with no GWT-RPC, and the backend debugging facilities could be extra components registered during web service deployment. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat

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. 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 -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat

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

----- Original Message ----- I'm assuming its the gwt-servlet that is taking most the bootup time. I don't see that Wise can have a lot of static code. I'm investigating using the restyGWT api to see if that can resolve some of these issues.

Il 31/08/2016 20:51, Jason Greene ha scritto: 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

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:

It was more a general comment for domain management rather than a direct comment on your PR. 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. Not saying this is something you should go ahead and do ;-) But it does open up options for adding custom management endpoints to that interface. Subsystems can also be defined on host controllers now so may even be options for domain mode. Darran. On 12/09/16 16:12, Alessio Soldano wrote:

https://issues.jboss.org/browse/WFCORE-1742 -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat

Il 12/09/2016 17:43, Brian Stansberry ha scritto: :) OK, just note that webservices subsystem already relies on WebHost almost the same way to support JAX-WS Endpoint.publish() API and XTS integration ;-) Is this option anything we are going to actually explore? Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss

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 <asoldano(a)redhat.com&gt; wrote:

On Tue, Sep 13, 2016 at 8:44 AM, Alessio Soldano <asoldano(a)redhat.com&gt; wrote: 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