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
WildFly roadmap and key dates for WildFly 17
by Brian Stansberry
Work is now underway on WildFly 17, so I wanted to blog about what I see
coming in the next few releases. You can read that at
https://wildfly.org/news/2019/03/09/Onward-to_WildFly-17/. I'd love to get
your feedback here. I'm particularly interested in peoples' thoughts on
what they'd like to see in Jakarta EE 9.
If you're interested in the details of new features that are being worked,
I really encourage you to keep an eye on
https://github.com/wildfly/wildfly-proposals/pulls and comment on any
proposals you see there. I encourage folks who submit a new proposal to
post here with a quick intro and a link.
WildFly 17 is scheduled for release three months after 16, continuing the
quarterly cadence. Here are the key dates:
- Fri, May 10 — PRs ready for merge for all features coming in via
WildFly Core
- Tue, May 14 — All features ready for merge
- Wed, May 15 — WildFly 17 Beta. No new features after this date.
- Fri, May 24 — All changes for WildFly Core ready
- Tue, May 28 — All changes for WildFly ready
- Thu, May 30 — WildFly 17 Final released
Best regards,
Brian
5 years, 6 months
Question about usage of jboss spec versions
by Matej Novotny
Hello,
This is probably stupid question but I was recently wondering, what's the actual reason why WFLY (and other RH technologies) use jboss versions of all the specs?
For instance https://github.com/jboss/jboss-annotations-api_spec instead of just picking up the javax.annotation artifact.
The contents are pretty much the same, so I think I have to be missing something trivial and obvious..
Is it historical reasons? Or perhaps a matter of licenses and productization?
Matej
5 years, 8 months
JDK 13 - Early Access build 14 is available
by Rory O'Donnell
Hi David & Richard*,*
*OpenJDK builds *- JDK 13 - Early Access build 14 is available at
http://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
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B13%22%3A...>
* Release notes [1]
* JDK 13 Schedule proposal accepted [2]
o 2019/06/13 Rampdown Phase One
o 2019/07/18 Rampdown Phase Two
o 2019/08/08 Initial Release Candidate
o 2019/08/22 Final Release Candidate
o 2019/09/17 General Availability
*jpackage EA *
* This is an early access build of JEP 343: Packaging Tool
<https://openjdk.java.net/jeps/343>, aimed at testing a prototype
implementation of jpackage, which is a new tool for packaging
self-contained Java applications along with a Java Runtime Environment.
* Build 30 is now available http://jdk.java.net/jpackage/
* Please send feedback via e-mail to core-libs-dev(a)openjdk.java.net
<mailto:core-libs-dev@openjdk.java.net>
*Quality Outreach report for **March 2019*
* The report for March 2019 is available here
<https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+Mar...>
* Thanks to all those contributed !
*Recent Blog:* A new (Japanese) era for Java!
<https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java>
Rgds,Rory
[1] http://jdk.java.net/13/release-notes
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002736.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
5 years, 8 months
How to Select a Different Name Context in Management Request Thread
by Cheng Fang
Hi,
I'm working on WFLY-11808 <https://issues.jboss.org/browse/WFLY-11808> (Unable
to do jndi lookup when starting batch job from web console), and would like
to get some help from team, especially naming and management experts.
The failure occurred when a batch job is started from management console or
CLI, and during the batch job execution it does some jndi lookup. The
lookup failed with NameNotFoundException.
In batch subsystem, it assigns the name context for the job execution by
calling:
NamespaceContextSelector.getCurrentSelector();
For a management-started job execution, it selected the one associated with
the current thread which is an external management request thread, and
apparently has no knowledge of the deployment.
Is there a way to select the name context associated with the deployment
that contains the batch job?
Thanks,
Cheng
5 years, 8 months
Release Announcement: General Availability of Java 12 / JDK 12
by Rory O'Donnell
**
Hi David & Richard*,*
* *
*1) Release Announcement: General Availability of Java 12 / JDK 12 [1] *
* JDK 12, the reference implementation of Java 12, is now Generally
Available.
* GPL-licensed OpenJDK builds from Oracle are available here:
https://jdk.java.net/12
This release includes the following eight features:
* JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
* JEP 230: Microbenchmark Suite
* JEP 334: JVM Constants API
* JEP 340: One AArch64 Port, Not Two
* JEP 341: Default CDS Archives
* JEP 344: Abortable Mixed Collections for G1
* JEP 346: Promptly Return Unused Committed Memory from G1
Thanks to everyone who contributed JDK 12, whether by creating features
or enhancements, logging bugs, or downloading and testing the
early-access builds.
*2) JDK 13 EA build 12, under both the GPL and Oracle EA licenses, is
now available at **http://jdk.java.net/13**.*
* Proposed - Schedule for JDK 13 [2]
o 2019/06/13 Rampdown Phase One
o 2019/07/18 Rampdown Phase Two
o 2019/08/08 Initial Release Candidate
o 2019/08/22 Final Release Candidate
o 2019/09/17 General Availability
* Recent Bug fixes of Interest
o Build 9:
+ 8214719: Deprecate -Xverify:none option
+ 8216360: Deprecate -XX:CompilationPolicyChoice
o Build 10:
+ 8218995: Deprecate the -XX:FailOverToOldVerifier option
o Build 12 : 8160247: Mark deprecated javax.security.cert APIs
with forRemoval=true
+ 8220050: Deprecate -XX:-ThreadLocalHandshakes
+ Apache Lucene Reported - 8219448: split-if update_uses
accesses stale idom data
* Changes in this build [3]
Rgds,Rory
[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002718.html
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002716.html
[3] Changes
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B11%22%3A...>
in this build
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
5 years, 8 months
Missing transformer tests
by Kabir Khan
TL;DR: It looks like we may be missing transformer tests in the following
subsystems: ejb3, infinispan, jca, logging, undertow. I've not dug in
beyond that.
Full:
We have been using ModelTestControllerVersion.EAP_7_2_0_TEMP (containing
WF14) for transformer testing until EAP 7.2.0 was released. [1] renames
this to be EAP_7_2_0 and points to EAP 7.2.0.
In addition I have some WIP to update the full mixed domain and subsystem
tests to do the same. When doing this I noticed that the only subsystem
that had transformer tests referencing EAP_7_2_0_TEMP was modcluster. I
knew messaging-activemq had some changes, which Emmanuel is looking at.
I've run the model comparison tool against master/7.2.0: and see changes
which might be significant:
====== Resource root address: ["subsystem" => "ejb3"] - Current version:
0.0.0; legacy version: 5.0.0 =======
--- Problems for relative address to root ["passivation-store" => "*"]:
Different 'access-type' for attribute 'bean-cache'. Current: "read-write";
legacy: "read-only"
Different 'access-type' for attribute 'cache-container'. Current:
"read-write"; legacy: "read-only"
====== Resource root address: ["subsystem" => "infinispan"] - Current
version: 0.0.0; legacy version: 8.0.0 =======
* --- Problems for relative address to root ["remote-cache-container" =>
"*"]:
Different 'default' for attribute 'protocol-version'. Current: "2.9";
legacy: "2.8"
====== Resource root address: ["subsystem" => "jca"] - Current version:
0.0.0; legacy version: 5.0.0 =======
--- Problems for relative address to root ["distributed-workmanager" =>
"*","long-running-threads" => "*"]:
* Missing attributes in current: [handoff-executor]; missing in legacy []
* Missing parameters for operation 'add' in current: [handoff-executor];
missing in legacy []
--- Problems for relative address to root ["distributed-workmanager" =>
"*","short-running-threads" => "*"]:
* Missing attributes in current: [handoff-executor]; missing in legacy []
* Missing parameters for operation 'add' in current: [handoff-executor];
missing in legacy []
--- Problems for relative address to root ["workmanager" =>
"*","long-running-threads" => "*"]:
* Missing attributes in current: [handoff-executor]; missing in legacy []
* Missing parameters for operation 'add' in current: [handoff-executor];
missing in legacy []
--- Problems for relative address to root ["workmanager" =>
"*","short-running-threads" => "*"]:
* Missing attributes in current: [handoff-executor]; missing in legacy []
* Missing parameters for operation 'add' in current: [handoff-executor];
missing in legacy []
--- Problems for relative address to root ["workmanager" =>
"default","long-running-threads" => "*"]:
* Missing attributes in current: [handoff-executor]; missing in legacy []
* Missing parameters for operation 'add' in current: [handoff-executor];
missing in legacy []
--- Problems for relative address to root ["workmanager" =>
"default","short-running-threads" => "*"]:
* Missing attributes in current: [handoff-executor]; missing in legacy []
* Missing parameters for operation 'add' in current: [handoff-executor];
missing in legacy []
====== Resource root address: ["subsystem" => "logging"] - Current version:
0.0.0; legacy version: 7.0.0 =======
* --- Problems for relative address to root ["json-formatter" => "*"]:
Different 'default' for attribute 'record-delimiter'. Current: "
"; legacy: ""
* --- Problems for relative address to root ["logging-profile" =>
"*","json-formatter" => "*"]:
Different 'default' for attribute 'record-delimiter'. Current: "
"; legacy: ""
* --- Problems for relative address to root ["logging-profile" =>
"*","xml-formatter" => "*"]:
Different 'default' for attribute 'record-delimiter'. Current: "
"; legacy: ""
* --- Problems for relative address to root ["xml-formatter" => "*"]:
Different 'default' for attribute 'record-delimiter'. Current: "
"; legacy: ""
====== Resource root address: ["subsystem" => "undertow"] - Current
version: 0.0.0; legacy version: 7.0.0 =======
--- Problems for relative address to root ["application-security-domain" =>
"*"]:
* Missing attributes in current: []; missing in legacy [enable-jaspi,
integrated-jaspi]
* Missing parameters for operation 'add' in current: []; missing in legacy
[enable-jaspi, integrated-jaspi]
Although WF16 doesn't provide any domain mode guarantees for previous
releases, this will one day end up as a product release and then it is
important that we have these tests in place. It is easier to add them as we
go along than to retrofit them when that time comes.
Thanks,
Kabir
[1] https://github.com/wildfly/wildfly-core/pull/3664
5 years, 8 months
