[JBoss JIRA] (ELY-175) SASL mechanism availability should take into account credential support.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-175?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse resolved ELY-175.
----------------------------------
Resolution: Done
> SASL mechanism availability should take into account credential support.
> ------------------------------------------------------------------------
>
> Key: ELY-175
> URL: https://issues.jboss.org/browse/ELY-175
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SASL
> Reporter: Darran Lofthouse
> Assignee: David Lloyd
> Fix For: 1.0.0.Alpha3
>
>
> One of the main reasons for having a getCredentialSupport API is so that we select appropriate authentication mechanisms based on the credentials available to us or the level of validation possible.
> This should also consider advertising all variants of a mechanism or strongest only.
> I will mention it here but we may want as a separate task some form of downgrade detection as this could be a sign of a malicious MITM.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (ELY-175) SASL mechanism availability should take into account credential support.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-175?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-175:
------------------------------------
Assignee: David Lloyd
> SASL mechanism availability should take into account credential support.
> ------------------------------------------------------------------------
>
> Key: ELY-175
> URL: https://issues.jboss.org/browse/ELY-175
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SASL
> Reporter: Darran Lofthouse
> Assignee: David Lloyd
> Fix For: 1.0.0.Alpha3
>
>
> One of the main reasons for having a getCredentialSupport API is so that we select appropriate authentication mechanisms based on the credentials available to us or the level of validation possible.
> This should also consider advertising all variants of a mechanism or strongest only.
> I will mention it here but we may want as a separate task some form of downgrade detection as this could be a sign of a malicious MITM.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-4998) Domain deployment batch subsystem resources throw an NPE when an attempting to read the resource
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4998?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-4998.
-------------------------------
Resolution: Cannot Reproduce Bug
I probably should have tested before I filed this bug.
> Domain deployment batch subsystem resources throw an NPE when an attempting to read the resource
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4998
> URL: https://issues.jboss.org/browse/WFLY-4998
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: James Perkins
> Assignee: James Perkins
>
> Jobs should likely not be allowed to be read from this address, but an NPE should not be thrown.
> {code}
> 2015-07-23 10:54:23,469 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool – 154) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "alploy-loyaltybe.ear"),
> ("subdeployment" => "loyalty-bundle.jar"),
> ("subsystem" => "batch"),
> ("job" => "RESOURCE_BUNDLE_JOB")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.batch.deployment.JobOperationStepHandler.execute(JobOperationStepHandler.java:45)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174) [wildfly-controller-1.0.0.Final.jar:1.0.0.Final]
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137) [wildfly-controller-1.0.0.Final.jar:1.0.0.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-4918) Remove default-stack usage and make stack required/explicit per channel
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4918?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-4918:
---------------------------------
Priority: Major (was: Minor)
> Remove default-stack usage and make stack required/explicit per channel
> -----------------------------------------------------------------------
>
> Key: WFLY-4918
> URL: https://issues.jboss.org/browse/WFLY-4918
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Alpha5
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 10.0.0.Beta1
>
>
> We discussed with Paul earlier today to go the way of making this explicit per channel, since currently there is a info when booting the default ha profiles:
> 18:06:44,039 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-4937) Implement graceful shutdown for transactions
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-4937:
-------------------------------------
Sorry, I was unclear. I wasn't proposing to pause the individual transactions.
What I meant was:
1. When suspend is called
2. Allow existing remote transactions to complete
3. Do not allow new remote transactions to be created
4. Until resume is called (or server restarts)
Is that the intended behavior? I think it would be consistent with what you are proposing (so long as doOtherStuff is @RequiresNew - if it was @Requires as the TX is already existing we wouldn't actually reject those ones as the lookup of the transaction would succeed)
> Implement graceful shutdown for transactions
> --------------------------------------------
>
> Key: WFLY-4937
> URL: https://issues.jboss.org/browse/WFLY-4937
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Affects Versions: 10.0.0.Alpha5
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 11.0.0.Alpha1
>
>
> We will handle suspend for JTA and JTS by disallowing new transactions and then block the suspend thread until the count of active transactions drops to zero. We will also suspend the recovery manager.
> We will *not* do graceful shutdown for the optional XTS subsystem. For example an incoming XTS request for an existing transaction will be blocked.
> Question: should we
> - raise a new JIRA for this XTS case;
> - document the deficiency and see if there are complaints;
> - document the deficiency and fix it in a subsequent release
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-4918) Remove default-stack usage and make stack required/explicit per channel
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4918?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-4918:
---------------------------------
Summary: Remove default-stack usage and make stack required/explicit per channel (was: Remove default-stack usage and make stack required per channel)
> Remove default-stack usage and make stack required/explicit per channel
> -----------------------------------------------------------------------
>
> Key: WFLY-4918
> URL: https://issues.jboss.org/browse/WFLY-4918
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Alpha5
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 10.0.0.Beta1
>
>
> We discussed with Paul earlier today to go the way of making this explicit per channel, since currently there is a info when booting the default ha profiles:
> 18:06:44,039 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-4918) Remove default-stack usage and make stack required/explicit per channel
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4918?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-4918:
---------------------------------
Summary: Remove default-stack usage and make stack required/explicit per channel (was: Remove default-stack and make stack required/explicit per channel)
> Remove default-stack usage and make stack required/explicit per channel
> -----------------------------------------------------------------------
>
> Key: WFLY-4918
> URL: https://issues.jboss.org/browse/WFLY-4918
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Alpha5
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 10.0.0.Beta1
>
>
> We discussed with Paul earlier today to go the way of making this explicit per channel, since currently there is a info when booting the default ha profiles:
> 18:06:44,039 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months