question 2 sec boot time of WISE

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

question 2 sec boot time of WISE

Rebecca Searls

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?

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?

1. lazy deployment of the utility
2. Only provide it in standalone-full.xml
3. Handle it the way xts subsystem was with a standalone-xts conf


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

jtgreene
Administrator

> On Aug 30, 2016, at 11:15 AM, Rebecca Searls <[hidden email]> 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

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

>
>
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Andrig Miller
Another point that I would like to add here, is that one of the options really flies in the face of another goal we have, which is not having many configuration files, like we used to.  I'm a little concerned over things like *.conf files being added.

Andy

On Wed, Aug 31, 2016 at 12:51 PM, Jason Greene <[hidden email]> wrote:

> On Aug 30, 2016, at 11:15 AM, Rebecca Searls <[hidden email]> 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

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

>
>
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Brian Stansberry
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”.

> On Aug 31, 2016, at 3:09 PM, Andrig Miller <[hidden email]> wrote:
>
> Another point that I would like to add here, is that one of the options really flies in the face of another goal we have, which is not having many configuration files, like we used to.  I'm a little concerned over things like *.conf files being added.
>
> Andy
>
> On Wed, Aug 31, 2016 at 12:51 PM, Jason Greene <[hidden email]> wrote:
>
> > On Aug 30, 2016, at 11:15 AM, Rebecca Searls <[hidden email]> 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
>
> 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
>
> >
> >
> > 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> Andrig (Andy) T. Miller
> Global Platform Director, Middleware
> Red Hat, Inc.
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Brian Stansberry
In reply to this post by jtgreene
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.

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

>
> 2) The deployment being listed in the user’s view of deployments, which is only supposed to represent what the user interacts with

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.

>
> 1) EJB is required, but there is likely no error indicating that EJB isn’t present, the annotated class will just be ignored.

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.

>
> 3) A mandatory port hand-off in the UI flow

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 <[hidden email]> wrote:
>
>
>> On Aug 30, 2016, at 11:15 AM, Rebecca Searls <[hidden email]> 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
>
> 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
>
>>
>>
>> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Andrig Miller
In reply to this post by Brian Stansberry
Okay, good.

Thanks Brian.

Andy

On Wed, Aug 31, 2016 at 2:24 PM, Brian Stansberry <[hidden email]> wrote:
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”.

> On Aug 31, 2016, at 3:09 PM, Andrig Miller <[hidden email]> wrote:
>
> Another point that I would like to add here, is that one of the options really flies in the face of another goal we have, which is not having many configuration files, like we used to.  I'm a little concerned over things like *.conf files being added.
>
> Andy
>
> On Wed, Aug 31, 2016 at 12:51 PM, Jason Greene <[hidden email]> wrote:
>
> > On Aug 30, 2016, at 11:15 AM, Rebecca Searls <[hidden email]> 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
>
> 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
>
> >
> >
> > 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> Andrig (Andy) T. Miller
> Global Platform Director, Middleware
> Red Hat, Inc.
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat






--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

jtgreene
Administrator
In reply to this post by Brian Stansberry


> On Aug 31, 2016, at 4:51 PM, Brian Stansberry <[hidden email]> 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.

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.

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Brian Stansberry

> On Aug 31, 2016, at 6:12 PM, Jason T. Greene <[hidden email]> wrote:
>
>
>
>> On Aug 31, 2016, at 4:51 PM, Brian Stansberry <[hidden email]> 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

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

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Alessio Soldano
In reply to this post by jtgreene
Il 01/09/2016 01:12, Jason T. Greene ha scritto:
> On the other hand i suspect this relies on CXF to generate the client
> side messages, so perhaps it would be a complex transition.

CXF is needed to generate the SOAP message on "client" side. But that
could still run on the server. What needs to be on the actual client
(browser) is the generation of the graphical representation of the
message. IOW, the user is not presented with a static page, but with
something that 1) depends on the previously selected service endpoint 2)
depends on how the user interacts with it (for example, say you have
arrays of complex types in the schema, the user can add and remove items
in the array and the page has to show the proper structure). The core of
the application generates a generic tree view of the request message,
which is modifiable according to the schema constraints (allowed types,
optional items, complex structures, collections, etc.); the GUI allows
the user to fill in data into that tree and modify it before eventually
pressing the invoke button and hence telling the core to convert the
tree back into actual arguments to make the ws invocation.
Not sure this fits with your concept of serving just static files, but
I'll let Rebecca comment here as she's worked on the GUI.

Cheers
Alessio

--
Alessio Soldano
Web Service Lead, JBoss

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Darran Lofthouse
In reply to this post by Brian Stansberry


On 01/09/16 01:23, Brian Stansberry wrote:

>
>> On Aug 31, 2016, at 6:12 PM, Jason T. Greene <[hidden email]> wrote:
>>
>>
>>
>>> On Aug 31, 2016, at 4:51 PM, Brian Stansberry <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]>
> >> wrote:
> >>
> >>
> >>
> >>> On Aug 31, 2016, at 4:51 PM, Brian Stansberry
> >>> <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Rebecca Searls
In reply to this post by Alessio Soldano


