Subsystem Inclusion Policy & Role of Feature Packs & Add-ons
by Jason Greene
Hello Everyone,
Recently there has been some confusion about how subsystems should be distributed, and whether or not they should be part of the WildFly repository.
There are three primary use-cases for distributing a subsystem.
#1 - Inclusion in an official WildFly distribution
#2 - A user installable "add-on distribution" which can be dropped on top of a WildFly Distribution (see [A])
#3 - A separate, independant, customized distribution, with a differing identity. Possibly build but not required as a layer (see [A])
If you are after #1, then the subsystem source code (defined as the portion of code which integrates with the server using the subsystem facilities) MUST be included in the WildFly repo. This is because subsystems heavily impact the stability of the server and our compliance with our strict management compatibility policy, and additionally it allows for us to keep all included subsystems up to date with core infrastructure changes such as capabilities and requirements, and the upcoming elytron security integration. Under this approach, a feature-pack is unlikely to be used, as it would likely just be part of the full feature-pack. It could very well be that we would introduce a different more expansive feature-pack in the future defining a larger distribution foot-print, however, there are currently no plans to do so.
If you are after #2, then you do not want a feature-pack, as feature-packs are just for building custom server distributions. If your use-case is #2 you are by definition not a custom server distribution, but rather a set of modules built the normal maven way.
If you are after #3, then you likely wish to use the feature-pack mechanism to make it easy to produce your custom distribution. This facility would allow you to keep your source repository limited to just the new subsystems you introduce, and pull the rest of the server bits via a maven dep. It is important, that you change the identity of the server (see [A]), such that patches for the official WildFly server are not accidentally installed.
Thanks!
[A] https://developer.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz...
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
7 years, 11 months
Fixing handling of 'required' attributes with 'alternatives'
by Brian Stansberry
tl;dr;
It’s not an uncommon thing to have a management attribute A that is required; i.e. must be set, but also has an alternative attribute B, where setting B satisfies the requirement for A, making an undefined value for A legal. We’re not handling that correctly and I want to fix it.[1] But fixing it will require some coordination with the HAL console.
Right now the way AttributeDefinition building works it’s not practical to declare that an attribute is required but only if no alternative is set. So instead attributes are declared as if they aren’t really required. This leads to less than helpful input validation, e.g. [2] and [3], since the attribute definition is imprecise.
The change I’d like to make will alter the read-resource-description output for 4 attributes, changing the value of the ‘nillable’ description from ‘false’ to ‘true’ so I want to coordinate that with the console team.
Long version
Harald and Claudio you guys are the main audience here. :)
For even longer version see description and comments on [1].
In a nutshell, if devs set the ‘allowNull’ property on an AttributeDefinition to ‘true’, the r-r-d output for the attribute has “nillable” => true. But there is no way to say “allowNull but only if an alternative is set.” So people are setting “allowNull” to true even if the attribute should be set in the absence of alternatives. And HAL has no metadata available to it to tell users they *must* set one of the alternatives. So I want to:
1) Add a setRequired(boolean) method to the AD builders where the fact that it means “must be defined if no alternative is defined” is explicitly declared
2) @Deprecate setAllowNull and point to setRequired
3) Clarify the meaning of setAllowNull(true) as being the same as setRequired(false)
4) Change the builder ‘allowNull’ constructor param name to “optional” and document its meaning as “allowing undefined values even in the absence of defined alternatives”. I could call the param ‘notRequired’ which is clearer in meaning but odd.
Then I will add a new ‘required’ metadata field to the r-r-d output and change the impl of the existing ’nillable’ metadata to a logical “!required || (alternatives != null && alternatives.length > 0)”
This will result in a change in the ‘nillable’ value for 4 attributes in the WildFly model from ‘false’ to ’true':
/subsystem=transactions PROCESS_ID_SOCKET_BINDING and PROCESS_ID_UUID
/core-service=management/security-realm=*/authenticaton=ldap USERNAME_FILTER and ADVANCED_FILTER
The latter two are not exposed in the console so the issue really is the two transaction attributes.
I haven’t checked other subsystems in things like Teiid or JDG, but if there are only 4 in all of WildFly I doubt there are many.
Also, if people start using the new behavior to correct problems like [2] and [3] people may expect the console to understand and reflect the concept of “required but only if there is no alternative’.
[1] https://issues.jboss.org/browse/WFCORE-1556
[2] https://issues.jboss.org/browse/WFLY-6608
[3] https://issues.jboss.org/browse/WFLY-6607
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
8 years, 1 month
WFLY/WFCORE PRs
by Kabir Khan
Please try to include a link to the Jira in the pull request when opening them. I want to be a good citizen and resolve them when merging, but it is a PITA to have to manually find the Jira issue in the absence of links.
8 years, 1 month
Remove PL from WFLY
by Pedro Igor Silva
Hi,
On the last few days I've been discussing with Tomaz about the possibility to remove PL from WFLY.
The reasons for that are:
- PicketLink was deprecated in favor of Keycloak. See [1] and [2].
- Fixes are only being done to product version by GSS/SEG teams.
- Most PL IdM and Federation capabilities such as SAML (plus a plenty of other things) are now available from Keycloak.
I think we can still provide an installer (we already have that) that could be used to enable PL to a WFLY installation. That would help people using PL to continue with their designs. But for PL Federation and Subsystem, Keycloak should be the best way to go.
Any comments ?
Regards.
Pedro Igor
[1] http://picketlink.org/news/2015/03/10/PicketLink-and-Keycloak-project-merge/
[2] http://picketlink.org/keycloak-merge-faq/
8 years, 2 months
use JGroups in a web application
by Carl Harris
I’m building a web application that targets Wildfly 10, and runs in a Wildfly HA cluster. In the application, I need to do some coordination between application nodes using JGroups. It seems silly to bring JGroups into the application itself, when Wildfly already needs a correctly configured JGroups stack for its own use.
I was thinking of making an extension that (through a deployment processor) adds a CDI extension to the web application to process injection points annotated with a @JGroupsChannel qualifier and inject a Channel bean. The CDI extension would be injected with JGroups services registered by Wildfly’s jgroups subsystem. Parameters on the annotation would allow the specification of the JGroups stack and channel name.
Before I started down this path, I thought I’d ask if there’s a more straightforward way to accomplish this; i.e. is there a better way to make use of Wildfly’s jgroups subsystem in my web application?
Thanks,
carl
8 years, 2 months
Subsystem Hierarchy
by Darran Lofthouse
I have received the following request regarding the hierarchy of the
Elytron subystem so just wanted to get some additional opinions: -
https://issues.jboss.org/browse/WFLY-7190
The Elytron subsystem is implemented by having a number of different
capabilities that are then chained together in the model to expose four
/ five capabilities that are then used across the application server to
access security related services.
https://github.com/wildfly-security-incubator/wildfly-capabilities/tree/e...
The reason for following the capability approach along with a component
assembly approach to assembling the configuration is so that we are
ready for other subsystems to be added to the server potentially
providing their own implementations of these capabilities.
For our capabilities we have one or more resource definitions making it
possible to configure different implementations of the capabilities
whilst having the configuration fully described in the model unlike the
previous map approach for login modules.
So the general problem is how should an administrator be able to see the
resources by type.
Within the admin console Claudio it looking at a tabbed interface where
different tabs can contain different resources so that seems to be
reasonably covered.
Within the CLI however an administrator is just presented by all
resource types within the subsystem when they use tab completion.
One option could be for us to introduce an arbitrary layer in the
subsystem and group our resources, e.g.
/subsystem=elytron/component=name-rewriter/
/subsystem=elytron/component=security-realm/
But before taking that approach it feels as though this information is
already there and there are possibly some other alternatives we could
consider.
Firstly I wonder if some of the read-* operations could have an
opportunity to take into account capabilities of child resources to
offer a filtered view?
Another possible option could be CLI commands e.g. add-name-rewriter,
add-security-realm - not sure if that would be one way to give a better
user experience.
Anyway just some random thoughts for the moment but wanted to open this
up before jumping immediately to the artificial hierarchy solution.
Regards,
Darran Lofthouse.
8 years, 2 months
ObjectType Review /subsystem=elytron/properties-realm=*
by Darran Lofthouse
A number of resources have been flagged within the Elytron subsystem
requesting that we review the use of ObjectTypes (and similar) within
the resource definitions.
Some I know we can simplify but others I would like to get a second
opinion on, firstly I wanted to look at the 'properties-realm' resource.
https://gist.github.com/darranl/ef7b06222e4dbe7ba242f7a5a2da991e
This is a realm implemented to make use of the legacy properties files
users of AS7 through WF10 will be familiar with so we need to reference
two different properties files with the group-properties being optional.
Where a file is referenced it is common to reference both a path and a
relative-to, rather than looking to find unique names for two path
attributes and unique names for two relative-to attributes I have
wrapped in specific OBJECT type attributes.
I could achieve a similar grouping by flattening and using attribute
groups but then the path and relative-to attributes would require unique
names. Personally I just felt that for two attributes always used as a
pair it was cleaner to wrap them into one.
Note: Checking the output myself the path should not be nillable and
the relative-to should not allow expressions so those two will be corrected.
Regards,
Darran Lofthouse.
8 years, 2 months
Proposal to add a new management subsystem to wildfly-core
by Jeff Mesnil
Hi,
TL;DR let's add a new subsystem to wildly-core to add new management-related resources instead of putting them in /core-service=management. Let's do that for WFLY 11.
# Use case
For WildFly 11, I have planned a new feature[1] to be able to notify user code when the state of the server changes (running, reload-required, etc.).
Until now this kind of resources related to the server management were put under /core-service=management.
However, this resource does not have well-defined semantic (e.g. what's the meaning of /core-service=management for a DC?).
Brian proposed to stop putting resources under this resource and add a new subsystem instead. This will clarify the semantic of the resources and uniformize the configuration and management of WildFly.
I propose to create a new extension in wildfly-core project to provide new management resources.
It will be the *successor* of /core-service=management (i.e. we stop adding *new* resources to /core-service=management).
This will not be a replacement for /core-service=management. Current resources under /core-service=management will remain there for WildFly 11.
I have no strong opinion about what doing after that: we can move/migrate them under the new subsystem, redirect them using alias or do nothing.
Some resource related to security will be deprecated by Elytron so doing nothing sounds correct for them.
Moving everything else to the new subsystem sounds a worthy goal but I have no idea of the actual effort to do so (and ensure that we remain compatible). The time and energy spent on this may not be worthwhile...
# What is the scope of this subsystem?
The scope would be identical to the /core-service=management resource.
Using a subsystem just make sure we have well-defined semantics for the resources underneath it. It also moves us towards the goal of extending WildFly in an uniform way instead of adding special resources outside of our extension API.
It is *not* a subsystem to manage WildFly or deployed applications à la JMX or JSR 77.
# What is the name of this subsystem?
The intuitive name would be /subsystem=management but I don't think it is a good name. It is too generic (does it expose a management API à la JMX? does it provide management features based on other project such as Hawkular?) and I don't think we should own such general term (even though we do have such general subsystem names such as io, security, logging).
If we follow the current convention, the name could be /subsystem=management-wildfly (feature + name of project providing the feature) but it does not sound good. The subsystem provides a way to manage WildFly, it does not provide a management feature *using* WildFly (this could also clash with name of the extension if/when we implement Java EE Management API 2.0[2]).
I prefer */subsystem=core-management* (or /subsystem=wildfly-management as a 2nd choice).
We have identified a few resources that are good candidates for this new resource:
* the feature to notify user code of server stat changes[1]
* Elytron needs a new access=identity resource[3]
# Roadmap
I propose to create asap an empty subsystem as a first step so that Elytron feature is not blocked by the development of my own feature (It should be a single commit on wildfly-core and can be fit in Elytron PRs if needed).
Then, we can have different PRs for new management resources that fits in this new subsystem.
We've also identified a simple management resource to evaluate the cost of moving/migrating/redirecting resources with the service=configuration-changes[4] and their implications for compatibility.
Would you guys agree with that proposal?
[1] https://issues.jboss.org/browse/WFCORE-1405
[2] https://www.jcp.org/en/jsr/detail?id=373
[3] https://developer.jboss.org/wiki/EnablingWildFlyElytronForManagementSecurity
[4] https://issues.jboss.org/browse/WFCORE-1642
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
8 years, 3 months
How "optional" should the NoSQL integration be for WildFly...
by Scott Marlow
Hi,
I'm thinking that the NoSQL unit tests should be optional, since most
WildFly developers won't have access to a local NoSQL database server.
Currently, to run the unit tests, you have to define "nosql-tests" (e.g.
./integration-tests.sh -Dnosql-tests).
As we work towards our first (NoSQL integration) pull requests for
WildFly master (and some small wildfly-core changes to the Phase class),
does anything else need to be optional?
Currently we are building WildFly to include the NoSQL driver artifacts,
for the specific versions of the drivers that we support. We also allow
other versions of the NoSQL drivers to be brought into WildFly, as long
as they are (API) compatible with the version that we (loosely)
integrate with.
Thanks for the feedback!
Scott
8 years, 3 months
