April 2019 - wildfly-dev - Jboss List Archives

[ELY-1778] Proposal for Enhanced Audit Logging - Feature Parity with Legacy in Elytron

by Justin Cook

Hello All, I've created a proposal [1] to enhance audit logging by feature parity with legacy audit logging in Elytron. Any feedback is welcome. [1] https://github.com/wildfly/wildfly-proposals/pull/196 <https://github.com/wildfly/wildfly-proposals/pull/184>

6 years, 5 months

1
0
0 / 0

Tyr - pull request format checker

by Martin Stefanko

Hi, I would like to present my side project Tyr [1] which is a tool that can verify GitHub pull request structure by a YAML definition (example in [2]) provided by a user. The PR author sees the violations immediately in the PR status which allows to correct mistakes right away when the PR is created. I've recorded a short demo available at [3]. The validation is fully configurable and can be extended with for instance analysis document links and similar. I would like to include this functionality in wildfly repository. Thoughts? [1] https://github.com/xstefank/tyr [2] https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30 [3] https://youtu.be/qZRcMQ6qIpg Martin Stefanko Software Engineer Middleware Runtimes Sustaining Engineering Team Red Hat

6 years, 5 months

5
18
0 / 0

HAL subsystem

by Harald Pehl

The management console uses various settings which need to survive a browser restart. Currently these settings are stored client side only either as cookie or in the browser local storage: # Cookie - Google Analytics on/off - Page size - Poll on/off - Poll time # Local Storage - Management endpoints (for HAL standalone mode) - Pinned items in the finder - JavaScript extensions - Macros Using the browser to store settings has the advantage of being very flexible. The settings are also not bound to a specific WildFly instance. For some settings like the management endpoints this is a requirement and won't change. However other settings make more sense if they are stored on the server side. That's why I'd like to propose a dedicated subsystem for HAL. It should hold the current settings (except the management endpoints). It should be extendable to store additional settings (currently there's an RFE to customize the visibility of notifications in HAL). Another advantage is that settings and data like macros could be properly secured using RBAC. I would like to hear your opinion about a dedicated subsystem for HAL. Does it makes sense? How should it look like? Any feedback and comments are welcome! // Harald

6 years, 5 months

2
3
0 / 0

JDBC Security Realm Enhancements

by Darran Lofthouse

I have just submitted the following proposal to add a couple of small enhancements to the JDBC SecurityRealm: - https://github.com/wildfly/wildfly-proposals/pull/193 The proposal is predominantly to complete some paperwork for development that has already taken place. This brings two main changes: - 1 - Where we load hashes and digests from a database we presently only support base64 encoding, this enhancement adds support for hex encoding. 2 - Adding support for storing passwords using modular crypt, this supports a variety of password types and allows hashes, salts, and iteration counts to be combined into a single field. Regards, Darran Lofthouse.

6 years, 5 months

1
0
0 / 0

Removal of commons-cli, commons-lang and commons-lang3 modules

by Brian Stansberry

Currently WildFly includes 3 JBoss Modules modules that are not used in our runtime. I would like to remove these in WildFly 17: org.apache.commons.cli org.apache.commons.lang[1] org.apache.commons.lang3 All three have the "jboss.api" = "private" property set in their module.xml, meaning they are marked for internal use only and we are free to remove them. End user applications should not have referenced these modules, and if they do we log a WARN on boot advising not to do that. However, other projects that extend WildFly (i.e. write their own subsystems) may be using these modules, so I wanted to notify any such folks that these will likely be going away and you'll need to provide these yourselves.ed. Best regards, Brian [1] This one is referenced in a commented out module.xml section related to My Faces 1.1 support. I've checked with Farah Juma and that is no longer relevant and the comment can be removed.

6 years, 5 months

8
15
0 / 0

[WFCORE-4362] Proposal for Configurable certificate authority used by a certificate-authority-account

by Diana Vilkolakova

Hello All, I've created a proposal [1] for [WFCORE-4362] Make the certificate authority used by a certificate-authority-account configurable. All feedback is welcomed. [1]: https://github.com/wildfly/wildfly-proposals/pull/192

6 years, 5 months

1
0
0 / 0

WildFly-Camel 10.0.0

by Thomas Diesler

WildFly-Camel 10.0.0 provides Camel-2.23.1 integration with WildFly-16.0.0 This is a major update release that comes with a new WildFly version. Component upgrades include WildFly-16.0.0 Galleon-3.0.1 Hawtio-2.5.0 In addition to that, we also resolved a number of other tasks and bugs <https://github.com/wildfly-extras/wildfly-camel/blob/master/docs/Changelo...>. For details please see the 10.0.0 Milestone <https://github.com/wildfly-extras/wildfly-camel/issues?q=milestone%3A10.0.0>. Enjoy

6 years, 6 months

2
1
0 / 0

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

6 years, 6 months

3
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

wildfly-dev April 2019