[wildfly-dev] question 2 sec boot time of WISE

[Andrig Miller]

Okay, good.

Thanks Brian.

Andy

On Wed, Aug 31, 2016 at 2:24 PM, Brian Stansberry <
brian.stansberry at redhat.com> 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 <anmiller at 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 at redhat.com>
> wrote:
> >
> > > On Aug 30, 2016, at 11:15 AM, Rebecca Searls <rsearls at 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 at 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 at lists.jboss.org
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160831/99a0d7a5/attachment.html