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.
the archetypes at https://github.com/wildfly/wildfly-archetypes
(e.g. "wildfly-javaee7-webapp-ear-blank-archetype") are for WildFly 8,
and when updating the WildFly version in pom.xmls, a lot of further
changes is required, see https://issues.jboss.org/browse/WFLY-9703
(which is only part of the changes).
I am interested in creating new archetypes for WildFly 15. What do you
My plan is to name them e.g.
"wildfly15-javaee8-webapp-ear-blank-archetype" and to create a new
archetype version each time a new WildFly major version is released.
If you are OK with this, I will struggle with my first steps in Git, and
I probably will ask some more or less dumb questions about details ;-).
I'm sorry to say that we've decided to delay the WildFly 18 Final release,
probably by at least seven days. There are a few critical bugs we want
resolved in the final, and those will require some component upgrades that
will take some time.
Please note that we won't be merging further changes for 18 unrelated to
the blocking issues that we're tracking. If that starts to be disruptive
we can look next week at creating the 18.0.x branch before the final and
using it for the last few changes, opening master up for work on 19.
Thanks everyone, for all your efforts on WildFly 18!
Sorry for pushing this but I wanted to ask if somebody could have a look
at LOGMGR-260  and the corresponding PR .
We believe this affects everybody that runs WildFly on Java 9+ and uses
JMX over RMI (the default implementation). The bug causes all
java.util.logging.Loggers used by JDK modules to have Level.ALL. The log
messages won't be written but the guards will fail and the LogRecords
will get created.
We have are running a custom patch with the PR but we would like to see
this merged so that we can get rid of the patch.
I'm following this guide to get logging sent to kafka:
This works on EAP 7.2.3.GA running on JDK 8, but fails to run on JDK 11:
15:54:28,819 ERROR [org.jboss.as.controller.management-operation]
(Controller Boot Thread) WFLYCTL0013: Operation ("add") failed -
("subsystem" => "logging"),
("custom-handler" => "kafka")
]): java.lang.IllegalArgumentException: Failed to load module
"org.apache.log4j" for pojo "kafka"
Do you think this is related to the new module system in JDK 11 and I
need to add some extra JVM flags to get it to work?
Thank you for your help!