From psilva at redhat.com Mon Jun 4 09:31:16 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 4 Jun 2018 10:31:16 -0300 Subject: [wildfly-dev] How to set an authorized identity to EltyronSecurity Context In-Reply-To: References: <91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com> <7fe0d553-2190-fa48-6728-41240497cb0c@redhat.com> Message-ID: In Keycloak integration we have a specific security realm implementation that expects a principal previously authenticated by a keycloak adapter (e.g.: using SAML or OIDC) and builds an authorized identity based on it. Basically, what this security realm does is populate the authorized idenitty with information from tokens. Later we complete authentication in Elytron and set the token as a credential into the identity. It is worth mention that in Keycloak integration, the adapter is a Elytron HTTP Authentication Mechanism, so we don't deal directly with the security domain but with the callback handler. Regarding ElytronSecurityDomainContextImpl, is method pushContext called after a call to isValid ? If so, the security domain should be set with the security identity and you don't even need to keep that ThreadLocal ... On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse < darran.lofthouse at redhat.com> wrote: > Just added Pedro in CC so see if he has any suggestions - this is sounding > similar to the problems he would have needed to handle when he added > support for KeyCloak integration using the Elytron APIs. > > Although the reported problem we are working on is in the context of > access to the token it does currently sound that there is a missing > pre-requisite step of tying the authentication to Elytron to we can > populate a SecurityIdentity. But this does not sound like the first time > we have needed to approach this. > > Regards, > Darran Lofthouse. > > > On Thu, 31 May 2018 at 10:54 Jim Ma wrote: > >> On 05/31/2018 05:37 PM, Darran Lofthouse wrote: >> >> So the validation is within Apache CXF - is there an end result to this >> validation where you have access to everything you need where we could >> perform some additional steps? >> >> >> After Apache CXF validation, we can get a LoginContext from CXF's >> exchange message : https://github.com/apache/cxf/ >> blob/master/core/src/main/java/org/apache/cxf/security/ >> LoginSecurityContext.java >> Can we do something to convert it to an Elytron authenticated identity ? >> Or we have to hook/replace something with Elytron in CXF's validation to >> make this work ? >> >> >> >> On Thu, 31 May 2018 at 10:34 Jim Ma wrote: >> >>> The saml validation is now Apache CXF's SAML functionality. We can't >>> port the CXF's security to rely on >>> our Elytron. >>> >>> On 05/31/2018 05:07 PM, Darran Lofthouse wrote: >>> >>> It sounds to me then that the place to start is within the SAML >>> validation, this is effectively an authentication step so should be ported >>> over to an Elytron based authentication - the end result of the >>> authentication would then be the required SecurityIdentity to propagate >>> from container to container. >>> >>> >>> On Thu, 31 May 2018 at 03:57 Jim Ma wrote: >>> >>>> On 05/30/2018 09:47 PM, Darran Lofthouse wrote: >>>> >>>> I am currently gathering together some information regarding how the >>>> JCA subsystem handles the requirement of populating a Subject for >>>> propagation into a resource adapter, however there is a general question >>>> about what is attempting to be achieved here. >>>> >>>> Once an EJB is secured using WildFly Elytron the associated identity is >>>> not accessed as a Subject instead it is accessed a SecurityIdentity the >>>> current SecurityIdentity can always be retrieved by calling the current >>>> SecurityDomain: - >>>> >>>> http://wildfly-security.github.io/wildfly-elytron/1.3. >>>> x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html# >>>> getCurrent-- >>>> http://wildfly-security.github.io/wildfly-elytron/1.3. >>>> x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html# >>>> getCurrentSecurityIdentity-- >>>> >>>> The SecurityIdentity has some similarity with the Subject in that >>>> amongst other things it also contains a collection of public credentials >>>> and a collection of private credentials: - >>>> >>>> http://wildfly-security.github.io/wildfly-elytron/1.3. >>>> x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html# >>>> getPublicCredentials-- >>>> http://wildfly-security.github.io/wildfly-elytron/1.3. >>>> x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html# >>>> getPrivateCredentials-- >>>> >>>> So I think the very first question is has the SecurityIdentity been >>>> correctly populated with any delegated credentials? If not that is going >>>> to be a pre-requisite for any follow on steps regardless. >>>> >>>> Then secondly what is it that is making use of this identity? Why >>>> can't it be ported to make use of the Elytron authentication client APIs >>>> which amongst other things provide support for delegation from the current >>>> identity. >>>> >>>> >>>> If we need to we can look at a conversion to a Subject but we are only >>>> doing that where it is really required. >>>> >>>> >>>> We don't have the SecurityIdentity populated, there is only principal >>>> and subject created by jbossws/CXF's saml validator. >>>> We need to convert the subject/principal to Elytron's >>>> SecurityIdentity or something else, then later on EJB subystem with Elytron >>>> security can retrieve this authenticated info without check it twice. >>>> So we'd like to know how can we convert a subject/principal >>>> to Elytron's SecurityIdentity and let Elytron know this is already >>>> authenticated and authorized. >>>> >>>> Thanks, >>>> Jim >>>> >>>> >>>> >>>> Regards, >>>> Darran Lofthouse. >>>> >>>> >>>> On Wed, 30 May 2018 at 10:27 Alessio Soldano >>>> wrote: >>>> >>>>> As suggested by Darran, I'm forwarding the message below to the list >>>>> on behalf of Jim. >>>>> The classes Jim is referring to are at https://github.com/wildfly/ >>>>> wildfly/tree/master/webservices/server-integration/src/main/java/org/ >>>>> jboss/as/webservices/security >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Jim Ma >>>>> Date: Wed, May 30, 2018 at 9:03 AM >>>>> Subject: Set an authorized identity to EltyronSecurity Context >>>>> To: Darran Lofthouse >>>>> Cc: Alessio Soldano >>>>> >>>>> >>>>> Hi Darran, >>>>> >>>>> We are helping look at a customer issue which requires propagate the >>>>> authenticated subject from webservice subsystem to >>>>> >>>>> ejb subystem. With old security domain , we can do this with creating >>>>> a subject : >>>>> >>>>> @Override >>>>> public void pushSubjectContext(final Subject subject, final >>>>> Principal principal, final Object credential) { >>>>> AccessController.doPrivileged(new PrivilegedAction() { >>>>> >>>>> public Void run() { >>>>> SecurityContext securityContext = >>>>> SecurityContextAssociation.getSecurityContext(); >>>>> if (securityContext == null) { >>>>> securityContext = createSecurityContext( >>>>> getSecurityDomain()); >>>>> setSecurityContextOnAssociation(securityContext); >>>>> } >>>>> securityContext.getUtil().createSubjectInfo(principal, credential, >>>>> subject); >>>>> return null; >>>>> } >>>>> }); >>>>> } >>>>> >>>>> >>>>> After Elytron, what is the equivalent thing to do this then ejb can >>>>> retrieve this security without check this twice ? >>>>> >>>>> Thanks, >>>>> >>>>> Jim >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Alessio Soldano >>>>> >>>>> Associate Manager >>>>> >>>>> Red Hat >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180604/744c703d/attachment-0001.html From asoldano at redhat.com Tue Jun 5 03:35:13 2018 From: asoldano at redhat.com (Alessio Soldano) Date: Tue, 5 Jun 2018 09:35:13 +0200 Subject: [wildfly-dev] How to set an authorized identity to EltyronSecurity Context In-Reply-To: References: <91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com> <7fe0d553-2190-fa48-6728-41240497cb0c@redhat.com> Message-ID: Hi Pedro, I'll let Jim follow-up on the details here and see with you the best way to move forward. This said, in the current scenario, the isValid is method is not called (it was originally thought for the username token profile scenario, so the string password credential would be available, etc), maybe it should be changed a bit to be used in this scenario too, so that the pushContext is not needed, according to what you're writing below. Can you and Jim please review the current implementation of ElytronSecurityDomainContextImpl and change it to support this SAML token authentication scenario too? Thanks On Mon, Jun 4, 2018 at 3:31 PM, Pedro Igor Silva wrote: > In Keycloak integration we have a specific security realm implementation > that expects a principal previously authenticated by a keycloak adapter > (e.g.: using SAML or OIDC) and builds an authorized identity based on it. > Basically, what this security realm does is populate the authorized > idenitty with information from tokens. > > Later we complete authentication in Elytron and set the token as a > credential into the identity. It is worth mention that in Keycloak > integration, the adapter is a Elytron HTTP Authentication Mechanism, so we > don't deal directly with the security domain but with the callback handler. > > Regarding ElytronSecurityDomainContextImpl, is method pushContext called > after a call to isValid ? If so, the security domain should be set with the > security identity and you don't even need to keep that ThreadLocal ... > > > On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse < > darran.lofthouse at redhat.com> wrote: > >> Just added Pedro in CC so see if he has any suggestions - this is >> sounding similar to the problems he would have needed to handle when he >> added support for KeyCloak integration using the Elytron APIs. >> > >> Although the reported problem we are working on is in the context of >> access to the token it does currently sound that there is a missing >> pre-requisite step of tying the authentication to Elytron to we can >> populate a SecurityIdentity. But this does not sound like the first time >> we have needed to approach this. >> > >> Regards, >> Darran Lofthouse. >> >> >> On Thu, 31 May 2018 at 10:54 Jim Ma wrote: >> >>> On 05/31/2018 05:37 PM, Darran Lofthouse wrote: >>> >>> So the validation is within Apache CXF - is there an end result to this >>> validation where you have access to everything you need where we could >>> perform some additional steps? >>> >>> >>> After Apache CXF validation, we can get a LoginContext from CXF's >>> exchange message : https://github.com/apache/cxf/ >>> blob/master/core/src/main/java/org/apache/cxf/security/Login >>> SecurityContext.java >>> Can we do something to convert it to an Elytron authenticated identity >>> ? >>> Or we have to hook/replace something with Elytron in CXF's validation >>> to make this work ? >>> >>> >>> >>> On Thu, 31 May 2018 at 10:34 Jim Ma wrote: >>> >>>> The saml validation is now Apache CXF's SAML functionality. We can't >>>> port the CXF's security to rely on >>>> our Elytron. >>>> >>>> On 05/31/2018 05:07 PM, Darran Lofthouse wrote: >>>> >>>> It sounds to me then that the place to start is within the SAML >>>> validation, this is effectively an authentication step so should be ported >>>> over to an Elytron based authentication - the end result of the >>>> authentication would then be the required SecurityIdentity to propagate >>>> from container to container. >>>> >>>> >>>> On Thu, 31 May 2018 at 03:57 Jim Ma wrote: >>>> >>>>> On 05/30/2018 09:47 PM, Darran Lofthouse wrote: >>>>> >>>>> I am currently gathering together some information regarding how the >>>>> JCA subsystem handles the requirement of populating a Subject for >>>>> propagation into a resource adapter, however there is a general question >>>>> about what is attempting to be achieved here. >>>>> >>>>> Once an EJB is secured using WildFly Elytron the associated identity >>>>> is not accessed as a Subject instead it is accessed a SecurityIdentity the >>>>> current SecurityIdentity can always be retrieved by calling the current >>>>> SecurityDomain: - >>>>> >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api- >>>>> javadoc/org/wildfly/security/auth/server/SecurityDomain. >>>>> html#getCurrent-- >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api- >>>>> javadoc/org/wildfly/security/auth/server/SecurityDomain. >>>>> html#getCurrentSecurityIdentity-- >>>>> >>>>> The SecurityIdentity has some similarity with the Subject in that >>>>> amongst other things it also contains a collection of public credentials >>>>> and a collection of private credentials: - >>>>> >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api- >>>>> javadoc/org/wildfly/security/auth/server/SecurityIdentity. >>>>> html#getPublicCredentials-- >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api- >>>>> javadoc/org/wildfly/security/auth/server/SecurityIdentity. >>>>> html#getPrivateCredentials-- >>>>> >>>>> So I think the very first question is has the SecurityIdentity been >>>>> correctly populated with any delegated credentials? If not that is going >>>>> to be a pre-requisite for any follow on steps regardless. >>>>> >>>>> Then secondly what is it that is making use of this identity? Why >>>>> can't it be ported to make use of the Elytron authentication client APIs >>>>> which amongst other things provide support for delegation from the current >>>>> identity. >>>>> >>>>> >>>>> If we need to we can look at a conversion to a Subject but we are only >>>>> doing that where it is really required. >>>>> >>>>> >>>>> We don't have the SecurityIdentity populated, there is only >>>>> principal and subject created by jbossws/CXF's saml validator. >>>>> We need to convert the subject/principal to Elytron's >>>>> SecurityIdentity or something else, then later on EJB subystem with Elytron >>>>> security can retrieve this authenticated info without check it >>>>> twice. So we'd like to know how can we convert a subject/principal >>>>> to Elytron's SecurityIdentity and let Elytron know this is already >>>>> authenticated and authorized. >>>>> >>>>> Thanks, >>>>> Jim >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Darran Lofthouse. >>>>> >>>>> >>>>> On Wed, 30 May 2018 at 10:27 Alessio Soldano >>>>> wrote: >>>>> >>>>>> As suggested by Darran, I'm forwarding the message below to the list >>>>>> on behalf of Jim. >>>>>> The classes Jim is referring to are at https://github.com/wildfly/wil >>>>>> dfly/tree/master/webservices/server-integration/src/main/ >>>>>> java/org/jboss/as/webservices/security >>>>>> >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: Jim Ma >>>>>> Date: Wed, May 30, 2018 at 9:03 AM >>>>>> Subject: Set an authorized identity to EltyronSecurity Context >>>>>> To: Darran Lofthouse >>>>>> Cc: Alessio Soldano >>>>>> >>>>>> >>>>>> Hi Darran, >>>>>> >>>>>> We are helping look at a customer issue which requires propagate the >>>>>> authenticated subject from webservice subsystem to >>>>>> >>>>>> ejb subystem. With old security domain , we can do this with creating >>>>>> a subject : >>>>>> >>>>>> @Override >>>>>> public void pushSubjectContext(final Subject subject, final >>>>>> Principal principal, final Object credential) { >>>>>> AccessController.doPrivileged(new PrivilegedAction() { >>>>>> >>>>>> public Void run() { >>>>>> SecurityContext securityContext = >>>>>> SecurityContextAssociation.getSecurityContext(); >>>>>> if (securityContext == null) { >>>>>> securityContext = createSecurityContext(getSecur >>>>>> ityDomain()); >>>>>> setSecurityContextOnAssociation(securityContext); >>>>>> } >>>>>> securityContext.getUtil().createSubjectInfo(principal, credential, >>>>>> subject); >>>>>> return null; >>>>>> } >>>>>> }); >>>>>> } >>>>>> >>>>>> >>>>>> After Elytron, what is the equivalent thing to do this then ejb can >>>>>> retrieve this security without check this twice ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jim >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Alessio Soldano >>>>>> >>>>>> Associate Manager >>>>>> >>>>>> Red Hat >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> > -- Alessio Soldano Associate Manager Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180605/d4c3785d/attachment-0001.html From elayaraja.s at gmail.com Tue Jun 5 06:26:52 2018 From: elayaraja.s at gmail.com (wildflyuser) Date: Tue, 5 Jun 2018 03:26:52 -0700 (MST) Subject: [wildfly-dev] How to define dependency between two app1.ear & app1.ear in wildfly 9.0.2 Message-ID: <1528194412029-0.post@n5.nabble.com> In my wildfly 9.0.2, i have deployed two ear(app1.ear & app2.ear) in app1.ear / META-INF/jboss-deployment-structure.xml how i can define to have dependency of app2.ear/modules.war/WEB-INF/lib -- Sent from: http://wildfly-development.1055759.n5.nabble.com/ From ema at redhat.com Tue Jun 5 23:30:09 2018 From: ema at redhat.com (Jim Ma) Date: Wed, 6 Jun 2018 11:30:09 +0800 Subject: [wildfly-dev] How to set an authorized identity to EltyronSecurity Context In-Reply-To: References: <91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com> <7fe0d553-2190-fa48-6728-41240497cb0c@redhat.com> Message-ID: <472e0a72-fe06-7936-abde-12a1fbbf07a7@redhat.com> On 06/04/2018 09:31 PM, Pedro Igor Silva wrote: > In Keycloak integration we have a specific security realm > implementation that expects a principal previously authenticated by a > keycloak adapter (e.g.: using SAML or OIDC) and builds an authorized > identity based on it. Basically, what this security realm does is > populate the authorized idenitty with information from tokens. > > Later we complete authentication in Elytron and set the token as a > credential into the identity. It is worth mention that in Keycloak > integration, the adapter is a Elytron HTTP Authentication Mechanism, > so we don't deal directly with the security domain but with the > callback handler. > > Regarding ElytronSecurityDomainContextImpl, is method pushContext > called after a call to isValid ??If so, the security domain should be > set with the security identity and you don't even need to keep that > ThreadLocal ... ?Thanks Pedro . Do you think the keycloak Elytron integration code can be improved or changed to a common utility to convert the principal to an Elytron identity? ?Can you please point me the integration code or some Elytron example code snippet to build this authorized identity from a authenticated principal ? > > On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse > > wrote: > > Just added Pedro in CC so see if he has any suggestions - this is > sounding similar to the problems he would have needed to handle > when he added support for KeyCloak integration using the Elytron > APIs. > > > Although the reported problem we are working on is in the context > of access to the token it does currently sound that there is a > missing pre-requisite step of tying the authentication to Elytron > to we can populate a SecurityIdentity.? But this does not sound > like the first time we have needed to approach this. > > > Regards, > Darran Lofthouse. > > > On Thu, 31 May 2018 at 10:54 Jim Ma > wrote: > > On 05/31/2018 05:37 PM, Darran Lofthouse wrote: >> So the validation is within Apache CXF - is there an end >> result to this validation where you have access to everything >> you need where we could perform some additional steps? >> > > ?After Apache CXF validation, we can get a LoginContext from > CXF's exchange message : > https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java > > ?Can we do something to convert it to an Elytron authenticated > identity ? > ?Or we have to hook/replace something with Elytron in CXF's > validation to make this work ? > > >> >> On Thu, 31 May 2018 at 10:34 Jim Ma > > wrote: >> >> The saml validation is now Apache CXF's SAML >> functionality. We can't port the CXF's security to rely on >> our Elytron. >> >> On 05/31/2018 05:07 PM, Darran Lofthouse wrote: >>> It sounds to me then that the place to start is within >>> the SAML validation, this is effectively an >>> authentication step so should be ported over to an >>> Elytron based authentication - the end result of the >>> authentication would then be the required >>> SecurityIdentity to propagate from container to container. >>> >>> >>> On Thu, 31 May 2018 at 03:57 Jim Ma >> > wrote: >>> >>> On 05/30/2018 09:47 PM, Darran Lofthouse wrote: >>>> I am currently gathering together some information >>>> regarding how the JCA subsystem handles the >>>> requirement of populating a Subject for propagation >>>> into a resource adapter, however there is a general >>>> question about what is attempting to be achieved here. >>>> >>>> Once an EJB is secured using WildFly Elytron the >>>> associated identity is not accessed as a Subject >>>> instead it is accessed a SecurityIdentity the >>>> current SecurityIdentity can always be retrieved by >>>> calling the current SecurityDomain: - >>>> >>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent-- >>>> >>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrentSecurityIdentity-- >>>> >>>> >>>> The SecurityIdentity has some similarity with the >>>> Subject in that amongst other things it also >>>> contains a collection of public credentials and a >>>> collection of private credentials: - >>>> >>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPublicCredentials-- >>>> >>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPrivateCredentials-- >>>> >>>> >>>> So I think the very first question is has the >>>> SecurityIdentity been correctly populated with any >>>> delegated credentials?? If not that is going to be >>>> a pre-requisite for any follow on steps regardless. >>>> >>>> Then secondly what is it that is making use of this >>>> identity?? Why can't it be ported to make use of >>>> the Elytron authentication client APIs which >>>> amongst other things provide support for delegation >>>> from the current identity. >>>> >>>> If we need to we can look at a conversion to a >>>> Subject but we are only doing that where it is >>>> really required. >>> >>> ? We don't have the SecurityIdentity populated, >>> there is only principal and subject created by >>> jbossws/CXF's saml validator. >>> ? We need to convert the subject/principal to >>> Elytron's SecurityIdentity or something else, then >>> later on EJB subystem with Elytron >>> ? security can retrieve this authenticated info >>> without check it twice. So we'd like to know how can >>> we convert a subject/principal >>> ? to Elytron's SecurityIdentity and let Elytron know >>> this is already authenticated and authorized. >>> >>> Thanks, >>> Jim >>> >>> >>>> >>>> Regards, >>>> Darran Lofthouse. >>>> >>>> >>>> On Wed, 30 May 2018 at 10:27 Alessio Soldano >>>> > >>>> wrote: >>>> >>>> As suggested by Darran, I'm forwarding the >>>> message below to the list on behalf of Jim. >>>> The classes Jim is referring to are at >>>> https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security >>>> >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: *Jim Ma* >>> > >>>> Date: Wed, May 30, 2018 at 9:03 AM >>>> Subject: Set an authorized identity to >>>> EltyronSecurity Context >>>> To: Darran Lofthouse >>>> >>> > >>>> Cc: Alessio Soldano >>> > >>>> >>>> >>>> Hi Darran, >>>> >>>> We are helping look at a customer issue which >>>> requires propagate the authenticated subject >>>> from webservice subsystem to >>>> >>>> ejb subystem. With old security domain , we can >>>> do this with creating a subject : >>>> >>>> ??? @Override >>>> ??? public void pushSubjectContext(final >>>> Subject subject, final Principal principal, >>>> final Object credential) { >>>> AccessController.doPrivileged(new >>>> PrivilegedAction() { >>>> >>>> public Void run() { >>>> ??????????????? SecurityContext securityContext >>>> = SecurityContextAssociation.getSecurityContext(); >>>> ??????????????? if (securityContext == null) { >>>> ??????????????????? securityContext = >>>> createSecurityContext(getSecurityDomain()); >>>> setSecurityContextOnAssociation(securityContext); >>>> ??????????????? } >>>> securityContext.getUtil().createSubjectInfo(principal, >>>> credential, subject); >>>> ??????????????? return null; >>>> ??????????? } >>>> ??????? }); >>>> ??? } >>>> >>>> >>>> After Elytron,? what is the equivalent thing to >>>> do this? then ejb can retrieve this security >>>> without check this twice ? >>>> >>>> Thanks, >>>> >>>> Jim >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Alessio Soldano >>>> >>>> Associate Manager >>>> >>>> Red Hat >>>> >>>> >>>> >>>> >>>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180606/f448d45b/attachment-0001.html From ppalaga at redhat.com Wed Jun 6 02:20:18 2018 From: ppalaga at redhat.com (Peter Palaga) Date: Wed, 6 Jun 2018 08:20:18 +0200 Subject: [wildfly-dev] Galleon roadmap Message-ID: <693047f0-6c55-e198-def3-6446d23bf1a7@redhat.com> Hi Alexey, These are questions from a layered product PoV (WildFly Camel in my case): (1) Is it still safe to rely on the traditional feature packs? (2) When will the time come that we'll have to switch to Galleon? Thanks, -- Peter From darran.lofthouse at redhat.com Wed Jun 6 03:59:52 2018 From: darran.lofthouse at redhat.com (Darran Lofthouse) Date: Wed, 6 Jun 2018 10:59:52 +0300 Subject: [wildfly-dev] How to set an authorized identity to EltyronSecurity Context In-Reply-To: <472e0a72-fe06-7936-abde-12a1fbbf07a7@redhat.com> References: <91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com> <7fe0d553-2190-fa48-6728-41240497cb0c@redhat.com> <472e0a72-fe06-7936-abde-12a1fbbf07a7@redhat.com> Message-ID: On the WildFly Elytron side if there is anything missing we can certainly consider it - I know on the KeyCloak side a KeyCloak specific realm was used but if we need something more generic for SAML we can certainly look at adding it if it is needed for this integration. Regards, Darran Lofthouse. On Wed, 6 Jun 2018 at 06:30 Jim Ma wrote: > On 06/04/2018 09:31 PM, Pedro Igor Silva wrote: > > In Keycloak integration we have a specific security realm implementation > that expects a principal previously authenticated by a keycloak adapter > (e.g.: using SAML or OIDC) and builds an authorized identity based on it. > Basically, what this security realm does is populate the authorized > idenitty with information from tokens. > > Later we complete authentication in Elytron and set the token as a > credential into the identity. It is worth mention that in Keycloak > integration, the adapter is a Elytron HTTP Authentication Mechanism, so we > don't deal directly with the security domain but with the callback handler. > > Regarding ElytronSecurityDomainContextImpl, is method pushContext called > after a call to isValid ? If so, the security domain should be set with the > security identity and you don't even need to keep that ThreadLocal ... > > > Thanks Pedro . Do you think the keycloak Elytron integration code can be > improved or changed to a common utility to convert the principal to an > Elytron identity? > Can you please point me the integration code or some Elytron example code > snippet to build this authorized identity from a authenticated principal ? > > > > On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse < > darran.lofthouse at redhat.com> wrote: > >> Just added Pedro in CC so see if he has any suggestions - this is >> sounding similar to the problems he would have needed to handle when he >> added support for KeyCloak integration using the Elytron APIs. >> > >> Although the reported problem we are working on is in the context of >> access to the token it does currently sound that there is a missing >> pre-requisite step of tying the authentication to Elytron to we can >> populate a SecurityIdentity. But this does not sound like the first time >> we have needed to approach this. >> > >> Regards, >> Darran Lofthouse. >> >> >> On Thu, 31 May 2018 at 10:54 Jim Ma wrote: >> >>> On 05/31/2018 05:37 PM, Darran Lofthouse wrote: >>> >>> So the validation is within Apache CXF - is there an end result to this >>> validation where you have access to everything you need where we could >>> perform some additional steps? >>> >>> >>> After Apache CXF validation, we can get a LoginContext from CXF's >>> exchange message : >>> https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java >>> Can we do something to convert it to an Elytron authenticated identity >>> ? >>> Or we have to hook/replace something with Elytron in CXF's validation >>> to make this work ? >>> >>> >>> >>> On Thu, 31 May 2018 at 10:34 Jim Ma wrote: >>> >>>> The saml validation is now Apache CXF's SAML functionality. We can't >>>> port the CXF's security to rely on >>>> our Elytron. >>>> >>>> On 05/31/2018 05:07 PM, Darran Lofthouse wrote: >>>> >>>> It sounds to me then that the place to start is within the SAML >>>> validation, this is effectively an authentication step so should be ported >>>> over to an Elytron based authentication - the end result of the >>>> authentication would then be the required SecurityIdentity to propagate >>>> from container to container. >>>> >>>> >>>> On Thu, 31 May 2018 at 03:57 Jim Ma wrote: >>>> >>>>> On 05/30/2018 09:47 PM, Darran Lofthouse wrote: >>>>> >>>>> I am currently gathering together some information regarding how the >>>>> JCA subsystem handles the requirement of populating a Subject for >>>>> propagation into a resource adapter, however there is a general question >>>>> about what is attempting to be achieved here. >>>>> >>>>> Once an EJB is secured using WildFly Elytron the associated identity >>>>> is not accessed as a Subject instead it is accessed a SecurityIdentity the >>>>> current SecurityIdentity can always be retrieved by calling the current >>>>> SecurityDomain: - >>>>> >>>>> >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent-- >>>>> >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrentSecurityIdentity-- >>>>> >>>>> The SecurityIdentity has some similarity with the Subject in that >>>>> amongst other things it also contains a collection of public credentials >>>>> and a collection of private credentials: - >>>>> >>>>> >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPublicCredentials-- >>>>> >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPrivateCredentials-- >>>>> >>>>> So I think the very first question is has the SecurityIdentity been >>>>> correctly populated with any delegated credentials? If not that is going >>>>> to be a pre-requisite for any follow on steps regardless. >>>>> >>>>> Then secondly what is it that is making use of this identity? Why >>>>> can't it be ported to make use of the Elytron authentication client APIs >>>>> which amongst other things provide support for delegation from the current >>>>> identity. >>>>> >>>>> >>>>> If we need to we can look at a conversion to a Subject but we are only >>>>> doing that where it is really required. >>>>> >>>>> >>>>> We don't have the SecurityIdentity populated, there is only >>>>> principal and subject created by jbossws/CXF's saml validator. >>>>> We need to convert the subject/principal to Elytron's >>>>> SecurityIdentity or something else, then later on EJB subystem with Elytron >>>>> security can retrieve this authenticated info without check it >>>>> twice. So we'd like to know how can we convert a subject/principal >>>>> to Elytron's SecurityIdentity and let Elytron know this is already >>>>> authenticated and authorized. >>>>> >>>>> Thanks, >>>>> Jim >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Darran Lofthouse. >>>>> >>>>> >>>>> On Wed, 30 May 2018 at 10:27 Alessio Soldano >>>>> wrote: >>>>> >>>>>> As suggested by Darran, I'm forwarding the message below to the list >>>>>> on behalf of Jim. >>>>>> The classes Jim is referring to are at >>>>>> https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security >>>>>> >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: Jim Ma >>>>>> Date: Wed, May 30, 2018 at 9:03 AM >>>>>> Subject: Set an authorized identity to EltyronSecurity Context >>>>>> To: Darran Lofthouse >>>>>> Cc: Alessio Soldano >>>>>> >>>>>> >>>>>> Hi Darran, >>>>>> >>>>>> We are helping look at a customer issue which requires propagate the >>>>>> authenticated subject from webservice subsystem to >>>>>> >>>>>> ejb subystem. With old security domain , we can do this with creating >>>>>> a subject : >>>>>> >>>>>> @Override >>>>>> public void pushSubjectContext(final Subject subject, final >>>>>> Principal principal, final Object credential) { >>>>>> AccessController.doPrivileged(new PrivilegedAction() { >>>>>> >>>>>> public Void run() { >>>>>> SecurityContext securityContext = >>>>>> SecurityContextAssociation.getSecurityContext(); >>>>>> if (securityContext == null) { >>>>>> securityContext = >>>>>> createSecurityContext(getSecurityDomain()); >>>>>> setSecurityContextOnAssociation(securityContext); >>>>>> } >>>>>> securityContext.getUtil().createSubjectInfo(principal, credential, >>>>>> subject); >>>>>> return null; >>>>>> } >>>>>> }); >>>>>> } >>>>>> >>>>>> >>>>>> After Elytron, what is the equivalent thing to do this then ejb can >>>>>> retrieve this security without check this twice ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jim >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Alessio Soldano >>>>>> >>>>>> Associate Manager >>>>>> >>>>>> Red Hat >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180606/3767d931/attachment-0001.html From alexey.loubyansky at redhat.com Wed Jun 6 06:32:26 2018 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Wed, 6 Jun 2018 12:32:26 +0200 Subject: [wildfly-dev] Galleon roadmap In-Reply-To: <693047f0-6c55-e198-def3-6446d23bf1a7@redhat.com> References: <693047f0-6c55-e198-def3-6446d23bf1a7@redhat.com> Message-ID: Hi Peter, On Wed, Jun 6, 2018, 8:20 AM Peter Palaga wrote: > Hi Alexey, > > These are questions from a layered product PoV (WildFly Camel in my case): > > (1) Is it still safe to rely on the traditional feature packs? > Yes, they are still fully supported for now. Although they are not used anymore to build the default wildfly distributions. There is a command line argument though that allows to build the dists using the legacy feature packs. (2) When will the time come that we'll have to switch to Galleon? > I'd say this has to start happening now. Ideally, by the end of the summer layered, deployed and other products that are using feature-packs should be using the new feature packs. The sooner we start the move the more time we'll have to adjust and identify what needs to be fixed. Feel free to ping me for guidance here or in Galleon room on hipchat. I used to have the docs in my personal repo on github, now that the project has moved to its official repo I need to upload the docs somewhere official as well. Currently the docs are in the corresponding modules in Galleon project [1] and Galleon plugins [2]. [1] https://github.com/wildfly/galleon [2] *https://github.com/wildfly/galleon-plugins * Alexey > Thanks, > > -- Peter > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180606/49cd1cc9/attachment.html From guillaume at hibernate.org Wed Jun 6 08:13:08 2018 From: guillaume at hibernate.org (Guillaume Smet) Date: Wed, 6 Jun 2018 14:13:08 +0200 Subject: [wildfly-dev] Patching generation facility broken with WildFly 13? Message-ID: Hi, For some time now, we build WildFly patches for Hibernate Validator. With 11 and 12, everything was OK, but I just tried to upgrade to WildFly 13 and the patch-gen-maven-plugin fails with the following error in the patchgen.log: java.io.IOException: org.jboss.modules.ModuleNotFoundException: org.jboss.modules:main at org.jboss.as.patching.generator.DistributionProcessor.process(DistributionProcessor.java:106) at org.jboss.as.patching.generator.Distribution.create(Distribution.java:68) at org.jboss.as.patching.generator.PatchGenerator.process(PatchGenerator.java:129) at org.jboss.as.patching.generator.PatchGenerator.main(PatchGenerator.java:73) Caused by: org.jboss.modules.ModuleNotFoundException: org.jboss.modules:main at org.jboss.modules.Module.addPaths(Module.java:1116) at org.jboss.modules.Module.link(Module.java:1472) at org.jboss.modules.Module.relinkIfNecessary(Module.java:1500) at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:226) at org.jboss.as.patching.generator.DistributionProcessor.process(DistributionProcessor.java:93) ... 3 more My branch is here: https://github.com/gsmet/hibernate-validator/tree/HV-1622 . A simple mvn clean install fails with the above error. If you drop the latest commit and go back to build WF 11 and 12, everything is fine. I use the latest patch-gen-maven-plugin with the latest wildfly-core (5.0.0.Final) so the latest wildfly-patching. Note that we usually support 2 versions of WF so I would like to keep supporting WF 12 too. Any thoughts? Thanks! -- Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180606/ae02de05/attachment.html From alexey.loubyansky at redhat.com Wed Jun 6 10:41:40 2018 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Wed, 6 Jun 2018 16:41:40 +0200 Subject: [wildfly-dev] Patching generation facility broken with WildFly 13? In-Reply-To: References: Message-ID: Hi Guillaume, thanks for bringing this up. There have been some changes in the module deps in wfcore since the release referenced from the patch gen. Please try this branch https://github.com/aloubyansky/patch-gen-1/commits/upgrade-wfcore-5 I was able to build your branch with your last commit and w/o it. If that works for you, please let me know, I'll make a release with the fix. Thanks, Alexey On Wed, Jun 6, 2018 at 2:13 PM, Guillaume Smet wrote: > Hi, > > For some time now, we build WildFly patches for Hibernate Validator. > > With 11 and 12, everything was OK, but I just tried to upgrade to WildFly > 13 and the patch-gen-maven-plugin fails with the following error in the > patchgen.log: > java.io.IOException: org.jboss.modules.ModuleNotFoundException: > org.jboss.modules:main > at org.jboss.as.patching.generator.DistributionProcessor.process( > DistributionProcessor.java:106) > at org.jboss.as.patching.generator.Distribution.create( > Distribution.java:68) > at org.jboss.as.patching.generator.PatchGenerator. > process(PatchGenerator.java:129) > at org.jboss.as.patching.generator.PatchGenerator.main( > PatchGenerator.java:73) > Caused by: org.jboss.modules.ModuleNotFoundException: > org.jboss.modules:main > at org.jboss.modules.Module.addPaths(Module.java:1116) > at org.jboss.modules.Module.link(Module.java:1472) > at org.jboss.modules.Module.relinkIfNecessary(Module.java:1500) > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:226) > at org.jboss.as.patching.generator.DistributionProcessor.process( > DistributionProcessor.java:93) > ... 3 more > > My branch is here: https://github.com/gsmet/hibernate-validator/tree/HV- > 1622 . A simple mvn clean install fails with the above error. If you drop > the latest commit and go back to build WF 11 and 12, everything is fine. > > I use the latest patch-gen-maven-plugin with the latest wildfly-core > (5.0.0.Final) so the latest wildfly-patching. > > Note that we usually support 2 versions of WF so I would like to keep > supporting WF 12 too. > > Any thoughts? > > Thanks! > > -- > Guillaume > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180606/daa96b9b/attachment.html From psilva at redhat.com Wed Jun 6 12:25:52 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 6 Jun 2018 13:25:52 -0300 Subject: [wildfly-dev] How to set an authorized identity to EltyronSecurity Context In-Reply-To: <472e0a72-fe06-7936-abde-12a1fbbf07a7@redhat.com> References: <91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com> <7fe0d553-2190-fa48-6728-41240497cb0c@redhat.com> <472e0a72-fe06-7936-abde-12a1fbbf07a7@redhat.com> Message-ID: I don't think Keycloak integration code can be worked to be a common utility. It seems to me that you would need a specific security realm implementation from where you could just return an authorized identity as a result of parsing the SAML assertion. Here is what we have in Keycloak [1]. As you can see, we are basically trusting a KeycloakPrincipal, previously created by the keycloak adapter, and creating an authorization identity from it. We don't re-authenticate the user. So when pushContext is called, you could use serverauthenticationcontext and the CBH to ask Elytron for a security identity. See [2]. In this last example, we pass the previously authenticated principal via EvidenceVerifyCallback. I think this might work for you. [1] https://github.com/pedroigor/keycloak/blob/d3e559453b7dcf6f0d9f32c5a9a7f8c49403bb3a/adapters/oidc/wildfly-elytron/src/main/java/org/keycloak/adapters/elytron/KeycloakSecurityRealm.java#L83 [2] https://github.com/pedroigor/keycloak/blob/d3dee07956be8d0ac69466ac9367984ab0ea072d/adapters/oidc/wildfly-elytron/src/main/java/org/keycloak/adapters/elytron/SecurityIdentityUtil.java#L45 On Wed, Jun 6, 2018 at 12:30 AM, Jim Ma wrote: > On 06/04/2018 09:31 PM, Pedro Igor Silva wrote: > > In Keycloak integration we have a specific security realm implementation > that expects a principal previously authenticated by a keycloak adapter > (e.g.: using SAML or OIDC) and builds an authorized identity based on it. > Basically, what this security realm does is populate the authorized > idenitty with information from tokens. > > Later we complete authentication in Elytron and set the token as a > credential into the identity. It is worth mention that in Keycloak > integration, the adapter is a Elytron HTTP Authentication Mechanism, so we > don't deal directly with the security domain but with the callback handler. > > Regarding ElytronSecurityDomainContextImpl, is method pushContext called > after a call to isValid ? If so, the security domain should be set with the > security identity and you don't even need to keep that ThreadLocal ... > > > Thanks Pedro . Do you think the keycloak Elytron integration code can be > improved or changed to a common utility to convert the principal to an > Elytron identity? > Can you please point me the integration code or some Elytron example code > snippet to build this authorized identity from a authenticated principal ? > > > > On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse < > darran.lofthouse at redhat.com> wrote: > >> Just added Pedro in CC so see if he has any suggestions - this is >> sounding similar to the problems he would have needed to handle when he >> added support for KeyCloak integration using the Elytron APIs. >> > >> Although the reported problem we are working on is in the context of >> access to the token it does currently sound that there is a missing >> pre-requisite step of tying the authentication to Elytron to we can >> populate a SecurityIdentity. But this does not sound like the first time >> we have needed to approach this. >> > >> Regards, >> Darran Lofthouse. >> >> >> On Thu, 31 May 2018 at 10:54 Jim Ma wrote: >> >>> On 05/31/2018 05:37 PM, Darran Lofthouse wrote: >>> >>> So the validation is within Apache CXF - is there an end result to this >>> validation where you have access to everything you need where we could >>> perform some additional steps? >>> >>> >>> After Apache CXF validation, we can get a LoginContext from CXF's >>> exchange message : https://github.com/apache/cxf/ >>> blob/master/core/src/main/java/org/apache/cxf/security/Login >>> SecurityContext.java >>> Can we do something to convert it to an Elytron authenticated identity >>> ? >>> Or we have to hook/replace something with Elytron in CXF's validation >>> to make this work ? >>> >>> >>> >>> On Thu, 31 May 2018 at 10:34 Jim Ma wrote: >>> >>>> The saml validation is now Apache CXF's SAML functionality. We can't >>>> port the CXF's security to rely on >>>> our Elytron. >>>> >>>> On 05/31/2018 05:07 PM, Darran Lofthouse wrote: >>>> >>>> It sounds to me then that the place to start is within the SAML >>>> validation, this is effectively an authentication step so should be ported >>>> over to an Elytron based authentication - the end result of the >>>> authentication would then be the required SecurityIdentity to propagate >>>> from container to container. >>>> >>>> >>>> On Thu, 31 May 2018 at 03:57 Jim Ma wrote: >>>> >>>>> On 05/30/2018 09:47 PM, Darran Lofthouse wrote: >>>>> >>>>> I am currently gathering together some information regarding how the >>>>> JCA subsystem handles the requirement of populating a Subject for >>>>> propagation into a resource adapter, however there is a general question >>>>> about what is attempting to be achieved here. >>>>> >>>>> Once an EJB is secured using WildFly Elytron the associated identity >>>>> is not accessed as a Subject instead it is accessed a SecurityIdentity the >>>>> current SecurityIdentity can always be retrieved by calling the current >>>>> SecurityDomain: - >>>>> >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api- >>>>> javadoc/org/wildfly/security/auth/server/SecurityDomain. >>>>> html#getCurrent-- >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api- >>>>> javadoc/org/wildfly/security/auth/server/SecurityDomain. >>>>> html#getCurrentSecurityIdentity-- >>>>> >>>>> The SecurityIdentity has some similarity with the Subject in that >>>>> amongst other things it also contains a collection of public credentials >>>>> and a collection of private credentials: - >>>>> >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api- >>>>> javadoc/org/wildfly/security/auth/server/SecurityIdentity. >>>>> html#getPublicCredentials-- >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api- >>>>> javadoc/org/wildfly/security/auth/server/SecurityIdentity. >>>>> html#getPrivateCredentials-- >>>>> >>>>> So I think the very first question is has the SecurityIdentity been >>>>> correctly populated with any delegated credentials? If not that is going >>>>> to be a pre-requisite for any follow on steps regardless. >>>>> >>>>> Then secondly what is it that is making use of this identity? Why >>>>> can't it be ported to make use of the Elytron authentication client APIs >>>>> which amongst other things provide support for delegation from the current >>>>> identity. >>>>> >>>>> >>>>> If we need to we can look at a conversion to a Subject but we are only >>>>> doing that where it is really required. >>>>> >>>>> >>>>> We don't have the SecurityIdentity populated, there is only >>>>> principal and subject created by jbossws/CXF's saml validator. >>>>> We need to convert the subject/principal to Elytron's >>>>> SecurityIdentity or something else, then later on EJB subystem with Elytron >>>>> security can retrieve this authenticated info without check it >>>>> twice. So we'd like to know how can we convert a subject/principal >>>>> to Elytron's SecurityIdentity and let Elytron know this is already >>>>> authenticated and authorized. >>>>> >>>>> Thanks, >>>>> Jim >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Darran Lofthouse. >>>>> >>>>> >>>>> On Wed, 30 May 2018 at 10:27 Alessio Soldano >>>>> wrote: >>>>> >>>>>> As suggested by Darran, I'm forwarding the message below to the list >>>>>> on behalf of Jim. >>>>>> The classes Jim is referring to are at https://github.com/wildfly/wil >>>>>> dfly/tree/master/webservices/server-integration/src/main/ >>>>>> java/org/jboss/as/webservices/security >>>>>> >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: Jim Ma >>>>>> Date: Wed, May 30, 2018 at 9:03 AM >>>>>> Subject: Set an authorized identity to EltyronSecurity Context >>>>>> To: Darran Lofthouse >>>>>> Cc: Alessio Soldano >>>>>> >>>>>> >>>>>> Hi Darran, >>>>>> >>>>>> We are helping look at a customer issue which requires propagate the >>>>>> authenticated subject from webservice subsystem to >>>>>> >>>>>> ejb subystem. With old security domain , we can do this with creating >>>>>> a subject : >>>>>> >>>>>> @Override >>>>>> public void pushSubjectContext(final Subject subject, final >>>>>> Principal principal, final Object credential) { >>>>>> AccessController.doPrivileged(new PrivilegedAction() { >>>>>> >>>>>> public Void run() { >>>>>> SecurityContext securityContext = >>>>>> SecurityContextAssociation.getSecurityContext(); >>>>>> if (securityContext == null) { >>>>>> securityContext = createSecurityContext(getSecur >>>>>> ityDomain()); >>>>>> setSecurityContextOnAssociation(securityContext); >>>>>> } >>>>>> securityContext.getUtil().createSubjectInfo(principal, credential, >>>>>> subject); >>>>>> return null; >>>>>> } >>>>>> }); >>>>>> } >>>>>> >>>>>> >>>>>> After Elytron, what is the equivalent thing to do this then ejb can >>>>>> retrieve this security without check this twice ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jim >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Alessio Soldano >>>>>> >>>>>> Associate Manager >>>>>> >>>>>> Red Hat >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180606/53764d24/attachment-0001.html From ema at redhat.com Thu Jun 7 05:17:36 2018 From: ema at redhat.com (Jim Ma) Date: Thu, 7 Jun 2018 17:17:36 +0800 Subject: [wildfly-dev] How to set an authorized identity to EltyronSecurity Context In-Reply-To: References: <91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com> <7fe0d553-2190-fa48-6728-41240497cb0c@redhat.com> <472e0a72-fe06-7936-abde-12a1fbbf07a7@redhat.com> Message-ID: <468e1386-cb02-7371-a761-4e4d804e31fe@redhat.com> Just to understand. I saw the SecurityIdentiy will be called by KeycloakHttpServerAuthenticationMechanism, and this will finally trigger the KeycloakSecurityRealm to create identity.?? To make this all work, we need to configure KeycloakSecurityRealm and KeycloakHttpServerAuthenticationMechanism under Elytron subsystem, right? ?06/07/2018 12:25 AM, Pedro Igor Silva wrote: > I don't think Keycloak integration code can be worked to be a common > utility. > > It seems to me that you would need a specific security realm > implementation from where you could just return an authorized identity > as a result of parsing the SAML assertion. Here is what we have in > Keycloak [1]. As you can see, we are basically trusting a > KeycloakPrincipal, previously created by the keycloak adapter, and > creating an authorization identity from it. We don't re-authenticate > the user. > > So when pushContext is called, you could use > serverauthenticationcontext and the CBH to ask Elytron for a security > identity. See [2]. In this last example, we pass the previously > authenticated principal via EvidenceVerifyCallback. > I think this might work for you. > > [1] > https://github.com/pedroigor/keycloak/blob/d3e559453b7dcf6f0d9f32c5a9a7f8c49403bb3a/adapters/oidc/wildfly-elytron/src/main/java/org/keycloak/adapters/elytron/KeycloakSecurityRealm.java#L83 > [2] > https://github.com/pedroigor/keycloak/blob/d3dee07956be8d0ac69466ac9367984ab0ea072d/adapters/oidc/wildfly-elytron/src/main/java/org/keycloak/adapters/elytron/SecurityIdentityUtil.java#L45 > > On Wed, Jun 6, 2018 at 12:30 AM, Jim Ma > wrote: > > On 06/04/2018 09:31 PM, Pedro Igor Silva wrote: >> In Keycloak integration we have a specific security realm >> implementation that expects a principal previously authenticated >> by a keycloak adapter (e.g.: using SAML or OIDC) and builds an >> authorized identity based on it. Basically, what this security >> realm does is populate the authorized idenitty with information >> from tokens. >> >> Later we complete authentication in Elytron and set the token as >> a credential into the identity. It is worth mention that in >> Keycloak integration, the adapter is a Elytron HTTP >> Authentication Mechanism, so we don't deal directly with the >> security domain but with the callback handler. >> >> Regarding ElytronSecurityDomainContextImpl, is method pushContext >> called after a call to isValid ??If so, the security domain >> should be set with the security identity and you don't even need >> to keep that ThreadLocal ... > > ?Thanks Pedro . Do you think the keycloak Elytron integration code > can be improved or changed to a common utility to convert the > principal to an Elytron identity? > ?Can you please point me the integration code or some Elytron > example code snippet to build this authorized identity from a > authenticated principal ? > >> >> On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse >> > > wrote: >> >> Just added Pedro in CC so see if he has any suggestions - >> this is sounding similar to the problems he would have needed >> to handle when he added support for KeyCloak integration >> using the Elytron APIs. >> >> >> Although the reported problem we are working on is in the >> context of access to the token it does currently sound that >> there is a missing pre-requisite step of tying the >> authentication to Elytron to we can populate a >> SecurityIdentity.? But this does not sound like the first >> time we have needed to approach this. >> >> >> Regards, >> Darran Lofthouse. >> >> >> On Thu, 31 May 2018 at 10:54 Jim Ma > > wrote: >> >> On 05/31/2018 05:37 PM, Darran Lofthouse wrote: >>> So the validation is within Apache CXF - is there an end >>> result to this validation where you have access to >>> everything you need where we could perform some >>> additional steps? >>> >> >> ?After Apache CXF validation, we can get a LoginContext >> from CXF's exchange message : >> https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java >> >> ?Can we do something to convert it to an Elytron >> authenticated identity ? >> ?Or we have to hook/replace something with Elytron in >> CXF's validation to make this work ? >> >> >>> >>> On Thu, 31 May 2018 at 10:34 Jim Ma >> > wrote: >>> >>> The saml validation is now Apache CXF's SAML >>> functionality. We can't port the CXF's security to >>> rely on >>> our Elytron. >>> >>> On 05/31/2018 05:07 PM, Darran Lofthouse wrote: >>>> It sounds to me then that the place to start is >>>> within the SAML validation, this is effectively an >>>> authentication step so should be ported over to an >>>> Elytron based authentication - the end result of >>>> the authentication would then be the required >>>> SecurityIdentity to propagate from container to >>>> container. >>>> >>>> >>>> On Thu, 31 May 2018 at 03:57 Jim Ma >>> > wrote: >>>> >>>> On 05/30/2018 09:47 PM, Darran Lofthouse wrote: >>>>> I am currently gathering together some >>>>> information regarding how the JCA subsystem >>>>> handles the requirement of populating a >>>>> Subject for propagation into a resource >>>>> adapter, however there is a general question >>>>> about what is attempting to be achieved here. >>>>> >>>>> Once an EJB is secured using WildFly Elytron >>>>> the associated identity is not accessed as a >>>>> Subject instead it is accessed a >>>>> SecurityIdentity the current SecurityIdentity >>>>> can always be retrieved by calling the current >>>>> SecurityDomain: - >>>>> >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent-- >>>>> >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrentSecurityIdentity-- >>>>> >>>>> >>>>> The SecurityIdentity has some similarity with >>>>> the Subject in that amongst other things it >>>>> also contains a collection of public >>>>> credentials and a collection of private >>>>> credentials: - >>>>> >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPublicCredentials-- >>>>> >>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPrivateCredentials-- >>>>> >>>>> >>>>> So I think the very first question is has the >>>>> SecurityIdentity been correctly populated with >>>>> any delegated credentials? If not that is >>>>> going to be a pre-requisite for any follow on >>>>> steps regardless. >>>>> >>>>> Then secondly what is it that is making use of >>>>> this identity?? Why can't it be ported to make >>>>> use of the Elytron authentication client APIs >>>>> which amongst other things provide support for >>>>> delegation from the current identity. >>>>> >>>>> If we need to we can look at a conversion to a >>>>> Subject but we are only doing that where it is >>>>> really required. >>>> >>>> ? We don't have the SecurityIdentity populated, >>>> there is only principal and subject created by >>>> jbossws/CXF's saml validator. >>>> ? We need to convert the subject/principal to >>>> Elytron's SecurityIdentity or something else, >>>> then later on EJB subystem with Elytron >>>> ? security can retrieve this authenticated info >>>> without check it twice. So we'd like to know >>>> how can we convert a subject/principal >>>> ? to Elytron's SecurityIdentity and let Elytron >>>> know this is already authenticated and authorized. >>>> >>>> Thanks, >>>> Jim >>>> >>>> >>>>> >>>>> Regards, >>>>> Darran Lofthouse. >>>>> >>>>> >>>>> On Wed, 30 May 2018 at 10:27 Alessio Soldano >>>>> >>>> > wrote: >>>>> >>>>> As suggested by Darran, I'm forwarding the >>>>> message below to the list on behalf of Jim. >>>>> The classes Jim is referring to are at >>>>> https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security >>>>> >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: *Jim Ma* >>>> > >>>>> Date: Wed, May 30, 2018 at 9:03 AM >>>>> Subject: Set an authorized identity to >>>>> EltyronSecurity Context >>>>> To: Darran Lofthouse >>>>> >>>> > >>>>> Cc: Alessio Soldano >>>> > >>>>> >>>>> >>>>> Hi Darran, >>>>> >>>>> We are helping look at a customer issue >>>>> which requires propagate the authenticated >>>>> subject from webservice subsystem to >>>>> >>>>> ejb subystem. With old security domain , >>>>> we can do this with creating a subject : >>>>> >>>>> ??? @Override >>>>> ??? public void pushSubjectContext(final >>>>> Subject subject, final Principal >>>>> principal, final Object credential) { >>>>> AccessController.doPrivileged(new >>>>> PrivilegedAction() { >>>>> >>>>> public Void run() { >>>>> ??????????????? SecurityContext >>>>> securityContext = >>>>> SecurityContextAssociation.getSecurityContext(); >>>>> ??????????????? if (securityContext == null) { >>>>> ??????????????????? securityContext = >>>>> createSecurityContext(getSecurityDomain()); >>>>> setSecurityContextOnAssociation(securityContext); >>>>> ??????????????? } >>>>> securityContext.getUtil().createSubjectInfo(principal, >>>>> credential, subject); >>>>> ??????????????? return null; >>>>> ??????????? } >>>>> ??????? }); >>>>> ??? } >>>>> >>>>> >>>>> After Elytron,? what is the equivalent >>>>> thing to do this? then ejb can retrieve >>>>> this security without check this twice ? >>>>> >>>>> Thanks, >>>>> >>>>> Jim >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Alessio Soldano >>>>> >>>>> Associate Manager >>>>> >>>>> Red Hat >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180607/c85454c0/attachment-0001.html From guillaume at hibernate.org Thu Jun 7 07:13:45 2018 From: guillaume at hibernate.org (Guillaume Smet) Date: Thu, 7 Jun 2018 13:13:45 +0200 Subject: [wildfly-dev] Patching generation facility broken with WildFly 13? In-Reply-To: References: Message-ID: Hi Alexey, On Wed, Jun 6, 2018 at 4:41 PM Alexey Loubyansky < alexey.loubyansky at redhat.com> wrote: > I was able to build your branch with your last commit and w/o it. If that > works for you, please let me know, I'll make a release with the fix. > I confirm it now works like a charm: I can build my patches for WF 12 and 13. Thanks for the quick fix. Looking forward to the release. Thanks! -- Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180607/1f50eb76/attachment.html From psilva at redhat.com Thu Jun 7 07:47:08 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 7 Jun 2018 08:47:08 -0300 Subject: [wildfly-dev] How to set an authorized identity to EltyronSecurity Context In-Reply-To: <468e1386-cb02-7371-a761-4e4d804e31fe@redhat.com> References: <91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com> <7fe0d553-2190-fa48-6728-41240497cb0c@redhat.com> <472e0a72-fe06-7936-abde-12a1fbbf07a7@redhat.com> <468e1386-cb02-7371-a761-4e4d804e31fe@redhat.com> Message-ID: Exactly. In addition to a security domain referencing the realm and a http-authentication-factory referencing the domain. On Thu, Jun 7, 2018 at 6:17 AM, Jim Ma wrote: > Just to understand. I saw the SecurityIdentiy will be called by > KeycloakHttpServerAuthenticationMechanism, and this will finally trigger > the KeycloakSecurityRealm to create identity. To make this all work, we > need to > configure KeycloakSecurityRealm and KeycloakHttpServerAuthenticationMechanism > under Elytron subsystem, right? > > > > 06/07/2018 12:25 AM, Pedro Igor Silva wrote: > > I don't think Keycloak integration code can be worked to be a common > utility. > > It seems to me that you would need a specific security realm > implementation from where you could just return an authorized identity as a > result of parsing the SAML assertion. Here is what we have in Keycloak [1]. > As you can see, we are basically trusting a KeycloakPrincipal, previously > created by the keycloak adapter, and creating an authorization identity > from it. We don't re-authenticate the user. > > So when pushContext is called, you could use serverauthenticationcontext > and the CBH to ask Elytron for a security identity. See [2]. In this last > example, we pass the previously authenticated principal via > EvidenceVerifyCallback. > I think this might work for you. > > [1] https://github.com/pedroigor/keycloak/blob/ > d3e559453b7dcf6f0d9f32c5a9a7f8c49403bb3a/adapters/oidc/ > wildfly-elytron/src/main/java/org/keycloak/adapters/elytron/ > KeycloakSecurityRealm.java#L83 > [2] https://github.com/pedroigor/keycloak/blob/ > d3dee07956be8d0ac69466ac9367984ab0ea072d/adapters/oidc/ > wildfly-elytron/src/main/java/org/keycloak/adapters/elytron/ > SecurityIdentityUtil.java#L45 > > On Wed, Jun 6, 2018 at 12:30 AM, Jim Ma wrote: > >> On 06/04/2018 09:31 PM, Pedro Igor Silva wrote: >> >> In Keycloak integration we have a specific security realm implementation >> that expects a principal previously authenticated by a keycloak adapter >> (e.g.: using SAML or OIDC) and builds an authorized identity based on it. >> Basically, what this security realm does is populate the authorized >> idenitty with information from tokens. >> >> Later we complete authentication in Elytron and set the token as a >> credential into the identity. It is worth mention that in Keycloak >> integration, the adapter is a Elytron HTTP Authentication Mechanism, so we >> don't deal directly with the security domain but with the callback handler. >> >> Regarding ElytronSecurityDomainContextImpl, is method pushContext called >> after a call to isValid ? If so, the security domain should be set with the >> security identity and you don't even need to keep that ThreadLocal ... >> >> >> Thanks Pedro . Do you think the keycloak Elytron integration code can be >> improved or changed to a common utility to convert the principal to an >> Elytron identity? >> Can you please point me the integration code or some Elytron example >> code snippet to build this authorized identity from a authenticated >> principal ? >> >> >> On Thu, May 31, 2018 at 7:03 AM, Darran Lofthouse < >> darran.lofthouse at redhat.com> wrote: >> >>> Just added Pedro in CC so see if he has any suggestions - this is >>> sounding similar to the problems he would have needed to handle when he >>> added support for KeyCloak integration using the Elytron APIs. >>> >> >>> Although the reported problem we are working on is in the context of >>> access to the token it does currently sound that there is a missing >>> pre-requisite step of tying the authentication to Elytron to we can >>> populate a SecurityIdentity. But this does not sound like the first time >>> we have needed to approach this. >>> >> >>> Regards, >>> Darran Lofthouse. >>> >>> >>> On Thu, 31 May 2018 at 10:54 Jim Ma wrote: >>> >>>> On 05/31/2018 05:37 PM, Darran Lofthouse wrote: >>>> >>>> So the validation is within Apache CXF - is there an end result to this >>>> validation where you have access to everything you need where we could >>>> perform some additional steps? >>>> >>>> >>>> After Apache CXF validation, we can get a LoginContext from CXF's >>>> exchange message : https://github.com/apache/cxf/ >>>> blob/master/core/src/main/java/org/apache/cxf/security/Login >>>> SecurityContext.java >>>> Can we do something to convert it to an Elytron authenticated identity >>>> ? >>>> Or we have to hook/replace something with Elytron in CXF's validation >>>> to make this work ? >>>> >>>> >>>> >>>> On Thu, 31 May 2018 at 10:34 Jim Ma wrote: >>>> >>>>> The saml validation is now Apache CXF's SAML functionality. We can't >>>>> port the CXF's security to rely on >>>>> our Elytron. >>>>> >>>>> On 05/31/2018 05:07 PM, Darran Lofthouse wrote: >>>>> >>>>> It sounds to me then that the place to start is within the SAML >>>>> validation, this is effectively an authentication step so should be ported >>>>> over to an Elytron based authentication - the end result of the >>>>> authentication would then be the required SecurityIdentity to propagate >>>>> from container to container. >>>>> >>>>> >>>>> On Thu, 31 May 2018 at 03:57 Jim Ma wrote: >>>>> >>>>>> On 05/30/2018 09:47 PM, Darran Lofthouse wrote: >>>>>> >>>>>> I am currently gathering together some information regarding how the >>>>>> JCA subsystem handles the requirement of populating a Subject for >>>>>> propagation into a resource adapter, however there is a general question >>>>>> about what is attempting to be achieved here. >>>>>> >>>>>> Once an EJB is secured using WildFly Elytron the associated identity >>>>>> is not accessed as a Subject instead it is accessed a SecurityIdentity the >>>>>> current SecurityIdentity can always be retrieved by calling the current >>>>>> SecurityDomain: - >>>>>> >>>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api- >>>>>> javadoc/org/wildfly/security/auth/server/SecurityDomain.html >>>>>> #getCurrent-- >>>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api- >>>>>> javadoc/org/wildfly/security/auth/server/SecurityDomain.html >>>>>> #getCurrentSecurityIdentity-- >>>>>> >>>>>> The SecurityIdentity has some similarity with the Subject in that >>>>>> amongst other things it also contains a collection of public credentials >>>>>> and a collection of private credentials: - >>>>>> >>>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api- >>>>>> javadoc/org/wildfly/security/auth/server/SecurityIdentity.ht >>>>>> ml#getPublicCredentials-- >>>>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api- >>>>>> javadoc/org/wildfly/security/auth/server/SecurityIdentity.ht >>>>>> ml#getPrivateCredentials-- >>>>>> >>>>>> So I think the very first question is has the SecurityIdentity been >>>>>> correctly populated with any delegated credentials? If not that is going >>>>>> to be a pre-requisite for any follow on steps regardless. >>>>>> >>>>>> Then secondly what is it that is making use of this identity? Why >>>>>> can't it be ported to make use of the Elytron authentication client APIs >>>>>> which amongst other things provide support for delegation from the current >>>>>> identity. >>>>>> >>>>>> >>>>>> If we need to we can look at a conversion to a Subject but we are >>>>>> only doing that where it is really required. >>>>>> >>>>>> >>>>>> We don't have the SecurityIdentity populated, there is only >>>>>> principal and subject created by jbossws/CXF's saml validator. >>>>>> We need to convert the subject/principal to Elytron's >>>>>> SecurityIdentity or something else, then later on EJB subystem with Elytron >>>>>> security can retrieve this authenticated info without check it >>>>>> twice. So we'd like to know how can we convert a subject/principal >>>>>> to Elytron's SecurityIdentity and let Elytron know this is already >>>>>> authenticated and authorized. >>>>>> >>>>>> Thanks, >>>>>> Jim >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> Darran Lofthouse. >>>>>> >>>>>> >>>>>> On Wed, 30 May 2018 at 10:27 Alessio Soldano >>>>>> wrote: >>>>>> >>>>>>> As suggested by Darran, I'm forwarding the message below to the list >>>>>>> on behalf of Jim. >>>>>>> The classes Jim is referring to are at >>>>>>> https://github.com/wildfly/wildfly/tree/master/webservices/s >>>>>>> erver-integration/src/main/java/org/jboss/as/webservices/security >>>>>>> >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: Jim Ma >>>>>>> Date: Wed, May 30, 2018 at 9:03 AM >>>>>>> Subject: Set an authorized identity to EltyronSecurity Context >>>>>>> To: Darran Lofthouse >>>>>>> Cc: Alessio Soldano >>>>>>> >>>>>>> >>>>>>> Hi Darran, >>>>>>> >>>>>>> We are helping look at a customer issue which requires propagate the >>>>>>> authenticated subject from webservice subsystem to >>>>>>> >>>>>>> ejb subystem. With old security domain , we can do this with >>>>>>> creating a subject : >>>>>>> >>>>>>> @Override >>>>>>> public void pushSubjectContext(final Subject subject, final >>>>>>> Principal principal, final Object credential) { >>>>>>> AccessController.doPrivileged(new PrivilegedAction() { >>>>>>> >>>>>>> public Void run() { >>>>>>> SecurityContext securityContext = >>>>>>> SecurityContextAssociation.getSecurityContext(); >>>>>>> if (securityContext == null) { >>>>>>> securityContext = createSecurityContext(getSecur >>>>>>> ityDomain()); >>>>>>> setSecurityContextOnAssociation(securityContext); >>>>>>> } >>>>>>> securityContext.getUtil().createSubjectInfo(principal, credential, >>>>>>> subject); >>>>>>> return null; >>>>>>> } >>>>>>> }); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> After Elytron, what is the equivalent thing to do this then ejb >>>>>>> can retrieve this security without check this twice ? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jim >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Alessio Soldano >>>>>>> >>>>>>> Associate Manager >>>>>>> >>>>>>> Red Hat >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180607/17739979/attachment-0001.html From alexey.loubyansky at redhat.com Thu Jun 7 08:18:17 2018 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Thu, 7 Jun 2018 14:18:17 +0200 Subject: [wildfly-dev] Patching generation facility broken with WildFly 13? In-Reply-To: References: Message-ID: Hi Guillaume, great, here is the release https://github.com/jbossas/patch-gen/releases/tag/2.0.1.Final Thanks, Alexey On Thu, Jun 7, 2018 at 1:13 PM, Guillaume Smet wrote: > Hi Alexey, > > On Wed, Jun 6, 2018 at 4:41 PM Alexey Loubyansky < > alexey.loubyansky at redhat.com> wrote: > >> I was able to build your branch with your last commit and w/o it. If that >> works for you, please let me know, I'll make a release with the fix. >> > > I confirm it now works like a charm: I can build my patches for WF 12 and > 13. Thanks for the quick fix. > > Looking forward to the release. > > Thanks! > > -- > Guillaume > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180607/dad5ff0c/attachment.html From jmesnil at redhat.com Thu Jun 7 09:41:18 2018 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 7 Jun 2018 15:41:18 +0200 Subject: [wildfly-dev] WildScribe updated for WildFly 13 Message-ID: Hi, Just a note that https://wildscribe.github.io has been updated with WildFly 13.0 Model reference. We have also added links to reference directly attributes or operations. So next time someone asked you what is the default value for HTTP/2 frame size in Undertow, you can just reply with a link to https://wildscribe.github.io/WildFly/13.0/subsystem/undertow/server/http-listener/index.html#attr-http2-max-frame-size :) These links are stable and can be used in WildFly documentation. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From guillaume at hibernate.org Thu Jun 7 09:41:50 2018 From: guillaume at hibernate.org (Guillaume Smet) Date: Thu, 7 Jun 2018 15:41:50 +0200 Subject: [wildfly-dev] Patching generation facility broken with WildFly 13? In-Reply-To: References: Message-ID: On Thu, Jun 7, 2018 at 2:18 PM Alexey Loubyansky < alexey.loubyansky at redhat.com> wrote: > great, here is the release > https://github.com/jbossas/patch-gen/releases/tag/2.0.1.Final > Thanks a lot Alexey! Will wait for it to show up on Maven Central and will update my build. -- Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180607/74fedd85/attachment.html From jkalina at redhat.com Tue Jun 12 03:43:47 2018 From: jkalina at redhat.com (Jan Kalina) Date: Tue, 12 Jun 2018 09:43:47 +0200 Subject: [wildfly-dev] How to define dependency between two app1.ear & app1.ear in wildfly 9.0.2 In-Reply-To: <1528194412029-0.post@n5.nabble.com> References: <1528194412029-0.post@n5.nabble.com> Message-ID: Check https://developer.jboss.org/thread/176211 ;) In theory it should be: Use export=true to ensure the dependency will be available to subdeployments of the EAR. Otherwise, you can assign dependencies to individual subdeployments too: For example, if you have myweb.war subdeployment in app1.ear: On Tue, Jun 5, 2018 at 12:26 PM, wildflyuser wrote: > In my wildfly 9.0.2, i have deployed two ear(app1.ear & app2.ear) > in app1.ear / META-INF/jboss-deployment-structure.xml how i can define to > have dependency of app2.ear/modules.war/WEB-INF/lib > > > > -- > Sent from: http://wildfly-development.1055759.n5.nabble.com/ > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jkalina at redhat.com Tue Jun 12 04:18:04 2018 From: jkalina at redhat.com (Jan Kalina) Date: Tue, 12 Jun 2018 10:18:04 +0200 Subject: [wildfly-dev] Is there any change in module concepts between jboss and wildfly In-Reply-To: <1527585115777-0.post@n5.nabble.com> References: <1527585115777-0.post@n5.nabble.com> Message-ID: Hi, the difference (and meaning of modules/system/layers/base) you are looking for is called layered distribution. You can find more info here: https://developer.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization If you have custom modules in your jboss modules directory, feel free to keep it in the same structure, directly in modules, in wildfly. But if you put all modules from jboss to wildfly, the resulting AS will not be wildfly - most of the functionality will be superseded by old jboss modules - there will be a lot of incompatibility between some jboss and wildfly modules too, so no, this will not make the upgrade easier. On Tue, May 29, 2018 at 11:11 AM, wildflyuser wrote: > 1) Is there any change in module concepts between jboss and wildfly ? > 2) In jobss we have folder as /modules in wildfly > modules/system/layers/base. Is there any difference ? > 3) As part of upgrade if we reuse/copy folder from /modules to > modules/ > so that my deployed application should consider only modules from > modules/ and it should not consider > modules/system/layers/base > Which will make the upgrade easier to proceed step by step. > > > > -- > Sent from: http://wildfly-development.1055759.n5.nabble.com/ > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From thofman at redhat.com Tue Jun 12 09:58:00 2018 From: thofman at redhat.com (Tomas Hofman) Date: Tue, 12 Jun 2018 15:58:00 +0200 Subject: [wildfly-dev] Taglibs - correct location of TLD files packaged in JARs Message-ID: <8aa45934-7cb4-2529-1c89-46451c09a6f4@redhat.com> Hi folks, we have an issue [0] where a web app with JAR packaged taglib is migrated from Tomcat to Wildfly/EAP and the two servers are resolving tablib location differently. The taglib file in the JAR is located in META-INF/resources/WEB-INF/tlds/hi.tld. It's added to the taglib map explicitly via element in web-fragment.xml (in the same JAR): /HiTag /WEB-INF/tlds/hi.tld This works in Tomcat, which takes *META-INF/resources/* as the root for resolving , and doesn't work in Wildfly, which takes *META-INF/* as the root. The functionality is described by JSP SPEC section 7.3 (I don't want to quote any parts here, because I would have to quote all of it) [1]. After going through it I think our interpretation is the correct one, though Apache think the contrary [2]. However, would it hurt if we added META-INF/resources/ as another root to allow both options? [0] The issue: https://issues.jboss.org/browse/JBEAP-14757 [1] JSP spec: http://download.oracle.com/otndocs/jcp/jsp-2_3-mrel2-eval-spec/ [2] I wrote to Apache mailing list and Jeremy Boynes replied: """ Here?s how I read the spec. JSP 7.3.3 talks about a ?taglib map? using elements in the deployment descriptor per your example. Per JSP 7.3.2 the URI is mapped to a context relative path interpreted relative to the root of the web application. Resources contained in a web fragment jar are located in its /META-INF/resources directory. Tomcat/Jasper are synthesizing the effective web application from the resources in the fragments, then resolving the URI in the taglib map against that merged application. I think that?s a correct interpretation of the spec. JSP 7.3.1 refers to implicit map entries found by scanning the web application?s jars from WEB-INF/lib. """ http://mail-archives.apache.org/mod_mbox/tomcat-taglibs-user/201805.mbox/%3C4E3C404C-1D9F-4292-BE77-C443C3C61671%40apache.org%3E -- Tomas Hofman Software Engineer, JBoss SET Red Hat From thofman at redhat.com Tue Jun 12 10:17:52 2018 From: thofman at redhat.com (Tomas Hofman) Date: Tue, 12 Jun 2018 16:17:52 +0200 Subject: [wildfly-dev] Taglibs - correct location of TLD files packaged in JARs In-Reply-To: References: <8aa45934-7cb4-2529-1c89-46451c09a6f4@redhat.com> <3f96bf62-d4f1-86a9-9673-551981cf8bb0@redhat.com> Message-ID: <9c463b1b-07bd-ae57-88e6-25e8a3214dfa@redhat.com> Adding back the list... So unless anyone posts any objections I will prepare a PR to that effect. Thanks! On 12/06/18 16:12, Remy Maucherat wrote: > On Tue, Jun 12, 2018 at 4:06 PM, Tomas Hofman > wrote: > > Hello Remy, > > just to explain, Jean Clere mentioned you might have an opinion on this, > which is why I included you directly. Feel free to ignore this if you think > this is more for other people. > > > Right now I think this is a grey area, and both ways sound reasonably > legitimate until there's a real clarification. > > R?my > > > Tomas > > > On 12/06/18 15:58, Tomas Hofman wrote: > > Hi folks, > > we have an issue [0] where a web app with JAR packaged taglib is > migrated from > Tomcat to Wildfly/EAP and the two servers are resolving tablib location > differently. > > The taglib file in the JAR is located in > META-INF/resources/WEB-INF/tlds/hi.tld. > > It's added to the taglib map explicitly via element in > web-fragment.xml (in the same JAR): > > ? ? ? ? ? > ? ? ? ? ? ? ? /HiTag > ? ? ? ? ? ? ? /WEB-INF/tlds/hi.tld > ? ? ? ? ? > > This works in Tomcat, which takes *META-INF/resources/* as the root for > resolving , and doesn't work in Wildfly, which takes > *META-INF/* as the root. > > The functionality is described by JSP SPEC section 7.3 (I don't want to > quote > any parts here, because I would have to quote all of it) [1]. After going > through it I think our interpretation is the correct one, though Apache > think > the contrary [2]. > > However, would it hurt if we added META-INF/resources/ as another root > to allow > both options? > > > [0] The issue: https://issues.jboss.org/browse/JBEAP-14757 > > [1] JSP spec: > http://download.oracle.com/otndocs/jcp/jsp-2_3-mrel2-eval-spec/ > > [2] I wrote to Apache mailing list and Jeremy Boynes replied: > > """ > Here?s how I read the spec. > > JSP 7.3.3 talks about a ?taglib map? using elements in the deployment > descriptor per your example. Per JSP 7.3.2 the URI is mapped to a context > relative path interpreted relative to the root of the web application. > Resources contained in a web fragment jar are located in its > /META-INF/resources directory. Tomcat/Jasper are synthesizing the > effective web > application from the resources in the fragments, then resolving the URI > in the > taglib map against that merged application. I think that?s a correct > interpretation of the spec. > > JSP 7.3.1 refers to implicit map entries found by scanning the web > application?s jars from WEB-INF/lib. > """ > > http://mail-archives.apache.org/mod_mbox/tomcat-taglibs-user/201805.mbox/%3C4E3C404C-1D9F-4292-BE77-C443C3C61671%40apache.org%3E > > > > > -- > Tomas Hofman > Software Engineer, JBoss SET > Red Hat > > -- Tomas Hofman Software Engineer, JBoss SET Red Hat From kkhan at redhat.com Fri Jun 15 10:25:33 2018 From: kkhan at redhat.com (Kabir Khan) Date: Fri, 15 Jun 2018 16:25:33 +0200 Subject: [wildfly-dev] Community Docs section in wildfly-proposals Message-ID: <6F7C5D6D-1A50-49F5-974A-3D7719487DAC@redhat.com> For those of you with open PRs in [1], please include a short section on community documentation as introduced in the template [2]. Thanks! [1] https://github.com/wildfly/wildfly-proposals [2] https://github.com/wildfly/wildfly-proposals/pull/81/files#diff-7da34e067ffc8fd7bc75ec52ef6fc26bR48 From ehugonne at redhat.com Mon Jun 18 09:47:24 2018 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Mon, 18 Jun 2018 15:47:24 +0200 Subject: [wildfly-dev] WFCORE-3932: Reactivating the model diff operation between 2 standalone instances Message-ID: <7d6d5468-f939-f9ba-3a3c-86177433f471@redhat.com> Hello, A while back we discussed the usage of Galleon to update a manually configured provisioned instance [1]. Now that Galleon is out I'd like to bring the subject to the table again. I 've written a proposal [2] to add the required operations to wildfly-core so that we could synchronize or export the model differences between 2 standalone instances. I've further developed the idea by exporting those changes alongside the file system changes in a Galleon feature-pack allowing the provisioning of the same instance without Galleon knowledge. I'd like to get some feedback along that idea to try to have it in WF14. Cheers, Emmanuel [1]: http://lists.jboss.org/pipermail/wildfly-dev/2017-September/006073.html [2]: https://github.com/wildfly/wildfly-proposals/pull/88 [3]: https://issues.jboss.org/browse/WFCORE-3932 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180618/d020e4e7/attachment.bin From kkhan at redhat.com Tue Jun 19 06:55:25 2018 From: kkhan at redhat.com (Kabir Khan) Date: Tue, 19 Jun 2018 11:55:25 +0100 Subject: [wildfly-dev] Community Docs section in wildfly-proposals Message-ID: <8B3D4B6B-ABFF-4BD1-AFC1-5B48E4CE78D9@redhat.com> If you have an open PR for a proposal, can you please add in the Community Documentation section that I have just added to the template (See the end of [1]). Basically just indicate where the documentation for a feature will live: == Community Documentation //// Generally a feature should have documentation as part of the PR to wildfly master, or as a follow up PR if the feature is in wildfly-core. In some cases though the documentation belongs more in a component, or does not need any documentation. Indicate which of these will happen. //// I have added that section because I find myself asking over and over again on RFEs where the feature documentation is. Often people say it is not needed as it is something trivial, but that could do with a bit more visibility. Thanks, Kabir [1] https://raw.githubusercontent.com/wildfly/wildfly-proposals/master/design-doc-template.adoc From yborgess at redhat.com Tue Jun 19 09:45:19 2018 From: yborgess at redhat.com (Yeray Borges) Date: Tue, 19 Jun 2018 14:45:19 +0100 Subject: [wildfly-dev] Security subsystem and its security-domain definitions in the servlet-distribution Message-ID: <69092f00-e2cf-f65e-8dbe-25cb63c1e937@redhat.com> Hello everyone, I'm doing a comparison between the different server configuration files generated in normal distribution and servlet-distribution, basically working on [1]. The security subsystem in the servlet distribution does not have these security domains configured whereas they are in the normal distribution: ??? ?????????? ... ??? ??? ??? ??? ??????? ??? ??? ??? ??? ??? ??? ??? ??????? ??? ??? ??? ??? ??? ??? ??? ??????? ??? ??????????? ??? ??????? ??? ??????? ??? ??? ??? I understand jboss-ejb-policy should not be configured because the servlet-distribution does not use ejbs, but what about jaspitest? I have no clue if it has to be included or not in the servlet-distribution. Do you know if we should include it? Regards, Yeray [1] https://issues.jboss.org/browse/WFLY-10421 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180619/a57834f2/attachment.html From elayaraja.s at gmail.com Wed Jun 20 07:30:43 2018 From: elayaraja.s at gmail.com (wildflyuser) Date: Wed, 20 Jun 2018 04:30:43 -0700 (MST) Subject: [wildfly-dev] Injection of persistence dependencies failed; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'jcsqlpu' is defined Message-ID: <1529494243892-0.post@n5.nabble.com> Upgade from jboss-as-7.1.1.Final to wildfly-9.0.2.Final we are facing below issue Caused by: java.lang.RuntimeException: org.springframework.beans.factory.access.BootstrapException: Unable to initialize group definition. Group resource name [classpath*:beanRefContext.xml], factory key [ear.context]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ear.context' defined in URL [vfs:/d01/wildfly-9.0.2.Final/standalone/deployments/app.ear/lib/advanced-api.jar/beanRefContext.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.springframework.context.support.ClassPathXmlApplicationContext]: Constructor threw exception; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'importResourceController': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.jamcracker.iaascommon.repository.ResourceTypeRepository com.jamcracker.importresources.controller.ImportResourceControler.resourceTypeRepository; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'defaultResourceTypeRepository': Injection of persistence dependencies failed; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'jcsqlpu' is defined Related cause: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.beans.factory.config.MethodInvokingFactoryBean#12' defined in "/d01/wildfly-9.0.2.Final/standalone/deployments/app.ear/lib/coreservice-serviceImpl-1.18-SNAPSHOT.jar/spring-context/coreservice-service-context.xml": Invocation of init method failed; nested exception is java.lang.IllegalStateException: Singleton instance not initialized yet Related cause: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.beans.factory.config.MethodInvokingFactoryBean#12' defined in "/d01/wildfly-9.0.2.Final/standalone/deployments/app.ear/lib/coreservice-serviceImpl-1.18-SNAPSHOT.jar/spring-context/coreservice-service-context.xml": Invocation of init method failed; nested exception is java.lang.IllegalStateException: Singleton instance not initialized yet Related cause: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.beans.factory.config.MethodInvokingFactoryBean#12' in persistence.xml, i have proper entry, nost sure its working in jboss-as-7.1.1.Final but not working in wildfly-9.0.2.Final org.hibernate.ejb.HibernatePersistence ------------------ ---------------------- ------------------- -- Sent from: http://wildfly-development.1055759.n5.nabble.com/ From elayaraja.s at gmail.com Thu Jun 21 01:43:02 2018 From: elayaraja.s at gmail.com (wildflyuser) Date: Wed, 20 Jun 2018 22:43:02 -0700 (MST) Subject: [wildfly-dev] java.net.SocketTimeoutException: connect timed out: .do not redirecting to my Action class. Message-ID: <1529559782738-0.post@n5.nabble.com> java.net.SocketTimeoutException: connect timed out 19/06/2018 11:33:55,503 ERROR [com.company.util.struts.JCActionServlet] HTML Parsing exception: : javax.servlet.ServletException: JBWEB004036: File "/superadmin/forwardToSuperAdminHome.do" not found at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:306) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) [jastow-1.1.1.Final.jar:1.1.1.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:198) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:195) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:108) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1069) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:274) [struts-1.1.jar:1.1] at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:455) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:320) [struts-1.1.jar:1.1] at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279) [struts-1.1.jar:1.1] at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) [struts-1.1.jar:1.1] at com.company.util.struts.JCActionServlet.process(JCActionServlet.java:105) [classes:] at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) [struts-1.1.jar:1.1] at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:208) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.includeImpl(RequestDispatcherImpl.java:345) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:258) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:940) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:610) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.struts.tiles.TilesUtilImpl.doInclude(TilesUtilImpl.java:137) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesUtil.doInclude(TilesUtil.java:177) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag.doInclude(InsertTag.java:756) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag$InsertHandler.doEndTag(InsertTag.java:881) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag.doEndTag(InsertTag.java:473) [struts-1.1.jar:1.1] at org.apache.jsp.web.tiles.layouts.pagebasenobreadnoline_jsp._jspx_meth_tiles_005fget_005f1(pagebasenobreadnoline_jsp.java:13037) at org.apache.jsp.web.tiles.layouts.pagebasenobreadnoline_jsp._jspService(pagebasenobreadnoline_jsp.java:1693) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) [jastow-1.1.1.Final.jar:1.1.1.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:208) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.includeImpl(RequestDispatcherImpl.java:345) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:258) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:940) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:610) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.struts.tiles.TilesUtilImpl.doInclude(TilesUtilImpl.java:137) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesUtil.doInclude(TilesUtil.java:177) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag.doInclude(InsertTag.java:756) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag$InsertHandler.doEndTag(InsertTag.java:881) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag.doEndTag(InsertTag.java:473) [struts-1.1.jar:1.1] at org.apache.jsp.web.tiles.layouts.base_jsp._jspx_meth_tiles_005fget_005f2(base_jsp.java:322) at org.apache.jsp.web.tiles.layouts.base_jsp._jspService(base_jsp.java:199) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) [jastow-1.1.1.Final.jar:1.1.1.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:208) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.includeImpl(RequestDispatcherImpl.java:345) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:258) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:940) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:610) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.struts.tiles.TilesUtilImpl.doInclude(TilesUtilImpl.java:137) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesUtil.doInclude(TilesUtil.java:177) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag.doInclude(InsertTag.java:756) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag$InsertHandler.doEndTag(InsertTag.java:881) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag.doEndTag(InsertTag.java:473) [struts-1.1.jar:1.1] at org.apache.jsp.superadmin.pages.view_jsp._jspService(view_jsp.java:67) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) [jastow-1.1.1.Final.jar:1.1.1.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:198) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:195) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:108) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1069) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:274) [struts-1.1.jar:1.1] at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:455) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:320) [struts-1.1.jar:1.1] at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279) [struts-1.1.jar:1.1] at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) [struts-1.1.jar:1.1] at com.company.util.struts.JCActionServlet.process(JCActionServlet.java:105) [classes:] at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) [struts-1.1.jar:1.1] at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at com.company.jsdn.security.servlets.JSDNCacheFilter.doFilter(JSDNCacheFilter.java:122) [classes:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at com.company.jsdn.security.servlets.EAccessFilter.doFilter(EAccessFilter.java:170) [classes:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at com.company.globalization.GlobalizationFilter.doFilter(GlobalizationFilter.java:214) [classes:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at com.company.globalfilters.servlet.SessionFilter.doFilter(SessionFilter.java:94) [jccore-1.62.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] -- Sent from: http://wildfly-development.1055759.n5.nabble.com/ From darran.lofthouse at redhat.com Thu Jun 21 05:15:36 2018 From: darran.lofthouse at redhat.com (Darran Lofthouse) Date: Thu, 21 Jun 2018 10:15:36 +0100 Subject: [wildfly-dev] Notifications / Plans Around Upcoming WildFly Core Tags Message-ID: Hello, Would it be possible to try and get some notifications or routine around the WildFly Core tags so that teams that feed into WildFly Core can coordinate around these? The WildFly Core tags are the only way we can get our code changes into WildFly. We have a few in progress RFEs that we are trying to coordinate merging and tagging in conjunction with the remainder of the process. At the same time I see Alpha2 has just been tagged - had I known there was an upcoming Alpha I may have tried to set our dates around it to hit it. Even if we don't have RFEs ready to merge if I know there is an imminent tag, if we have a number of bug fixes merged to our repo I may create a new tag so we can get our fixes into WildFly. Regards, Darran Lofthouse. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180621/a849d209/attachment.html From jmesnil at redhat.com Thu Jun 21 05:42:57 2018 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 21 Jun 2018 11:42:57 +0200 Subject: [wildfly-dev] Notifications / Plans Around Upcoming WildFly Core Tags In-Reply-To: References: Message-ID: Hi Darran, > On 21 Jun 2018, at 11:15, Darran Lofthouse wrote: > Would it be possible to try and get some notifications or routine around the WildFly Core tags so that teams that feed into WildFly Core can coordinate around these? I have been working towards that goal. The idea is to have time-boxed releases of WildFly Core (either every 2 or 3 weeks) that are integrated in WildFly codebase. I?m still figuring out the automation of that process[1] so that doing core releases is less time consuming (hence the Alpha2 to check that the automation is fine) I am working on a document that will give all interested users (and component leads) the information about the planned schedule for WildFly Core. I also plan to send reminders to wildfly-dev before each important releases (Beta, CR, Final). These releases will be driven to some extent by WildFly own release schedule and may be in addition to the predictable time-boxed releases Regarding the coordination of merging PRs, I?ll need some help from the PR authors. If you think several PRs needs to be merged within a single Core release, please make it clear in the PR description. In that case, we?ll hold until all PRs are ready-to-be-merged and do that in a single step. For PRs that adds new features, we have some other external requirements (documentation, QE approval) that may delay the merge. This has to be taken into account if several RFE PR must be delivered within a single Core release. @darran, does that address your concern? jeff [1] https://github.com/jmesnil/wildfly-core-release/wiki/WildFly-Core-Release-Process -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From darran.lofthouse at redhat.com Thu Jun 21 05:53:58 2018 From: darran.lofthouse at redhat.com (Darran Lofthouse) Date: Thu, 21 Jun 2018 10:53:58 +0100 Subject: [wildfly-dev] Notifications / Plans Around Upcoming WildFly Core Tags In-Reply-To: References: Message-ID: On Thu, 21 Jun 2018 at 10:43 Jeff Mesnil wrote: > Hi Darran, > > > On 21 Jun 2018, at 11:15, Darran Lofthouse > wrote: > > Would it be possible to try and get some notifications or routine around > the WildFly Core tags so that teams that feed into WildFly Core can > coordinate around these? > > I have been working towards that goal. > The idea is to have time-boxed releases of WildFly Core (either every 2 or > 3 weeks) that are integrated in WildFly codebase. > I?m still figuring out the automation of that process[1] so that doing > core releases is less time consuming (hence the Alpha2 to check that the > automation is fine) > That sounds great, we have a number of engineers working concurrently on security - if we know where the timeboxing of core is going to hit we can also define our own timebox. I am working on a document that will give all interested users (and > component leads) the information about the planned schedule for WildFly > Core. > > I also plan to send reminders to wildfly-dev before each important > releases (Beta, CR, Final). > These releases will be driven to some extent by WildFly own release > schedule and may be in addition to the predictable time-boxed releases > > Regarding the coordination of merging PRs, I?ll need some help from the PR > authors. If you think several PRs needs to be merged within a single Core > release, please make it clear in the PR description. > In that case, we?ll hold until all PRs are ready-to-be-merged and do that > in a single step. > For PRs that adds new features, we have some other external requirements > (documentation, QE approval) that > may delay the merge. This has to be taken into account if several RFE PR > must be delivered within a single > Core release. > Yeah this is the issue I am also trying to work with here, but I also have changes going into Elytron that I can not merge until I know the complete chain has passed otherwise even the component upgrade will not be mergable. Where we have a set mergable PRs as a single until once all code review. QE review etc.. is complete I wonder if it will be easier for me to combine the component upgrade and individual PRs into one PR so we can test it as a single unit. Some of the core PRs will depend on the component update anyway and then I may be able to use the staging repo testing we talked about previously. > > @darran, does that address your concern? > > jeff > > > [1] > https://github.com/jmesnil/wildfly-core-release/wiki/WildFly-Core-Release-Process > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180621/72e93d9e/attachment.html From elayaraja.s at gmail.com Fri Jun 22 01:39:00 2018 From: elayaraja.s at gmail.com (wildflyuser) Date: Thu, 21 Jun 2018 22:39:00 -0700 (MST) Subject: [wildfly-dev] upgrade jboss-as-7.1.1.Final to wildfly-9.0.2.Final: action to tiles and *.do its not working Message-ID: <1529645940140-0.post@n5.nabble.com> We are upgading from jboss-as-7.1.1.Final to wildfly-9.0.2.Final Is there any change in undertow-servlet in wildfly-9.0.2.Final ? When we access the action with *.do its working, but same when we try from action to tiles and *.do its not working. >From action to action is not working, plesae find the below log ERROR [com.company.util.struts.JCActionServlet] HTML Parsing exception: : javax.servlet.ServletException: JBWEB004036: File "/superadmin/forwardToSuperAdminHome.do" not found at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:306) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) [jastow-1.1.1.Final.jar:1.1.1.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:198) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:195) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:108) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1069) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:274) [struts-1.1.jar:1.1] at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:455) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:320) [struts-1.1.jar:1.1] at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279) [struts-1.1.jar:1.1] at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) [struts-1.1.jar:1.1] at com.company.util.struts.JCActionServlet.process(JCActionServlet.java:105) [classes:] at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) [struts-1.1.jar:1.1] at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:208) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.includeImpl(RequestDispatcherImpl.java:345) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:258) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:940) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:610) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.struts.tiles.TilesUtilImpl.doInclude(TilesUtilImpl.java:137) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesUtil.doInclude(TilesUtil.java:177) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag.doInclude(InsertTag.java:756) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag$InsertHandler.doEndTag(InsertTag.java:881) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag.doEndTag(InsertTag.java:473) [struts-1.1.jar:1.1] at org.apache.jsp.web.tiles.layouts.pagebasenobreadnoline_jsp._jspx_meth_tiles_005fget_005f1(pagebasenobreadnoline_jsp.java:15954) at org.apache.jsp.web.tiles.layouts.pagebasenobreadnoline_jsp._jspService(pagebasenobreadnoline_jsp.java:4566) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) [jastow-1.1.1.Final.jar:1.1.1.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:208) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.includeImpl(RequestDispatcherImpl.java:345) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:258) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:940) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:610) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.struts.tiles.TilesUtilImpl.doInclude(TilesUtilImpl.java:137) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesUtil.doInclude(TilesUtil.java:177) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag.doInclude(InsertTag.java:756) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag$InsertHandler.doEndTag(InsertTag.java:881) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag.doEndTag(InsertTag.java:473) [struts-1.1.jar:1.1] at org.apache.jsp.web.tiles.layouts.base_jsp._jspx_meth_tiles_005fget_005f2(base_jsp.java:403) at org.apache.jsp.web.tiles.layouts.base_jsp._jspService(base_jsp.java:277) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) [jastow-1.1.1.Final.jar:1.1.1.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:208) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.includeImpl(RequestDispatcherImpl.java:345) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:258) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:940) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:610) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.struts.tiles.TilesUtilImpl.doInclude(TilesUtilImpl.java:137) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesUtil.doInclude(TilesUtil.java:177) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag.doInclude(InsertTag.java:756) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag$InsertHandler.doEndTag(InsertTag.java:881) [struts-1.1.jar:1.1] at org.apache.struts.taglib.tiles.InsertTag.doEndTag(InsertTag.java:473) [struts-1.1.jar:1.1] at org.apache.jsp.superadmin.pages.view_jsp._jspService(view_jsp.java:73) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.1.1.Final.jar:1.1.1.Final] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.1.1.Final.jar:1.1.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) [jastow-1.1.1.Final.jar:1.1.1.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:198) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:195) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:108) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1069) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:274) [struts-1.1.jar:1.1] at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:455) [struts-1.1.jar:1.1] at org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:320) [struts-1.1.jar:1.1] at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279) [struts-1.1.jar:1.1] at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) [struts-1.1.jar:1.1] at com.company.util.struts.JCActionServlet.process(JCActionServlet.java:105) [classes:] at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) [struts-1.1.jar:1.1] at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at com.company.jsdn.security.servlets.JSDNCacheFilter.doFilter(JSDNCacheFilter.java:122) [classes:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at com.company.jsdn.security.servlets.EAccessFilter.doFilter(EAccessFilter.java:170) [classes:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at com.company.globalization.GlobalizationFilter.doFilter(GlobalizationFilter.java:202) [classes:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at com.company.globalfilters.servlet.SessionFilter.doFilter(SessionFilter.java:94) [jccore-1.62.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) [undertow-core-1.2.9.Final.jar:1.2.9.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72] -- Sent from: http://wildfly-development.1055759.n5.nabble.com/ From arjan.tijms at gmail.com Fri Jun 22 03:15:02 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 22 Jun 2018 09:15:02 +0200 Subject: [wildfly-dev] Security subsystem and its security-domain definitions in the servlet-distribution In-Reply-To: <69092f00-e2cf-f65e-8dbe-25cb63c1e937@redhat.com> References: <69092f00-e2cf-f65e-8dbe-25cb63c1e937@redhat.com> Message-ID: Hi, The jaspitest domain is to allow a (servlet) application to "activate" JASPIC and install JASPIC authentication modules without having to modify the server distribution. For almost as long as JBoss supports JASPIC the promise has been that such explicit activation would some time in the future not be needed anymore. Initially the promise was that with Undertow this would be fixed, but when it wasn't Elytron would address it. Now that Elytron is there I'm not sure if it's indeed finally not needed anymore. Darran Lofthouse should be the one who knows. If Elytron still requires the manual "activation" of JASPIC, then the jaspitest domain is likely needed. Both Tomcat and Jetty also support (the Servlet Container Profile of) JASPIC. Kind regards, Arjan On Tue, Jun 19, 2018 at 3:54 PM Yeray Borges wrote: > Hello everyone, > > I'm doing a comparison between the different server configuration files > generated in normal distribution and servlet-distribution, basically > working on [1]. > > The security subsystem in the servlet distribution does not have these > security domains configured whereas they are in the normal distribution: > > > > ... > > > > > > > > > > > > > > > > > > > > > I understand jboss-ejb-policy should not be configured because the > servlet-distribution does not use ejbs, but what about jaspitest? > I have no clue if it has to be included or not in the > servlet-distribution. > > Do you know if we should include it? > > Regards, > Yeray > > [1] https://issues.jboss.org/browse/WFLY-10421 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180622/92d7c87e/attachment.html From elayaraja.s at gmail.com Mon Jun 25 20:28:41 2018 From: elayaraja.s at gmail.com (wildflyuser) Date: Mon, 25 Jun 2018 17:28:41 -0700 (MST) Subject: [wildfly-dev] upgrade jboss-as-7.1.1.Final to wildfly-9.0.2.Final: action to tiles and *.do its not working In-Reply-To: <1529645940140-0.post@n5.nabble.com> References: <1529645940140-0.post@n5.nabble.com> Message-ID: <1529972921105-0.post@n5.nabble.com> while calling tiles after adding redirect="true" it works ? Not sure we have alternate solutions ? -- Sent from: http://wildfly-development.1055759.n5.nabble.com/ From jperkins at redhat.com Tue Jun 26 12:20:37 2018 From: jperkins at redhat.com (James Perkins) Date: Tue, 26 Jun 2018 09:20:37 -0700 Subject: [wildfly-dev] upgrade jboss-as-7.1.1.Final to wildfly-9.0.2.Final: action to tiles and *.do its not working In-Reply-To: <1529972921105-0.post@n5.nabble.com> References: <1529645940140-0.post@n5.nabble.com> <1529972921105-0.post@n5.nabble.com> Message-ID: This list is meant for developing WildFly. For questions about WildFly it's best to use the forums https://developer.jboss.org/en/wildfly. On Mon, Jun 25, 2018 at 5:40 PM wildflyuser wrote: > while calling tiles after adding redirect="true" it works ? Not sure we > have > alternate solutions ? > > > > -- > Sent from: http://wildfly-development.1055759.n5.nabble.com/ > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180626/b0e127ff/attachment.html