<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Sorry for the late reply. :(</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 9, 2019 at 12:54 PM Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com">darran.lofthouse@jboss.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Presently working on WFCORE-4360 adding support for expression resolution backed by a credential store - the main barrier is going to be the solution to bridge expression resolution with a subsystem provided component.<div><br></div></div></blockquote><div><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"></span></div><div><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Parallel boot being the big problem, as there is no ordering of operation steps across subsystems.</span></div><div><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"></span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>I am wondering if the following is going to be viable to support a configurable expression resolver from a subsystem.</div><div><br>I see the RuntimeExpressionResolver is created very early in the boot process, however at the time it is created the CapabilityRegistry is also available. This is making me think if the CapabilityRegistry can be passed in to the RuntimeExpressionResolver.</div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Sounds reasonable.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>I would then imagine the resource handling expression resolution would register a non-dynamic capability which exposes an expression resolver runtime API. </div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">It's a runtime API so the object is created in Stage.MODEL when the capability is registered, so it is available at the start of Stage.RUNTIME. So, so far ok...</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>This in turn may also need to cross reference a credential store which would also need to be accessible using the runtime API of a capability.</div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">again a runtime API so the object is created in Stage.MODEL so available at the start of Stage.RUNTIME.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>At the time of expression resolution the RuntimeExpressionResolver would then check the CapabilityRegistry to see if an expression resolver has been registered and attempt to use it falling back to vault then default ModelNode resolution if it does not resolve the expression.<br>Using a runtime API I suspect I would likely need to trigger the initialisation of these APIs at the start of Stage.RUNTIME - that looks feasible by adding a stage to Stage.RUNTIME with addFirst test to true - maybe to be safe these should also start on demand based on first access.<br></div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">I think the big problem is these runtime API objects need to access some service and that service isn't available until the Elytron subsystem Stage.RUNTIME steps happen, and there is no consistent ordering of those steps vs other subsystems.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Even if parallel boot didn't exist, if a Stage.MODEL step adds a RUNTIME step with addFirst 'true', that RUNTIME is only 'first' until some subsequent Stage.MODEL step does the same thing.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">If the runtime API objects don't rely on anything done by the elytron subsystem in Stage.RUNTIME, then it's ok. For example if they are instantiated with their configuration data and thereafter they just work independently, it's ok. For the runtime API object for your '<span style="font-family:Arial,Helvetica,sans-serif">resource handling expression resolution' that sounds feasible. Is it feasible for the credential stores?</span></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Best regards,</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Brian</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Regards,</div><div>Darran Lofthouse.</div><div><br></div></div>
_______________________________________________<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/mailman/listinfo/wildfly-dev</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div></div>