[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-9529:
---------------------------------------
[~silvaran] No, that was just a simplification of the app, the issue is that on such event, and without a EE component in context, the Java EE standard JNDI contexts are not available, and JMSContext dependency on it makes it fail to work. There are two possible solutions for this, make such contexts (even if limited on resources bound) available, or instead remove usage of JNDI by the injected JMSContext implementation, and while I can code both quickly I'm investigating what is the proper solution (even comparing with other vendor app servers).
By the way, I did not test that but it should work if you pack the app in a war instead of ear.
> 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: JMS, Naming
> Affects Versions: 10.1.0.Final, 11.0.0.Final
> Environment: Running on Windows 10, Java 64-bit 1.8.0_131
> Reporter: Scott Van Wart
> Assignee: Eduardo Martins
> 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.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ]
Scott Van Wart commented on WFLY-9529:
--------------------------------------
[~emmartins] does the startup delay you put in injected-jms2.zip work around this issue? I'm at the point where I'll need to just start using an injected ConnectionFactory and manage my own JMSContext objects. I've noticed that it doesn't happen all the time (but sometimes will happen consistently--as in the original project I attached).
> 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: JMS, Naming
> Affects Versions: 10.1.0.Final, 11.0.0.Final
> Environment: Running on Windows 10, Java 64-bit 1.8.0_131
> Reporter: Scott Van Wart
> Assignee: Eduardo Martins
> 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.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-6464) JPA 2.2 Support
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6464?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-6464:
-------------------------------
Description:
>From JPA 2.2 specification appendix section A.1:
{code}
A.1 Maintenance Release Draft
Created document from Java Persistence 2.1 Final Release specification.
The following annotations have been marked @Repeatable:
AssociationOverride
AttributeOverride
Convert
JoinColumn
MapKeyJoinColumn
NamedEntityGraph
NamedNativeQuery
NamedQuery
NamedStoredProcedureQuery
PersistenceContext
PersistenceUnit
PrimaryKeyJoinColumn
SecondaryTable
SqlResultSetMapping
SequenceGenerator
TableGenerator
Added SequenceGenerators and TableGenerators annotations.
Added support for CDI injection into AttributeConverter classes.
Added support for the mapping of the following java.time types:
java.time.LocalDate
java.time.LocalTime
java.time.LocalDateTime
java.time.OffsetTime
java.time.OffsetDateTime
Added default Stream getResultStream() method to Query interface.
Added default Stream<X> getResultStream() method to TypedQuery interface.
Replaced reference to JAR file specification in persistence provider bootstrapping section with more general reference to Java SE service provider requirements.
Updated persistence.xml and orm.xml schemas to 2.2 versions.
Updated Related Documents.
{code}
was:
>From JPA 2.2 specification appendix section A.1:
{code}
A.1 Maintenance Release Draft
Created document from Java Persistence 2.1 Final Release specification.
The following annotations have been marked @Repeatable:
AssociationOverride
AttributeOverride
Convert
JoinColumn
MapKeyJoinColumn
NamedEntityGraph
NamedNativeQuery
NamedQuery
NamedStoredProcedureQuery
PersistenceContext
PersistenceUnit
PrimaryKeyJoinColumn
SecondaryTable
SqlResultSetMapping
SequenceGenerator
TableGenerator
Added SequenceGenerators and TableGenerators annotations.
Added support for CDI injection into AttributeConverter classes.
Added support for the mapping of the following java.time types:
java.time.LocalDate
java.time.LocalTime
java.time.LocalDateTime
java.time.OffsetTime
java.time.OffsetDateTime
Added default Stream getResultStream() method to Query interface.
Added default Stream<X> getResultStream() method to TypedQuery interface.
Replaced reference to JAR file specification in persistence provider bootstrapping section with more
general reference to Java SE service provider requirements.
Updated persistence.xml and orm.xml schemas to 2.2 versions.
Updated Related Documents.
{code}
> JPA 2.2 Support
> ---------------
>
> Key: WFLY-6464
> URL: https://issues.jboss.org/browse/WFLY-6464
> Project: WildFly
> Issue Type: Sub-task
> Components: JPA / Hibernate
> Reporter: David Lloyd
> Assignee: Scott Marlow
> Fix For: 12.0.0.Alpha1
>
>
> From JPA 2.2 specification appendix section A.1:
> {code}
> A.1 Maintenance Release Draft
> Created document from Java Persistence 2.1 Final Release specification.
> The following annotations have been marked @Repeatable:
> AssociationOverride
> AttributeOverride
> Convert
> JoinColumn
> MapKeyJoinColumn
> NamedEntityGraph
> NamedNativeQuery
> NamedQuery
> NamedStoredProcedureQuery
> PersistenceContext
> PersistenceUnit
> PrimaryKeyJoinColumn
> SecondaryTable
> SqlResultSetMapping
> SequenceGenerator
> TableGenerator
> Added SequenceGenerators and TableGenerators annotations.
> Added support for CDI injection into AttributeConverter classes.
> Added support for the mapping of the following java.time types:
> java.time.LocalDate
> java.time.LocalTime
> java.time.LocalDateTime
> java.time.OffsetTime
> java.time.OffsetDateTime
> Added default Stream getResultStream() method to Query interface.
> Added default Stream<X> getResultStream() method to TypedQuery interface.
> Replaced reference to JAR file specification in persistence provider bootstrapping section with more general reference to Java SE service provider requirements.
> Updated persistence.xml and orm.xml schemas to 2.2 versions.
> Updated Related Documents.
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ELY-1466) Add configuration option to BASIC mechanism to switch off challenging
by Ray Ramos (JIRA)
[ https://issues.jboss.org/browse/ELY-1466?page=com.atlassian.jira.plugin.s... ]
Ray Ramos commented on ELY-1466:
--------------------------------
The business requirement would be, "As an application developer, I need multiple authentication and authorizations methods configured for the same application, in order to support both human and machine consumption."
For humans, HTML, CSS, JSP, JSF, etc would be secured using FORM authentication and probably some type of SSO like LDAP or SAML.
And in the same application, a JAX-RS, JAX-WS, and possibly bare Servlet, would be configured for consumption by a machine. This could simply be HTTP BASIC or also LDAP or SAML.
The point is, one application, multiple clients.
> Add configuration option to BASIC mechanism to switch off challenging
> ---------------------------------------------------------------------
>
> Key: ELY-1466
> URL: https://issues.jboss.org/browse/ELY-1466
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: HTTP
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.2.0.Beta11
>
>
> This may be desirable where paired with FORM auth so users can use FORM auth and other clients use BASIC.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-283 at 12/13/17 2:50 PM:
----------------------------------------------------------
Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...
{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/-1696122173
c/r/s = 0/13/0
{code}
{code}
major = d0000 = 0 / 13 / 0
Calling Error = 0
Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
Supplementary Status Bits = 0
minor = -1696122173 (signed dec) = 2598845123 (unsigned dec) = 9AE73AC3 (hex)
{code}
*Update:* the error above occure when ccache does not exists - to resolve, run *kinit* and sign in as any unrelated user - even from unrelated kerberos realm - when the ccache exists, *remote/localhost(a)JBOSS.ORG* credential is obtained correctly too. (After kdestroy the error above will return.)
was (Author: honza889):
Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...
{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/-1696122173
c/r/s = 0/13/0
{code}
{code}
major = d0000 = 0 / 13 / 0
Calling Error = 0
Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
Supplementary Status Bits = 0
minor = -1696122173 (signed dec) = 2598845123 (unsigned dec) = 9AE73AC3 (hex)
{code}
> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
> Key: ELY-283
> URL: https://issues.jboss.org/browse/ELY-283
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: Peter Skopek
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3460) Update the public packages in the org.wildfly.security.elytron module
by Farah Juma (JIRA)
Farah Juma created WFCORE-3460:
----------------------------------
Summary: Update the public packages in the org.wildfly.security.elytron module
Key: WFCORE-3460
URL: https://issues.jboss.org/browse/WFCORE-3460
Project: WildFly Core
Issue Type: Task
Components: Security
Reporter: Farah Juma
Assignee: Farah Juma
ELY-1451 is going to make the {{org.wildfly.security.asn1}}, {{org.wildfly.security.x500}}, and {{org.wildfly.security.x500.cert}} pacakges public. The Elytron module definition needs to be updated to reflect this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months