<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 5, 2018 at 8:48 AM, Rostislav Svoboda <span dir="ltr"><<a href="mailto:rsvoboda@redhat.com" target="_blank">rsvoboda@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> Hi everyone,<br>
><br>
> I would like to outline a brief JBoss MSC Plans for Year 2018.<br>
><br>
> Goals defined below address both:<br>
> * Cloud First Effort<br>
> - Reduce WildFly memory footprint<br>
> - Speed up WildFly boot time<br>
> * Potential Migration to MSC 2<br>
><br>
> MSC Library Goals:<br>
> * SHORT TERM GOALS (MSC 1.2.x, 1.3.x)<br>
> [1] simplify MSC state machine - deprecate useless MSC internal states<br>
> (e.g. REMOVED, WONT_START, WAITING, REMOVING, STOPPING maybe others)<br>
> [2] deprecate API exposing MSC internals<br>
> (e.g. replace ServiceListener with LifecycleListener)<br>
> [3] deprecate MSC Values, Injections & Injectors and provide alternative API<br>
> (alternative API should have same minimalistic memory requirements like MSC<br>
> 2)<br>
> * LONG TERM GOALS (MSC 1.4.x)<br>
> [4] remove deprecated APIs and all deprecated stuff<br>
<br>
</span>Could you map MSC 1.2.x, 1.3.x and 1.4.x to planned WF 12/13/14/15 releases ?<br></blockquote><div><br></div><div>MSC 1.2.x will become a maintainance branch for EAP 7.1 stream.<br></div><div>According to our plans (David wants to bring in new ThreadPool implementation)</div><div>MSC 1.3.x should make it to WildFly 12.</div><div>MSC 1.4.x should make it to WildFly that will be the baseline for next</div><div>major EAP version following EAP based on WildFly 12.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Especially interested in MSC 1.4.x due to removal of deprecated stuff.<br>
<br>
Thank you.<br>
Rostislav<br>
<span><br>
> WildFly MSC Integration Goals:<br>
> + SHORT TERM GOALS (WildFly 12)<br>
> * replace ServiceListeners with LifecycleListeners (LifecycleListeners don't<br>
> expose MSC internals)<br>
> * eliminate MSC optional dependencies from WildFLy Core<br>
> * eliminate MSC Values, Injections & Injectors and migrate to alternative API<br>
> * WildFly Management Layer should not expose MSC APIs as its public API<br>
> (complicates potential migration to MSC2 and breaks encapsulation)<br>
> + LONG TERM GOALS (WildFly versions targeting next major EAP)<br>
> * eliminate MSC optional dependencies from WildFly (probably via<br>
> Capabilities)<br>
> (MSC Optional Dependencies have been fixed recently but there's still<br>
> performance issue<br>
> - in worst case scenario if service A has N optional dependencies<br>
> it may happen service A is restarted N times before it is stabilized in UP<br>
> state)<br>
><br>
> Feedback and comments more than welcome!<br>
><br>
> --<br>
> Rio<br>
><br>
><br>
</span>> ______________________________<wbr>_________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/wildfly-dev</a><br>
</blockquote></div><br><br clear="all">-- <br><div class="m_-6523209164866545598gmail_signature" data-smartmail="gmail_signature"><div>Rio<br></div></div>
</div></div>