[wildfly-dev] HAL subsystem

[Brian Stansberry]

I can't see storing this kind of thing in standalone.xml or host.xml, so
this means some other form of persistent store. The use cases around
managing that store would have to be gone through carefully.

The content repository can be used for that kind of thing, but it's not
meant to be directly managed. So no supported copying of your content from
one instance to another, etc, at least not without specific tooling we'd
have to provide.

People would also expect to be able to migrate this content when upgrading.
Which is just a variant of copying your content from one instance to
another.

For a domain the content repository is a domain-wide store (which is
actually a pro, since it means any host that is in sync with the domain can
become master and know it will have the needed data.)

How would this relate to possible uses of HAL in cloud environments?

On Thu, Apr 4, 2019 at 6:05 AM Harald Pehl <hpehl at redhat.com> wrote:

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

How so?

I assume content would be per user so access to parts of the content would
be restricted based on userid.

Perhaps some kind of administrative operations that give access to other
users content, use of which would be limited based on the WildFly RBAC
roles?

>
> 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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190404/5ef6dd85/attachment-0001.html