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 <jason.greene(a)redhat.com>
wrote:
> On Aug 30, 2016, at 11:15 AM, Rebecca Searls <rsearls(a)redhat.com> 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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.