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 …
[View More]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
[View Less]
5 years, 12 months
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 …
[View More]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.
[View Less]
5 years, 12 months
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, …
[View More]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.
[View Less]
6 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
6 years
