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, 9 months
JDK 16 Early Access build 26 is now available
by Rory O'Donnell
Hi David & Richard,
OpenJDK 16 Early Access build 26**is now available at
http://jdk.java.net/16
* 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>.
* Schedule: *JDK 16 Rampdown Phase One Starts on 2020/12/10 [1] *
* Features [1]: Most recent Integrations:
o Integrated JEP 389: Foreign Linker API (Incubator)
<https://openjdk.java.net/jeps/389> with this release.
+ JEP 389 introduces an API that offers statically-typed,
pure-Java access to native code.
+ This API, together with the JEP 383
<https://openjdk.java.net/jeps/383>, will considerably
simplify the otherwise error-prone process of binding to a
native library.
**
* Release Notes [2]
* Changes in recent builds that maybe of interest:
o Build 26
+ JDK-8202343: *Disable TLS 1.0 and 1.1*
+ JDK-8251317:**Support for CLDR version 38**
+ JDK-8212879: Make JVMTI TagMap table concurrent
+ JDK-8236926: Concurrently uncommit memory in G1
+ JDK-8243559: Removed Root Certificates with 1024-bit Keys
+ JDK-8253459: Argument index of zero or unrepresentable by
int throws IllegalFormatException
+ JDK-8256643: Terminally deprecate ThreadGroup stop, destroy,
isDestroyed, setDaemon and isDaemon
o Build 25
+ JDK-8247781: Day period support added to java.time formats
+ JDK-8202471: (ann) Cannot read type annotations on generic
receiver type's type variables *[**Reported by ByteBuddy]*
+ JDK-8255947: [macos] Signed macOS jpackage app doesn't
filter spurious '-psn' argument *[**Reported by JOSM]*
+ JDK-8256063: Module::getPackages returns the set of package
names in this module
* JDK 16 - topics of interest
o Inside Java Episode 7 “The Vector API” with John Rose and Paul
Sandoz
+ https://inside.java/2020/11/17/podcast-007/
<https://inside.java/2020/11/17/podcast-007/>
o Biased locking Obsoletion update
+ https://inside.java/2020/11/17/biased-locking-obsoletion/
<https://inside.java/2020/11/17/biased-locking-obsoletion/>
* Project Loom with Ron Pressler
o https://inside.java/2020/11/24/podcast-008/
* Update on 64-bit ARM Support for Oracle OpenJDK and Oracle JDK
o https://inside.java/2020/11/12/arm-support-update/
<https://inside.java/2020/11/12/arm-support-update/>
Project Lanai Early-Access: EA 7 Build 16-lanai+3-278
<http://jdk.java.net/lanai/> (2020/11/17)
* 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>
* These EA builds are produced for the purpose of gathering feedback.
Use for any other purpose is at your own risk.
* Please send feedback via e-mail to lanai-dev(a)openjdk.java.net
<mailto:lanai-dev@openjdk.java.net>. To send e-mail to this address
you must first subscribe to the mailing list
<https://mail.openjdk.java.net/mailman/listinfo/lanai-dev>.
The Java Cryptographic Roadmap has been updated [3]:
* Distrust TLS 1.0 and TLS 1.1 by default
o TLS protocol versions 1.0 and 1.1 are no longer considered
secure and have been superseded by more secure and modern
versions (TLS 1.2 and 1.3). This change has been integrated with
JDK 16 Early Access build 26.
* Upgrade of default algorithms used to encrypt PKCS12 keystores
o The new algorithms are based on AES-256 and SHA-256 and are
stronger than the old algorithms which were based on RC2,
DESede, and SHA-1.This change is already included in JDK 16
Early Access build 23.
RgdsRory
[1] https://openjdk.java.net/projects/jdk/16/
[2] https://jdk.java.net/16/release-notes
[3] https://www.java.com/en/jre-jdk-cryptoroadmap.html
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
3 years, 11 months
Re: Reactive specs in standalone-microprofile.xml or not
by Kabir Khan
I missed out wildfly-dev at some point, re-adding so the full thread is
public
On Wed, 25 Nov 2020 at 17:33, Kabir Khan <kkhan(a)redhat.com> wrote:
>
>
> On Wed, 25 Nov 2020 at 17:18, Brian Stansberry <
> brian.stansberry(a)redhat.com> wrote:
>
>>
>>
>> On Wed, Nov 25, 2020 at 5:46 AM Kabir Khan <kkhan(a)redhat.com> wrote:
>>
>>>
>>>
>>> On Tue, 24 Nov 2020 at 18:46, Brian Stansberry <
>>> brian.stansberry(a)redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Nov 24, 2020 at 3:38 AM Kabir Khan <kkhan(a)redhat.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> One thing missing in the proposal
>>>>> <https://github.com/wildfly/wildfly-proposals/pull/320> of the
>>>>> inclusion of MicroProfile Reactive Messaging (and RSO which is used by
>>>>> Reactive Messaging) is if we should add it to
>>>>> standalone-microprofile(-ha).xml or not?
>>>>>
>>>>> As it previously came in via the feature pack
>>>>> <https://github.com/wildfly-extras/wildfly-mp-reactive-feature-pack>
>>>>> it made sense to have it added from the FP, but now that it will be part of
>>>>> WildFly I am not sure what to do. In a way the reactive specs are separate
>>>>> from the other MP specs and not part of the MP platform, and adding the
>>>>> current MP platform is probably the main use-case for
>>>>> standalone-microprofile.xml?
>>>>>
>>>>> At the same time I guess it could be nice for users to have something
>>>>> out of the box to run these. If we do not want it in
>>>>> standalone-microprofile.xml, do we want:
>>>>>
>>>>> * an xml in docs/examples/configs
>>>>> * an enable-reactive.cli script in docs/examples
>>>>>
>>>>> It is worth pointing out that what 'reactive' is will evolve:
>>>>> * We are currently only supporting RM 1.0, so we only need Reactive
>>>>> Messaging and RSO. Once RM .next is out it makes sense to also include
>>>>> Context Propagation (which is currently in the feature pack) to support
>>>>> 'user bridge' use cases.
>>>>> * All subsystems are currently empty, however we will look at making
>>>>> Reactive Messaging at least configurable going forward (to move stuff like
>>>>> connection info out from the MP config properties into something
>>>>> referenceable in the subsystem)
>>>>> * RM can work without connectors. We are currently porting the Kafka
>>>>> connector, while the others (presently MQTT and AMQP) live in the feature
>>>>> pack. Inclusion of these is presently a pure Galleon layers thing, but once
>>>>> included may have impact on the subsystem implementations.
>>>>>
>>>>> So perhaps we should either go with a pure documentation approach, or
>>>>> a minimal CLI script to turn these on. I'd be happy to hear your thoughts.
>>>>>
>>>>
>>>> And a layer. :)
>>>>
>>>
>> s/a layer/a layer or layers/g
>>
>>> In WildFly I currently have layers for:
>>> * the two subsystems
>>> * the kafka connector
>>>
>>> Are you saying you would like something like a microprofile-reactive
>>> layer (similar to microprofile-platform)?
>>>
>>
>> No, I just meant we want good layer coverage, as that is the best
>> approach for letting people tailor their config. I didn't see the word
>> layer in your email. :)
>>
>>
>>> If so, I think I would just include the two core subsystem layers and
>>> leave the connector out, as there may be more in the future and as you once
>>> mentioned elsewhere we don't want those to magically show up in provisioned
>>> servers in future releases. On that note, note that context propagation
>>> will be added soonish and probably should be part of the
>>> microprofile-reactive layer once it shows up. It sort of breaks the 'rule'
>>> but less so than a bunch of reactive messaging connectors showing up :)
>>>
>>
>> Maybe at some point a microprofile-reactive layer would make sense but
>> not until it has a clear fixed meaning that we can comfortably evolve, and
>> better yet *not evolve*. It is much better if a layer in version Y does not
>> produce significantly differ results vs previous version X.
>>
>> I don't know enough to have an opinion about a kafka connector layer. I
>> should probably look at the analysis doc and the code!
>>
>> BTW for folks who weren't aware, this is why the 'microprofile-platform'
>> layer is called 'microprofile-platform' and not 'microprofile'. A layer
>> named 'microprofile' would be too open ended so people using it would not
>> be able to predict how it would evolve. Would new MP-related subsystem
>> 'foo' be added when WF introduces it? The 'microprofile-platform' layer
>> means the things in MP platform that WF provides, so if we add something
>> and it is a platform spec we will add it to that layer, and if you use that
>> layer and upgrade, you'll get it. If you don't want that, then use the
>> individual layers for the specs you want.
>>
> That's fine, I was happy with the layers I already have :)
>
>>
>>
>>>
>>>
>>>> My instinct is we should avoid adding things into our standard config
>>>> files. The pro of adding is things just work OOTB but the con is the many
>>>> people who aren't really using things now have them and may not even
>>>> notice. And then it is hard to take them away. So to put things in the
>>>> standard configs I think we need to expect a pretty high level of use. That
>>>> or they are required by some general 'meaning' of the config, e.g. a server
>>>> running standalone-microprofile.xml being able to pass the MP *platform*
>>>> TCKs. I don't think the RM stuff will be high enough level of use yet.
>>>>
>>>> We also know that the reactive stuff will be evolving after WF 23 we
>>>> might be better off seeing what that looks like before adding things in the
>>>> standard configs.
>>>>
>>>> IIRC there's been discussion in the past of not adding more example
>>>> configs and instead only including CLI scripts. OTOH maybe we are better
>>>> off avoiding CLI scripts, which require writing by hand / manual
>>>> maintenance and are fairly difficult to test.
>>>>
>>> +1 I can add my stuff easily in tests and wherever else, I just needed
>>> to stop guessing how this should work :)
>>>
>>>>
>>>>
>>>>> Thanks,
>>>>>
>>>>> Kabir
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Manager, Senior Principal Software Engineer
>>>> Red Hat
>>>>
>>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>>
>
3 years, 12 months
Reactive specs in standalone-microprofile.xml or not
by Kabir Khan
Hi,
One thing missing in the proposal
<https://github.com/wildfly/wildfly-proposals/pull/320> of the inclusion of
MicroProfile Reactive Messaging (and RSO which is used by Reactive
Messaging) is if we should add it to standalone-microprofile(-ha).xml or
not?
As it previously came in via the feature pack
<https://github.com/wildfly-extras/wildfly-mp-reactive-feature-pack> it
made sense to have it added from the FP, but now that it will be part of
WildFly I am not sure what to do. In a way the reactive specs are separate
from the other MP specs and not part of the MP platform, and adding the
current MP platform is probably the main use-case for
standalone-microprofile.xml?
At the same time I guess it could be nice for users to have something out
of the box to run these. If we do not want it in
standalone-microprofile.xml, do we want:
* an xml in docs/examples/configs
* an enable-reactive.cli script in docs/examples
It is worth pointing out that what 'reactive' is will evolve:
* We are currently only supporting RM 1.0, so we only need Reactive
Messaging and RSO. Once RM .next is out it makes sense to also include
Context Propagation (which is currently in the feature pack) to support
'user bridge' use cases.
* All subsystems are currently empty, however we will look at making
Reactive Messaging at least configurable going forward (to move stuff like
connection info out from the MP config properties into something
referenceable in the subsystem)
* RM can work without connectors. We are currently porting the Kafka
connector, while the others (presently MQTT and AMQP) live in the feature
pack. Inclusion of these is presently a pure Galleon layers thing, but once
included may have impact on the subsystem implementations.
So perhaps we should either go with a pure documentation approach, or a
minimal CLI script to turn these on. I'd be happy to hear your thoughts.
Thanks,
Kabir
3 years, 12 months
WildFly 22 Development Schedule
by Brian Stansberry
Time continues to fly by! We're hard at work on WildFly 22 and next thing
we know it will be time to release it.
Here are the key dates:
Friday Dec 4 -- Feature freeze for features coming in via WildFly Core. PRs
must be in a mergeable state early in the European work day.
Wed Dec 9 -- Feature freeze for features coming in via main WildFly. PRs
must be in a mergeable state at the start of the European work day.
Thur Dec 10 -- WildFly 22.0.0.Beta1
Mon, Jan 11 -- All changes for WildFly 22 should be in mergeable state
Wed Jan 13/Thur Jan 14 -- WildFly 22.0.0.Final tagged and made available
for download.
Note the longer than normal gap between the Beta and Final. This is due to
the expectation that many people will not be working in late December and
early January. Please plan your work accordingly. Try and get things done
as soon as possible after the Beta.
Best regards,
Brian
4 years
Announcing WildFly 22 Alpha1 and WildFly Preview
by Brian Stansberry
I'm happy to announce the release of WildFly 22.0.0.Alpha1. It's available
for download from https://www.wildfly.org/downloads/.
We typically don't do releases this early in the dev cycle for a WildFly
major, but this time we wanted to let the WildFly community have a look at
the new 'WildFly Preview' flavor of WildFly that we're adding. We’re using
WildFly Preview to give our community a tech preview look at things we see
coming down the road in our main WildFly distribution. Right now this is
mostly about what we are doing with Jakarta EE 9, where we've made a lot of
progress this last month.
My blog post announcing the release gets into a lot more details. Please
have a look at
https://www.wildfly.org/news/2020/11/12/Jakarta-EE-9-with-WildFly-Preview/,
try it out and give us your feedback!
Thanks so much to everyone in the WildFly community who have been working
on EE 9, both for WildFly and in general. I'd like to specially thank Scott
Marlow, Richard Opalka, Jean-Francois Denise and Darran Lofthouse for their
hard work in pulling WildFly Preview together.
Best regards,
Brian
4 years
JDK 16 Early Access build 24 is now available
by Rory O'Donnell
Hi David & Richard,
OpenJDK 16 Early Access build 24**is now available at
http://jdk.java.net/16
* 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>.
* Schedule
2020/12/10 Rampdown Phase One
2021/01/14 Rampdown Phase Two
2021/02/04 Initial Release Candidate
2021/02/18 Final Release Candidate
2021/03/16 General Availability
* Features:
o JEPs targeted to JDK 16, so far:
+ JEP 338: Vector API (Incubator)
<https://openjdk.java.net/jeps/338>
+ JEP 347: Enable C++14 Language Features
<https://openjdk.java.net/jeps/347>
+ JEP 357: Migrate from Mercurial to Git
<https://openjdk.java.net/jeps/357>
+ JEP 369: Migrate to GitHub <https://openjdk.java.net/jeps/369>
+ JEP 376: ZGC: Concurrent Thread-Stack Processing
<https://openjdk.java.net/jeps/376>
+ JEP 380: Unix-Domain Socket Channels
<https://openjdk.java.net/jeps/380>
+ JEP 386: Alpine Linux Port <https://openjdk.java.net/jeps/386>
+ JEP 387: Elastic Metaspace <https://openjdk.java.net/jeps/387>
+ JEP 388: Windows/AArch64 Port
<https://openjdk.java.net/jeps/388>
+ JEP 392: Packaging Tool <https://openjdk.java.net/jeps/392>
+ JEP 393: Foreign-Memory Access API (Third Incubator)
<https://openjdk.java.net/jeps/393>
+ JEP 394: Pattern Matching for instanceof
<https://openjdk.java.net/jeps/394>
+ JEP 395: Records <https://openjdk.java.net/jeps/395>
**
* Release Notes are available at http://jdk.java.net/16/release-notes
<http://jdk.java.net/16/release-notes>
* Changes in recent builds that maybe of interest:
o Build 24
+ JDK-8231599: NPE when loading a preview classfile from a
future Java version
# *Reported by JUnit5*
+ JDK-8254661: arm32: additional cleanup after fixing SIGSEGV
# *Reported by JaCoCo*
+ JDK-8255584: `HttpPrincipal::getName` returns incorrect name
+ JDK-8255226: (tz) Upgrade time-zone data to tzdata2020d
o Build 23
+ JDK-8254876: (fs) NullPointerException not thrown when first
argument to Path.of or Paths.get is null
+ JDK-8255576: (fs) Files.isHidden() throws
ArrayIndexOutOfBoundsException (unix)
# *Reported by JUnit5*
+ JDK-8255616: Removal of experimental features AOT and Graal JIT
o Build 22
+ JDK-8243583: Change 'final' error checks to throw ICCE
+ JDK-8254982: (tz) Upgrade time-zone data to tzdata2020c
Project Loom Early-Access Build: Build 16-loom+7-285
<http://jdk.java.net/loom/> (2020/11/4)
* *Want to know more* - check out -
https://inside.java/2020/11/11/project-loom-at-nyc-java-sig/
* 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>
o These builds are based on jdk-16+20
<https://github.com/openjdk/jdk/releases/tag/jdk-16%2B20>
o These EA builds are produced for the purpose of gathering
feedback. Use for any other purpose is at your own risk.
o Please send feedback via e-mail to loom-dev(a)openjdk.java.net
<mailto:loom-dev@openjdk.java.net>. To send e-mail to this
address you must first subscribe to the mailing list
<http://mail.openjdk.java.net/mailman/listinfo/loom-dev>.
Rgds,Rory
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
4 years
