[JBoss JIRA] (WFLY-6490) Undertow listener's 'enabled' attribute should not require reload to go from false to true
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-6490:
--------------------------------------
Summary: Undertow listener's 'enabled' attribute should not require reload to go from false to true
Key: WFLY-6490
URL: https://issues.jboss.org/browse/WFLY-6490
Project: WildFly
Issue Type: Enhancement
Components: Web (Undertow)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
In general an 'enabled' type attribute shouldn't require a reload to go from 'false' to 'true'. Turning something on generally isn't disruptive to other currently running services. It's turning things off that can be problematic.
While not a focus of this JIRA, possibly even the true -> false case could be supported via the "allow-resource-service-restart" => true header, although that needs a bit more thought. Over the years I've gone back and forth on the wisdom of making support for that more widespread. It adds flexibility at the risk of making it easier for users to screw up. These days though I'm trending back toward thinking it's a good thing to support.
Side note: 'enabled' attributes are better avoided in the first place. :)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-261) Rework (and move) UsernamePasswordHashUtil
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-261?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-261:
---------------------------------
Fix Version/s: 1.1.0.Beta6
(was: 1.1.0.Beta5)
> Rework (and move) UsernamePasswordHashUtil
> ------------------------------------------
>
> Key: ELY-261
> URL: https://issues.jboss.org/browse/ELY-261
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: API / SPI, Passwords
> Reporter: Darran Lofthouse
> Fix For: 1.1.0.Beta6
>
>
> Firstly this class is not really SASL specific so should be in a general util package.
> Secondly we now have password specs and a PasswordFactory - if this class still has a future then maybe it should be using those instead of it's own custom implementation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-341) PEM file format support
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-341?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-341:
---------------------------------
Fix Version/s: 1.1.0.Beta6
(was: 1.1.0.Beta5)
> PEM file format support
> -----------------------
>
> Key: ELY-341
> URL: https://issues.jboss.org/browse/ELY-341
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: KeyStores
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta6
>
>
> We should add support for PEM formats for formats including (but not limited to):
> * X.509 Certificate
> * CSRs
> * CRLs
> * RSA and DSA Public and Private Keys
> * PKCS8 format Private Keys
> * DH parameters
> * ECDSA Public Key
> * EC Private Key
> * EC Parameters
> This API could be consumed by various utilities or by custom credential storage implementations.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-422) Default SSLContext?
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-422?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-422:
---------------------------------
Fix Version/s: 1.1.0.Beta6
(was: 1.1.0.Beta5)
> Default SSLContext?
> -------------------
>
> Key: ELY-422
> URL: https://issues.jboss.org/browse/ELY-422
> Project: WildFly Elytron
> Issue Type: Task
> Components: SSL
> Reporter: Darran Lofthouse
> Fix For: 1.1.0.Beta6
>
>
> We know we want one, what we don't know is exactly that it means and is it an Elytron concern or subsystem concern.
> One issue is within Elytron our SSLContext implementations are either server side specific or client side specific - we may even want to review if there is any way to review what it is being used for and act accordingly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month