2:19 p.m.
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?
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?
Thank you!
Diana
12:44 a.m.
Hi Diana,
FYI everyone, this has been discussed quite a bit at
https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to...
On Fri, Dec 8, 2023 at 7:20 AM Diana Krepinska <dvilkola(a)redhat.com> wrote:
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(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
388
days inactive
391
days old
1 comments
2 participants
participants (2)
-
Brian Stansberry -
Diana Krepinska