Re: [wildfly-dev] Read Elytron security domain from Undertow's ApplicationSecurityDomainService

On Mon, Jul 6, 2020 at 12:21 PM Jim Ma <ema(a)redhat.com&gt; wrote: > Hi Darran, > This looks good. Please go ahead to submit pull requests. > Basically we can change webservice code to pass SecurityMetaData to > ElytronSecurityDomainContextImpl and finally get the Elytron > SecurityDomain. Is there any Elytron utility class to get the actual > Elyron SecurityDomain from a ServiceName ? > That but shouldn't need any specific utility code, it will just be an MSC service dependency allowing direct access to the security domain once injected into a service. > Thanks, > Jim > > On Mon, Jul 6, 2020 at 4:01 PM Darran Lofthouse < > darran.lofthouse(a)jboss.com&gt; wrote: > >> Hello Jim, >> >> Just wanted to check how your early reviews of the changes have gone? >> >> Long term I want to undertake a lot more work to pull security >> processing as early as we can within the deployment unit processors but for >> now this feels like a suitable intermediate step. If you think you can >> work with this I will get the pull requests submitted against WildFly Core >> and WildFly so we can make sure we get plenty of CI runs. >> >> Regards, >> Darran Lofthouse. >> >> >> On Tue, Jun 9, 2020 at 9:38 AM Jim Ma <ema(a)redhat.com&gt; wrote: >> >>> Hi Darran, >>> Thanks for the update. I'll look at your change. Once this PR is >>> merged, I'll start to fix this webservice issue based on your new change. >>> >>> Cheers, >>> Jim >>> >>> On Mon, Jun 8, 2020 at 6:45 PM Darran Lofthouse < >>> darran.lofthouse(a)jboss.com&gt; wrote: >>> >>>> I have two topic branches prepared with the solution I think I can >>>> make use of for now. >>>> >>>> There is still quite a lot of work to do but this aligns with the >>>> current subsystems in WildFly. Later on and especially once we remove >>>> legacy security I would like the definition of the security policy to take >>>> place in earlier phases to collaboratively define the resulting security >>>> policy for the deployment so at the very latest before we enter >>>> Phase.INSTALL the policy is fully defined and can be used by >>>> all subsystems. For the Undertow and EJB subsystems I was able to achieve >>>> this during Phase.PARSE and Phase.POST_MODULE, however the web services >>>> DeploymentUnitProcessors add a new web meta data in Phase.INSTALL which >>>> needs to be taken into account. >>>> >>>> The two topic branches are: >>>> >>>> https://github.com/darranl/wildfly-core/tree/WFCORE-4962 >>>> https://github.com/darranl/wildfly/tree/WFLY-13319 >>>> >>>> Unless I run into any more testing issues I believe these are now >>>> complete. >>>> >>>> If the Elytron subsystem is installed the following will be attached >>>> to the DeploymentUnit at Phase.STRUCTURE 0x2300: >>>> >>>> >>>> https://github.com/darranl/wildfly-core/blob/WFCORE-4962/server/src/main/... >>>> >>>> Various DeploymentUnitProcessors interact with this metadata but if >>>> an Elytron SecurityDomain is selected for the web deployment >>>> the getSecurityDomain() method will return a ServiceName which can be used >>>> to add a dependency to obtain a reference to it. The latest the service >>>> name of the security domain will be set is Phase.INSTALL 0x1CFF. The >>>> ServiceName is not set as a result of any resolution within the EJB >>>> subsystem as a single deployment could contain EJBs in addition to web >>>> content. This metadata is also exclusively in relation to an Elytron >>>> SecurityDomain so it not set for a legacy SecurityDomain. >>>> >>>> Any subsystem wishing to use the resolved security domain can either >>>> install a DeploymentUnitProcessor after Phase.INSTALL 0x1CFF, or they can >>>> cache a reference to the SecurityMetaData instance and retrieve the >>>> ServiceName at a later point. >>>> >>>> I am going to perform some more all tests runs locally with some >>>> different permutations before I submit the PRs but I have been running into >>>> some issues with the EJBInvocationStatisticsTestCase which I see is >>>> currently being worked on so just waiting for that test to be more stable >>>> as it keeps affecting my local builds. Other than that I believe I do have >>>> all tests passing, including a new test I added to test identity >>>> propagation into the EJB container when using MicroProfile JWT. >>>> >>>> Regards, >>>> Darran Lofthouse. >>>> >>>> >>>> >>>> On Tue, Jun 2, 2020 at 11:38 AM Darran Lofthouse < >>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>> >>>>> I almost have a solution in place that I think we can use, I have >>>>> just run into an issue specifically related to the web services metadata I >>>>> think I can find a way past if for the changes I am specifically making but >>>>> it may still make it harder to get the security domain into the web >>>>> services deployment unit processor. >>>>> >>>>> Overall it feels like a general problem is too much security domain >>>>> resolution is happening within Phase.INSTALL - this is leaving us with very >>>>> little flexibility as the resulting security policy is very dependent on >>>>> the relationships between the deployment unit processors in this phase >>>>> occurring in the order they presently operate in. >>>>> >>>>> The ideal that I am trying to reach is that we clean up the security >>>>> policy resolution and definition into earlier phases so we cleanly define >>>>> the policy in an early phase and then apply it in the later phases, this >>>>> makes us a lot less dependent on the ordering within a specific phase and >>>>> IMO will give us a much cleaner solution as we will be able to define what >>>>> is known about the security policy at each phase and at which phase it is >>>>> safe to apply in later phases. >>>>> >>>>> The new JWT integration has had an impact on this but in general all >>>>> resolutions for JWT can happen in Phase.PARSE. I have been able to make a >>>>> change to Undertow to also pull the resolution step into Phase.PARSE. I >>>>> haven't quite been able to split out EJB into a sooner Phase yet but that >>>>> is already in Phase.POST_MODULE so we are before we enter Phase.INSTALL. >>>>> >>>>> My current problem is the Web services integration attempts to set a >>>>> chosen security domain within the WebMetaDataCreatingDeploymentAspect which >>>>> is executed quite late in the Phase.INSTALL from 0x1C11 or later - what I >>>>> really need to look at is how to get the meta data manipulated by this >>>>> deployment aspect ideally into Phase.PARSE. >>>>> >>>>> The end result that I am aiming for is that once we enter >>>>> Phase.INSTALL if a WildFly Elytron SecurityDomain is being used for a >>>>> deployment, a ServiceName which provides a reference to the SecurityDomain >>>>> being used will be attached to the DeploymentUnit. Any other subsystems >>>>> will then be able to add a dependency on this ServiceName and use it. >>>>> >>>>> Regards, >>>>> Darran Lofthouse. >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, May 7, 2020 at 9:37 AM Darran Lofthouse < >>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>> >>>>>> Ok, that may actually be a fraction early for the resolution to have >>>>>> taken place so may need something in addition to this. >>>>>> >>>>>> Generally the security processing has been tied into individual >>>>>> subsystems, what I need to work on as well is pulling more of these >>>>>> decisions back into the PARSE phase. >>>>>> >>>>>> It looks to me that your deployment activity happens then in the >>>>>> INSTALL phase between 0x1C11 and 0x1CFF >>>>>> >>>>>> I am going to be adding the new attachment to all DeploymentUnits >>>>>> (Assuming the Elytron subsystem is installed) within the STRUCTURE phase so >>>>>> all subsequent DUPs can make use of it / cache the reference etc,,, >>>>>> However the final resolution where we identify the SecurityDomain is >>>>>> happening within the UndertowDeploymentProcessor at 0x1D00. >>>>>> >>>>>> I think really now is going to have to be the time where I pull some >>>>>> of the steps in UndertowDeploymentProcessor back to the PARSE phase, that >>>>>> way you will have everything you need. >>>>>> >>>>>> The scope of the issue I am working on seems to have expanded a >>>>>> little ;-) but this feels like it is going to contribute a lot to the next >>>>>> steps to allow PicketBox to be removed from the default configuration. >>>>>> >>>>>> Long term for subsystems such as web services you should just be >>>>>> able to pull this new SecurityMetaData attachment from the DeploymentUnit >>>>>> and use that to identify the resulting policy being applied without needing >>>>>> to duplicate any resolution logic performed in other subsystems. >>>>>> >>>>>> Regards, >>>>>> Darran Lofthouse. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, May 7, 2020 at 3:30 AM Jim Ma <ema(a)redhat.com&gt; wrote: >>>>>> >>>>>>> Thanks Darran. >>>>>>> EndpointService[1] installed by EndpointServiceDeplomentAspect[2] >>>>>>> needs to access it . The EndpointServiceDeployment is wrapped in >>>>>>> AbstractDeploymentUnitProcessor[3] with Phase.INSTALL to deploy/undeploy. >>>>>>> [1] >>>>>>> https://github.com/wildfly/wildfly/blob/master/webservices/server-integra... >>>>>>> [2] >>>>>>> https://github.com/wildfly/wildfly/blob/master/webservices/server-integra... >>>>>>> [3] >>>>>>> https://github.com/wildfly/wildfly/blob/master/webservices/server-integra... >>>>>>> >>>>>>> On Wed, May 6, 2020 at 6:32 PM Darran Lofthouse < >>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>> >>>>>>>> Hello Jim, >>>>>>>> >>>>>>>> Sorry I haven't had a chance to try your reproducer but I am >>>>>>>> currently debugging another issue and I think the solution for this issue >>>>>>>> may actually help with the problem you are having. >>>>>>>> >>>>>>>> https://issues.redhat.com/browse/WFLY-13319 >>>>>>>> >>>>>>>> In the case I am looking into the EJB deployment unit processors >>>>>>>> are being executed before it has been determined, I have been considering >>>>>>>> whether I could tweak the order of one of the DUPs but that is not possible >>>>>>>> due to the dependencies so I need another solution anyway. >>>>>>>> >>>>>>>> What I am presently thinking is during the Phase.STRUCTURE I could >>>>>>>> add an empty "SecurityMetaData" object as an attachment to the >>>>>>>> DeploymentUnit, initially this will just contain a single value which will >>>>>>>> be the ServiceName of the Elytron SecurityDomain to use and will default to >>>>>>>> "null". >>>>>>>> >>>>>>>> The first DeploymentUnitProcessor to identify that an Elytron >>>>>>>> SecurityDomain is to be used will then set the ServiceName of the >>>>>>>> SecurityDomain to use. >>>>>>>> >>>>>>>> Longer term we will be removing the application-security-domain >>>>>>>> resources as they were just to enable coexistence with legacy security so >>>>>>>> at some point in the future deployments will either be secured using >>>>>>>> Elytron or will be unsecured and having a common SecurityMetaData can act >>>>>>>> as the shared base for the future. >>>>>>>> >>>>>>>> Can you please confirm from which of the Web Services >>>>>>>> DeploymentUnitProcessors you need access to this, we will probably need to >>>>>>>> double check if any other checks need pulling further forward, so far we >>>>>>>> have one happens in Phase.PARSE, one in Phase.POST, and one in >>>>>>>> Phase.INSTALL. Ideally long term we will pull all of this identification >>>>>>>> back to Phase.PARSE. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Darran Lofthouse. >>>>>>>> >>>>>>>> >>>>>>>> On Wed, May 6, 2020 at 8:10 AM Jim Ma <ema(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>>> Hi Darran, >>>>>>>>> Did you get time to look at this reproducer? Any findings ? >>>>>>>>> Thanks, >>>>>>>>> Jim >>>>>>>>> >>>>>>>>> On Thu, Apr 2, 2020 at 2:00 PM Jim Ma <ema(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> Thanks Darran. I uploaded the war deployment and reproduce >>>>>>>>>> steps readme to >>>>>>>>>> https://github.com/jimma/elytron-null-securitydomain. >>>>>>>>>> Let me know if this helps to debug why the SecurityDomain is not >>>>>>>>>> associated. >>>>>>>>>> >>>>>>>>>> On Thu, Apr 2, 2020 at 12:33 AM Darran Lofthouse < >>>>>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>>>>> >>>>>>>>>>> TBH Jim, I think I would need to dig into the code with a >>>>>>>>>>> debugger to double check what is happening there. >>>>>>>>>>> >>>>>>>>>>> SecurityDomain.getCurrent() will return null when no >>>>>>>>>>> SecurityDomain is associated with the deployment, the >>>>>>>>>>> DeploymentUnitProcessor added for the Elytron integration essentially >>>>>>>>>>> checks what SecurityDomain name Undertow was going to use and then checks >>>>>>>>>>> if it should swap in an Elytron SecurityDomain instead. >>>>>>>>>>> >>>>>>>>>>> If SecurityDomain association is being skipped due to the lack >>>>>>>>>>> of a security-constraint we should probably revisit that as there are >>>>>>>>>>> plenty of scenarios where association of a SecurityDomain would make sense >>>>>>>>>>> even if the constraints are not defined in the web.xml. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Apr 1, 2020 at 11:29 AM Jim Ma <ema(a)redhat.com&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Darran, >>>>>>>>>>>> >>>>>>>>>>>> The SecurityDomain.getCurrent() returns null when there is >>>>>>>>>>>> "other" security domain in jboss-web.xml and no “security-constraint” >>>>>>>>>>>> defined in web.xml like: >>>>>>>>>>>> >>>>>>>>>>>> -------------jboss-web.xml--------------------- >>>>>>>>>>>> <jboss-web> >>>>>>>>>>>> <security-domain>other</security-domain> >>>>>>>>>>>> </jboss-web> >>>>>>>>>>>> --------------web.xml------------------------------ >>>>>>>>>>>> <web-app >>>>>>>>>>>> version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" >>>>>>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >>>>>>>>>>>> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee >>>>>>>>>>>> http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"> >>>>>>>>>>>> <servlet> >>>>>>>>>>>> <servlet-name>TestService</servlet-name> >>>>>>>>>>>> >>>>>>>>>>>> <servlet-class>org.jboss.test.ws.jaxws.samples.wsse.policy.jaas.ServiceImpl</servlet-class> >>>>>>>>>>>> </servlet> >>>>>>>>>>>> <servlet-mapping> >>>>>>>>>>>> <servlet-name>TestService</servlet-name> >>>>>>>>>>>> <url-pattern>/*</url-pattern> >>>>>>>>>>>> </servlet-mapping> >>>>>>>>>>>> </web-app> >>>>>>>>>>>> >>>>>>>>>>>> Does this mean Elytron security domain mapped by undertow >>>>>>>>>>>> "other" application domain only is enforced/set for web deployment which >>>>>>>>>>>> contains <security-constraint>deployment descriptor ? >>>>>>>>>>>> When does SecurityDomain.getCurrent() return null value ? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Jim >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Mar 16, 2020 at 6:35 PM Darran Lofthouse < >>>>>>>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Yes there should be no difference at runtime, if we >>>>>>>>>>>>> identified the Elytron domain via the default security domain it should >>>>>>>>>>>>> still be associated with the deployment in the same way. >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Mar 16, 2020 at 10:33 AM Jim Ma <ema(a)redhat.com&gt; >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Will this work for Undertow default "other" application >>>>>>>>>>>>>> security domain's reference Elytron SecurityDomain ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Mar 16, 2020 at 6:26 PM Darran Lofthouse < >>>>>>>>>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Overall it is the SecurityDomain.getCurrent method you >>>>>>>>>>>>>>> need: - >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://wildfly-security.github.io/wildfly-elytron/master-public/org/wild... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If a SecurityDomain is associated with the Thread's context >>>>>>>>>>>>>>> class loader it will be returned. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Mar 16, 2020 at 10:22 AM Jim Ma <ema(a)redhat.com&gt; >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Mar 16, 2020 at 6:07 PM Darran Lofthouse < >>>>>>>>>>>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I don't know if it will help but the SecurityDomain is >>>>>>>>>>>>>>>>> associated with the ClassLoader of the deployment, not sure if that could >>>>>>>>>>>>>>>>> be an alternative way for WS to access it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'll try it . Can you please point me some code example >>>>>>>>>>>>>>>> or test code? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The thing that is complicating it for now is the dual >>>>>>>>>>>>>>>>> mode with PicketBox, once we remove PicketBox a deployment will either have >>>>>>>>>>>>>>>>> an Elytron SecurityDomain or it will not. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes. Now webservice has to add many PicketBox or Elytron >>>>>>>>>>>>>>>> checks to do following actions. We wrap this as much as possible with spi >>>>>>>>>>>>>>>> interface. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Fri, Mar 13, 2020 at 8:20 AM Jim Ma <ema(a)redhat.com&gt; >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Thu, Mar 12, 2020 at 8:12 PM Darran Lofthouse < >>>>>>>>>>>>>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Is it possible to identify the revelevent >>>>>>>>>>>>>>>>>>> DeploymentUnitProcessors in this process along with their phase and >>>>>>>>>>>>>>>>>>> priority so we can check the ordering. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The "other"'s mapped Elytron security domain service is >>>>>>>>>>>>>>>>>> required to read in EndpointServiceDeploymentAspect. It's installed >>>>>>>>>>>>>>>>>> in Phase.INSTALL, Phase.INSTALL_WS_DEPLOYMENT_ASPECTS priority. It's >>>>>>>>>>>>>>>>>> running before UndertowDeploymentProcessor >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> What may be more appropriate is for the Undertow DUP to >>>>>>>>>>>>>>>>>>> attach something which identifies the SecurityDomain instead of the web >>>>>>>>>>>>>>>>>>> services DUP relying on internal API / repeating the same checks already >>>>>>>>>>>>>>>>>>> performed within Undertow. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In the future we will be removing all of the >>>>>>>>>>>>>>>>>>> application security domain resources so coordinating using attachments >>>>>>>>>>>>>>>>>>> will hopefully also future proof any fix. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It looks this attachment should be set in some Undertow >>>>>>>>>>>>>>>>>> DUP before UndertowDeploymentProcessor. WebService needs a >>>>>>>>>>>>>>>>>> Securitycontext to call the ejb ws endpoint method or webservice endpoint >>>>>>>>>>>>>>>>>> method : >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> https://github.com/wildfly/wildfly/blob/master/webservices/server-integra... >>>>>>>>>>>>>>>>>> Is there better api/approach to perform this kind of >>>>>>>>>>>>>>>>>> method invocation ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Jim >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>> Darran Lofthouse. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Thu, Mar 12, 2020 at 11:45 AM Jim Ma <ema(a)redhat.com&gt; >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> There is ws deployment failure issue[1] which is >>>>>>>>>>>>>>>>>>>> caused by Webservice subsystem doesn't correctly get mapped elytron >>>>>>>>>>>>>>>>>>>> security domain from web deployment's default "other" >>>>>>>>>>>>>>>>>>>> application security domain. I tried to fix this by >>>>>>>>>>>>>>>>>>>> reading Elytron security domain from Undertow started services, but it >>>>>>>>>>>>>>>>>>>> looks now ApplicationSecurityDomainService is private static and it doesn't >>>>>>>>>>>>>>>>>>>> provide a getter which allows to get Elytron security domain. Webservice >>>>>>>>>>>>>>>>>>>> subsystem requires an Undertow service like >>>>>>>>>>>>>>>>>>>> ApplicationSecurityDomainService[2] started by EJB subsystem to read the >>>>>>>>>>>>>>>>>>>> Elytron security domain. Is it doable to change >>>>>>>>>>>>>>>>>>>> Undertow's ApplicationSecurityDomainService to provide mapped security >>>>>>>>>>>>>>>>>>>> domain ? Or any better approach to get the mapped Elytron domain ? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> [1]https://issues.redhat.com/browse/WFLY-12765 >>>>>>>>>>>>>>>>>>>> [2] >>>>>>>>>>>>>>>>>>>> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>> Jim >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> wildfly-dev mailing list >>>>>>>>>>>>>>>>>>>> wildfly-dev(a)lists.jboss.org >>>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>