WildFly Elytron - Credential Store - Next Stages
by Darran Lofthouse
During WildFly 15 and WildFly 16 I am looking at the next stages for
credential store development based on a few feature requests we have not
handled yet.
We are at the stage where this development is likely to affect multiple
areas of the application server, additionally we need to consider these
requests as a set so we don't take a decision for one that prevents us
working on the remainder.
I have put together a blog post describing some of the general issues we
want to look into: -
http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next...
Some of these changes will have an impact on any subsystem currently
referencing the credential store.
Other changes we will need to decide if the solution lies within WildFly
Elytron, the management tier of the server, or the admin tools - or
possibly a combination of all three.
I am also going to share this link in the community forums to try and
obtain some additional feedback from end users.
Regards,
Darran Lofthouse.
4 years, 9 months
Release Announcement: General Availability of JDK 11
by Rory O'Donnell
Hi David & Richard,*
*
*1) Release Announcement: General Availability of JDK 11 *
* JDK 11, the reference implementation of Java 11 and the first
long-term support release produced under the six-month rapid-cadence
release model [1][2], is now Generally Available.
* GPL-licensed OpenJDK builds from Oracle are available here:
https://jdk.java.net/11
This release includes seventeen features:
* 181: Nest-Based Access Control <http://openjdk.java.net/jeps/181>
* 309: Dynamic Class-File Constants <http://openjdk.java.net/jeps/309>
* 315: Improve Aarch64 Intrinsics <http://openjdk.java.net/jeps/315>
* 318: Epsilon: A No-Op Garbage Collector
<http://openjdk.java.net/jeps/318>
* 320: Remove the Java EE and CORBA Modules
<http://openjdk.java.net/jeps/320>
* 321: HTTP Client (Standard) <http://openjdk.java.net/jeps/321>
* 323: Local-Variable Syntax for Lambda Parameters
<http://openjdk.java.net/jeps/323>
* 324: Key Agreement with Curve25519 and Curve448
<http://openjdk.java.net/jeps/324>
* 327: Unicode 10 <http://openjdk.java.net/jeps/327>
* 328: Flight Recorder <http://openjdk.java.net/jeps/328>
* 329: ChaCha20 and Poly1305 Cryptographic Algorithms
<http://openjdk.java.net/jeps/329>
* 330: Launch Single-File Source-Code Programs
<http://openjdk.java.net/jeps/330>
* 331: Low-Overhead Heap Profiling <http://openjdk.java.net/jeps/331>
* 332: Transport Layer Security (TLS) 1.3
<http://openjdk.java.net/jeps/332>
* 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
<http://openjdk.java.net/jeps/333>
* 335: Deprecate the Nashorn JavaScript Engine
<http://openjdk.java.net/jeps/335>
* 336: Deprecate the Pack200 Tools and API
<http://openjdk.java.net/jeps/336>
2) Quality Outreach Report for September 2018 is available*
*
* Quality Outreach report September 2018
*Thanks to everyone who contributed to JDK 11 by downloading and testing
the early-access builds.
In particular the following developers who logged **18 issues in the JDK
Bug System.*
* Netty
* Eclipse Jetty
* Apache Lucene
* JUnit5
* Apache Tomcat
* Apache Ant
* Apache POI
* AssertJ
* Eclipse Collections
* Byte Buddy
* RxJava
3) JDK 12 EA build 12, under both the GPL and Oracle EA licenses, are
now available at http://jdk.java.net/11 .
* Schedule , Status & Features
o http://openjdk.java.net/projects/jdk/12/
* Release Notes:
o http://jdk.java.net/12/release-notes
**
Rgds,Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
5 years
Completion of DeploymentUnitProcessor.deploy(ear, war1, war2) observed in a subsequent phase?
by Peter Palaga
Hi *,
I cannot find any info about what (if any) are the guarantees for
ordering and exit of DeploymentUnitProcessors (DUPs) in case of an EAR
that contains multiple WARs.
I have a situation like this: MyDUP1 is registered for Phase.PARSE and
MyDup2 is registered for Phase.DEPENDENCIES.
I can see from the logs that MyDUP1.deploy(ear),
MyDUP1.deploy(ear.war1), MyDUP1.deploy(war2), etc. are executed by
distinct threads which is perfectly OK.
I'd like to know if there is any guarantee that MyDup2.deploy(*)
observes the completion of MyDUP1.deploy(ear), MyDUP1.deploy(ear.war1),
MyDUP1.deploy(ear.war2), etc.?
MyDUP1.deploy() collects some info from the EAR and the WARs and stores
it as an attachment of the DeploymentUnit. MyDup2.deploy() is supposed
to read that attachment and so it is important that the info is complete
when MyDup2.deploy() reads it.
Thanks,
-- Peter
5 years
Changes to Wildfly model that affects HAL
by Claudio Miranda
Hi, I would like to propose to add a label "affects-hal" to
WFLY/WFCORE issues that may affect HAL, for example if the resulting
change may add/change/remove resources/operations or dependent
resources, this way once the PR is open, we may test the changes
before it is merged or work on a HAL feature branch.
I have had manually looking (and following) for PR that contains those
changes, but it is more of a guessing work.
An alternative to add the label, would be to add the "Web Console"
component to the issue, but this would not work as there should be two
issues one for WFLY/WFCORE and one for HAL.
I would like to hear your opinions on this topic to help us track
those incoming changes.
Thanks
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
5 years
Making More Use of wildfly-proposals
by Darran Lofthouse
At the moment we have a lot of effort going into populating the
wildfly-proposals repository with the proposals for new features as they
are added to the application server - but at the end other than them
sitting in the repository we don't really do anything with them.
I was wondering if we could maybe do something to add a table of contents
per WildFly release cross referencing the proposals added in that release
and at the end we could generate publishable documentation.
This could give us some quite detailed release notes without a huge amount
of additional effort taking advantage of the effort that goes into writing
these in the first place.
Regards,
Darran Lofthouse.
5 years
org.apache.httpcomponents.core requires org.apache.commons.codec
by Sanne Grinovero
Hi all,
the Elasticsearch integration feature we have in Hibernate Search uses
the Apache httpcomponents module from WildFly.
In WildFly 14 we get:
Exception in thread "Hibernate Search: Elasticsearch transport
thread-2" java.lang.NoClassDefFoundError:
org/apache/commons/codec/binary/Base64
2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search:
Elasticsearch transport thread-2) at
org.apache.http.impl.auth.BasicScheme.authenticate(BasicScheme.java:168)
2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search:
Elasticsearch transport thread-2) at
org.apache.http.impl.auth.HttpAuthenticator.doAuth(HttpAuthenticator.java:239)
2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search:
Elasticsearch transport thread-2) at
org.apache.http.impl.auth.HttpAuthenticator.generateAuthResponse(HttpAuthenticator.java:218)
2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search:
Elasticsearch transport thread-2) at
org.apache.http.impl.nio.client.MainClientExec.generateRequest(MainClientExec.java:224)
Seems that the `org.apache.httpcomponents.core` is not declaring the
dependency on module `org.apache.commons.codec`.
One complexity is that the first one is included in WildFly core, the
second is only added by WildFly full.
I guess I could add an optional dependency, but I wonder if many more
users would expect the basic authentication scheme to work in WildFly
core? In that case you would probably prefer to include the codec in
WildFly Core.
I can try fixing this but would need to know which solution you all
prefer. Also, not sure about the severity: definitely bad for
Hibernate Search users, but I don't know which other components might
be using this module.
Created: https://issues.jboss.org/browse/WFCORE-4083
Thanks,
Sanne
5 years
