Sorry for the late reply. :( On Tue, Jul 9, 2019 at 12:54 PM Darran Lofthouse < darran.lofthouse(a)jboss.com&gt; wrote: > 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. > > Parallel boot being the big problem, as there is no ordering of operation steps across subsystems. > I am wondering if the following is going to be viable to support a > configurable expression resolver from a subsystem. > > 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. > Sounds reasonable. > > I would then imagine the resource handling expression resolution would > register a non-dynamic capability which exposes an expression resolver > runtime API. > 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... 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. > again a runtime API so the object is created in Stage.MODEL so available at the start of Stage.RUNTIME. > > 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. > 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. > 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. 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. 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 'resource handling expression resolution' that sounds feasible. Is it feasible for the credential stores? Best regards, Brian Regards, > Darran Lofthouse. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat