[JBoss JIRA] (WFCORE-2559) caching-realm with ldap-realm cannot be added when LDAP is unreachable
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2559?page=com.atlassian.jira.plugi... ]
Kabir Khan commented on WFCORE-2559:
------------------------------------
Closed as per comment on JBEAP-9684
> caching-realm with ldap-realm cannot be added when LDAP is unreachable
> ----------------------------------------------------------------------
>
> Key: WFCORE-2559
> URL: https://issues.jboss.org/browse/WFCORE-2559
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta9
> Reporter: Ondrej Lukas
> Assignee: Bartosz Baranowski
> Priority: Critical
>
> In case when caching-realm is used together with ldap-realm and LDAP server (which is used by that ldap-realm) is unreachable, then caching-realm cannot be added.
> This issue also causes that this realm service is not correctly started when server is started. It means that in case when LDAP server is unreachable during starting application server, then this realm will not work until it will be reloaded again and LDAP will be reachable.
> Following exception occurs for CLI command:
> {code}
> /subsystem=elytron/caching-realm=some-cache-realm:add(realm=some-ldap-realm)
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.some-cache-realm" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service
> Caused by: java.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> Caused by: java.net.ConnectException: Connection refused"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.some-cache-realm"]
> },
> "rolled-back" => true
> }
> {code}
> Following exception occurs in server log when mentioned above CLI command is executed:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.security-realm.some-cache-realm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.registerIdentityChangeListener(LdapSecurityRealm.java:153)
> at org.wildfly.security.auth.realm.CachingSecurityRealm.<init>(CachingSecurityRealm.java:60)
> at org.wildfly.security.auth.realm.CachingModifiableSecurityRealm.<init>(CachingModifiableSecurityRealm.java:53)
> at org.wildfly.extension.elytron.CachingRealmDefinition$RealmAddHandler.lambda$createService$0(CachingRealmDefinition.java:143)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> ... 3 more
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:187)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.registerIdentityChangeListener(LdapSecurityRealm.java:149)
> ... 9 more
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:101)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:442)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:356)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:227)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:462)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:185)
> ... 10 more
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> ... 32 more
> 09:26:07,954 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("caching-realm" => "some-cache-realm")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.some-cache-realm" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service
> Caused by: java.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> Caused by: java.net.ConnectException: Connection refused"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.some-cache-realm"]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2559) caching-realm with ldap-realm cannot be added when LDAP is unreachable
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2559?page=com.atlassian.jira.plugi... ]
Kabir Khan closed WFCORE-2559.
------------------------------
Resolution: Won't Fix
> caching-realm with ldap-realm cannot be added when LDAP is unreachable
> ----------------------------------------------------------------------
>
> Key: WFCORE-2559
> URL: https://issues.jboss.org/browse/WFCORE-2559
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta9
> Reporter: Ondrej Lukas
> Assignee: Bartosz Baranowski
> Priority: Critical
>
> In case when caching-realm is used together with ldap-realm and LDAP server (which is used by that ldap-realm) is unreachable, then caching-realm cannot be added.
> This issue also causes that this realm service is not correctly started when server is started. It means that in case when LDAP server is unreachable during starting application server, then this realm will not work until it will be reloaded again and LDAP will be reachable.
> Following exception occurs for CLI command:
> {code}
> /subsystem=elytron/caching-realm=some-cache-realm:add(realm=some-ldap-realm)
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.some-cache-realm" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service
> Caused by: java.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> Caused by: java.net.ConnectException: Connection refused"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.some-cache-realm"]
> },
> "rolled-back" => true
> }
> {code}
> Following exception occurs in server log when mentioned above CLI command is executed:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.security-realm.some-cache-realm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.registerIdentityChangeListener(LdapSecurityRealm.java:153)
> at org.wildfly.security.auth.realm.CachingSecurityRealm.<init>(CachingSecurityRealm.java:60)
> at org.wildfly.security.auth.realm.CachingModifiableSecurityRealm.<init>(CachingModifiableSecurityRealm.java:53)
> at org.wildfly.extension.elytron.CachingRealmDefinition$RealmAddHandler.lambda$createService$0(CachingRealmDefinition.java:143)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> ... 3 more
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:187)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.registerIdentityChangeListener(LdapSecurityRealm.java:149)
> ... 9 more
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:101)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:442)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:356)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:227)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:462)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:185)
> ... 10 more
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> ... 32 more
> 09:26:07,954 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("caching-realm" => "some-cache-realm")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.some-cache-realm" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.some-cache-realm: Failed to start service
> Caused by: java.lang.IllegalStateException: ELY01146: Ldap realm failed to register notification listener
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> Caused by: java.net.ConnectException: Connection refused"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.some-cache-realm"]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1085) CS tool, Help contains wrong description of "--create" option, there is description with true/false value.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-1085?page=com.atlassian.jira.plugin.s... ]
Hynek Švábek updated ELY-1085:
------------------------------
Description:
Help contains wrong description of "--create" option, there is description with true/false value.
And now there is wrong behaviour too. I am able set some value (even invalid) for \--create option and it is valid.
I can set e.g. "--create false" and it pass. It is very confusing.
--create option doesn't expect any value.
Please make it consistent:
# "--create" is only flag -> please fix help usage and fix it in command (\--create false must be invalid)
# "--create" expects true/false value, in this case leave help usage unchanged
{code}
java -jar wildfly-elytron-tool.jar credential-store --add secret_alias --password pass123 --secret secret_password --create false -f -l newstore.jceks
Alias "secret_alias" has been successfully stored
Credential store command summary:
--------------------------------------
/subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location="newstore.jceks",create=true,implementation-properties={"keyStoreType"=>"JCEKS","create"=>"true","location"=>"newstore.jceks","modifiable"=>"true"},credential-reference={clear-text="pass123"})
{code}
{code}
java -jar wildfly-elytron-tool.jar credential-store --help
...
-c,--create Create credential store [true/false]
...
{code}
was:
Help contains wrong description of "--create" option, there is description with true/false value.
--create option doesn't expect any value.
{code}
java -jar wildfly-elytron-tool.jar credential-store --help
...
-c,--create Create credential store [true/false]
...
{code}
> CS tool, Help contains wrong description of "--create" option, there is description with true/false value.
> ----------------------------------------------------------------------------------------------------------
>
> Key: ELY-1085
> URL: https://issues.jboss.org/browse/ELY-1085
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> Help contains wrong description of "--create" option, there is description with true/false value.
> And now there is wrong behaviour too. I am able set some value (even invalid) for \--create option and it is valid.
> I can set e.g. "--create false" and it pass. It is very confusing.
> --create option doesn't expect any value.
> Please make it consistent:
> # "--create" is only flag -> please fix help usage and fix it in command (\--create false must be invalid)
> # "--create" expects true/false value, in this case leave help usage unchanged
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --add secret_alias --password pass123 --secret secret_password --create false -f -l newstore.jceks
> Alias "secret_alias" has been successfully stored
> Credential store command summary:
> --------------------------------------
> /subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location="newstore.jceks",create=true,implementation-properties={"keyStoreType"=>"JCEKS","create"=>"true","location"=>"newstore.jceks","modifiable"=>"true"},credential-reference={clear-text="pass123"})
> {code}
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --help
> ...
> -c,--create Create credential store [true/false]
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8662) EJB over HTTP needs explicit dependency on undertow-core
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8662?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-10607 to WFLY-8662:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8662 (was: JBEAP-10607)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
Web (Undertow)
(was: EJB)
(was: Web (Undertow))
Affects Version/s: (was: 7.1.0.DR16)
(was: 7.1.0.DR17)
> EJB over HTTP needs explicit dependency on undertow-core
> --------------------------------------------------------
>
> Key: WFLY-8662
> URL: https://issues.jboss.org/browse/WFLY-8662
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
>
> If I want to build a standalone EJB client which uses the HTTP transport, I have to explicitly add a dependency on {{io.undertow:undertow-core}} artifact, otherwise the client will fail with {{java.lang.ClassNotFoundException: io.undertow.util.AttachmentKey}}
> I think that either the client should get rid of this dependency, or it should be included transitively, so that the only two required artifacts are {{org.jboss:jboss-ejb-client}} and {{org.wildfly.wildfly-http-client:wildfly-http-ejb-client}} so that the pom.xml can be shorter.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2667) CLI returns always "0" if CLI is started with "cmd /c " on Windows
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2667?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-2667:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1444620|https://bugzilla.redhat.com/show_bug.cgi?id=1444620] from MODIFIED to ON_QA
> CLI returns always "0" if CLI is started with "cmd /c " on Windows
> ------------------------------------------------------------------
>
> Key: WFCORE-2667
> URL: https://issues.jboss.org/browse/WFCORE-2667
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Scripts
> Environment: Windows
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Priority: Critical
> Fix For: 3.0.0.Beta16
>
>
> *Description of problem:*
> CLI returns always "0" if CLI is started with "cmd /c " on Windows
> This issue is regression against EAP 7.0.0, but priority of this jira is not blocker, because this issue is corner case.
> *Steps to Reproduce:*
> # jboss-cli.bat --command=version_error
> # echo Exit Code is %errorlevel%
> # REM verify correct return value: 1
> # cmd /c jboss-cli.bat --command=version_error
> # echo Exit Code is %errorlevel%
> # REM return value is 0 in EAP 7.1.0.DR16. Correct return value should be 1
> *Actual results:*
> {noformat}
> C:\Users\Administrator\playground\7.1.0.DR16\jboss-eap-7.1\bin>jboss-cli.bat --command=version_error
> Unexpected command 'version_error'. Type 'help --commands' for the list of supported commands.
> C:\Users\Administrator\playground\7.1.0.DR16\jboss-eap-7.1\bin>echo Exit Code is %errorlevel%
> Exit Code is 1
> C:\Users\Administrator\playground\7.1.0.DR16\jboss-eap-7.1\bin>
> C:\Users\Administrator\playground\7.1.0.DR16\jboss-eap-7.1\bin>cmd /c jboss-cli.bat --command=version_error
> Unexpected command 'version_error'. Type 'help --commands' for the list of supported commands.
> C:\Users\Administrator\playground\7.1.0.DR16\jboss-eap-7.1\bin>echo Exit Code is %errorlevel%
> Exit Code is 0
> C:\Users\Administrator\playground\7.1.0.DR16\jboss-eap-7.1\bin>
> {noformat}
> *Expected results:*
> {noformat}
> C:\Users\Administrator\playground\7.0.0\jboss-eap-7.0\bin>jboss-cli.bat --command=version_error
> Unexpected command 'version_error'. Type 'help --commands' for the list of supported commands.
> C:\Users\Administrator\playground\7.0.0\jboss-eap-7.0\bin>echo Exit Code is %errorlevel%
> Exit Code is 1
> C:\Users\Administrator\playground\7.0.0\jboss-eap-7.0\bin>
> C:\Users\Administrator\playground\7.0.0\jboss-eap-7.0\bin>cmd /c jboss-cli.bat --command=version_error
> Unexpected command 'version_error'. Type 'help --commands' for the list of supported commands.
> C:\Users\Administrator\playground\7.0.0\jboss-eap-7.0\bin>echo Exit Code is %errorlevel%
> Exit Code is 1
> C:\Users\Administrator\playground\7.0.0\jboss-eap-7.0\bin>
> {noformat}
> *Additional info:*
> We see this issue also if jboss-cli.bat script is called from groovy or java
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1282:
-------------------------------------
Fix Version/s: 3.0.0.Beta18
(was: 3.0.0.Beta17)
> Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1282
> URL: https://issues.jboss.org/browse/WFCORE-1282
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 1.0.2.Final
> Environment: Oracle Java
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Beta18
>
> Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log
>
>
> User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7.
> Setting as critical as these cipher suites, are considered for strong and widely used in my opinion.
> In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all.
> Note, that analogous configuration in EAP6 works fine.
> Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites().
> Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-887:
------------------------------------
Fix Version/s: 3.0.0.Beta18
(was: 3.0.0.Beta17)
> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
> Key: WFCORE-887
> URL: https://issues.jboss.org/browse/WFCORE-887
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Beta18
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We should look for other cases like this too, although those changes should be separate JIRAs.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years