Just a quick update on this enhancement, I have reworked and resubmitted
The implementation has progressed well, the remaining piece is massaging
the runtime API and relevant resources to make this new expression resolver
completely available at the point it is first used. Most of the dependency
ordering seems manageable as only a couple of resources in the Elytron
subsystem are involved - the one tricky piece looks to be access to a
"relative-to" path which normally would be accessed using an MSC service
On Fri, Jul 12, 2019 at 11:41 PM Brian Stansberry <
Sorry for the late reply. :(
On Tue, Jul 9, 2019 at 12:54 PM Darran Lofthouse <
> 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.
> 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?
> Darran Lofthouse.
> wildfly-dev mailing list
Manager, Senior Principal Software Engineer