[JBoss JIRA] (WFLY-9888) Server log messages does not reflect the use of "distinct" naming for EJB's
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-9888?page=com.atlassian.jira.plugin.... ]
Chao Wang reassigned WFLY-9888:
-------------------------------
Assignee: Chao Wang
> Server log messages does not reflect the use of "distinct" naming for EJB's
> ---------------------------------------------------------------------------
>
> Key: WFLY-9888
> URL: https://issues.jboss.org/browse/WFLY-9888
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Chao Wang
> Priority: Minor
>
> If an application (jboss-ejb3.xml) or server configuration is marked with the distinct flag
> <jboss:ejb-jar .... version="3.1" impl-version="2.0">
> <distinct-name>WOLF</distinct-name>
> </jboss:ejb-jar>
> The client need to use the the correct lookup with distinct name
> "ejb:MyEAR/MyEjbJar/WOLF/MyBean!MyInterface
> to get the bean proxy.
> Unfortunately there is no hint whether an application is marked with this distinct flag.
> The server log still show the same output as without like this:
> INFO WFLYEJB0473: JNDI bindings for session bean named 'SimpleBean' in deployment unit 'subdeployment "ejb.jar" of deployment "EAP71-PLAYGROUND-server.ear"' are as follows:
> java:global/EAP71-PLAYGROUND-server/ejb/SimpleBean!org.jboss.wfink.eap71.playground.Simple
> It would be good if the log message show the correct JNDI name or a hint that the EJB has a distinct name applied.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9869) Pure HTTP EJB invocation not working
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9869?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-9869.
----------------------------------
Fix Version/s: 12.0.0.CR1
Resolution: Done
> Pure HTTP EJB invocation not working
> ------------------------------------
>
> Key: WFLY-9869
> URL: https://issues.jboss.org/browse/WFLY-9869
> Project: WildFly
> Issue Type: Quality Risk
> Components: EJB
> Affects Versions: 11.0.0.Final, 12.0.0.Beta1
> Environment: Debian 9 - 64-bit
> Reporter: Andre Izu
> Assignee: Stuart Douglas
> Labels: ejb, pure_http
> Fix For: 12.0.0.CR1
>
> Attachments: ejb-http-client.zip
>
>
> I have been trying to make the "pure" http EJB invocation from a remote server instance, without success.
> The client module was built inside a war file, while the server artifact was build in an ear file.
> When I set the Context.PROVIDER_URL to "remote+http://127.0.0.1:8080" or "http://localhost:8080/wildfly-services", the remote invocation works fine via main() method.
> When I set the Context.PROVIDER_URL to "remote+http://127.0.0.1:8080", the remote invocation works fine via http://localhost:8080/web/index.jsp (client application calling server application)
> Now when I set the Context.PROVIDER_URL to "http://localhost:8080/wildfly-services", the remote invocation via http://localhost:8080/web/index.jsp (client application calling server application) returns:
> {panel:title=Client application calling server application}
> 2018-01-05 15:30:07,346 INFO [stdout] (default task-44) jndiName: ejb:wejb/wejb/CalculatorEJB!br.com.server.Calculator
> 2018-01-05 15:30:07,351 INFO [stdout] (default task-44) Proxy for remote EJB StatelessEJBLocator for "wejb/wejb/CalculatorEJB", view is interface br.com.server.Calculator, affinity is None
> 2018-01-05 15:30:07,352 ERROR [io.undertow.request] (default task-44) UT005023: Exception handling request to /web/: org.apache.jasper.JasperException: org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$852/801580157.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 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: org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
> at org.jboss.ejb.client.EJBReceiverInvocationContext$ResultProducer$Failed.getResult(EJBReceiverInvocationContext.java:151)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:567)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:56)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:133)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:118)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:78)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:172)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:907)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:165)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100)
> at com.sun.proxy.$Proxy61.calculateInterest(Unknown Source)
> at br.com.client.RemoteEJBClient.main(RemoteEJBClient.java:20)
> at br.com.client.RemoteEJBClient.func(RemoteEJBClient.java:14)
> at org.apache.jsp.index_jsp._jspService(index_jsp.java:99)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> ... 47 more
> Suppressed: javax.ejb.NoSuchEJBException: EJBCLIENT000024: No EJB receiver available for handling destination "http://localhost:8080/wildfly-services"
> at org.jboss.ejb.client.EJBClientContext.resolveReceiver(EJBClientContext.java:571)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:438)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocation(RemotingEJBClientInterceptor.java:51)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocation(TransactionPostDiscoveryInterceptor.java:79)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocation(DiscoveryEJBClientInterceptor.java:90)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocation(NamingEJBClientInterceptor.java:66)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:165)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.EJBClientInvocationContext$$Lambda$915/72354668.accept(Unknown Source)
> at org.wildfly.common.context.Contextual.runExConsumer(Contextual.java:203)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:302)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:161)
> ... 55 more
> {panel}
> This behaviour is reproduceable with the attached project. One detail not mentioned in the jboss forum is that I started wildfly 11 with standalone-full.xml
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9903) Cannot remove modcluster subsystem for the first time
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9903?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-9903:
--------------------------------------
Thanks for the report.
This looks like a regression introduced with https://github.com/wildfly/wildfly/commit/ca46ebe7820c34818d175079385a83d...
Note that we have a test but that only operates on the model with no runtime, here is a patch to expand the test case to actually fail and reproduce this issue.
{noformat}
diff --git a/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/mod_cluster/ModClusterSubsystemAddTestCase.java b/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/mod_cluster/ModClusterSubsystemAddTestCase.java
index 6d7ce63dc3..e2a996c9ef 100644
--- a/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/mod_cluster/ModClusterSubsystemAddTestCase.java
+++ b/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/mod_cluster/ModClusterSubsystemAddTestCase.java
@@ -32,6 +32,7 @@ import org.jboss.as.cli.CommandContext;
import org.jboss.as.cli.batch.Batch;
import org.jboss.as.controller.client.ModelControllerClient;
import org.jboss.as.test.integration.management.util.CLITestUtil;
+import org.jboss.as.test.shared.ServerReload;
import org.jboss.dmr.ModelNode;
import org.junit.Assert;
import org.junit.Test;
@@ -77,6 +78,8 @@ public class ModClusterSubsystemAddTestCase {
outcome = response.get("outcome").asString();
Assert.assertEquals("Adding mod_cluster subsystem failed! " + request.toJSONString(false), SUCCESS, outcome);
+ ServerReload.executeReloadAndWaitForCompletion(controllerClient);
+
// Test subsystem remove
request = ctx.buildRequest("/subsystem=modcluster:remove");
response = controllerClient.execute(request);
{noformat}
> Cannot remove modcluster subsystem for the first time
> -----------------------------------------------------
>
> Key: WFLY-9903
> URL: https://issues.jboss.org/browse/WFLY-9903
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 12.0.0.Beta1
> Environment: Debian stable, openjdk 8
> Reporter: Marcel Šebek
> Assignee: Radoslav Husar
>
> Removal of modcluster subsystem first produces an error, and succeeds for the second time:
> [standalone@localhost:9990 /] /subsystem=modcluster:remove()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0441: Operation has resulted in failed or missing services
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> ",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=modcluster:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> Error in the wildfly output is
> 18:35:11,316 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 78) MODCLUSTER000002: Initiating mod_cluster shutdown
> 18:35:11,319 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("remove") failed - address: ([("subsystem" => "modcluster")]) - failure description: "WFLYCTL0441: Operation has resulted in failed or missing services
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> "
> 18:35:11,321 INFO [org.jboss.as.controller] (management-handler-thread - 2) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> For the second time, it succeeds.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9744) Improve Infinispan subsystem model descriptions
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9744?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9744:
---------------------------------
Description:
In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
* should describe behavior
* should avoid using domain model terminology (e.g. attributes, child)
* take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
* remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
{code}
"deprecated" => {
"since" => "5.0.0",
"reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
},
{code}
Upon completion, we can remove the sections from documentation and link.
was:
In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
* should describe behavior
* should avoid using domain model terminology (e.g. attributes, child)
* take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
* remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
{quote}
"deprecated" => {
"since" => "5.0.0",
"reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
},
{quote}
Upon completion, we can remove the sections from documentation and link.
> Improve Infinispan subsystem model descriptions
> ------------------------------------------------
>
> Key: WFLY-9744
> URL: https://issues.jboss.org/browse/WFLY-9744
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
>
> In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
> * should describe behavior
> * should avoid using domain model terminology (e.g. attributes, child)
> * take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
> * remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
> {code}
> "deprecated" => {
> "since" => "5.0.0",
> "reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
> },
> {code}
> Upon completion, we can remove the sections from documentation and link.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9744) Improve Infinispan subsystem model descriptions
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9744?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9744:
---------------------------------
Description:
In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
* should describe behavior
* should avoid using domain model terminology (e.g. attributes, child)
* take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
* remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
{noformat}
"deprecated" => {
"since" => "5.0.0",
"reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
},
{noformat}
Upon completion, we can remove the sections from documentation and link.
was:
In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
* should describe behavior
* should avoid using domain model terminology (e.g. attributes, child)
* take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
Upon completion, we can remove the sections from documentation and link.
> Improve Infinispan subsystem model descriptions
> ------------------------------------------------
>
> Key: WFLY-9744
> URL: https://issues.jboss.org/browse/WFLY-9744
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
>
> In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
> * should describe behavior
> * should avoid using domain model terminology (e.g. attributes, child)
> * take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
> * remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
> {noformat}
> "deprecated" => {
> "since" => "5.0.0",
> "reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
> },
> {noformat}
> Upon completion, we can remove the sections from documentation and link.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9744) Improve Infinispan subsystem model descriptions
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9744?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9744:
---------------------------------
Description:
In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
* should describe behavior
* should avoid using domain model terminology (e.g. attributes, child)
* take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
* remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
{quote}
"deprecated" => {
"since" => "5.0.0",
"reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
},
{quote}
Upon completion, we can remove the sections from documentation and link.
was:
In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
* should describe behavior
* should avoid using domain model terminology (e.g. attributes, child)
* take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
* remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
{noformat}
"deprecated" => {
"since" => "5.0.0",
"reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
},
{noformat}
Upon completion, we can remove the sections from documentation and link.
> Improve Infinispan subsystem model descriptions
> ------------------------------------------------
>
> Key: WFLY-9744
> URL: https://issues.jboss.org/browse/WFLY-9744
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
>
> In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
> * should describe behavior
> * should avoid using domain model terminology (e.g. attributes, child)
> * take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
> * remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
> {quote}
> "deprecated" => {
> "since" => "5.0.0",
> "reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
> },
> {quote}
> Upon completion, we can remove the sections from documentation and link.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3479) Deploying an empty deployment and adding content later fails in a composite
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3479?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3479:
-------------------------------------
Fix Version/s: 5.0.0.Alpha1
(was: 4.0.0.CR1)
> Deploying an empty deployment and adding content later fails in a composite
> ---------------------------------------------------------------------------
>
> Key: WFCORE-3479
> URL: https://issues.jboss.org/browse/WFCORE-3479
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.10.Final
> Reporter: Kabir Khan
> Assignee: ehsavoie Hugonnet
> Fix For: 5.0.0.Alpha1
>
>
> When adding mixed domain tests for EAP 7.1.0 I could not get the MixedDomainDeployment710TestCase.testExplodedDeployment() test to work. Comparing with the core domain ExplodedDeploymentTestCase.testInstallAndExplodeDeploymentOnDCFromScratch(), they both do the following:
> {code}
> 1) Create an empty deployment
> 2) Add some content to the deployment using input streams
> 3) Add the deployment to a server group
> {code}
> However, they differ in that ExplodedDeploymentTestCase does this as individual steps, while MixedDomainDeployment710TestCase does this in a composite. I have a branch at https://github.com/kabir/wildfly-core/tree/WFCORE-3479 which expands ExplodedDeploymentTestCase to demonstrate the problem.
> Going back to MixedDomainDeploymentTestCase, the testExplodedDeployment() test pushes the following composite to the DC:
> {code}
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "content" => [{"empty" => true}]
> },
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [
> {
> "target-path" => "index.html",
> "input-stream-index" => 0
> },
> {
> "target-path" => "index2.html",
> "input-stream-index" => 1
> }
> ]
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "other-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "main-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> }
> ],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "b016e0a3-4175-4f40-b6b9-779fc0fd1745",
> "execute-for-coordinator" => true
> }
> }
> {code}
> What ends up being pushed to the slave is:
> {code}
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x8f, 0x7c, 0x8c, 0x80, 0x35, 0x88, 0x36, 0x16,
> 0x61, 0xfa, 0x0a, 0x10, 0x30, 0xf9, 0x13, 0x29,
> 0x04, 0x05, 0x9d, 0x82
> },
> "archive" => false
> }],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
> },
> "runtime-name" => undefined
> },
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "target-path" => "."
> }],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
> },
> "path" => [
> "index.html",
> "index2.html"
> ]
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "other-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "main-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> }
> ],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc",
> "execute-for-coordinator" => true
> }
> }
> {code}
> The error reported by the DC is:
> {code}
> {
> "outcome" => "failed",
> "result" => {
> "step-1" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-2" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-3" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-4" => {
> "outcome" => "failed",
> "rolled-back" => true
> }
> },
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}}}}}}}},
> "rolled-back" => true,
> "server-groups" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "result" => {
> "step-1" => {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found",
> "rolled-back" => true
> },
> "step-2" => {"outcome" => undefined}
> },
> "failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}},
> "rolled-back" => true
> }}}}}}
> }
> {code}
> Having debugged the slave process a bit, I *believe* the following is what is passed to the servers by the slave HC:
> {code}
> {
> "operation" => "composite",
> "steps" => [
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "target-path" => "."
> }],
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "path" => [
> "index.html",
> "index2.html"
> ]
> },
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "enabled" => true,
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "runtime-name" => "test.war",
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "archive" => false
> }]
> }
> ],
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "address" => []
> }
> {code}
> Note that 'add-content' now comes BEFORE 'add', which would explain the "Management resource '[(\"deployment\" => \"test.war\")]' not found".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3542) Elytron JDBC realm password mapping is not consistent with underlying implementation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3542?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3542:
-------------------------------------
Fix Version/s: 5.0.0.Alpha1
(was: 4.0.0.CR1)
> Elytron JDBC realm password mapping is not consistent with underlying implementation
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-3542
> URL: https://issues.jboss.org/browse/WFCORE-3542
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: David Lloyd
> Assignee: Darran Lofthouse
> Fix For: 5.0.0.Alpha1
>
>
> There is no way to configure the JDBC realm to use modular crypt in WildFly, even though the underlying realm does support it.
> The problem is that the {{salt-index}} and {{itereration-count-index}} attributes should be optional, and if they not given, a value of {{-1}} should be passed to the mapper. By omitting both of these values, the database column values will then be recognized as modular-crypt strings.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months