Thanks, Darran. If anyone has any questions about what's necessary to allow a dependency on the org.picketbox module to be marked as optional, I encourage you to ask here, as other people are likely to have a similar question. On Thu, Jun 3, 2021 at 2:51 AM Darran Lofthouse < darran.lofthouse(a)jboss.com&gt; wrote: > Previously we have worked to eliminate all mandatory module dependencies > on the org.jboss.as.security module - this means that this module is not > only provisioned by Galleon if we are provisioning a layer which includes > the subsystem. > > The next target we need to tackle is the org.picketbox module, this step > will involve some work within each of the affected components. We need to > reach the point that all other module dependencies on this one are also > optional so it is only provisioned when the legacy security subsystem is > provisioned. > > At the top level this is being tracked under: > https://issues.redhat.com/browse/WFLY-13889 > > For the individual subsystems I have split out a set of tasks so they can > be tackled individually: > - Messaging - https://issues.redhat.com/browse/WFLY-14752 > - IIOP - https://issues.redhat.com/browse/WFLY-13679 > - Web Services - https://issues.redhat.com/browse/WFLY-14841 > - JCA - https://issues.redhat.com/browse/WFLY-14842 > - EJB3 - https://issues.redhat.com/browse/WFLY-14843 > - Application Client - https://issues.redhat.com/browse/WFLY-14844 > - security-api / security-integration - > https://issues.redhat.com/browse/WFLY-14845 > > I have left these unassigned by default so we can see when they have been > picked up. > > Some of these may be more complicated than others so the most urgent task > is to identify where we think we are going to run into problems so we can > define a solution. > > Some solutions could include: > - Moving utility code to WildFly Elytron or some other common project. > - Forking utility code to a private implementation in the project that > needs it. > - For anything affecting deployments using capabilities to check if > legacy security is present. > - Any optional use of legacy security should be disabled from Java 13 > and later. > - Other solutions to be developed. > > This specific task is not about changing the default configuration to > move on from legacy security. Once this step is complete we will be ready > to start adjusting the default configuration to eliminate legacy security. > > Regards, > Darran Lofthouse. > > > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His