[JBoss JIRA] (WFBUILD-22) Upgrade jandex to 2.0.x
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFBUILD-22:
----------------------------------
Summary: Upgrade jandex to 2.0.x
Key: WFBUILD-22
URL: https://issues.jboss.org/browse/WFBUILD-22
Project: WildFly Build Tools
Issue Type: Component Upgrade
Affects Versions: 1.1.6.Final
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
Currently build tools still uses jandex 1.2.x but should rather use 2.0.x to be in line with WildFly
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 8 months
[JBoss JIRA] (WFCORE-1052) Add server-config parameter to :reload op
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1052?page=com.atlassian.jira.plugi... ]
Kabir Khan commented on WFCORE-1052:
------------------------------------
I have added the better strings in https://github.com/wildfly/wildfly-core/pull/1876
> Add server-config parameter to :reload op
> -----------------------------------------
>
> Key: WFCORE-1052
> URL: https://issues.jboss.org/browse/WFCORE-1052
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 3.0.0.Alpha1
>
>
> {code}
> [13:48] Kabir Khan: @BrianStansberry @JasonGreene $./build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/bin/standalone.sh --server-config=20151013-134726769standalone.xml
looks for that file in the snapshots directory
> [13:48] Kabir Khan:
> [standalone@localhost:9990 /] :list-snapshots
> {
> "outcome" => "success",
> "result" => {
> "directory" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly-core/build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone_xml_history/snapshot",
> "names" => [
> "20151013-134523280standalone.xml",
> "20151013-134726769standalone.xml"
> ]
> }
> }
> Show less
> [13:50] Kabir Khan: server-config should probably be a parameter to the :reload operation
> {code}
> Similarly we should add host-config and domain-config parameters to the host's reload operation. Using domain-config on a non-DC host should fail.
> For a domain server, we should not have the server-config parameter.
> We should check the existence of the file before the reload actually is done, or we will end up in a sticky situation.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 8 months
[JBoss JIRA] (WFLY-7373) Revisit the "jboss.naming.client.ejb.context" property and its use in the DatabaseTimerServiceMultiNode*TestCases
by Farah Juma (JIRA)
Farah Juma created WFLY-7373:
--------------------------------
Summary: Revisit the "jboss.naming.client.ejb.context" property and its use in the DatabaseTimerServiceMultiNode*TestCases
Key: WFLY-7373
URL: https://issues.jboss.org/browse/WFLY-7373
Project: WildFly
Issue Type: Bug
Reporter: Farah Juma
Assignee: Farah Juma
Both {{DatabaseTimerServiceMultiNodeExecutionDisabledTestCase}} and {{DatabaseTimerServiceMultiNodeTestCase}} rely on specifying the {{jboss.naming.client.ejb.context}} property during {{InitialContext}} creation in order to ensure that an {{EJBClientContext}} will get set up properly with an appropriate {{EJBReceiver}}. Since the new WildFly naming client doesn't currently handle this property, we need to manually set the {{EJBClientConfiguration}} in this test for now. We need to revisit this modification when the new WildFly naming client and EJB client are being integrated. Note that without this modification, the tests fail with the following error:
{code}
java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:testTimerServiceSimple, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@6548bb7d
at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:774)
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:128)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
at com.sun.proxy.$Proxy24.scheduleTimer(Unknown Source)
at org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeExecutionDisabledTestCase.testEjbTimeoutOnOtherNode(DatabaseTimerServiceMultiNodeExecutionDisabledTestCase.java:197)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 8 months
[JBoss JIRA] (ELY-685) Credential-reference(alias=) should be resolved in time of request.
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-685:
--------------------------------
Summary: Credential-reference(alias=) should be resolved in time of request.
Key: ELY-685
URL: https://issues.jboss.org/browse/ELY-685
Project: WildFly Elytron
Issue Type: Bug
Components: Credential Store
Affects Versions: 1.1.0.Beta10
Reporter: Hynek Švábek
Assignee: Peter Skopek
Credential-reference should be resolved in time of request - in this case the alias which contains wrong password in CredentialStore (we can change it later to right password...).
If I add credential reference with alias which contains wrong password then I get this error:
{code}
{
"outcome" => "failed",
"failure-description" => {
"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.fireflyWrong" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.fireflyWrong: WFLYELY00004: Unable to start the service.
Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect
Caused by: java.security.UnrecoverableKeyException: Password verification failed"},
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.fireflyWrong"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
},
"rolled-back" => true
}
{code}
*When I reload server then same command pass!*
But I nowhere got information about reload-required
{code}
/subsystem=elytron/key-store=fireflyWrong:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=credStore2,alias=ffWithWrongPass})
{code}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 8 months
[JBoss JIRA] (ELY-683) Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-683:
--------------------------------
Summary: Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
Key: ELY-683
URL: https://issues.jboss.org/browse/ELY-683
Project: WildFly Elytron
Issue Type: Bug
Components: Credential Store
Reporter: Hynek Švábek
Assignee: Peter Skopek
Priority: Minor
Add error message with information that is not allowed to read secret-value and entry-type from Credential Store over CLI.
This CLI commands
{code}
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
{code}
end with success result.
{code}
{
"outcome" => "success",
"result" => undefined
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 8 months
[JBoss JIRA] (ELY-682) There isn't possibility set entry-type for new entry in Credential Store.
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-682:
--------------------------------
Summary: There isn't possibility set entry-type for new entry in Credential Store.
Key: ELY-682
URL: https://issues.jboss.org/browse/ELY-682
Project: WildFly Elytron
Issue Type: Bug
Components: Credential Store
Reporter: Hynek Švábek
Assignee: Peter Skopek
There isn't possibility set entry-type for new entry in Credential Store
This CLI command
{code}
/subsystem=elytron/credential-store=testCS/alias=aliasEntryType:add(secret-value=secretVALUE, entry-type=org.wildfly.security.credential.PasswordCredential)
{code}
ends with
{code}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'",
"rolled-back" => true
}
{code}
*Server log:*
{code}
10:30:39,074 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 18) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("credential-store" => "testCS"),
("alias" => "aliasEntryType")
]): java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'
at org.wildfly.extension.elytron.CredentialStoreAliasDefinition$AddHandler.performRuntime(CredentialStoreAliasDefinition.java:166)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
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)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 8 months
[JBoss JIRA] (JGRP-2112) Sticky site masters
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2112?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2112.
----------------------------
Resolution: Done
> Sticky site masters
> -------------------
>
> Key: JGRP-2112
> URL: https://issues.jboss.org/browse/JGRP-2112
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.12, 4.0
>
>
> If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
> Example:
> * Member C in site LON sends messages C1 and C2 to site NYC
> * C1 picks SM1 and C2 picks SM2
> * Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues
> h4. Design
> * When sending a message to the one of the site masters of the current site, or from a site master to a remote site master, we invoke a callback to pick the site master based on the original caller
> * Note that this only applies when we have more than one site master.
> * The callback passes the address of the original caller and the list of available site masters, and needs to return a site master
> h5. Transactions
> * Transactions by different originators with overlapping key sets cannot be reliably ordered
> * Transactional support therefore requires single site masters
> * This should not be an issue as transactions bundle multiple updates, so the number of messages sent is less than non-transactional updates
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 8 months
[JBoss JIRA] (WFCORE-1052) Add server-config parameter to :reload op
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1052?page=com.atlassian.jira.plugi... ]
Kabir Khan commented on WFCORE-1052:
------------------------------------
It should be the same as the --server-config command line option, i.e. https://docs.jboss.org/author/display/WFLY10/Command+line+parameters. I *believe* that we turned off the possibility to use absolute paths a long time ago due to the task of keeping the history directory up to date.
The --server-config command line option is mentioned at the end of https://docs.jboss.org/author/display/WFLY10/Configuration+file+history, and in https://docs.jboss.org/author/display/WFLY10/Command+line+parameters.
I could probably append onto the end of the operation parameter something like "This parameter will be resolved the same as the --server-config command line option used when starting the server"
> Add server-config parameter to :reload op
> -----------------------------------------
>
> Key: WFCORE-1052
> URL: https://issues.jboss.org/browse/WFCORE-1052
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 3.0.0.Alpha1
>
>
> {code}
> [13:48] Kabir Khan: @BrianStansberry @JasonGreene $./build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/bin/standalone.sh --server-config=20151013-134726769standalone.xml
looks for that file in the snapshots directory
> [13:48] Kabir Khan:
> [standalone@localhost:9990 /] :list-snapshots
> {
> "outcome" => "success",
> "result" => {
> "directory" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly-core/build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone_xml_history/snapshot",
> "names" => [
> "20151013-134523280standalone.xml",
> "20151013-134726769standalone.xml"
> ]
> }
> }
> Show less
> [13:50] Kabir Khan: server-config should probably be a parameter to the :reload operation
> {code}
> Similarly we should add host-config and domain-config parameters to the host's reload operation. Using domain-config on a non-DC host should fail.
> For a domain server, we should not have the server-config parameter.
> We should check the existence of the file before the reload actually is done, or we will end up in a sticky situation.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 8 months