Embedded broker layer
by Emmanuel Hugonnet
Hello,
Currently there is no way to use layers to provision an embedded broker and I've been thinking about to provide such a layer.
The embedded broker configuration is done using the "messaging-activemq" feature group [1]. This feature group configure the embedded broker
itself, the ee default connection factory and the mdb part in the ejb3 subsystem.
Introducing an embedded broker layer requires several changes in the current layers:
- it should not be the responsibility of the embedded broker layer to configure mbd in the ejb3 subsystem, thus i propose to introduce a
new ejb-mdb layer that would depend on the ejb layer [2] and have an optional dependency on the embedded-broker layer.
- the embedded-broker layer would depend on the current messaging-activemq layer [3] and configure the ee default connection factory and
broker according to wht is already defined in the "messaging-activemq" feature group [1].
What do you think about this plan ?
Cheers,
Emmanuel
[1]: https://github.com/wildfly/wildfly/blob/main/ee-feature-pack/galleon-comm...
[2]: https://github.com/wildfly/wildfly/tree/main/ee-feature-pack/galleon-comm...
[3]: https://github.com/wildfly/wildfly/tree/main/ee-feature-pack/galleon-comm...
3 years, 10 months
Updates on conscious language work
by Brian Stansberry
I wanted to give an update on things that are going on related to conscious
language in the WildFly project.
First, for the WF 27 release we intend to move away from 'master / slave'
in user visible production code related to WildFly's domain mode. After
some good input today from Paul Ferraro, a Host Controller that is
configured to act as the Domain Controller will be referred to as the
'primary' instead of the 'master'; other Host Controllers will be referred
to as 'secondary'.
The main effect of this would be the name of two of the standard config
files we ship:
host-master.xml -> host-primary.xml
host-slave.xml -> host-secondary.xml
The master/slave concept doesn't have a deep presence in the actual code or
user API, beyond the name of those 2 files. It's mostly something that
appears in docs.
Second, if anyone is blocking re what to do about whitelist/blacklist in WF
code, without objection I suggest we go with allowlist / blocklist, which
seems to be the most common choice for what to use.
Third, fyi that I've renamed the default branch in a couple repos related
to WildFly from 'master' to main:
https://github.com/wildfly/wildfly.github.io (source behind docs.wildfly.org
)
https://github.com/wildfly/wildfly.org (source behind wildfly.org)
If you have a local clone of these repositories, the steps to convert your
clone are:
git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a
Best regards,
Brian Stansberry
Red Hat
He/Him/His
3 years, 10 months
Milestone -jbossorg releases of EE 10 API
by Brian Stansberry
As of last week there were no milestone releases for the EE 10 specs listed
at [1] available in maven central. It's not clear when public releases of
some of these specs might be possible. I've directly addressed the WFLY
component leads for the JIRA components that integrate those because I'd
like to get answers to 3 questions:
1) Would near term (say next couple weeks) production of a -jbossorg
variant of a milestone of a spec be useful to you? E.g. unblock other
work. Probably this could be done by forking the official spec branch into
our existing JBoss fork repos and publishing a -jbossorg variant of
an existing tag.
2) If not useful near term, an info on when the lack of a public API
milestone would be a problem for you EE 10 work would be useful.
3) If useful, could you help?
I'll create a google sheet to record input.
Note that I'm not talking about using these releases for the long term;
it's just about avoiding needing to use staging repos for WF 27 development
while we wait for releases in maven central. Obviously there is a
cost/benefit tradeoff here, hence the request for input.
[1]
Authentication
Concurrency
Connectors
Enterprise Java Beans (no biggie; just a micro)
JSON Binding
JSON Processing
Messaging
RESTFul Webservices
Server Pages
Servlet
Standard Tag Library
Websocket
Best regards,
Brian
3 years, 10 months
Finer grained tracking of progress on EE 10
by Brian Stansberry
I want to get things started re getting more fine-grained issues created
for the various EE 10 spec migration issues linked to
https://issues.redhat.com/browse/WFLY-15679. In many cases the issues
directly linked to WFLY-15679 are too coarse-grained, because there are a
number of distinct tasks that can be done separately for each, and to have
a realistic sense of where we stand we need to have visibility into how
things stand with those finer-grained pieces
A good recommendation I got from Tom Jenkinson is to add a comment on the
various per-spec issues outlining the various types of detailed issues the
assignee should consider filing, along with instructions as to how to do
so. The following is what I propose adding:
"Please consider creating subtasks of this issue for any of the following
or other similar activities that can be accomplished as discrete pieces of
work toward this JIRA's overall goal. Please add the 'EE10' label to any
such issue.
* Ensuring that the standalone TCK for this spec can be run against a
current build of WildFly Preview, and if possible reporting any issues to
spec's working group before it is finalized.[1]
* Creating a branch for the EE 10 variant in the github repo for the JBoss
fork of the spec, based on the appropriate code at Jakarta.[2]
* Integrating a milestone release of the spec API into WildFly's main
branch.
* Integrating a milestone release of the implementation artifacts into
WildFly's main branch.
* Integrating the final release of the spec API into WildFly's main branch.
* Integrating final releases of the implementation artifacts
Reminder: WildFly 27 is feature-boxed, so integrating non-final
dependencies into main is not just ok, it is encouraged. Doing so lets us
identify issues early.
We'll be using these finer-grained issues to better track progress on
https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=14333&view=pla...
and elsewhere."
Note that I don't include passing standalone or parts of the platform TCK
here, because it's not clear to me that that kind of thing can be cleanly
decomposed into discrete pieces of work. We know we need to pass the TCKs.
Note also that this message and the related issues are focused on WildFly
Preview. Our ultimate goal is to convert the standard WildFly code to EE
10, ideally as soon as possible. But to do that we'll need to complete the
work of getting native jakarta.* namespace variants of all our components.
That work can proceed in parallel with our work on EE 10 if we continue to
do it in WFP for now.
[1] I'd only add this to issues where a standalone TCK exists.
[2] I'd only add this to issues where we are using a fork of the EE 9.1
spec API code in WildFly Preview.
Best regards,
Brian
3 years, 10 months
standalone/ directory shared by multiple Wildfly instances?
by Tomas Hofman
Hello,
could anybody confirm if it's OK (or not OK) to run multiple clustering
Wildfly instances that would share common standalone/ directory? Even if
the instances are supposed to be running the same deployments?
I always thought that the standalone/ directory should be separate for
each Wildfly/EAP instance, but I can't find any resources that would
clearly state that shared standalone/ is a problem.
The problems I think of are:
* instances could override their standalone.xml config,
* instances could override some transactional or cache data?
Thanks :),
Tomas
3 years, 10 months
JDK 18 Release Candidate builds & JDK 19 Early-Access builds
by David Delabassee
All,
The Release Candidates of JDK 18 have been released [1]. At this stage,
only P1 issues will be evaluated [2]. And with the JDK 18 General
Availability sets for March 22nd, it is now time to shift the focus to
JDK 19. I'd like to thank those of you who have already provided
feedback on the early Early Builds of JDK 19. Feedback is always
extremely useful, even more, when it comes early in the development cycle.
[1]
https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006404.html
[2] https://openjdk.java.net/jeps/3
## JDK 18 Release Candidate
The Release Candidate builds of JDK 18 are now available [3], and are
provided under the GNU General Public License v2, with the Classpath
Exception. The Release Notes are available here [4].
[3] https://jdk.java.net/18/
[4] https://jdk.java.net/18/release-notes
## JDK 19 Early-Access builds
JDK 19 Early-Access builds 11 are now available [5], and are provided
under the GNU General Public License v2, with the Classpath Exception.
The Release Notes are available here [6].
[5] https://jdk.java.net/19/
[6] https://jdk.java.net/19/release-notes
Recent changes that maybe of interest:
* JDK-8278067: Make HttpURLConnection default keep alive timeout
configurable
* JDK-8281000: ClassLoader::registerAsParallelCapable throws NPE if
caller is null
* JDK-8282279: Interpret case-insensitive string locale independently
* JDK-8176706: Support CLDR's Additional (Skeleton) Date-Time Formats
* JDK-5041655: (ch) FileLock: negative param and overflow issues
* JDK-8255266: Update Public Suffix List to 3c213aa
* JDK-8280958: G1/Parallel: Unify marking code structure
* JDK-8072070: Improve interpreter stack banging
* JDK-8277175: Add a parallel multiply method to BigInteger
* JDK-8278947: Support for array constants in constant table
* JDK-8281462: Annotation toString output for enum not reusable for
source input
* JDK-8281175: Add a -providerPath option to jarsigner
* JDK-8277795: ldap connection timeout not honoured under contention
* JDK-8279842: HTTPS Channel Binding support for Java GSS/Kerberos
* JDK-8280744: Allow SuppressWarnings to be used in all declaration contexts
* JDK-8272984: javadoc support for reproducible builds
* JDK-8272317: jstatd has dependency on Security Manager which needs to
be removed
## New Project Loom Early-Access builds
Project Loom Early-Access builds19-loom+4-115 (2022/2/13) are available
[7] with the related Javadoc [8].
These EA builds are based on JDK 19 (jdk-19+9). In those builds, the
APIs for Structured Concurrency and Scope Locals have been moved into
the `jdk.incubator.concurrent` incubator module. Note that the module
name may change later. To use those APIs, simply use `--add-modules
jdk.incubator.concurrent` at compile and runtime.
Those EA builds are provided under the GNU General Public License,
version 2, with the Classpath Exception and are produced for the purpose
of gathering feedback. Use for any other purpose is at your own risk.
Proper feedback should be sent to the `loom-dev` mailing list [9].
[7] https://jdk.java.net/loom/
[8] https://download.java.net/java/early_access/loom/docs/api/
[9] https://mail.openjdk.java.net/mailman/listinfo/loom-dev
## Topics of Interest
* JDK 18 - Card Table Card Size Shenanigans
https://tschatzl.github.io/2022/02/15/card-table-card-size.html
* Compiled & Tested Code In Javadoc - Inside Java Newscast #20
https://inside.java/2022/02/10/insidejava-newscast-020/
* New candidate JEP: 423: Region Pinning for G1
https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006368.html
* Refactoring Java 8 code with Java 17 new features - JEP Café #9
https://inside.java/2022/02/01/jepcafe9/
As always, let us know if you find any issues while testing your
projects on the latest JDK Early Access builds. Thanks for your support!
--David
3 years, 10 months
