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

--

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