February 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry

by Cody Lerum (Jira)

[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ] Cody Lerum commented on WFLY-9529: ---------------------------------- Just hit this again trying to use {code} @Resource private TransactionSynchronizationRegistry transactionSynchronizationRegistry; {code} >From within a CDI bean that is in a ManagedExectuorTask The MES starts creates and tears down a Request context like {code} try { context = CDI.current().select(BoundRequestContext.class).get(); context.associate(storage); context.activate(); //Do some work } finally { if (context != null) { context.invalidate(); context.deactivate(); context.dissociate(storage); } {code} Is there something special I need to do to hook the MES into the the Transaction Registry? > Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9529 > URL: https://issues.jboss.org/browse/WFLY-9529 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JMS, Naming > Affects Versions: 14.0.1.Final, 10.1.0.Final, 11.0.0.Final, 12.0.0.Final, 13.0.0.Final > Environment: Running on Windows 10, Java 64-bit 1.8.0_131 > Reporter: Scott Van Wart > Assignee: Eduardo Martins > Priority: Major > Labels: ActiveMQ, jms, transaction > Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt > > > If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread. > My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions. > I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11756) AcmeResourceHandler should avoid per-request object allocations

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-11756: --------------------------------------- Summary: AcmeResourceHandler should avoid per-request object allocations Key: WFLY-11756 URL: https://issues.jboss.org/browse/WFLY-11756 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Brian Stansberry Assignee: Brian Stansberry AcmeResourceHandler is using String.matches(String) to check if it needs to handle a request, which results in per-request allocations. At minimum this should use a precompile Pattern. That still results in per-request allocation of a Matcher though. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-45) Bring the dependency versions in-line with WildFly Core

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELYWEB-45?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELYWEB-45: ----------------------------- Summary: Bring the dependency versions in-line with WildFly Core (was: Upgrade WildFly Elytron to 1.8.0.Final) > Bring the dependency versions in-line with WildFly Core > ------------------------------------------------------- > > Key: ELYWEB-45 > URL: https://issues.jboss.org/browse/ELYWEB-45 > Project: Elytron Web > Issue Type: Component Upgrade > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.4.0.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11755) AcmeResourceHandler should avoid per-request object allocations

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11755?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11755: ------------------------------------ Summary: AcmeResourceHandler should avoid per-request object allocations (was: AcmeResourceHandler should use a precompiled Pattern) > AcmeResourceHandler should avoid per-request object allocations > --------------------------------------------------------------- > > Key: WFLY-11755 > URL: https://issues.jboss.org/browse/WFLY-11755 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > > AcmeResourceHandler is using String.matches(String) to check if it needs to handle a request, which results in per-request allocations. > At minimum this should use a precompile Pattern. That still results in per-request allocation of a Matcher though. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11755) AcmeResourceHandler should use a precompiled Pattern

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-11755: --------------------------------------- Summary: AcmeResourceHandler should use a precompiled Pattern Key: WFLY-11755 URL: https://issues.jboss.org/browse/WFLY-11755 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Brian Stansberry Assignee: Brian Stansberry AcmeResourceHandler is using String.matches(String) to check if it needs to handle a request, which results in per-request allocations. At minimum this should use a precompile Pattern. That still results in per-request allocation of a Matcher though. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11754) Drop camel case that has crept into package names

by Darran Lofthouse (Jira)

Darran Lofthouse created WFLY-11754: --------------------------------------- Summary: Drop camel case that has crept into package names Key: WFLY-11754 URL: https://issues.jboss.org/browse/WFLY-11754 Project: WildFly Issue Type: Task Components: JPA / Hibernate, Test Suite Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 17.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1677) Elytron Bearer Token Authentication - Return a 401 on Invalid Token

by Martin Mazanek (Jira)

[ https://issues.jboss.org/browse/ELY-1677?page=com.atlassian.jira.plugin.s... ] Martin Mazanek updated ELY-1677: -------------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/1244 (was: https://github.com/wildfly-security/wildfly-elytron/pull/1236) > Elytron Bearer Token Authentication - Return a 401 on Invalid Token > ------------------------------------------------------------------- > > Key: ELY-1677 > URL: https://issues.jboss.org/browse/ELY-1677 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Affects Versions: 1.7.0.CR1 > Reporter: Edward Stathopoulos > Assignee: Martin Mazanek > Priority: Major > Fix For: 1.8.0.Final > > > *Issue* > Currently, Elytron will send back a 403 Response when an invalid bearer token is sent. For the built-in JWT validator (the token validation we are using), this [includes a few checks like signature, expiration time, audience and issuer|https://github.com/wildfly-security/wildfly-elytron/blob/1.7.0.CR1...]. > It seems that the current [BearerTokenAuthenticationMechanism|https://github.com/wildfly-security/wi...] does not differentiate between failed authentication and failed authorization, returning a 403 in both cases. This produces conflicting and erroneous results. Did I fail to authenticate (say, expired JWT) or did I authenticate but do not have access to the resource in question? > This would also be closer in line with [RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage)|https://tools.ietf.org/html/rfc6750#section-3] which includes an example of an expired (invalid) token. > {quote} > And in response to a protected resource request with an > authentication attempt using an expired access token: > HTTP/1.1 401 Unauthorized > WWW-Authenticate: Bearer realm="example", > error="invalid_token", > error_description="The access token expired" > {quote} > *Potential Solution* > Perhaps this could be ameliorated by something akin to the following change in BearerTokenAuthenticationMechanism::evaluateRequest by differentiating between failure to authorize and failure to authenticate the token. Merely a quick, unvetted example as I haven't had enough time to dig in to the source. > {code} > if (verifyCallback.isVerified()) { > AuthorizeCallback authorizeCallback = new AuthorizeCallback(null, null); > handleCallback(authorizeCallback); > if (authorizeCallback.isAuthorized()) { > httpBearer.debugf("Token authentication successful."); > handleCallback(new IdentityCredentialCallback(new BearerTokenCredential(tokenEvidence.getToken()), true)); > handleCallback(AuthenticationCompleteCallback.SUCCEEDED); > request.authenticationComplete(); > return; > } > else{ > httpBearer.debugf("Token authorization failed message."); > request.authenticationFailed("Some token unauthorized message", response -> response.setStatusCode(FORBIDDEN)); > return; > } > } > httpBearer.debugf("Token authentication failed."); > request.authenticationFailed("Invalid bearer token", response -> response.setStatusCode(UNAUTHORIZED)); > return; > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-46) Elytron Bearer Token Authentication - Return a 401 on Invalid Token test fix

by Martin Mazanek (Jira)

[ https://issues.jboss.org/browse/ELYWEB-46?page=com.atlassian.jira.plugin.... ] Martin Mazanek moved ELY-1759 to ELYWEB-46: ------------------------------------------- Project: Elytron Web (was: WildFly Elytron) Key: ELYWEB-46 (was: ELY-1759) Component/s: (was: Authentication Mechanisms) Affects Version/s: (was: 1.7.0.CR1) Fix Version/s: (was: 1.8.0.Final) > Elytron Bearer Token Authentication - Return a 401 on Invalid Token test fix > ---------------------------------------------------------------------------- > > Key: ELYWEB-46 > URL: https://issues.jboss.org/browse/ELYWEB-46 > Project: Elytron Web > Issue Type: Bug > Reporter: Martin Mazanek > Assignee: Martin Mazanek > Priority: Major > > *Issue* > Currently, Elytron will send back a 403 Response when an invalid bearer token is sent. For the built-in JWT validator (the token validation we are using), this [includes a few checks like signature, expiration time, audience and issuer|https://github.com/wildfly-security/wildfly-elytron/blob/1.7.0.CR1...]. > It seems that the current [BearerTokenAuthenticationMechanism|https://github.com/wildfly-security/wi...] does not differentiate between failed authentication and failed authorization, returning a 403 in both cases. This produces conflicting and erroneous results. Did I fail to authenticate (say, expired JWT) or did I authenticate but do not have access to the resource in question? > This would also be closer in line with [RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage)|https://tools.ietf.org/html/rfc6750#section-3] which includes an example of an expired (invalid) token. > {quote} > And in response to a protected resource request with an > authentication attempt using an expired access token: > HTTP/1.1 401 Unauthorized > WWW-Authenticate: Bearer realm="example", > error="invalid_token", > error_description="The access token expired" > {quote} > *Potential Solution* > Perhaps this could be ameliorated by something akin to the following change in BearerTokenAuthenticationMechanism::evaluateRequest by differentiating between failure to authorize and failure to authenticate the token. Merely a quick, unvetted example as I haven't had enough time to dig in to the source. > {code} > if (verifyCallback.isVerified()) { > AuthorizeCallback authorizeCallback = new AuthorizeCallback(null, null); > handleCallback(authorizeCallback); > if (authorizeCallback.isAuthorized()) { > httpBearer.debugf("Token authentication successful."); > handleCallback(new IdentityCredentialCallback(new BearerTokenCredential(tokenEvidence.getToken()), true)); > handleCallback(AuthenticationCompleteCallback.SUCCEEDED); > request.authenticationComplete(); > return; > } > else{ > httpBearer.debugf("Token authorization failed message."); > request.authenticationFailed("Some token unauthorized message", response -> response.setStatusCode(FORBIDDEN)); > return; > } > } > httpBearer.debugf("Token authentication failed."); > request.authenticationFailed("Invalid bearer token", response -> response.setStatusCode(UNAUTHORIZED)); > return; > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1759) Elytron Bearer Token Authentication - Return a 401 on Invalid Token test fix

by Martin Mazanek (Jira)

Martin Mazanek created ELY-1759: ----------------------------------- Summary: Elytron Bearer Token Authentication - Return a 401 on Invalid Token test fix Key: ELY-1759 URL: https://issues.jboss.org/browse/ELY-1759 Project: WildFly Elytron Issue Type: Bug Components: Authentication Mechanisms Affects Versions: 1.7.0.CR1 Reporter: Martin Mazanek Assignee: Martin Mazanek Fix For: 1.8.0.Final *Issue* Currently, Elytron will send back a 403 Response when an invalid bearer token is sent. For the built-in JWT validator (the token validation we are using), this [includes a few checks like signature, expiration time, audience and issuer|https://github.com/wildfly-security/wildfly-elytron/blob/1.7.0.CR1...]. It seems that the current [BearerTokenAuthenticationMechanism|https://github.com/wildfly-security/wi...] does not differentiate between failed authentication and failed authorization, returning a 403 in both cases. This produces conflicting and erroneous results. Did I fail to authenticate (say, expired JWT) or did I authenticate but do not have access to the resource in question? This would also be closer in line with [RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage)|https://tools.ietf.org/html/rfc6750#section-3] which includes an example of an expired (invalid) token. {quote} And in response to a protected resource request with an authentication attempt using an expired access token: HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example", error="invalid_token", error_description="The access token expired" {quote} *Potential Solution* Perhaps this could be ameliorated by something akin to the following change in BearerTokenAuthenticationMechanism::evaluateRequest by differentiating between failure to authorize and failure to authenticate the token. Merely a quick, unvetted example as I haven't had enough time to dig in to the source. {code} if (verifyCallback.isVerified()) { AuthorizeCallback authorizeCallback = new AuthorizeCallback(null, null); handleCallback(authorizeCallback); if (authorizeCallback.isAuthorized()) { httpBearer.debugf("Token authentication successful."); handleCallback(new IdentityCredentialCallback(new BearerTokenCredential(tokenEvidence.getToken()), true)); handleCallback(AuthenticationCompleteCallback.SUCCEEDED); request.authenticationComplete(); return; } else{ httpBearer.debugf("Token authorization failed message."); request.authenticationFailed("Some token unauthorized message", response -> response.setStatusCode(FORBIDDEN)); return; } } httpBearer.debugf("Token authentication failed."); request.authenticationFailed("Invalid bearer token", response -> response.setStatusCode(UNAUTHORIZED)); return; {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3672) Wire setup

by Anna Baker (Jira)

[ https://issues.jboss.org/browse/DROOLS-3672?page=com.atlassian.jira.plugi... ] Anna Baker resolved DROOLS-3672. -------------------------------- Resolution: Done > Wire setup > ---------- > > Key: DROOLS-3672 > URL: https://issues.jboss.org/browse/DROOLS-3672 > Project: Drools > Issue Type: Sub-task > Reporter: Anna Baker > Assignee: Anna Baker > Priority: Major > > Wire setup of DuplicateColumnCommand / DuplicateColumnEvent and modify tests -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2019