[JBoss JIRA] (ELY-849) Rename setMechanismProperties to setSaslMechanismProperties
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-849?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-849:
---------------------------------
Fix Version/s: 1.1.0.CR5
(was: 1.1.0.CR4)
> Rename setMechanismProperties to setSaslMechanismProperties
> -----------------------------------------------------------
>
> Key: ELY-849
> URL: https://issues.jboss.org/browse/ELY-849
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Client
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.1.0.CR5
>
>
> If we later add HTTP mechanisms we have no way to differentiate between HTTP and SASL mechanism properties.
> We could probably share properties and rely on protocol matching in the MatchRule but as a single AuthenticationConfiguration will support both HTTP and SASL I think independent properties will be required.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-681) Hide private packages from generated javadoc.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-681?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-681:
---------------------------------
Fix Version/s: 1.1.0.CR5
(was: 1.1.0.CR4)
> Hide private packages from generated javadoc.
> ---------------------------------------------
>
> Key: ELY-681
> URL: https://issues.jboss.org/browse/ELY-681
> Project: WildFly Elytron
> Issue Type: Task
> Components: Build
> Reporter: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.CR5
>
>
> We may want two profiles so we can generate a full javadoc and a 'public' javadoc.
> The 'public' javadoc should be the default one generated and should exclude the following packages: -
> org.wildfly.security._private
> org.wildfly.security.asn1
> org.wildfly.security.auth.realm
> org.wildfly.security.auth.realm.*
> org.wildfly.security.authz.jacc
> org.wildfly.security.credential.store.impl
> org.wildfly.security.security.digest
> org.wildfly.security.http.impl
> org.wildfly.security.security.keystore
> org.wildfly.security.mechanism.oauth2
> org.wildfly.security.mechanism.scram
> org.wildfly.security.password.impl
> org.wildfly.security.password.util
> org.wildfly.security.pem
> org.wildfly.security.sasl
> org.wildfly.security.sasl.* (Except util)
> org.wildfly.security.util
> org.wildfly.security.util_private
> org.wildfly.security.x500
> org.wildfly.security.x500.cert
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9133) Wildfly 10.1.0 add-user command
by Bobby Bassman (JIRA)
Bobby Bassman created WFLY-9133:
-----------------------------------
Summary: Wildfly 10.1.0 add-user command
Key: WFLY-9133
URL: https://issues.jboss.org/browse/WFLY-9133
Project: WildFly
Issue Type: Bug
Components: ConfigAdmin
Affects Versions: 10.1.0.Final
Environment: Windows 10 64 bit
Wildfly 10.1.0
Reporter: Bobby Bassman
Assignee: Thomas Diesler
If Wildfly 10 does not initially have the 'admin' user. It must be created using the 'add-user' command line. When the command ('add-user') is used, without any warning, it may update the property files belonging to a different Jboss installation, rendering that installation broken.
This is because 'add-user' relies on environment variable 'JBOSS_HOME' - which may be set to a JBoss installation other than the Wildfly installation to which the 'add-user' command applies.
It appears that 'add-user.bat' has some code to detect this scenario, but it didn't work.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9132) Applications won't deploy if their persistence.xml have multiple persistence units
by Bobby Bassman (JIRA)
Bobby Bassman created WFLY-9132:
-----------------------------------
Summary: Applications won't deploy if their persistence.xml have multiple persistence units
Key: WFLY-9132
URL: https://issues.jboss.org/browse/WFLY-9132
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 10.1.0.Final
Environment: Windows 10 64 bit
Wildfly 10.1.0
Reporter: Bobby Bassman
Assignee: Scott Marlow
Applications won't deploy if their persistence.xml have multiple persistence units. This was not a problem with EAP. Now, Wildfly requires that each @PersistenceContext have a 'unitName' parameter. WIth EAP 6.4, if a @PersistenceContext did not have a 'unitName' parameter, then the default PU was used. By requiring that @PersistenceUnit have 'unitName', developers are forced to unnecessarily bind Java code to configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months