At the moment I have been able to handle the IIOP subsystem and have a PR
ready for review here:
This one is now ready for PR review.
Thank you Emmanuel for WFLY-14752 and making it optional for messaging.
It would be great if we can please get some assignees for the following
- Web Services
The first step we need for each of these three is some analysis as to how
deep the PicketBox dependencies are.
Where we can control the use of PicketBox libraries either through
subsystem configuration or ar deployment time where we can detect if the
legacy security subsystem is present we are most of the way there. The
bigger challenge is where components use PicketBox APIs in all situations
as they will be affected once PicketBox is not available and we will need
to get some alternatives in place.
On Fri, Jun 4, 2021 at 5:40 PM Brian Stansberry <brian.stansberry(a)redhat.com>
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 <
> 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
> At the top level this is being tracked under:
> 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 -
> 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.
> 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
Principal Architect, Red Hat JBoss EAP