[JBoss JIRA] (WFLY-7861) Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22
by James Perkins (JIRA)
James Perkins created WFLY-7861:
-----------------------------------
Summary: Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22
Key: WFLY-7861
URL: https://issues.jboss.org/browse/WFLY-7861
Project: WildFly
Issue Type: Component Upgrade
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
Note both WildFly and WildFly Core will need to be updated. It may be possible to remove the dependencies from WildFly and keep everything in core. However it needs to be determined if we should add all the slf4j dependencies to core.
There should no longer be a need for the forked version. The fix for [SLF4J-167|http://jira.qos.ch/browse/SLF4J-167] should be in version 1.7.14 with some additional fixes for replaying the previously lost logs.
[Quote from comment on JIRA|http://jira.qos.ch/browse/SLF4J-167?focusedCommentId=17048&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17048]
{quote}
The problem of lost logs during initialization in a multi-threaded application is solved by storing and replaying the logs which would be otherwise lost. Fix available in SLF4J version 1.7.15.
{quote}
Analysis will need to be done to ensure this works as expected before the fork is no longer required.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-6775) Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6775?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-6775:
--------------------------------
Summary: Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22 (was: Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.21)
> Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22
> -----------------------------------------------------
>
> Key: WFLY-6775
> URL: https://issues.jboss.org/browse/WFLY-6775
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> Note both WildFly and WildFly Core will need to be updated. It may be possible to remove the dependencies from WildFly and keep everything in core. However it needs to be determined if we should add all the slf4j dependencies to core.
> There should no longer be a need for the forked version. The fix for [SLF4J-167|http://jira.qos.ch/browse/SLF4J-167] should be in version 1.7.14 with some additional fixes for replaying the previously lost logs.
> [Quote from comment on JIRA|http://jira.qos.ch/browse/SLF4J-167?focusedCommentId=17048&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17048]
> {quote}
> The problem of lost logs during initialization in a multi-threaded application is solved by storing and replaying the logs which would be otherwise lost. Fix available in SLF4J version 1.7.15.
> {quote}
> Analysis will need to be done to ensure this works as expected before the fork is no longer required.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1620) Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1620?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-1620:
----------------------------------
Summary: Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22 (was: Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.21)
> Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22
> -----------------------------------------------------
>
> Key: WFCORE-1620
> URL: https://issues.jboss.org/browse/WFCORE-1620
> Project: WildFly Core
> Issue Type: Component Upgrade
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> There should no longer be a need for the forked version. The fix for [SLF4J-167|http://jira.qos.ch/browse/SLF4J-167] should be in version 1.7.14 with some additional fixes for replaying the previously lost logs.
> [Quote from comment on JIRA|http://jira.qos.ch/browse/SLF4J-167?focusedCommentId=17048&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17048]
> {quote}
> The problem of lost logs during initialization in a multi-threaded application is solved by storing and replaying the logs which would be otherwise lost. Fix available in SLF4J version 1.7.15.
> {quote}
> Analysis will need to be done to ensure this works as expected before the fork is no longer required.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1620) Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1620?page=com.atlassian.jira.plugi... ]
James Perkins reassigned WFCORE-1620:
-------------------------------------
Assignee: Frank Langelage (was: James Perkins)
> Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22
> -----------------------------------------------------
>
> Key: WFCORE-1620
> URL: https://issues.jboss.org/browse/WFCORE-1620
> Project: WildFly Core
> Issue Type: Component Upgrade
> Components: Logging
> Reporter: James Perkins
> Assignee: Frank Langelage
>
> There should no longer be a need for the forked version. The fix for [SLF4J-167|http://jira.qos.ch/browse/SLF4J-167] should be in version 1.7.14 with some additional fixes for replaying the previously lost logs.
> [Quote from comment on JIRA|http://jira.qos.ch/browse/SLF4J-167?focusedCommentId=17048&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17048]
> {quote}
> The problem of lost logs during initialization in a multi-threaded application is solved by storing and replaying the logs which would be otherwise lost. Fix available in SLF4J version 1.7.15.
> {quote}
> Analysis will need to be done to ensure this works as expected before the fork is no longer required.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7860) Only import transactions lazily
by David Lloyd (JIRA)
David Lloyd created WFLY-7860:
---------------------------------
Summary: Only import transactions lazily
Key: WFLY-7860
URL: https://issues.jboss.org/browse/WFLY-7860
Project: WildFly
Issue Type: Enhancement
Components: EJB
Reporter: David Lloyd
The EJB client/server protocol can perform many optimizations if a server can lazily import the transaction only if needed when an invocation arrives for processing.
Unfortunately our CMTTxInterceptor infrastructure is built around the assumption that the transaction (if any) will resumed on the calling thread, which prevents the EJB transport protocol from reporting back that the transaction was not used.
The CMTTxInterceptor and its subtypes must be modified to look for the transaction on the invocation object, rather than on the current thread. The local EJB invocation sources must suspend the transaction and install it on to the invocation context. CMTTxInterceptor would then assume that the current thread holds no transaction, resuming if necessary, instead of assuming that the current thread holds the inherited transaction and suspending if necessary.
Once this is complete, org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor can be completely removed from the container.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (JBJCA-1336) Wrong handling of XAResource wrapping with XAResourceWrapperStatImpl
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1336?page=com.atlassian.jira.plugin... ]
Stefano Maestri resolved JBJCA-1336.
------------------------------------
Resolution: Done
> Wrong handling of XAResource wrapping with XAResourceWrapperStatImpl
> --------------------------------------------------------------------
>
> Key: JBJCA-1336
> URL: https://issues.jboss.org/browse/JBJCA-1336
> Project: IronJacamar
> Issue Type: Bug
> Reporter: Ondra Chaloupka
> Assignee: Stefano Maestri
> Priority: Blocker
> Attachments: JMSCrashRecoveryTestCase_commitHaltAtPhaseEnd_jta_server_ij-1.3.5_710.DR8.log, JMSCrashRecoveryTestCase_commitHaltAtPhaseEnd_jta_server_ij-1.4.0_710.DR9.log
>
>
> IronJacamar 1.4.0.Final came with {{XAResourceWrapperStatImpl}} which brings incompatibility of wrapping {{XAResource}} for transaction manager.
> This is regression against behavior of 7.0.0.GA.
> *Observed behavior*
> Transaction object store is not cleared in some cases when {{Artemis Active MQ}} is used as XADatasource. I think these are cases where functionality of JBTM-860 is used.
> *Probably cause*
> My observation came to fact that this is caused by change at {{core/src/main/java/org/jboss/jca/core/connectionmanager/tx/TxConnectionManagerImpl.java}} where wrapped {{XAResource}} is currently returned when {{com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord}} is created. The trouble is that AMQ {{XAResource}} implementation returns different jndiName than the wrapper one ({{java:/JmsXA}} vs. {{java:/JmsXA NodeId:2d77d48f-bd2b-11e6-b7e4-28d244b2cf29}}). This inconsistency causes trouble during recovery where method {{XAResourceRecord#wasResourceContactedByRecoveryModule}} is used to decide whether {{TwoPhaseOutcome.FINISH_OK}} or {{TwoPhaseOutcome.FINISH_ERROR}} is outcome of the periodic recovery commit action for particular participant.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7499) Elytron "expressions-allowed" => false attributes
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7499?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7499:
----------------------------------
I think they should. (But it would be also standalone PR, as it is part of wildfly-controller, not elytron-subsystem - maybe it should be standalone issue)
> Elytron "expressions-allowed" => false attributes
> -------------------------------------------------
>
> Key: WFLY-7499
> URL: https://issues.jboss.org/browse/WFLY-7499
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Labels: user_experience
>
> Please change these attributes to {{"expressions-allowed" => true}} if reasonable
> {code}
> /configurable-sasl-server-factory/protocol
> /configurable-sasl-server-factory/server-name
> /filesystem-realm/levels
> /token-realm/public-key
> /token-realm/principal-claim
> /token-realm/oauth2-introspection/host-name-verification-policy
> /token-realm/oauth2-introspection/introspection-url
> /token-realm/oauth2-introspection/client-secret
> /token-realm/oauth2-introspection/client-id
> /token-realm/oauth2-introspection/public-key
> /token-realm/oauth2-introspection/token-realm
> /jdbc-realm/principal-query/sql
> /jdbc-realm/principal-query/data-source
> /jdbc-realm/clear-password-mapper/password-index
> /jdbc-realm/bcrypt-mapper/password-index
> /jdbc-realm/bcrypt-mapper/salt-index
> /jdbc-realm/bcrypt-mapper/iteration-count-index
> /jdbc-realm/salted-simple-digest-mapper/algorithm
> /jdbc-realm/salted-simple-digest-mapper/password-index
> /jdbc-realm/salted-simple-digest-mapper/salt-index
> /jdbc-realm/simple-digest-mapper/password-index
> /jdbc-realm/scram-mapper/algorithm
> /jdbc-realm/scram-mapper/password-index
> /jdbc-realm/scram-mapper/salt-index
> /jdbc-realm/scram-mapper/iteration-count-index
> /security-domain/default-realm
> These applies to key-store and key-manager:
> */credential-reference/store
> */credential-reference/alias
> */credential-reference/type
> */credential-reference/clear-text
> {code}
> These are not marked as capability reference. But seems referencing another service, so not sure if it is issue in these cases:
> * /jdbc-realm/principal-query/data-source
> * /security-domain/default-realm
> * /credential-reference/store
> "Collection of primitives" , e.g. LIST of STRING, OBJECT of STRING :
> {code}
> /configurable-sasl-server-factory/properties
> /custom-role-mapper/configuration
> /mapped-regex-realm-mapper/realm-map
> /x500-attribute-principal-decoder/required-oids
> /custom-permission-mapper/configuration
> /configurable-http-server-mechanism-factory/properties
> /custom-name-rewriter/configuration
> /custom-principal-decoder/configuration
> /custom-realm-mapper/configuration
> /custom-modifiable-realm/configuration
> /custom-credential-security-factory/configuration
> /custom-role-decoder/configuration
> /custom-realm/configuration
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months