[Red Hat JIRA] (WFLY-13991) Artemis should not delete corrupted log files
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13991?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13991:
----------------------------------
Summary: Artemis should not delete corrupted log files (was: Artemis should not delete corrupt log files)
> Artemis should not delete corrupted log files
> ---------------------------------------------
>
> Key: WFLY-13991
> URL: https://issues.redhat.com/browse/WFLY-13991
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 21.0.0.Final
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> When a corrupted artemis journal file is seen Artemis shuts down EAP, but before it does that it deletes the corrupted file. This means that no after the event analysis/investigation can be done as the corrupted journal file is gone.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (WFLY-6660) Allow dumping Artemis journal to file using WildFly Management API
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-6660?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-6660:
---------------------------------
Summary: Allow dumping Artemis journal to file using WildFly Management API (was: Allow to dump Artemis journal to file using WildfFly Management API)
> Allow dumping Artemis journal to file using WildFly Management API
> ------------------------------------------------------------------
>
> Key: WFLY-6660
> URL: https://issues.redhat.com/browse/WFLY-6660
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Emmanuel Hugonnet
> Priority: Major
> Attachments: journal.txt
>
>
> For debugging and investigation purposes it would useful to have CLI operation which would dump content of Artemis journal directory.
> New CLI operation like {{print-journal-date-content}} would print content of journal to a file.
> It would do the same thing like following Artemis CLI command:
> {code}
> .../activemq-artemis/artemis-distribution/target/apache-artemis-1.3.0-SNAPSHOT-bin/apache-artemis-1.3.0-SNAPSHOT/bin/artemis data print --bindings bindings --journal journal --paging paging --large-messages largemessages
> {code}
> This should work only in Admin only mode as dumping journal in run-time is not possible when data changes.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (ELY-1440) FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-1440?page=com.atlassian.jira.plugin.... ]
Farah Juma updated ELY-1440:
----------------------------
Fix Version/s: 1.15.0.CR2
(was: 1.15.0.CR1)
> FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.
> ----------------------------------------------------------------------------------------------
>
> Key: ELY-1440
> URL: https://issues.redhat.com/browse/ELY-1440
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI
> Reporter: Darran Lofthouse
> Priority: Major
> Fix For: 1.15.0.CR2
>
>
> This API was introduced to cover the case where authentication happens late in a request, generally that is quite a rare event.
> Even though the API may be popular it would likely happen once for a session and all future requests for that session the identity would be known in advance.
> At the moment by not running as the existing identity we are loosing all automatic identity outflow opportunities as calls pass from the servlet container to the EJB container.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-1682?page=com.atlassian.jira.plugin.... ]
Farah Juma updated ELY-1682:
----------------------------
Fix Version/s: 1.15.0.CR2
(was: 1.15.0.CR1)
> Fallback to another SASL client mechanism when SASL client initialisation fails
> -------------------------------------------------------------------------------
>
> Key: ELY-1682
> URL: https://issues.redhat.com/browse/ELY-1682
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.7.0.CR1
> Reporter: Martin Choma
> Priority: Major
> Fix For: 1.15.0.CR2
>
> Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt
>
>
> {code:title=HipChat conversation}
> Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential.
> But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok.
> I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for?
> Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected
> Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case).
> In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved.
> Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting
> though for that one as that is where that loop happens but start with an ELY issue
> {code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month