Hello,
I have a candidate feature that requires an Elytron component upgrade, but no configuration changes are required in the elytron subsystem. It seems that such use case does not fall under the new experimental feature support. I wanted to ask whether a feature like this could be handled in some way?
It's not handled at a technical level by Paul's management API stability level work I merged last week. At this point the options for something like that are:
1) Upgrade the component in WildFly Preview, via the dependency entries in
https://github.com/wildfly/wildfly/blob/main/preview/galleon-local/pom.xml. (This is what we did for many things during the transition from EE 8 to EE 9.). That's a pain though for something with as many artifacts as Elytron. It also doesn't make the feature available to users of standard WildFly.
2) Have the elytron feature configurable and use the subsystem to turn it off if the server is not at the appropriate stability level.
We need an answer for this kind of use case. A potential one is to create different WildFly Channels channels for different stability levels and the user then provisions using the appropriate channel. We'd need to get the UX around that right. For example, many preview features might work just fine without requiring use of a separate channel to provision. Others might be like yours and not involve any integration code change, and just need the channel. Others might be a mix; e.g. a new preview-level attribute that only functions correctly if there is an upgraded component. How does the user know what to do?
I have another feature, which would not be ready for WF31, but I wanted to ask about it because we are also not sure if the new process could be used with it later. It introduces handling of a new property name in the existing properties in the subsystem. But these properties can be custom and have no validator. So it does not seem like it will be suitable to be delivered using the new process, is this correct?
From the chat discussion it sounds like there is a way to deal with this. It's a workaround though.
Thank you!
Diana
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message/VD4SSOIBFO3EGOCFPX2UG7GZ5ASHWIH4/