JDK 12 enters Rampdown Phase Two
by Rory O'Donnell
Hi David & Richard,*
*
**OpenJDK builds *- JDK 12 Early Access build 28 **is now available **at
: - jdk.java.net/12/*
* Per the JDK 12 schedule [1], we are now in Rampdown Phase Two.
o For more details , see Mark Reinhold's email to jdk-dev mailing
list [2]
o The overall feature set is frozen, no further JEPs will be
targeted to this release.
o Per the JDK Release Process [3] we now turn our focusto P1 and
P2 bugs.
**OpenJDK builds *- JDK 13 Early Access build 4 is **now available **at
: - jdk.java.net/13/*
* 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>.
* Release Notes:
o http://jdk.java.net/13/release-notes
* Changes in this build
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B3%22%3A%...>
Blog Updates from Java SE Product Management since last email.
* Oracle Java SE Releases FAQ [3]
* Oracle Java SE Support Roadmap [4]
Rgds,Rory
[1] http://openjdk.java.net/projects/jdk/12/#Schedule
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2019-January/002537.html
[3] https://blogs.oracle.com/java-platform-group/oracle-java-se-releases-faq
[4] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
4 years, 2 months
Should I fail or should I undefine ?
by Emmanuel Hugonnet
Hello,
I was looking into introducing new metrics and got into a discussion with Jeff about what is the proper way to handle the fact that the
service is missing.
Currently if the JMSBridge is not available as a service then reading any read only runtime attribute fails with a:
{
"outcome" => "failed",
"result" => 0,
"failure-description" => "WFLYCTL0216: Management resource '[
(\"subsystem\" => \"messaging-activemq\"),
(\"jms-bridge\" => \"test\")
]' not found",
"rolled-back" => true
}
So "/subsystem=messaging-activemq/jms-bridge=test:read-attribute(name=started)" will fail in admin-only mode. This feels strange to me as i
would expect an "undefined" result and not a failure. In the same way, trying to get the number of processed messages by the bridge should
return undefined since the bridge is not running. Do we have a rule so that this behaviour is consistent ?
Cheers,
Emmanuel
4 years, 2 months
Re: [wildfly-dev] wildfly-gradle plugin
by Sanne Grinovero
hi Ahmed!
Good point, I didn't make an example for that.
Such defails are controlled in the provisioning.xml file; add
copy-module-artifacts="true" in the server-provisioning, that's in the
main element.
For example see the main example at [1]
<server-provisioning xmlns="urn:wildfly:server-provisioning:1.1"
extract-schemas="true" copy-module-artifacts="true"
extract-schemas-groups="org.jboss.as org.wildfly
org.wildfly.core org.jboss.metadata">
<feature-packs>
<feature-pack groupId="org.wildfly"
artifactId="wildfly-feature-pack" version="${project.version}">
<contents>
<filter pattern="copyright.txt" include="false"/>
<filter pattern="README.txt" include="false"/>
<filter pattern="docs/contrib/*" include="false"/>
</contents>
</feature-pack>
</feature-packs>
</server-provisioning>
I'll add an example to the README.
1 - https://github.com/wildfly/wildfly-build-tools/
Thanks,
Sanne
On Tue, 15 Jan 2019 at 14:59, ahmed galal <a.galal7(a)gmail.com> wrote:
>
> good day sanne
>
> i was trying to use wildfly-gradle plugin to run some tests on the materialized server using arquillian.
> but the plugin creates a thin version of the server , ho can i configure the plugin to generate a fat version of the server with all the jars ? so i can run it directly from the build directory?
4 years, 2 months
New WildFly Project Lead
by Jason Greene
[Also Posted to Wildfly Blog: http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/]
I am very excited to announce that Brian Stansberry (@bestansberry) will be taking on the role of WildFly project lead. Brian has been a major contributor to the project for almost 15 years now. During this time, he led a number of critical and complex subsystems including Clustering, Management, and most recently the cross-cutting cloud integration work. He is also one of our most active reviewers, and has helped many contributors navigate deep WildFly internals. Congratulations Brian!
It’s been a great journey, so I want to think each and every one of you for your contributions and support over the years. Our work as a community has frequently pushed the envelope, and led to WildFly being one of the most innovative and popular application servers available. While I will be moving on from this role, I won’t be too far way, still participating but tackling a new challenge (I’ll have more to say about that in the future).
With Brian at the helm, and all the great folks contributing to the project, I know WildFly has a bright future. I look forward to seeing the next chapter.
Turn the page.
-Jason
4 years, 2 months
CI testing with the security manager enabled
by Brian Stansberry
FYI about some small changes in how we test PRs...
tl;dr; We are running the entire testsuite with a security manager enabled
as one of the CI jobs run when PRs are tested. If a PR fails this test,
there will need to be some form of correction before merging.
For quite a while now one of the jobs that runs when you submit or update a
PR turns on the JVM security manager for the WF processes being tested. But
until this year that job only ran a relatively small portion of the overall
testsuite. Now it has been modified to run the entire testsuite.
The effect of this is PRs that introduce failures when the security manager
is enabled will be detected before merge. For a long time my colleagues in
Red Hat QE have run the entire suite with the security manager enabled and
filed bug reports for issues. Now we'll catch these before merging, a much
more efficient way of dealing with them.
The 3,000 meter overview of how WildFly works with a security manager
installed is the code WildFly ships (including libraries from other
projects) is intended to have full permissions to do what it wants, but
code in deployments needs to be granted permissions. Whether a particular
call that results in a security manager check results in the deployment
code needing a permission depends on whether the call stack involves
deployment code, and if does, whether WildFly code higher in the stack used
a privileged block to limit the part of the stack the security manager
evaluates for permissions.
If your PR has a failure in the security manager job, here's what you can
do:
Do some thinking about whether the failure is because a deployment you are
introducing in the test is doing something for which it's reasonable that
the deployment would need permissions. For example, it's directly opening
an HttpClient, or is directly reading a system property or is directly
reading a file.
1) If the answer is CLEARLY YES, then
a) modify the test to stop doing that or
b) use the utils in the WildFly testsuite codebase to add a permissions.xml
to the test deployment such that it gets the permissions it needs.[1]
2) If the answer is CLEARLY NO, then WildFly should have been using a
privileged block for something, or is doing something unnecessary, so
a) if it was your PR that introduced the problem, fix the PR.
b) else file a WFLY or WFCORE JIRA showing the problem, including a stack
trace of the security manager failure. You can then use a utility in the
WildFly testsuite code to ignore the test in the security manager test.[2]
Include a note in the JIRA that you've done this so removing the ignore can
be part of resolving the JIRA.
3) If the answer is NOT SURE, do not just add a permission in a
permissions.xml! Don't sweep a possible problem under the rug. Instead, try
to have a discussion with the PR reviewers or in chat or here to get some
feedback, and once you've gone as far as you're willing with that, file a
JIRA for the problem and ignore the test when the security manager is
enabled[2].
My thanks to the many folks over the years who've worked to get all but a
tiny fraction of our thousands of tests passing with a security manager.
And especially to James Perkins and Martin Choma who've really pushed on
this this year.
[1] For example,
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basi...
This grants the deployment the permission to read a lot of system
properties. That looks scary but it's just because the test wants to read a
lot of properties.
[2] For example,
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basi...
Please include the comment showing the issue that was filed; that helps
make it easier to find and remove these once the JIRA is resolved.
Best regards,
Brian
4 years, 2 months
JDK 12 Early Access build 26 & JDK 13 Early Access builds available
by Rory O'Donnell
Hi David & Richard,*
*
Happy New Year!
*OpenJDK builds *- JDK 12 Early Access build 26 is available at
http://jdk.java.net/12/
* 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 since last email
o Distrust TLS server certificates anchored by Symantec Root CAs
(JDK-8207258 <https://bugs.openjdk.java.net/browse/JDK-8207258>)
o Customizing the generation of a PKCS12 keystore (JDK-8076190
<https://bugs.openjdk.java.net/browse/JDK-8076190>)
o Compact Number Formatting Support (JDK-8177552
<https://bugs.openjdk.java.net/browse/JDK-8177552>)
*OpenJDK builds *- JDK 13 - Early Access build 2 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%2B1%22%3A%...>
*jpackage EA builds*
* 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.
* 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 December 2018*
* The report for December 2018 is available here
<https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+for...>
Rgds,Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
4 years, 2 months
