WildFly 29.0.0.Alpha1 release
by Brian Stansberry
I've completed the release of the primary server zips/tars for WildFly and
WildFly Preview 29.0.0.Alpha1, along with the associated wildfly,
wildfly-ee and wildfly-preview feature packs. Thanks folks, for all the
good work on this.
These artifacts are available on repository.jboss.org. We don't plan to add
them to wildfly.org/downloads.
The 29 Alpha1 release is primarily an internal milestone, which is why
we're not taking the time to add it to the downloads page. We've been doing
a lot of code reorganization, deprecated code removal and other
housekeeping type work since the WildFly 28 release, plus of course bug
fixing and some feature work. The binary server release allows other parts
of the WildFly ecosystem to integrate the results of that work and make
sure all is well. The 29 Alpha1 tag represents the end of the period where
that kind of housekeeping is a primary focus. Of course, there's always
more housekeeping to do. And our user community is certainly welcome to try
out the release.
With the completion of this milestone, I'd like in the next week to do a
review of where we are for WildFly 29 Beta1. That's tentatively scheduled
to be released on June 29.
Best regards,
--
Brian Stansberry
WildFly Project Lead
He/Him/His
2 years, 3 months
Removing the logging.properties Configuration File
by James Perkins
Hello All,
I've talked about this many times, but I think it's really the time to
tackle this now. I would like to propose that we remove the boot logging
configuration file and collect log messages until the logging subsystem is
activated.
This should solve several old JIRA's. Here are 5 of them without looking
too hard :)
- https://issues.redhat.com/browse/WFCORE-152
- https://issues.redhat.com/browse/WFCORE-157
- https://issues.redhat.com/browse/WFCORE-474
- https://issues.redhat.com/browse/WFCORE-2516
- https://issues.redhat.com/browse/WFCORE-5275
We also benefit from being able to make WildFly much easier to move between
hosts. I see this as a benefit for both bare-metal and cloud. Currently,
once booted the logging.properties is written with absolute paths which
causes boot issues if the file system is changed.
This would also allow us to upgrade the JBoss Log Manager to the latest
version which includes some nice enhancements. One of which is better
coloring of log messages. We could even log a WildFly logo on boot :) More
seriously though, it will keep WildFy in line with the version that other
projects are using.
Really, overall, there are nothing but benefits in doing this. The only
cons I see are the following;
- Potentiel for OOME if all logging is enabled for all loggers.
- This would be extremely rare I would think and may never even
happen.
- A system property would need to be used to define the lowest logging
level wanted. However, this is better than requiring a logging.properties
to control this IMO.
This change would not remove the ability to use a logging.properties if the
user has chosen to remove the logging subsystem. In those cases, the
logging.properties would still work. However, if the logging subsystem is
also present it would override anything in the logging.properties
configuration.
Any questions, opinions or comments are welcome. If this seems reasonable
it seems like something we should get moving on ASAP.
--
James R. Perkins
JBoss by Red Hat
2 years, 3 months
