12:41 a.m.
Sorry for the late reply. :(
On Tue, Jul 9, 2019 at 12:54 PM Darran Lofthouse <darran.lofthouse(a)jboss.com>
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