[JBoss JIRA] (WFCORE-4882) Correct minOccurts value for host element in XSD
by Chao Wang (Jira)
[ https://issues.redhat.com/browse/WFCORE-4882?page=com.atlassian.jira.plug... ]
Chao Wang updated WFCORE-4882:
------------------------------
Summary: Correct minOccurts value for host element in XSD (was: Broken 'domain.xml' after migration of <host-scoped-roles> leading to 'Boostrap error' in HAL)
> Correct minOccurts value for host element in XSD
> ------------------------------------------------
>
> Key: WFCORE-4882
> URL: https://issues.redhat.com/browse/WFCORE-4882
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Server
> Affects Versions: 11.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
> Attachments: Screenshot.png
>
>
> Broken 'domain.xml' after migration of <host-scoped-roles> leading to 'Boostrap error' in HAL.
> A broken domain configuration
> {code:xml}
> <host-scoped-roles>
> <role name="custom-role-name" base-role="Administrator">
> </role>
> </host-scoped-roles>
> {code}
> This broken configuration doesn't bother the old HAL, so user only see the issue from HAL after the migration.
> The correct one should be:
> {code:xml}
> <host-scoped-roles>
> <role name="dbaish" base-role="Administrator">
> <host name="master"/>
> </role>
> </host-scoped-roles>
> {code}
> https://github.com/wildfly/wildfly-core/blob/11.0.0.Final/server/src/main... show minOccurs="1", which is incorrect, the minOccurs should be 0 here.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFCORE-4882) Broken 'domain.xml' after migration of <host-scoped-roles> leading to 'Boostrap error' in HAL
by Chao Wang (Jira)
[ https://issues.redhat.com/browse/WFCORE-4882?page=com.atlassian.jira.plug... ]
Chao Wang updated WFCORE-4882:
------------------------------
Description:
Broken 'domain.xml' after migration of <host-scoped-roles> leading to 'Boostrap error' in HAL.
A broken domain configuration
{code:xml}
<host-scoped-roles>
<role name="custom-role-name" base-role="Administrator">
</role>
</host-scoped-roles>
{code}
This broken configuration doesn't bother the old HAL, so user only see the issue from HAL after the migration.
The correct one should be:
{code:xml}
<host-scoped-roles>
<role name="dbaish" base-role="Administrator">
<host name="master"/>
</role>
</host-scoped-roles>
{code}
https://github.com/wildfly/wildfly-core/blob/11.0.0.Final/server/src/main... show minOccurs="1", which is incorrect, the minOccurs should be 0 here.
was:
When migrating a domain configuration from JBoss EAP 7.1.6 having a broken {{<host-scoped-roles>}} configuration, the resulting {{domain.xml}} on EAP 7.2 is broken as well.
JBoss EAP 7.1 is relaxed during accessing the HAL and simply ignores the broken configuration, whereas JBoss EAP 7.2 will not allow access to the HAL and report a *_Bootstrap error_*.
The {{jboss-server-migration.[sh|bat]}} should identify this broken configuration and *deny* the migration of it.
> Broken 'domain.xml' after migration of <host-scoped-roles> leading to 'Boostrap error' in HAL
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-4882
> URL: https://issues.redhat.com/browse/WFCORE-4882
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Server
> Affects Versions: 11.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
> Attachments: Screenshot.png
>
>
> Broken 'domain.xml' after migration of <host-scoped-roles> leading to 'Boostrap error' in HAL.
> A broken domain configuration
> {code:xml}
> <host-scoped-roles>
> <role name="custom-role-name" base-role="Administrator">
> </role>
> </host-scoped-roles>
> {code}
> This broken configuration doesn't bother the old HAL, so user only see the issue from HAL after the migration.
> The correct one should be:
> {code:xml}
> <host-scoped-roles>
> <role name="dbaish" base-role="Administrator">
> <host name="master"/>
> </role>
> </host-scoped-roles>
> {code}
> https://github.com/wildfly/wildfly-core/blob/11.0.0.Final/server/src/main... show minOccurs="1", which is incorrect, the minOccurs should be 0 here.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFWIP-310) Insufficient validation for WildFlyServer without applicationImage and applicationSource
by Jan Blizňák (Jira)
Jan Blizňák created WFWIP-310:
---------------------------------
Summary: Insufficient validation for WildFlyServer without applicationImage and applicationSource
Key: WFWIP-310
URL: https://issues.redhat.com/browse/WFWIP-310
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Jan Blizňák
Assignee: Jeff Mesnil
Operator phase 2 EAP7-1337 extends WildFlyServer CRD with applicationSource spec.
According to analysis, one of these _must_ be specifed:
* applicationImage
* applicationSource
However, creating CR without any of these passes, without any validation error or log for end user, but such operator is then useless.
I am using wildfly-operator image build from latest https://github.com/wildfly/wildfly-operator/pull/132
{code:java}
# given you have WildFlyServer CRD already installed on cluster
cat > demo.yaml << EOF
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: demo-should-fail
spec:
replicas: 1
EOF
oc create -f demo.yaml
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-5190) ClassCastException while Evaluating rules
by Minal Bhalodi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5190?page=com.atlassian.jira.plug... ]
Minal Bhalodi commented on DROOLS-5190:
---------------------------------------
Not able to reproduce this problem but looking at the data, I found out that first it was throwing classCastException with message for first three request:
[className=DroolsKieContainerCommandServiceImpl]- Error calling container <container_name>java.lang.ClassCastException: org.drools.core.reteoo.RuleTerminalNode cannot be cast to org.drools.core.reteoo.LeftInputAdapterNode
at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:109)
and then message became null:
[className=DroolsKieContainerCommandServiceImpl]- Error calling container '<container_name>' java.lang.ClassCastException: null
> ClassCastException while Evaluating rules
> -----------------------------------------
>
> Key: DROOLS-5190
> URL: https://issues.redhat.com/browse/DROOLS-5190
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 7.18.0.Final
> Reporter: Minal Bhalodi
> Assignee: Mario Fusco
> Priority: Major
>
> We are seeing ClasscastException while evaluating kie rules. Everytime we see this issue we have to restart the server to fix it.
> This doens't happen to all our kubernetes pods where same kie-server is running. This happens to either 1 or 2 pods all the time.
> This issue is also not reproducible
> Also we see different stack Trace with ClassCastException every time, Here I am pasting some of them:
> ERROR 1 :
> [className=DroolsKieContainerCommandServiceImpl]- Error calling container 'kie_personalization'java.lang.ClassCastException: null
> ERROR 2:
> Error calling container 'kie_personalization'java.lang.ClassCastException: org.drools.core.reteoo.RuleTerminalNode cannot be cast to org.drools.core.reteoo.LeftInputAdapterNode
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:109)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:213)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:88)
> at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34)
> at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1062)
> at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1009)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1001)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1330)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1321)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1305)
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109)
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:34)
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:160)
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:66)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:251)
> at org.kie.server.services.drools.RulesExecutionService.call(RulesExecutionService.java:61)
> at org.kie.server.services.drools.DroolsKieContainerCommandServiceImpl.callContainer(DroolsKieContainerCommandServiceImpl.java:70)
> at org.kie.server.remote.rest.drools.CommandResource.manageContainer(CommandResource.java:91)
> at sun.reflect.GeneratedMethodAccessor83.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179)
> at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:193)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:103)
> at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
> at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:216)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:220)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:661)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at com.intuit.v4.intlgntsys.recommender.personalizationrulesengine.services.util.MDCFilter.doFilter(MDCFilter.java:40)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.springframework.boot.actuate.web.trace.servlet.HttpTraceFilter.doFilterInternal(HttpTraceFilter.java:90)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:320)
> at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:127)
> at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:91)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)
> at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:119)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)
> at org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:137)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)
> at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:111)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)
> at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:170)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)
> at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:63)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)
> at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilterInternal(BasicAuthenticationFilter.java:215)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)
> at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:116)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)
> at org.springframework.security.web.header.HeaderWriterFilter.doFilterInternal(HeaderWriterFilter.java:74)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)
> at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:105)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)
> at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:56)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)
> at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:215)
> at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:178)
> at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:357)
> at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:270)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:109)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:93)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.filterAndRecordMetrics(WebMvcMetricsFilter.java:117)
> at org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.doFilterInternal(WebMvcMetricsFilter.java:106)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:200)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
> at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:798)
> at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
> at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFCORE-4905) Provide common capability for Remoting connectors
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFCORE-4905?page=com.atlassian.jira.plug... ]
Richard Achmatowicz updated WFCORE-4905:
----------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/4132 (was: https://github.com/wildfly/wildfly-core/pull/4099)
> Provide common capability for Remoting connectors
> -------------------------------------------------
>
> Key: WFCORE-4905
> URL: https://issues.redhat.com/browse/WFCORE-4905
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 11.0.0.Final
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 11.0.1.Final
>
>
> The EJB3 subsystem has an element <remote/> which performs a few different functions relating to external clients accessing EJBs on the server:
> * sets up a Remoting connector service so that external clients may connect to the server using EJB / Remoting or EJB / HTTP Upgrade / Remoting
> * sets up client mappings entries for those remote clients which are used in topology updates to allow the client to find the server's connectors
> The Remoting subsystem has two connector types which may be supplied to the <remote connector-ref/> attribute. <connector name="remoting-connector"/> represents a Remoting endpoint and <http-connector name="http-connector"/> represents an Undertow listener which may be used with HTTP Upgrade.
> At present, in the Remoting subsystem, these connectors have two separately defined capabilities:
> // for <connector/>
> private static final String CONNECTOR_CAPABILITY_NAME ="org.wildfly.remoting.connector";
> static final RuntimeCapability<Void> CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(CONNECTOR_CAPABILITY_NAME, true).build();
> // for <http-connector/>
> private static final String HTTP_CONNECTOR_CAPABILITY_NAME = "org.wildfly.remoting.http-connector";
> static final RuntimeCapability<Void> HTTP_CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(HTTP_CONNECTOR_CAPABILITY_NAME, true).build();
> The proposal here is to allow referencing both connectors using a single capability base name, "org.wildfly.remoting.connector" to simplify specification of the capabilities which the <remote/> element needs (i.e. it may depend on one or the other). These are both dynamically named capabilities, so their names will vary based on the name of the management resource instance they represent. Because capability names are considered public API, the existing capability name for org.wildfly.remoting.http-connector cannot be removed to further simplify.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFCORE-4905) Provide common capability for Remoting connectors
by Richard Achmatowicz (Jira)
Richard Achmatowicz created WFCORE-4905:
-------------------------------------------
Summary: Provide common capability for Remoting connectors
Key: WFCORE-4905
URL: https://issues.redhat.com/browse/WFCORE-4905
Project: WildFly Core
Issue Type: Bug
Components: Remoting
Affects Versions: 11.0.0.Final
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 12.0.0.Beta1
The EJB3 subsystem has an element <remote/> which performs a few different functions relating to external clients accessing EJBs on the server:
* sets up a Remoting connector service so that external clients may connect to the server using EJB / Remoting or EJB / HTTP Upgrade / Remoting
* sets up client mappings entries for those remote clients which are used in topology updates to allow the client to find the server's connectors
The Remoting subsystem has two connector types which may be supplied to the <remote connector-ref/> attribute. <connector name="remoting-connector"/> represents a Remoting endpoint and <http-connector name="http-connector"/> represents an Undertow listener which may be used with HTTP Upgrade.
At present, in the Remoting subsystem, these connectors have two separately defined capabilities:
// for <connector/>
private static final String CONNECTOR_CAPABILITY_NAME ="org.wildfly.remoting.connector";
static final RuntimeCapability<Void> CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(CONNECTOR_CAPABILITY_NAME, true).build();
// for <http-connector/>
private static final String HTTP_CONNECTOR_CAPABILITY_NAME = "org.wildfly.remoting.http-connector";
static final RuntimeCapability<Void> HTTP_CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(HTTP_CONNECTOR_CAPABILITY_NAME, true).build();
The proposal here is to allow referencing both connectors using a single capability base name, "org.wildfly.remoting.connector" to simplify specification of the capabilities which the <remote/> element needs (i.e. it may depend on one or the other). These are both dynamically named capabilities, so their names will vary based on the name of the management resource instance they represent. Because capability names are considered public API, the existing capability name for org.wildfly.remoting.http-connector cannot be removed to further simplify.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFCORE-4905) Provide common capability for Remoting connectors
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFCORE-4905?page=com.atlassian.jira.plug... ]
Richard Achmatowicz updated WFCORE-4905:
----------------------------------------
Fix Version/s: 11.0.1.Final
(was: 12.0.0.Beta1)
> Provide common capability for Remoting connectors
> -------------------------------------------------
>
> Key: WFCORE-4905
> URL: https://issues.redhat.com/browse/WFCORE-4905
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 11.0.0.Final
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 11.0.1.Final
>
>
> The EJB3 subsystem has an element <remote/> which performs a few different functions relating to external clients accessing EJBs on the server:
> * sets up a Remoting connector service so that external clients may connect to the server using EJB / Remoting or EJB / HTTP Upgrade / Remoting
> * sets up client mappings entries for those remote clients which are used in topology updates to allow the client to find the server's connectors
> The Remoting subsystem has two connector types which may be supplied to the <remote connector-ref/> attribute. <connector name="remoting-connector"/> represents a Remoting endpoint and <http-connector name="http-connector"/> represents an Undertow listener which may be used with HTTP Upgrade.
> At present, in the Remoting subsystem, these connectors have two separately defined capabilities:
> // for <connector/>
> private static final String CONNECTOR_CAPABILITY_NAME ="org.wildfly.remoting.connector";
> static final RuntimeCapability<Void> CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(CONNECTOR_CAPABILITY_NAME, true).build();
> // for <http-connector/>
> private static final String HTTP_CONNECTOR_CAPABILITY_NAME = "org.wildfly.remoting.http-connector";
> static final RuntimeCapability<Void> HTTP_CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(HTTP_CONNECTOR_CAPABILITY_NAME, true).build();
> The proposal here is to allow referencing both connectors using a single capability base name, "org.wildfly.remoting.connector" to simplify specification of the capabilities which the <remote/> element needs (i.e. it may depend on one or the other). These are both dynamically named capabilities, so their names will vary based on the name of the management resource instance they represent. Because capability names are considered public API, the existing capability name for org.wildfly.remoting.http-connector cannot be removed to further simplify.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-4919) Long running query at kie-server startup
by Danny Rucker (Jira)
[ https://issues.redhat.com/browse/DROOLS-4919?page=com.atlassian.jira.plug... ]
Danny Rucker commented on DROOLS-4919:
--------------------------------------
Hi,
This is an issue that is still affecting us during our deployments. So I wanted to see what help could I provide on providing a fix for it, but I see you may have already fixed it. Can help me determine what settings are needed, and where they are so I can set it up properly?
Thanks,
Danny
> Long running query at kie-server startup
> ----------------------------------------
>
> Key: DROOLS-4919
> URL: https://issues.redhat.com/browse/DROOLS-4919
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 7.28.0.Final
> Reporter: Danny Rucker
> Assignee: Maciej Swiderski
> Priority: Major
>
> The following query is executed at start up of kie-server
> ```
> select vil.processInstanceId, vil.processId, vil.id, vil.variableId, vil.value from VariableInstanceLog vil where vil.id in (select MAX(v.id) from VariableInstanceLog v group by v.variableId, v.processInstanceId)
> ```
> This is causing some issues with getting kie-server to start up.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-11905) Move module org.apache.xml-resolver from WildFly Core to WildFly
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-11905?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-11905:
-----------------------------------------
[~parsharma] If there isn't one already, please file a WFCORE JIRA to track the removal of this from WildFly Core. And please link any WFCORE JIRA to this one.
> Move module org.apache.xml-resolver from WildFly Core to WildFly
> ----------------------------------------------------------------
>
> Key: WFLY-11905
> URL: https://issues.redhat.com/browse/WFLY-11905
> Project: WildFly
> Issue Type: Task
> Components: Web Services
> Reporter: Brian Stansberry
> Assignee: Parul Sharma
> Priority: Minor
>
> The org.apache.xml-resolver module is not used by WildFly Core. Only use is in full:
> {code}
> $ git grep xml-resolver | grep module.x
> feature-pack/src/main/resources/modules/system/layers/base/org/apache/cxf/impl/main/module.xml: <module name="org.apache.xml-resolver" />
> feature-pack/src/main/resources/modules/system/layers/base/org/apache/cxf/main/module.xml: <module name="org.apache.xml-resolver" />
> feature-pack/src/main/resources/modules/system/layers/base/org/apache/cxf/services-sts/main/module.xml: <module name="org.apache.xml-resolver" />
> feature-pack/src/main/resources/modules/system/layers/base/org/apache/cxf/ws-security/main/module.xml: <module name="org.apache.xml-resolver" />
> {code}
> Moving it will tidy things up some and perhaps avoid any special handling for it as Galleon layers work continues.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months