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, 8 months
Refactoring the WildFly OpenSSL project
by Farah Juma
As it stands today, the WildFly OpenSSL project contains both Java code and
native code. This means that each time we need to do a release, we need to
build the natives, regardless of whether or not there have actually been
changes made to the native code. The process of building the natives on
various platforms takes time and has caused delays in the past that could
have been avoided if we were able to handle changes to the Java code only
as a separate release. We have actually found that there have been many
times where a release has involved changes to only the Java code. To
simplify the release process, we're going to be splitting out the native
code from the WildFly OpenSSL project into a separate project. That
way, changes to the Java code only will be able to be handled as a separate
release, without needing to rebuild the natives. The proposed changes can
be found in our incubator:
https://github.com/wildfly-security-incubator/wildfly-openssl-natives
https://github.com/wildfly-security-incubator/wildfly-openssl/tree/2.x
The native modules that have been split out are going to retain the same
group and artifact ID as they had when contained in the wildfly-openssl
project.
Regards,
Farah
4 years, 2 months
gRPC in WildFly
by Ron Sigal
Recently the RESTEasy group has been looking at protobuf and gRPC and
discussing how they might fit into the JAX-RS world. We now have a
feature request (https://github.com/wildfly/wildfly-proposals/pull/326)
for exposing JAX-RS resources as gRPC servers
(https://issues.redhat.com/browse/WFLY-13530). Briefly, it would work as
follows. Compiling the proto file
service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply) {}
...
}
will create a class GreeterGrpc, and a gRPC service can be created by
subclassing an inner class. Rather than implementing a gRPC service, we
propose passing the request to the appropriate JAX-RS resource,
something like this:
class GreeterImpl extends GreeterGrpc.GreeterImplBase {
@Override
public void sayHello(HelloRequest req, StreamObserver<HelloReply
responseObserver) {
JAXRSForwarderBuilder builder = new JAXRSForwarderBuilder();
builder.servlet("ResteasyServlet").pathTranslator((String s) ->
("test/" + s)); // Configure the JAXRSForwarder
JAXRSForwarder forwarder = builder.build();
forwarder.forward(req, (StreamObserver) responseObserver);
}
}
The gRPC infrasture would catch a request, dispatch it to GreeterImpl,
and the JAXRSForwarder would
1. create an HttpServletRequest and an HttpServletResponse
2. find and invoke the appropriate RESTEasy servlet
3. pass the result to the gRPC StreamObserver
The idea is to hide the complexity behind the JAXRSForwarder.
Now, this proposal is limited to extending RESTEasy. However, Darren
Lofthouse has been reading it carefully and has suggested that it could
be part of a larger discussion of how WildFly could incorporate gRPC.
Some discussion points:
1. Right now we're proposing to open a dedicated socket for the gRPC
infrastructure, which runs on top of Netty. When Undertow incorporates
Netty, maybe gRPC could share a socket with other subsystems.
2. Maybe there should be a separate gRPC subsystem.
3. Maybe we should go beyond servers and consider supporting gRPC
clients. For example, maybe gRPC clients could be injected into JAX-RS
resources the same as MicroProfile REST Clients.
4. Darren has suggested that Elytron should be involved.
In fact, I'm going to quote one of Darren's recent remarks:
> Starting to research gRPC myself it feels like the kind of thing
> where the general support / strategy within the application server
> should be defined, the individual subsystems such as JAX-RS and
> EJB which want to expose their existing deployments would then
> dynamically make their resources available through this. For areas
> such as security this would be provided consistently within the
> general support.
>
> For gRPC initially if feels like it could have a good fit with
> CDI, I don't know how practical that would be and if it would
> cause a lot of considerations that may make it a better fit as a
> SmallRye project. On one side if that gets too complex it may be
> something that makes more sense as a SmallRye project to define
> how gRPC deployments are handled, on the other side unless the
> exposing of JAX-RS endpoints is 100% automated including the
> protobuf generation it sounds like a level of user deployment may
> be necessary anyway which may mean deployment handling is required.
>
> I think the exposed socket is possibly less of an issue compared
> to the general strategy. Maybe it will be necessary to expose a
> separate server socket for now, I would have thought something
> like this could justify it's own subsystem which would mean it can
> be defined in it's own Galleon layer but that would mean as a
> subsystem it could follow a similar path the Remoting subsystem
> took i.e. exposing a port and once possible adding support to
> delegate through Undertow.
>
> Regarding the other comments about how this could integrate with
> Undertow, the main motivation for gRPC seems to be the use of this
> binary protocol we probably should be cautious that we are not
> adding too many layers on our side that requests need to be
> translated thought otherwise we may be negating the benefits from
> the outset.
>
> Recently the tasks I have been working through have involved a lot
> of DeploymentUnitProcessor refactoring to restore better
> collaboration between subsystems regarding how they share security
> policy information, so far it has been slow going and considering
> backwards compatibility there is still quite a long way to go.
> This is the reason for something like this I am interested in the
> overall architecture first so we can hopefully avoid this kind of
> retrospective refactoring as we need to enhance it further.
Any comments are welcome.
4 years, 2 months
JDK 15 is now in Rampdown Phase Two
by Rory O'Donnell
Hi David & Richard, **
*Per the JDK 15 schedule, we are in Rampdown Phase Two* *[1]*
Per the JDK Release Process [2] we now turn our focus to *P1 and P2
bugs*, which can be fixed with approval [3].
Late enhancements are still possible, with approval [4], but the bar is
now extraordinarily high.
**Please advise if you have any open high priority issues.* *
* Schedule for JDK 15
o 2*020/07/16 Rampdown Phase Two*
o 2020/08/06 Initial Release Candidate
o 2020/08/20 Final Release Candidate
o 2020/09/15 General Availability
* Features included in JDK 15:
o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
<http://openjdk.java.net/jeps/339>
o JEP 360: Sealed Classes (Preview) <http://openjdk.java.net/jeps/360>
o JEP 371: Hidden Classes <http://openjdk.java.net/jeps/371>
o JEP 372: Remove the Nashorn JavaScript Engine
<http://openjdk.java.net/jeps/372>
o JEP 373: Reimplement the Legacy DatagramSocket API
<https://openjdk.java.net/jeps/373>
o JEP 374: Disable and Deprecate Biased Locking
<http://openjdk.java.net/jeps/374>
o JEP 375: Pattern Matching for instanceof (Second Preview)
<https://openjdk.java.net/jeps/375>
o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
<http://openjdk.java.net/jeps/377>
o JEP 378: Text Blocks <http://openjdk.java.net/jeps/378>
o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
<https://openjdk.java.net/jeps/379>
o JEP 381: Remove the Solaris and SPARC Ports
<https://openjdk.java.net/jeps/381>
o JEP 383: Foreign-Memory Access API (Second Incubator)
<https://openjdk.java.net/jeps/383>
o JEP 384: Records (Second Preview)
<https://openjdk.java.net/jeps/384>
o JEP 385: Deprecate RMI Activation for Removal
<https://openjdk.java.net/jeps/385>
*JDK 15 **Early Access build 32 **is available**at : - jdk.java.net/15/*
These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception.
* Release notes
o http://jdk.java.net/15/release-notes
* Recent fixes that might be of interest
o
Build 32
+ 8231800: Better listing of arrays
+ 8234836: Improve serialization handling
o Build 31
+ JDK-8248505: Unexpected NoSuchAlgorithmException when using
secure random impl from BCFIPS provider
o Build 29
+ JDK-8233014: Enable ShowCodeDetailsInExceptionMessages by
default
*JDK 16 Early Access build 6 ****is available**at : - jdk.java.net/16/*
These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception.
* JEP Candidate
o JEP 388: Windows/AArch64 Port <https://openjdk.java.net/jeps/388>
* JEPs proposed to target
o JEP 347: Enable C++14 Language Features
<https://openjdk.java.net/jeps/347>
* JEPs targeted to JDK 16, so far:
o JEP 369: Migrate to GitHub <https://openjdk.java.net/jeps/369>
o JEP 357: Migrate from Mercurial to Git
<https://openjdk.java.net/jeps/357>
**
* Recent fixes that might be of interest
o
Build 32
+ 8231800: Better listing of arrays
+ 8234836: Improve serialization handling
o Build 5
+ JDK-8218021: Have jarsigner preserve posix permission attributes
+ JDK-8245302: Upgrade LogRecord to support long thread ids
and remove its usage of ThreadLocal
+ JDK-8248505: Unexpected NoSuchAlgorithmException when using
secure random impl from BCFIPS provider
*Cryptoroadmap updated *
* https://www.java.com/en/jre-jdk-cryptoroadmap.html
*The "Best of the JDK" feature face-off tournament: Result!*_*
*_
* *JDK Mission Control *is the winner based on the Twitter poll
<https://twitter.com/java/status/1281595323685703683?s=20>.
*The Quality Outreach Report for *June 2020**is available via the
Quality Wiki page*: **June 2020
<https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+Jun...>
*
*__*
Rgds,Rory
[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-July/004536.html
[2] https://openjdk.java.net/jeps/3
[3] https://openjdk.java.net/jeps/3#Fix-Request-Process
[4] https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
4 years, 3 months
