Plugging in Credential Store backed ExpressionResolver
by 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.
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
capability.
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.
Regards,
Darran Lofthouse.
3 years, 10 months
Updating the WildFly archetypes
by Wolfgang Knauf
Hi,
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
think?
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 ;-).
Best regards
Wolfgang
5 years, 1 month
Allowing disabling of 'graceful startup'
by Brian Stansberry
tl;dr question is how to disable 'graceful startup'. Skip the background if
you know what that means. :)
Background
Back in 2016 when we added the feature to allow a server to be started in
'suspended' state[1], that work also included a fix for the longstanding
bug whereby during server start endpoints would be started and accepting
external requests before all the services (e.g. from deployments) would be
started. The result would be requests could reach the still-starting server
and would fail, e.g. HTTP requests might get a 404 or some variety of 500.
I refer to this bug fix as 'graceful startup'.
Since the fix was introduced we've gotten quite a number of requests to be
able to turn off that bug fix, e.g. WFCORE-4291.[2] The scenario is users
deploy two apps, where app A during start makes an *external* request to
app B and won't complete start until that request is handled. And, the
users deploy both A and B in the same server. The server won't allow the
external request during boot, so A won't complete start and thus the
overall server start hangs until timeout.
I consider this kind of deployment pattern to be a bit of an anti-pattern,
but we've gotten enough request to allow it that I'm looking into how to
satisfy it. Also, at least for HTTP requests, mod_cluster can be used to
prevent external requests reaching a server before things are ready, so if
the 'internal' requests were not sent through the LB there's at least one
'error free' use case for this.
The Question
Question is whether to
a) have an overall config switch to disable graceful startup across the
board (e.g. a new value for the --start-mode cmd line param passed to
standalone.sh)
b) have a subsystem specific setting in the undertow subsystem that
configures undertow to allow requests in during boot.
Pros of a)
* Other request patterns are also handled. For example, if our app A was
making a remote EJB call to app B, then an undertow only setting won't
handle it. If we start adding multiple per-subsystem flags it gets ugly.
* Requests to web applications may still fail, as there are other aspects
of the server that are rejecting certain calls until 'graceful startup' is
complete. For example ee-concurrency rejects adding scheduled tasks
(although that is somewhat a bug[3]), and the XTS integration looks to be
designed to reject certain requests.[4] There may be others. If we have
make web requests an exceptional pattern, going forward we have to account
for that pattern in everything.
* The undertow subsystem itself has two different mechanisms for rejecting
requests, with three different call patterns, all of which would need to be
adapted.
Pros of b)
* It limits the change to the HTTP use case, the one where we know
mod_cluster can be used to prevent external requests.
* I'm not sure about the batch subsystem; i.e. whether it is ok to have
batch jobs starting before server start is complete. If the relevant
services all have MSC dependencies on everthing they need it should be ok.
If not there needs to be some adaptation listen for when the server is
fully started, which seems doable.
* There may be code that is using this 'graceful startup' as a way not to
prevent end user activity, but to prevent premature internal server
activity. I think RecoverySuspendController may be an example of this; i.e.
preventing start of the tx recovery thread until the server is started. But
for this kind of thing there are other, better solutions.
Right now my preference is a), a global switch. If we're doing this I'm not
inclined to limit it to HTTP only as I expect we'll just have to revisit it
later. And I think I know how to deal with the more technical pros of the
http-only approach.
WDYT?
[1] https://issues.jboss.org/browse/WFCORE-1829
[2] https://issues.jboss.org/browse/WFCORE-4291
[3] https://issues.jboss.org/browse/WFLY-12329
[4] https://github.com/wildfly/wildfly/pull/9419
Best regards,
Brian
5 years, 4 months
Key dates for WildFly 18
by Brian Stansberry
We've been working on WildFly 18 for a little over a month now, and I'm
past due to announce the expected schedule. We've been monitoring
developments with Jakarta EE 8, work on which is heading into the home
stretch. If it goes final in time we'd like to both certify WildFly 18 at
release[1] and base our EE API jars on the Jakarta projects.[2] Please
recall that the Java EE 8 and Jakarta EE 8 API jars are meant to be binary
equivalent, so this change should not introduce runtime behavior
differences.
Anyway, here are the key dates in the WildFly 18 schedule:
- Fri, Aug 30 — PRs ready for merge for all features coming in via WildFly
Core
- Tue, Sept 3 — All features ready for merge
- Wed, Sept 4 — WildFly 18 Beta. No new features after this date.
- Fri, Sept 13 — All changes for WildFly Core ready
- Tue, Sept 17 — All changes for WildFly ready
- Thu, Sept 19 — WildFly 18 Final released
WildFly Core should continue to produce betas every couple of weeks; just
today Jeff Mesnil released 10.0.0.Beta2.[3]
[1] https://issues.jboss.org/browse/WFLY-12297
[2] https://issues.jboss.org/browse/WFLY-12300
[3] https://github.com/wildfly/wildfly-core/releases/tag/10.0.0.Beta2
Best regards,
Brian
5 years, 5 months
JDK 13 enters Rampdown Phase Two
by Rory O'Donnell
Hi David & Richard,
**OpenJDK builds *- JDK 13 Early Access build 30 **is now available **at
: - jdk.java.net/13/*
* Per the JDK 13 schedule [1], we are now in Rampdown Phase Two.
o For more details , see Mark Reinhold's email to jdk-dev mailing
list [2]
o The overall feature set is frozen, no further JEPs will be
targeted to this release.
o Per the JDK Release Process [3] we now turn our focus to P1 and
P2 bugs.
* I want to draw your attention to some noteable changes in previous
builds of JDK 13. These changes are important for those that
develop/maintain their own socket implementation
(java.net.SocketImpl) or use the setSocketImplFactory or
setSocketFactory APIs to change the system-wide socket implementation:
o http://jdk.java.net/13/release-notes#JDK-8224477 - delivered in
build 23
o http://jdk.java.net/13/release-notes#JDK-8216978 - delivered in
build 20
o http://jdk.java.net/13/release-notes#JDK-8220493 - delivered in
build 13
**OpenJDK builds *- JDK 14 Early Access build 6 is **now available **at
: - jdk.java.net/14/*
* These early-access, open-source builds are provided under the
o GNU General Public License, version 2, with the Classpath
Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
* Changes of interest since last email
o 8225239: Refactor NetworkInterface lookups
o 8226409: Enable argument profiling for sun.misc.Unsafe.put*/get*
* JEP targeted to JDK 14:
o JEP352: Non-Volatile Mapped
* Bug fixes reported by Open Source Projects :
o JDK-8227080 - fixed in b5 -reported by Eclipse Jetty
The Java Crypto Roadmap
<https://www.java.com/en/jre-jdk-cryptoroadmap.html> has been updated :
* Released - 16-July-2019 - Release Affected JDK 7u231 - Disabled
Kerberos DES encryption by default
* Targeted Date - 2020 - Targeted Release - JDK 8 - Transport Layer
Security (TLS) 1.3
Rgds,Rory
[1] http://openjdk.java.net/projects/jdk/13/#Schedule
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-July/003170.html
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
5 years, 5 months
Upgrade MicroProfile Health Check 2.0.1
by Jean-Frederic Mesnil
Hi,
I’ve opened a PR to upgrade MicroProfile Health Check to 2.0.1 for WildFly 18.
This major release of the specification has breaking changes that might impact existing users of the HTTP health check probe.
The major changes are:
* the /health HTTP endpoint now checks both liveness and (newly introduced) readiness probes
* the JSON payload has changed (the outcome field has been renamed to status) but the HTTP error codes are the same
* the new /health/live and /health/ready HTTP endpoints checks respectively only the liveness and readiness probes.
There is also a new attribute in the subsystem definition named “empty-checks-status” that defines the global status (UP or DOWN) when no probes are registered (default is UP).
This allows applications to make sure that the server is checked as not ready / alive until the application is deployed, its probes are registered and evaluated to determine the liveness/readiness of the application.
More info in the proposal PR: https://github.com/wildfly/wildfly-proposals/pull/229
Jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
5 years, 5 months
Manually testing docs changes
by Brian Stansberry
Perhaps this will be a "well of course you idiot" thing, but while
reviewing https://github.com/wildfly/wildfly/pull/12381 I realized it's
quite simple to manually test the docs output from a PR...
1) check out the PR branch locally
2) cd docs
3) mvn clean package
4) open target/generated-docs/index.html
Voila, you have the root page for the 'current' version of the docs open in
your browser and you can maneuver around without problem to have a look at
the proposed docs.
Best regards,
Brian
5 years, 5 months
JDK 13 , JDK 14 & Valhalla Early Access builds are available.
by Rory O'Donnell
Hi David & Richard,
**OpenJDK* 13 Early Access build **28 is now available **at : -
jdk.java.net/13/*
* These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Changes in this build 28 [1]
*Reminder of a change in b24 - A jrt URI can only encode paths to files
in /modules tree **(JDK-8224946
<https://bugs.openjdk.java.net/browse/JDK-8224946>)*
A |jrt| URL is a hierarchical URI with syntax |jrt:/[$MODULE[/$PATH]]|.
When using the |jrt| file system, a |java.net.URI| object can be created
with the |java.nio.file.Path::toUri| method to encode a normalized path
to a file in the |/modules| tree. A |jrt| URL cannot encode a path to a
file in the |/packages| tree. The |jrt| file system provider has changed
in this release so that |toUri| fails with |IOError| when it is not
possible to encode the file path as a jrt URI. *This change may impact
tools have been making use of URLs that are not compliant with the
syntax. Tools with paths to files in **|/packages|**can use the
**|toRealPath()|**method to obtain the real path (in **|/modules|**)
before attempting to convert the file path to a URI.*
*OpenJDK 14 **Early Access build 4 **is now available **at : -
jdk.java.net/14/*
* These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Changes in this build [2]
*Project Valhalla "L-World Inline Types" Early-Access Builds*
* Build jdk-14-valhalla+1-8
* These early-access builds are provided under the GNU General Public
License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Please send feedback via e-mail to valhalla-dev(a)openjdk.java.net
<mailto:valhalla-dev@openjdk.java.net>. To send e-mail to this
address you must first subscribe to the mailing list.
*The Skara tooling is now open source *[3]
we are happy to announce that the tooling for project Skara is now open
source and available at
* https://github.com/openjdk/skara <https://github.com/openjdk/skara.>
The Skara tooling includes both server-side tools (so called "bots") as
well as several command-line tools **
If you have any questions, feedback etc. send them to Skara mailing list [4]
Rgds, Rory
[1] JDK 13 - Changes in b28 here
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B27%22%3A...>
[2] JDK 14 - Changes in b4 here
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B3%22%3A%...>
[3] https://mail.openjdk.java.net/pipermail/skara-dev/2019-June/000047.html
[4] https://mail.openjdk.java.net/mailman/listinfo/skara-dev
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
5 years, 5 months
