Deprecated Direct Property Access Removal Warning
by Jason Lee
I have a PR open (https://github.com/wildfly/wildfly-core/pull/4636) that
hides properties that were long ago marked as deprecated. To be clear, the
properties themselves are not deprecated, but direct access has been. There
are getters and (where appropriate) setters that should be used instead.
Most of WildFly full has already been updated to use the methods for
accessing the properties (with a few stragglers addressed at
https://github.com/wildfly/wildfly/pull/14378). If you have a subsystem not
in the wildfly repo or any project that depends on WildFly Core that uses
AbstractAttributeDefinitionBuilder or any of its children, it would be
prudent to verify your usage to ensure you are not using the now-hidden
properties directly.
If you have questions or concerns, please comment on the PR.
Thanks!
Jason Lee
Principal Software Engineer
Red Hat JBoss EAP
5 years
Drop the Java EE 7 guide for WildFly 24
by Brian Stansberry
I propose we not produce an equivalent to
https://docs.wildfly.org/23/JavaEE_Tutorial.html for WF 24. So basically we
drop the relevant adoc pages from the WildFly docs maven module.
It's titled as being about Java EE 7, but WF 24 will be a Jakarta EE 8
server. A big chunk of what's in there is TODOs. We could retitle the doc,
but I'm not sure if what's there is up to date.
I've heard some discussions of how we should revamp our developer guides,
and I agree. I think a good first step is drop this one and start over. It
has some REST and webservices content that might still be useful; if so it
can be ported into a new document.
Best regards,
Brian
5 years
Fwd: Re: [ANNOUNCE] Rename wildfly-core "master" branch to "main"
by Frank Langelage
Step 3 throws an error for me:
jboss@sb2000:/home/jboss/WildFly-Core-master/wildfly-core git branch -m
master main
jboss@sb2000:/home/jboss/WildFly-Core-master/wildfly-core git fetch origin
remote: Enumerating objects: 326, done.
remote: Counting objects: 100% (326/326), done.
remote: Compressing objects: 100% (189/189), done.
remote: Total 326 (delta 168), reused 286 (delta 131), pack-reused 0
Receiving objects: 100% (326/326), 64.65 KiB | 23.00 KiB/s, done.
Resolving deltas: 100% (168/168), completed with 41 local objects.
From github.com:/langfr/wildfly-core
* [new branch] 15.x -> origin/15.x
jboss@sb2000:/home/jboss/WildFly-Core-master/wildfly-core git branch -u
origin/main main
error: the requested upstream branch 'origin/main' does not exist
hint:
hint: If you are planning on basing your work on an upstream
hint: branch that already exists at the remote, you may need to
hint: run "git fetch" to retrieve it.
hint:
hint: If you are planning to push out a new local branch that
hint: will track its remote counterpart, you may want to use
hint: "git push -u" to set the upstream config as you push.
jboss@sb2000:/home/jboss/WildFly-Core-master/wildfly-core git status
On branch main
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified:
controller/src/test/java/org/jboss/as/controller/persistence/FilePersistenceUtilsTest.java
modified:
testsuite/standalone/src/test/java/org/jboss/as/test/integration/credential/store/ManagementAuthenticationUsersTestCase.java
modified:
testsuite/standalone/src/test/java/org/jboss/as/test/integration/management/cli/AppendTestCase.java
modified:
testsuite/standalone/src/test/java/org/jboss/as/test/integration/management/cli/CliAliasTestCase.java
modified:
testsuite/standalone/src/test/java/org/jboss/as/test/integration/management/cli/CliCommentsTestCase.java
modified:
testsuite/standalone/src/test/java/org/jboss/as/test/integration/management/cli/CliControllerConfigTestCase.java
no changes added to commit (use "git add" and/or "git commit -a")
Am 15.06.2021 um 09:44 schrieb Jean-Frederic Mesnil:
> Hi,
>
> The renaming of “master" to “main” branch for wildfly-core is over.
>
> If you go to https://github.com/wildfly/wildfly-core, you should have
> a notification to update your local environment. This includes running
> the following commands:
>
> —8<—
> git branch -m master main
> git fetch origin
> git branch -u origin/main main
> git remote set-head origin -a
> —8<—
>
> If you have opened PR against wildfly/wildfly-core, you have nothing
> to do, the change is automatic.
>
> The CI has been updated and I verified the PR jobs runs fine (from
> https://ci.wildfly.org/project/WildFlyCore_PullRequest?mode=builds).
>
> I tried to do a thorough change in all the WildFly Core jobs on
> https://ci.wildfly.org/project/WildFlyCore?mode=builds and most of the
> jobs are fine too.
>
> Best regards,
> Jeff
>
> --
> Jeff Mesnil
> Principal Software Engineer
> Red Hat
> http://jmesnil.net/
> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
5 years
[ANNOUNCE] Rename wildfly-core "master" branch to "main"
by Jean-Frederic Mesnil
Hi,
We have now released WildFly Core 16.0.0.Final for the upcoming release of WildFly 24 and will start development of WildFly Core 17.
We’ll take the opportunity to be early in the development cycle to change the default branch for wildfly/wildfly-core project from “master" to “main".
GitHub has some instructions that should help with the move: https://github.com/github/renaming. It should work transparently at the project level and each contributor will just need to update their local environment.
We also need to update all the CI scripts we are using to test WildFly Core.
Once the switch is done, I’ll send another mail to inform each contributor with the steps to update their local environment.
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
5 years
Making PicketBox Optional
by Darran Lofthouse
Previously we have worked to eliminate all mandatory module dependencies on
the org.jboss.as.security module - this means that this module is not only
provisioned by Galleon if we are provisioning a layer which includes the
subsystem.
The next target we need to tackle is the org.picketbox module, this step
will involve some work within each of the affected components. We need to
reach the point that all other module dependencies on this one are also
optional so it is only provisioned when the legacy security subsystem is
provisioned.
At the top level this is being tracked under:
https://issues.redhat.com/browse/WFLY-13889
For the individual subsystems I have split out a set of tasks so they can
be tackled individually:
- Messaging - https://issues.redhat.com/browse/WFLY-14752
- IIOP - https://issues.redhat.com/browse/WFLY-13679
- Web Services - https://issues.redhat.com/browse/WFLY-14841
- JCA - https://issues.redhat.com/browse/WFLY-14842
- EJB3 - https://issues.redhat.com/browse/WFLY-14843
- Application Client - https://issues.redhat.com/browse/WFLY-14844
- security-api / security-integration -
https://issues.redhat.com/browse/WFLY-14845
I have left these unassigned by default so we can see when they have been
picked up.
Some of these may be more complicated than others so the most urgent task
is to identify where we think we are going to run into problems so we can
define a solution.
Some solutions could include:
- Moving utility code to WildFly Elytron or some other common project.
- Forking utility code to a private implementation in the project that
needs it.
- For anything affecting deployments using capabilities to check if legacy
security is present.
- Any optional use of legacy security should be disabled from Java 13 and
later.
- Other solutions to be developed.
This specific task is not about changing the default configuration to move
on from legacy security. Once this step is complete we will be ready to
start adjusting the default configuration to eliminate legacy security.
Regards,
Darran Lofthouse.
5 years
JDK 17 is now in Rampdown Phase One
by Rory O'Donnell
Hi David & Richard,
*Per the JDK 17 schedule , we are in Rampdown Phase One [1].*
**Please advise if you find any issues while testing the latest Early
Access builds**.**
* Schedule:
o *2021/06/10 Rampdown Phase One*
o 2021/07/15 Rampdown Phase Two
o 2021/08/05 Initial Release Candidate
o 2021/08/19 Final Release Candidate
o 2021/09/14 General Availability
The overall feature set is frozen. No further JEPs will be targeted to
this release.
**
* Important JEPs have been integrated – Attention Required!
* *JEP 411: **Deprecate the Security Manager for
Removal*<https://openjdk.java.net/jeps/411>
o Deprecate, for removal, most Security Manager related classes
and methods.
o Warning message at startup if the Security Manager is enabled on
the command line.
o Warning message at run time if a Java application or library
installs a Security Manager dynamically.
o Deprecation is in concert with the legacy Applet API (JEP 398).
* *JEP 407: **Remove RMI Activation*<https://openjdk.java.net/jeps/407>
o Removal the Remote Method Invocation (RMI) Activation mechanism,
while preserving the rest of RMI.
o It was deprecated for removal by JEP
385<https://openjdk.java.net/jeps/385>in Java SE 15.
* *JEP 403: **Strongly Encapsulate JDK
Internals*<https://openjdk.java.net/jeps/403>
o Strongly encapsulate all internal elements of the JDK, except
for critical internal APIs such as /sun.misc.Unsafe/.
o It will no longer be possible to relax the strong encapsulation
of internal elements via a single command-line option.
* Other features integrated in JDK 17:
o *JEP 306: **Restore Always-Strict Floating-Point
Semantics*<https://openjdk.java.net/jeps/306>
o JEP 356: Enhanced Pseudo-Random Number
Generators<https://openjdk.java.net/jeps/356>
o JEP 382: New macOS Rendering
Pipeline<https://openjdk.java.net/jeps/382>
o JEP 391: macOS/AArch64 Port<https://openjdk.java.net/jeps/391>
o JEP 398: Deprecate the Applet API for
Removal<https://openjdk.java.net/jeps/398>
o *JEP 406: **Pattern Matching for switch
(Preview)*<https://openjdk.java.net/jeps/406>
o JEP 409: Sealed Classes<https://openjdk.java.net/jeps/409>
o JEP 410: Remove the Experimental AOT and JIT
Compiler<https://openjdk.java.net/jeps/410>
o JEP 412: Foreign Function & Memory API
(Incubator)<https://openjdk.java.net/jeps/412>
o *JEP 414: **Vector API (Second
Incubator)*<https://openjdk.java.net/jeps/414>
o *JEP 415: **Context-Specific Deserialization
Filters*<https://openjdk.java.net/jeps/415>
*OpenJDK 17 Early Access build 26 is available at
**https://jdk.java.net/17*<https://jdk.java.net/17>
* These early-access , open-source builds are provided under the
o GNU General Public License, version 2, with the Classpath
Exception<https://openjdk.java.net/legal/gplv2+ce.html>
* Release Notes are available at
https://jdk.java.net/17/release-notes<https://jdk.java.net/17/release-notes>
* Changes in recent builds that maybe of interest:
* *Build 26:*
o JDK-8268241: deprecate JVM TI Heap functions 1.0
o JDK-8266846: Add java.time.InstantSource
o JDK-8248268: Support KWP in addition to KW
o JDK-8204686: Dynamic parallel reference processing support for
Parallel GC
o JDK-8259530: Generated docs contain MIT/GPL-licenced works
without reproducing the licence [*Reported by Apache Maven*]
o JDK-8266766: Arrays of types that cannot be an annotation member
do not yield exceptions [*Reported by ByteBuddy*]
o JDK-8266598: Exception values for
AnnotationTypeMismatchException are not always informative
[*Reported by ByteBuddy*]
* *Build 25*
o JDK-8266653: Change update mode for JDK rpm/deb installers as it
breaks "yum update" for JDK11+
o JDK-8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language
codes to current
o JDK-8229517: Support for optional asynchronous/buffered logging
o JDK-8182043: Access to Windows Large Icons
*OpenJDK 18 Early Access build 1 is now available at
**https://jdk.java.net/18* <https://jdk.java.net/18>
* These early-access , open-source builds are provided under the
o GNU General Public License, version 2, with the Classpath
Exception <https://openjdk.java.net/legal/gplv2+ce.html>
* Issues addressed in this build - here
<https://github.com/openjdk/jdk/compare/jdk-18%2B0...jdk-18%2B1>
*Other Topics which might be of Interest: *
**
* Java Cryptographic Roadmap [2] has been updated.
* Inside Java Newscast #6 [3]
o a closer look at the list of JEPs of JDK 17 as well as the
development process
* Inside Java Newscast #7 [4]
o discusses in greater detail `pattern matching for switch`,
previewed in JDK 17
Rgds,Rory
[1]
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-June/005690.html
<https://mail.openjdk.java.net/pipermail/jdk-dev/2021-June/005690.html><https://mail.openjdk.java.net/pipermail/jdk-dev/2021-June/005690.html><https://mail.openjdk.java.net/pipermail/jdk-dev/2021-June/005690.html>
[2] https://java.com/en/jre-jdk-cryptoroadmap.html
<https://java.com/en/jre-jdk-cryptoroadmap.html>
[3] https://inside.java/2021/06/10/insidejava-newscast-006/
<https://inside.java/2021/06/10/insidejava-newscast-006/>
[4] https://inside.java/2021/06/13/podcast-017/
<https://inside.java/2021/06/13/podcast-017/>
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
5 years
