[JBoss JIRA] (WFLY-11262) violation of call-by-value if a outbound connection is configured
by Wolf-Dieter Fink (Jira)
Wolf-Dieter Fink created WFLY-11262:
---------------------------------------
Summary: violation of call-by-value if a outbound connection is configured
Key: WFLY-11262
URL: https://issues.jboss.org/browse/WFLY-11262
Project: WildFly
Issue Type: Bug
Components: EJB
Reporter: Wolf-Dieter Fink
If the server default configuration is used an EJB invocation via @Remote interface is, according to the specification, with call-by-value.
But if the application is configured with jboss-ejb-client.xml to have a remote-outbound-connection the EJB invocation via @Remote is done as call-by-reference no matter whether the configuration is default or
<in-vm-remote-interface-invocation pass-by-value="true"/>
is used.
This is a violation of the specification and can cause serious unexpected issues at runtime for the application if the parameters or return values are mutable
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3208) [Infinispan indexing] Creating Guided rule in "<default>" package causes exception in UI
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3208?page=com.atlassian.jira.plugi... ]
Michael Anstis reassigned DROOLS-3208:
--------------------------------------
Assignee: Adriel Paredes (was: Michael Anstis)
> [Infinispan indexing] Creating Guided rule in "<default>" package causes exception in UI
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-3208
> URL: https://issues.jboss.org/browse/DROOLS-3208
> Project: Drools
> Issue Type: Bug
> Components: Guided Rule Editor
> Reporter: Jan Hrcek
> Assignee: Adriel Paredes
> Priority: Major
>
> When using infinispan as indexing backend, When you create new Guided rule in "<default>" package, the UI shows unexpected exception with the following stack trace (obtained by copy to clipboard button)
> {code:java}
> {"ToSubject":"org.kie.workbench.common.services.shared.rulename.RuleNamesService:RPC","CommandType":"getRuleNames:org.uberfire.backend.vfs.Path:java.lang.String:","Qualifiers":{"^EncodedType":"java.util.ArrayList","^ObjectID":"1","^Value":[]},"ReplyTo":"org.kie.workbench.common.services.shared.rulename.RuleNamesService:RPC.getRuleNames:org.uberfire.backend.vfs.Path:java.lang.String::240:RespondTo:RPC","ErrorTo":"org.kie.workbench.common.services.shared.rulename.RuleNamesService:RPC.getRuleNames:org.uberfire.backend.vfs.Path:java.lang.String::240:Errors:RPC","AdditionalDetails":"<tt>
> org.jboss.errai.bus.client.api.base.MessageDeliveryFailure: error invoking RPC endpoint public abstract java.util.Collection org.kie.workbench.common.services.shared.rulename.RuleNamesService.getRuleNames(org.uberfire.backend.vfs.Path,java.lang.String)
> at org.jboss.errai.bus.server.io.AbstractRPCMethodCallback.invokeMethodFromMessage(AbstractRPCMethodCallback.java:75)
> at org.jboss.errai.bus.server.io.ValueReplyRPCEndpointCallback.callback(ValueReplyRPCEndpointCallback.java:40)
> at org.jboss.errai.bus.server.io.RemoteServiceCallback.callback(RemoteServiceCallback.java:54)
> at org.jboss.errai.cdi.server.CDIExtensionPoints$2.callback(CDIExtensionPoints.java:448)
> at org.jboss.errai.bus.server.DeliveryPlan.deliver(DeliveryPlan.java:47)
> at org.jboss.errai.bus.server.ServerMessageBusImpl.sendGlobal(ServerMessageBusImpl.java:297)
> at org.jboss.errai.bus.server.SimpleDispatcher.dispatchGlobal(SimpleDispatcher.java:46)
> at org.jboss.errai.bus.server.service.ErraiServiceImpl.store(ErraiServiceImpl.java:96)
> at org.jboss.errai.bus.server.service.ErraiServiceImpl.store(ErraiServiceImpl.java:113)
> at org.jboss.errai.bus.server.servlet.DefaultBlockingServlet.doPost(DefaultBlockingServlet.java:144)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:130)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at org.uberfire.ext.security.server.SecureHeadersFilter.doFilter(SecureHeadersFilter.java:110)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at org.uberfire.ext.security.server.SecurityIntegrationFilter.doFilter(SecurityIntegrationFilter.java:70)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:65)
> 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.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1501)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1501)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1501)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1501)
> 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:330)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException: <No Message>
> at org.kie.workbench.common.services.refactoring.backend.server.query.response.RuleNameResponseBuilder.lambda$getRuleNamesFromKObject$1(RuleNameResponseBuilder.java:98)
> at java.util.Optional.flatMap(Optional.java:241)
> at org.kie.workbench.common.services.refactoring.backend.server.query.response.RuleNameResponseBuilder.getRuleNamesFromKObject(RuleNameResponseBuilder.java:98)
> at org.kie.workbench.common.services.refactoring.backend.server.query.response.RuleNameResponseBuilder.buildResponse(RuleNameResponseBuilder.java:64)
> at org.kie.workbench.common.services.refactoring.backend.server.query.RefactoringQueryServiceImpl.query(RefactoringQueryServiceImpl.java:214)
> at org.kie.workbench.common.services.refactoring.backend.server.query.RefactoringQueryServiceImpl$Proxy$_$$_WeldClientProxy.query(Unknown Source)
> at org.kie.workbench.common.services.backend.rulename.RuleNameServiceImpl.queryRuleNames(RuleNameServiceImpl.java:79)
> at org.kie.workbench.common.services.backend.rulename.RuleNameServiceImpl.getRuleNames(RuleNameServiceImpl.java:69)
> at org.kie.workbench.common.services.backend.rulename.RuleNameServiceImpl$Proxy$_$$_WeldClientProxy.getRuleNames(Unknown Source)
> 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:498)
> at org.jboss.errai.bus.server.io.AbstractRPCMethodCallback.invokeMethodFromMessage(AbstractRPCMethodCallback.java:65)
> at org.jboss.errai.bus.server.io.ValueReplyRPCEndpointCallback.callback(ValueReplyRPCEndpointCallback.java:40)
> at org.jboss.errai.bus.server.io.RemoteServiceCallback.callback(RemoteServiceCallback.java:54)
> at org.jboss.errai.cdi.server.CDIExtensionPoints$2.callback(CDIExtensionPoints.java:448)
> at org.jboss.errai.bus.server.DeliveryPlan.deliver(DeliveryPlan.java:47)
> at org.jboss.errai.bus.server.ServerMessageBusImpl.sendGlobal(ServerMessageBusImpl.java:297)
> at org.jboss.errai.bus.server.SimpleDispatcher.dispatchGlobal(SimpleDispatcher.java:46)
> at org.jboss.errai.bus.server.service.ErraiServiceImpl.store(ErraiServiceImpl.java:96)
> at org.jboss.errai.bus.server.service.ErraiServiceImpl.store(ErraiServiceImpl.java:113)
> at org.jboss.errai.bus.server.servlet.DefaultBlockingServlet.doPost(DefaultBlockingServlet.java:144)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:130)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at org.uberfire.ext.security.server.SecureHeadersFilter.doFilter(SecureHeadersFilter.java:110)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at org.uberfire.ext.security.server.SecurityIntegrationFilter.doFilter(SecurityIntegrationFilter.java:70)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:65)
> 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.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1501)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1501)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1501)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1501)
> 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:330)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> <\/tt>"}
> {code}
> This only happens for DRL files (not for any other asset type) and only with infinispan (not with default Lucene indexing).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11260) Appache httpcomponents.core cannot see required Commons codec classes
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFLY-11260?page=com.atlassian.jira.plugin... ]
Yeray Borges resolved WFLY-11260.
---------------------------------
Resolution: Duplicate Issue
Radoslav, thank you for reporting this issue, it is already fixed for wildfly 15: https://issues.jboss.org/browse/WFCORE-4083
> Appache httpcomponents.core cannot see required Commons codec classes
> ---------------------------------------------------------------------
>
> Key: WFLY-11260
> URL: https://issues.jboss.org/browse/WFLY-11260
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.0.Final
> Reporter: Radoslav Ivanov
> Assignee: Yeray Borges
> Priority: Major
>
> Appache httpcomponents.core cannot see required Commons codec classes
> {code:java}
> java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64
> at org.apache.httpcomponents.core//org.apache.http.impl.auth.BasicScheme.authenticate(BasicScheme.java:168)
> at org.apache.httpcomponents.core//org.apache.http.impl.auth.HttpAuthenticator.doAuth(HttpAuthenticator.java:239)
> at org.apache.httpcomponents.core//org.apache.http.impl.auth.HttpAuthenticator.generateAuthResponse(HttpAuthenticator.java:218)
> at org.apache.httpcomponents.core//org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:262)
> at org.apache.httpcomponents.core//org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.httpcomponents.core//org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at org.apache.httpcomponents.core//org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at org.apache.httpcomponents.core//org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at org.apache.httpcomponents.core//org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> {code}
> The fix is to add a module dependency to "org.apache.commons.codec" in the "org.apache.httpcomponents.core" module.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11260) Appache httpcomponents.core cannot see required Commons codec classes
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFLY-11260?page=com.atlassian.jira.plugin... ]
Yeray Borges reassigned WFLY-11260:
-----------------------------------
Priority: Major (was: Blocker)
Assignee: Yeray Borges (was: Stuart Douglas)
> Appache httpcomponents.core cannot see required Commons codec classes
> ---------------------------------------------------------------------
>
> Key: WFLY-11260
> URL: https://issues.jboss.org/browse/WFLY-11260
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.0.Final
> Reporter: Radoslav Ivanov
> Assignee: Yeray Borges
> Priority: Major
>
> Appache httpcomponents.core cannot see required Commons codec classes
> {code:java}
> java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64
> at org.apache.httpcomponents.core//org.apache.http.impl.auth.BasicScheme.authenticate(BasicScheme.java:168)
> at org.apache.httpcomponents.core//org.apache.http.impl.auth.HttpAuthenticator.doAuth(HttpAuthenticator.java:239)
> at org.apache.httpcomponents.core//org.apache.http.impl.auth.HttpAuthenticator.generateAuthResponse(HttpAuthenticator.java:218)
> at org.apache.httpcomponents.core//org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:262)
> at org.apache.httpcomponents.core//org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.httpcomponents.core//org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at org.apache.httpcomponents.core//org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at org.apache.httpcomponents.core//org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at org.apache.httpcomponents.core//org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> {code}
> The fix is to add a module dependency to "org.apache.commons.codec" in the "org.apache.httpcomponents.core" module.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11261) CLI unable to refer jberet resources after run PurgeBatchlet
by Norito Agetsuma (Jira)
[ https://issues.jboss.org/browse/WFLY-11261?page=com.atlassian.jira.plugin... ]
Norito Agetsuma updated WFLY-11261:
-----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/11793
> CLI unable to refer jberet resources after run PurgeBatchlet
> ------------------------------------------------------------
>
> Key: WFLY-11261
> URL: https://issues.jboss.org/browse/WFLY-11261
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 14.0.0.Final
> Reporter: Norito Agetsuma
> Assignee: Cheng Fang
> Priority: Major
> Attachments: jberet-sample.zip
>
>
> It's not possible to refer jberet runtime resource after execute org.jberet.repository.PurgeBatchlet with batch property "purgeJobsByNames".
> {code:title=jboss-cli output before execute PurgeBatchlet}
> [standalone@localhost:9990 /] /deployment=jberet-sample.war/subsystem=batch-jberet/job=dummy-job:read-resource(include-runtime=true,recursive=true)
> {
> "outcome" => "success",
> "result" => {
> "instance-count" => 1,
> "job-xml-names" => ["dummy-job.xml"],
> "running-executions" => 0,
> "execution" => {"1" => {
> "batch-status" => "COMPLETED",
> "create-time" => "2018-10-31T14:54:27.297+0900",
> "end-time" => "2018-10-31T14:54:27.343+0900",
> "exit-status" => "COMPLETED",
> "instance-id" => 1L,
> "last-updated-time" => "2018-10-31T14:54:27.343+0900",
> "start-time" => "2018-10-31T14:54:27.306+0900"
> }}
> }
> }
> {code}
> {code:title=jboss-cli output after PurgeBatchlet}
> /deployment=jberet-sample.war/subsystem=batch-jberet/job=dummy-job:read-resource(include-runtime=true,recursive=true)
> {
> "outcome" => "failed",
> "rolled-back" => true
> }
> {code}
> Then output following server.log
> {code}
> 14:55:23,104 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "jberet-sample.war"),
> ("subsystem" => "batch-jberet"),
> ("job" => "dummy-job"),
> ("execution" => "1")
> ]): javax.batch.operations.NoSuchJobExecutionException: JBERET000604: No job execution with id 1
> at org.jberet.operations.AbstractJobOperator.getJobExecutionImpl(AbstractJobOperator.java:354)
> at org.jberet.operations.AbstractJobOperator.getJobInstance(AbstractJobOperator.java:310)
> at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobInstance(JobOperatorService.java:281)
> at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobExecution(JobOperatorService.java:308)
> at org.wildfly.extension.batch.jberet.deployment.BatchJobExecutionResourceDefinition$JobExecutionOperationStepHandler.updateModel(BatchJobExecutionResourceDefinition.java:200)
> at org.wildfly.extension.batch.jberet.deployment.JobOperationReadOnlyStepHandler.execute(JobOperationReadOnlyStepHandler.java:47)
> at org.wildfly.extension.batch.jberet.deployment.JobOperationStepHandler.executeRuntime(JobOperationStepHandler.java:74)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> 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:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> Even though delete JobExecution in JobRepository, JobExecution id "1" still show by JBoss CLI.
> {code:title=jboss-cli output}
> [standalone@localhost:9990 /] /deployment=jberet-sample.war/subsystem=batch-jberet/job=dummy-job:read-resource
> {
> "outcome" => "success",
> "result" => {"execution" => {"1" => undefined}}
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11261) CLI unable to refer jberet resources after run PurgeBatchlet
by Norito Agetsuma (Jira)
[ https://issues.jboss.org/browse/WFLY-11261?page=com.atlassian.jira.plugin... ]
Norito Agetsuma moved JBEAP-15751 to WFLY-11261:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-11261 (was: JBEAP-15751)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Batch
(was: Batch)
Affects Version/s: 14.0.0.Final
(was: 7.1.4.GA)
> CLI unable to refer jberet resources after run PurgeBatchlet
> ------------------------------------------------------------
>
> Key: WFLY-11261
> URL: https://issues.jboss.org/browse/WFLY-11261
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 14.0.0.Final
> Reporter: Norito Agetsuma
> Assignee: Cheng Fang
> Priority: Major
> Attachments: jberet-sample.zip
>
>
> It's not possible to refer jberet runtime resource after execute org.jberet.repository.PurgeBatchlet with batch property "purgeJobsByNames".
> {code:title=jboss-cli output before execute PurgeBatchlet}
> [standalone@localhost:9990 /] /deployment=jberet-sample.war/subsystem=batch-jberet/job=dummy-job:read-resource(include-runtime=true,recursive=true)
> {
> "outcome" => "success",
> "result" => {
> "instance-count" => 1,
> "job-xml-names" => ["dummy-job.xml"],
> "running-executions" => 0,
> "execution" => {"1" => {
> "batch-status" => "COMPLETED",
> "create-time" => "2018-10-31T14:54:27.297+0900",
> "end-time" => "2018-10-31T14:54:27.343+0900",
> "exit-status" => "COMPLETED",
> "instance-id" => 1L,
> "last-updated-time" => "2018-10-31T14:54:27.343+0900",
> "start-time" => "2018-10-31T14:54:27.306+0900"
> }}
> }
> }
> {code}
> {code:title=jboss-cli output after PurgeBatchlet}
> /deployment=jberet-sample.war/subsystem=batch-jberet/job=dummy-job:read-resource(include-runtime=true,recursive=true)
> {
> "outcome" => "failed",
> "rolled-back" => true
> }
> {code}
> Then output following server.log
> {code}
> 14:55:23,104 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "jberet-sample.war"),
> ("subsystem" => "batch-jberet"),
> ("job" => "dummy-job"),
> ("execution" => "1")
> ]): javax.batch.operations.NoSuchJobExecutionException: JBERET000604: No job execution with id 1
> at org.jberet.operations.AbstractJobOperator.getJobExecutionImpl(AbstractJobOperator.java:354)
> at org.jberet.operations.AbstractJobOperator.getJobInstance(AbstractJobOperator.java:310)
> at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobInstance(JobOperatorService.java:281)
> at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobExecution(JobOperatorService.java:308)
> at org.wildfly.extension.batch.jberet.deployment.BatchJobExecutionResourceDefinition$JobExecutionOperationStepHandler.updateModel(BatchJobExecutionResourceDefinition.java:200)
> at org.wildfly.extension.batch.jberet.deployment.JobOperationReadOnlyStepHandler.execute(JobOperationReadOnlyStepHandler.java:47)
> at org.wildfly.extension.batch.jberet.deployment.JobOperationStepHandler.executeRuntime(JobOperationStepHandler.java:74)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> 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:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> Even though delete JobExecution in JobRepository, JobExecution id "1" still show by JBoss CLI.
> {code:title=jboss-cli output}
> [standalone@localhost:9990 /] /deployment=jberet-sample.war/subsystem=batch-jberet/job=dummy-job:read-resource
> {
> "outcome" => "success",
> "result" => {"execution" => {"1" => undefined}}
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3193) UX to support selection of multiple data/domain object instances
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3193?page=com.atlassian.jira.plugi... ]
Klara Kufova edited comment on DROOLS-3193 at 10/31/18 4:57 AM:
----------------------------------------------------------------
[~uxdlc], it is currently not possible to reorder columns or rows once they are created, and as far as I know, such feature is not even planned in the future (but I may be wrong). It is however possible to insert a column or a row basically anywhere in the table, which is, in my opinion, sufficient. Do you agree?
Columns are not numbered, but rows are.
Regarding the last image you posted, in the current implementation, it is not possible to achieve it (all columns whose instance type is {{Dispute}} would get merged together, so there would be only one header row called {{Dispute}} and the header row below would be divided into six columns as in the image). You need to introduce an alias to create this structure (such as {{First dispute}}, {{Second dispute}}, {{Third dispute}}). But otherwise, it is a valid grid.
was (Author: kkufova):
[~uxdlc], it is currently not possible to reorder columns or rows once they are created, and I don't think such feature is even planned in the future. It is however possible to insert a column or a row basically anywhere in the table, which is, in my opinion, sufficient. Do you agree? As far as I know,
Columns are not numbered, but rows are.
Regarding the last image you posted, in the current implementation, it is not possible to achieve it (all columns whose instance type is {{Dispute}} would get merged together, so there would be only one header row called {{Dispute}} and the header row below would be divided into six columns as in the image). You need to introduce an alias to create this structure (such as {{First dispute}}, {{Second dispute}}, {{Third dispute}}). But otherwise, it is a valid grid.
> UX to support selection of multiple data/domain object instances
> ----------------------------------------------------------------
>
> Key: DROOLS-3193
> URL: https://issues.jboss.org/browse/DROOLS-3193
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2018-10-30 at 10.50.55 AM.png
>
>
> As user I want to use multiple instances of the same data object in my test scenarios (multiple instances support) (i.e. scenario with more than one instance of “Person”...), so that I can create a test scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3193) UX to support selection of multiple data/domain object instances
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3193?page=com.atlassian.jira.plugi... ]
Klara Kufova commented on DROOLS-3193:
--------------------------------------
[~uxdlc], it is currently not possible to reorder columns or rows once they are created, and I don't think such feature is even planned in the future. It is however possible to insert a column or a row basically anywhere in the table, which is, in my opinion, sufficient. Do you agree? As far as I know,
Columns are not numbered, but rows are.
Regarding the last image you posted, in the current implementation, it is not possible to achieve it (all columns whose instance type is {{Dispute}} would get merged together, so there would be only one header row called {{Dispute}} and the header row below would be divided into six columns as in the image). You need to introduce an alias to create this structure (such as {{First dispute}}, {{Second dispute}}, {{Third dispute}}). But otherwise, it is a valid grid.
> UX to support selection of multiple data/domain object instances
> ----------------------------------------------------------------
>
> Key: DROOLS-3193
> URL: https://issues.jboss.org/browse/DROOLS-3193
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2018-10-30 at 10.50.55 AM.png
>
>
> As user I want to use multiple instances of the same data object in my test scenarios (multiple instances support) (i.e. scenario with more than one instance of “Person”...), so that I can create a test scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3209) Datasource Management Errors after changing Wildfly management to HTTPS and 9993
by Marijan Cavar (Jira)
Marijan Cavar created DROOLS-3209:
-------------------------------------
Summary: Datasource Management Errors after changing Wildfly management to HTTPS and 9993
Key: DROOLS-3209
URL: https://issues.jboss.org/browse/DROOLS-3209
Project: Drools
Issue Type: Bug
Affects Versions: 7.12.0.Final
Environment: RHEL 7.5, Wildfly 11.0.0.Final, Drools 7.12.0.Final.
Reporter: Marijan Cavar
Assignee: Mario Fusco
I have enabled HTTPS on Drools application and Wildfly Management port. Seems to work everything fine if I connect to Wildfly management port (9993) and application port 8443. But after the application comes up, app is throwing errors about reaching datasource, and that is management address and port of an Application server. I have changed the configuration in WEB-INF/classes/datasource-management.properties of WAR file to:
datasource.management.wildfly.host=10.20.30.237
datasource.management.wildfly.port=9993
Error I am getting in the server.log:
[org.kie.workbench.common.screens.datasource.management.backend.integration.wildfly.WildflyBaseClient] (pool-7-thread-1) It was not possible to open connection to Wildfly/EAP server.: java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to http-remoting://10.20.30.237:9993. The connection failed.
It seems to me that the problem is related with the "http-remoting" that app is still using. How to change this to "https-remoting"?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month