----- Original Message -----

> From: "Alessio Soldano" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, September 1, 2016 3:40:52 AM
> Subject: Re: [wildfly-dev] question 2 sec boot time of WISE
>
> Il 01/09/2016 01:12, Jason T. Greene ha scritto:
> > On the other hand i suspect this relies on CXF to generate the client
> > side messages, so perhaps it would be a complex transition.
>
> CXF is needed to generate the SOAP message on "client" side. But that
> could still run on the server. What needs to be on the actual client
> (browser) is the generation of the graphical representation of the
> message. IOW, the user is not presented with a static page, but with
> something that 1) depends on the previously selected service endpoint 2)
> depends on how the user interacts with it (for example, say you have
> arrays of complex types in the schema, the user can add and remove items
> in the array and the page has to show the proper structure). The core of
> the application generates a generic tree view of the request message,
> which is modifiable according to the schema constraints (allowed types,
> optional items, complex structures, collections, etc.); the GUI allows
> the user to fill in data into that tree and modify it before eventually
> pressing the invoke button and hence telling the core to convert the
> tree back into actual arguments to make the ws invocation.
> Not sure this fits with your concept of serving just static files, but
> I'll let Rebecca comment here as she's worked on the GUI.
>

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.


> Cheers
> Alessio
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Rebecca Searls

Are there any details about what elements from the Wise war are taking the longest during bootup?
Or is there a specific logging setting or package name I should add to my local wfly to see more detail?



----- Original Message -----

> From: "Rebecca Searls" <[hidden email]>
> To: "Alessio Soldano" <[hidden email]>
> Cc: [hidden email]
> Sent: Thursday, September 1, 2016 11:36:14 AM
> Subject: Re: [wildfly-dev] question 2 sec boot time of WISE
>
>
>
> ----- Original Message -----
> > From: "Alessio Soldano" <[hidden email]>
> > To: [hidden email]
> > Sent: Thursday, September 1, 2016 3:40:52 AM
> > Subject: Re: [wildfly-dev] question 2 sec boot time of WISE
> >
> > Il 01/09/2016 01:12, Jason T. Greene ha scritto:
> > > On the other hand i suspect this relies on CXF to generate the client
> > > side messages, so perhaps it would be a complex transition.
> >
> > CXF is needed to generate the SOAP message on "client" side. But that
> > could still run on the server. What needs to be on the actual client
> > (browser) is the generation of the graphical representation of the
> > message. IOW, the user is not presented with a static page, but with
> > something that 1) depends on the previously selected service endpoint 2)
> > depends on how the user interacts with it (for example, say you have
> > arrays of complex types in the schema, the user can add and remove items
> > in the array and the page has to show the proper structure). The core of
> > the application generates a generic tree view of the request message,
> > which is modifiable according to the schema constraints (allowed types,
> > optional items, complex structures, collections, etc.); the GUI allows
> > the user to fill in data into that tree and modify it before eventually
> > pressing the invoke button and hence telling the core to convert the
> > tree back into actual arguments to make the ws invocation.
> > Not sure this fits with your concept of serving just static files, but
> > I'll let Rebecca comment here as she's worked on the GUI.
> >
>
> 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.
>
>
> > Cheers
> > Alessio
> >
> > --
> > Alessio Soldano
> > Web Service Lead, JBoss
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Alessio Soldano
In reply to this post by jtgreene
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


--
Alessio Soldano
Web Service Lead, JBoss

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Alessio Soldano
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/679fad6e3f9244f1c1caf7507434dff0fbfe5701
[3]
https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77

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


--
Alessio Soldano
Web Service Lead, JBoss

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Darran Lofthouse
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/679fad6e3f9244f1c1caf7507434dff0fbfe5701
> [3]
> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77
>
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Alessio Soldano
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/679fad6e3f9244f1c1caf7507434dff0fbfe5701
>> [3]
>> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77
>>
>> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Alessio Soldano
Web Service Lead, JBoss

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Darran Lofthouse
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:

> 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/679fad6e3f9244f1c1caf7507434dff0fbfe5701
>>> [3]
>>> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77
>>>
>>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Brian Stansberry
In reply to this post by Alessio Soldano
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.

To integrate with the management interface we’d need to develop a different contract.


> On Sep 12, 2016, at 10:12 AM, Alessio Soldano <[hidden email]> 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/679fad6e3f9244f1c1caf7507434dff0fbfe5701
>>> [3]
>>> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77
>>>
>>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: question 2 sec boot time of WISE

Alessio Soldano
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 ;-)

> To integrate with the management interface we’d need to develop a different contract
Is this option anything we are going to actually explore?

Cheers
Alessio


>
>
>> On Sep 12, 2016, at 10:12 AM, Alessio Soldano <[hidden email]> 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/679fad6e3f9244f1c1caf7507434dff0fbfe5701
>>>> [3]
>>>> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77
>>>>
>>>> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Alessio Soldano
>> Web Service Lead, JBoss
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Alessio Soldano
Web Service Lead, JBoss

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12
Loading...