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/679fad6e3f9244f1c1caf7507...
[3]
https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox...
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