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.
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. 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
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 assume everyone is aware of what Wildscribe  is. I've had a thought
that instead of having this massive site that will keep growing with each
version of WildFly released that we start adding this model documentation
on the WildFly Documentation site . The idea is to just add a link on
each releases index page with a link to the model descriptions.
This would be automated as well with the docs project within WildFly. It
means that as part of the release process when building the docs the
Wildscribe model pages would be generated automatically.
My proposal would be for WildFly 19+ we would no longer update the
Wildscribe website. As you can see on the site if you click on versions
it's getting quite long :). All new Wildsribe pages would be present on the
main documentation for that version. The Wildscribe site would have a note
about where the documentation would now be for newer releases.
Any thoughts or concerns about this? If not objections I'll file a JIRA and
do some work on this as it shouldn't take all that long.
James R. Perkins
JBoss by Red Hat
I am curious: how are these possible component upgrade reports generated? I
am looking for something that will give me the same sort of info for the
java project I am working on.
I am trying to build the latest wildfly from a clone of the github repo at
https://github.com/bstansberry/wildfly.git. I understand this is the latest
and is from the principal maintainer, Brian Stansberry. I've changed the
pom references to the old log4j-v1 to the new log4j-v2 but a pom dependency
analysis reveals there is a still a dependency on v1. I am at a loss as to
where exactly it is coming from. I hope someone here can shed some light
The relevant part of the dependency tree is shown from the extract below:
INFO [m] org.wildfly:wildfly-ts-integ-smoke:jar:19.0.0.Beta1-SNAPSHOT
INFO [m] +- org.jboss.ws.cxf:jbossws-cxf-client:jar:5.3.0.Final:test
INFO [m] | +- log4j:log4j:jar:1.2.17:test
Initially I thought it might be coming via an old version of apache CXF but
I see from the top level pom that version 3.3.4 is being used, which is the
latest. Any ideas?