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
7 years
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
7 years
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.
7 years
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.
7 years
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
7 years
