April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13267) Convert EJB3 subsystem transformers to use chained transformers

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13267?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13267: ------------------------------ Description: The EJB3 subsystem defines its subsystem transformers in the class org.jboss.as.ejb3.subsystem.EJBTransformers. This class organizes transformers in '[the old way|https://docs.jboss.org/author/display/WFLY/Domain%20Mode%20Subsystem%...]' (see https://docs.jboss.org/author/display/WFLY/Domain+Mode+Subsystem+Transfor...), so that there is a lot of code duplication. This issue will reorganize the transformers to use the chained transformer technique, where only the changes from the current version to the most recent legacy version need be specified. was: The EJB3 subsystem defines its subsystem transformers in the class org.jboss.as.ejb3.subsystem.EJBTransformers. This class organizes transformers in 'the old way' (see https://docs.jboss.org/author/display/WFLY/Domain+Mode+Subsystem+Transfor...), so that there is a lot of code duplication. This issue will reorganize the transformers to use the chained transformer technique, where only the changes from the current version to the most recent legacy version need be specified. > Convert EJB3 subsystem transformers to use chained transformers > --------------------------------------------------------------- > > Key: WFLY-13267 > URL: https://issues.redhat.com/browse/WFLY-13267 > Project: WildFly > Issue Type: Task > Components: EJB > Affects Versions: 19.0.0.Final > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > Fix For: 20.0.0.Beta1 > > > The EJB3 subsystem defines its subsystem transformers in the class org.jboss.as.ejb3.subsystem.EJBTransformers. > This class organizes transformers in '[the old way|https://docs.jboss.org/author/display/WFLY/Domain%20Mode%20Subsystem%...]' (see https://docs.jboss.org/author/display/WFLY/Domain+Mode+Subsystem+Transfor...), so that there is a lot of code duplication. > This issue will reorganize the transformers to use the chained transformer technique, where only the changes from the current version to the most recent legacy version need be specified. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi... ] Richard Achmatowicz edited comment on WFLY-13132 at 4/27/20 4:41 PM: --------------------------------------------------------------------- Any kind of preference for one protocol over another when choosing the target of the invocation would be set in DiscoveryEJBClientInterceptor, as this is where the results of a call to discovery are processed and a final choice of target is made (see doFirstMatchDiscovery(), doAnyDiscovery( ), doClusterDiscovery()). The results of the discovery calls (before processing required to choose the target) will include all URIs over all protocols which satisfy the filter spec. So some questions: * is there a need to constrain the protocol used to be consistent across a single client? ** e.g. maybe for use with transactions, all invocations need to arrive at the same port? ** or for some other added value feature (such as security credentials set up for one URI and not another using a different protocol? ** or maybe for performance reasons? * what happens with legacy versions of EJB client when discovery offers two possible protocols? Is it possible to repeatedly choose a URI which it cannot handle when an EJBReceiver is being selected? * how to decide on which protocol to use if several are available? was (Author: rachmato): Any kind of preference for one protocol over another when choosing the target of the invocation would be set in DiscoveryEJBClientInterceptor, as this is where the results of a call to discovery are processed and a final choice of target is made (see doFirstMatchDiscovery(), doAnyDiscovery( ), doClusterDiscovery()). The results of the discovery calls (before processing required to choose the target) will include all URIs over all protocols which satisfy the filter spec. So some questions: * is there a need to constrain the protocol used to be consistent across a single client? ** e.g. maybe for use with transactions, all invocations need to arrive at the same port? or for some other added value feature (such as SSO)? ** maybe for performance reasons? * what happens with legacy versions of EJB client when discovery offers two possible protocols? Is it possible to repeatedly choose a URI which it cannot handle when an EJBReceiver is being selected? > Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client > ----------------------------------------------------------- > > Key: WFLY-13132 > URL: https://issues.redhat.com/browse/WFLY-13132 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.0.0.Beta2 > Reporter: Joerg Baesner > Assignee: Richard Achmatowicz > Priority: Major > Labels: downstream_dependency > Attachments: playground.zip > > > h2. +Issue+ > h3. +General Client setup:+ > {code:java} > Properties p = new Properties(); > p.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory"); > p.put(Context.PROVIDER_URL, {see below}); > p.put(Context.SECURITY_PRINCIPAL, USER); > p.put(Context.SECURITY_CREDENTIALS, PWD); > Context context = new InitialContext(p); > {code} > ---- > h3. +Standard server configuration:+ > {code:xml} > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > ... > <remote connector-ref="http-remoting-connector" thread-pool-name="default"> > <channel-creation-options> > <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> > <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> > </channel-creation-options> > </remote> > ... > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> > <properties> > <property name="SSL_ENABLED" value="false"/> > </properties> > </connector> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > {code} > h5. +invocation from remote client to server with:+ > * {{remote://localhost:4447}} > * {{remote+http://localhost:8080}} > h5. +Client side topology update always:+ > {noformat} > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8080 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8180 > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb > {noformat} > ---- > h3. +Legacy server configuration:+ > {code:xml} > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > ... > <remote connector-ref="remoting-connector" thread-pool-name="default"> > <channel-creation-options> > <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> > <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> > </channel-creation-options> > </remote> > ... > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> > <properties> > <property name="SSL_ENABLED" value="false"/> > </properties> > </connector> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > {code} > h5. +invocation from remote client to server with:+ > * {{remote://localhost:4447}} > * {{remote+http://localhost:8080}} > h5. +Client side topology update always:+ > {noformat} > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4447 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4547 > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb > {noformat} > h2. +Conclusion+ > Depending on what is configured as {{connector-ref}} in the {{remote}} of the _ejb3_ subsystem the {{CLUSTER_TOPOLOGY}} update is different. From a client perspective it would be expected that either the {{CLUSTER_TOPOLOGY}} update would _only_ contain destinations that are applicable for the _connector/protocol_ that has been used, or maybe even _ALL_ available destinations, as the client could potentially run a mix of protocols between invocations... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi... ] Richard Achmatowicz edited comment on WFLY-13132 at 4/27/20 4:29 PM: --------------------------------------------------------------------- Any kind of preference for one protocol over another when choosing the target of the invocation would be set in DiscoveryEJBClientInterceptor, as this is where the results of a call to discovery are processed and a final choice of target is made (see doFirstMatchDiscovery(), doAnyDiscovery( ), doClusterDiscovery()). The results of the discovery calls (before processing required to choose the target) will include all URIs over all protocols which satisfy the filter spec. So some questions: * is there a need to constrain the protocol used to be consistent across a single client? ** e.g. maybe for use with transactions, all invocations need to arrive at the same port? or for some other added value feature (such as SSO)? ** maybe for performance reasons? * what happens with legacy versions of EJB client when discovery offers two possible protocols? Is it possible to repeatedly choose a URI which it cannot handle when an EJBReceiver is being selected? was (Author: rachmato): Any kind of preference for one protocol over another when choosing the target of the invocation would be set in DiscoveryEJBClientInterceptor, as this is where the results of a call to discovery are processed and a final choice of target is made (see doFirstMatchDiscovery(), doAnyDiscovery( ), doClusterDiscovery()). The results of the discovery calls (before processing required to choose the target) will include all URIs over all protocols which satisfy the filter spec. So some questions: - is there a need to constrain the protocol used to be consistent across a single client? -- e.g. maybe for use with transactions, all invocations need to arrive at the same port? or for some other added value feature (such as SSO)? -- maybe for performance reasons? - what happens with legacy versions of EJB client when discovery offers two possible protocols? > Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client > ----------------------------------------------------------- > > Key: WFLY-13132 > URL: https://issues.redhat.com/browse/WFLY-13132 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.0.0.Beta2 > Reporter: Joerg Baesner > Assignee: Richard Achmatowicz > Priority: Major > Labels: downstream_dependency > Attachments: playground.zip > > > h2. +Issue+ > h3. +General Client setup:+ > {code:java} > Properties p = new Properties(); > p.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory"); > p.put(Context.PROVIDER_URL, {see below}); > p.put(Context.SECURITY_PRINCIPAL, USER); > p.put(Context.SECURITY_CREDENTIALS, PWD); > Context context = new InitialContext(p); > {code} > ---- > h3. +Standard server configuration:+ > {code:xml} > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > ... > <remote connector-ref="http-remoting-connector" thread-pool-name="default"> > <channel-creation-options> > <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> > <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> > </channel-creation-options> > </remote> > ... > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> > <properties> > <property name="SSL_ENABLED" value="false"/> > </properties> > </connector> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > {code} > h5. +invocation from remote client to server with:+ > * {{remote://localhost:4447}} > * {{remote+http://localhost:8080}} > h5. +Client side topology update always:+ > {noformat} > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8080 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8180 > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb > {noformat} > ---- > h3. +Legacy server configuration:+ > {code:xml} > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > ... > <remote connector-ref="remoting-connector" thread-pool-name="default"> > <channel-creation-options> > <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> > <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> > </channel-creation-options> > </remote> > ... > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> > <properties> > <property name="SSL_ENABLED" value="false"/> > </properties> > </connector> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > {code} > h5. +invocation from remote client to server with:+ > * {{remote://localhost:4447}} > * {{remote+http://localhost:8080}} > h5. +Client side topology update always:+ > {noformat} > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4447 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4547 > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb > {noformat} > h2. +Conclusion+ > Depending on what is configured as {{connector-ref}} in the {{remote}} of the _ejb3_ subsystem the {{CLUSTER_TOPOLOGY}} update is different. From a client perspective it would be expected that either the {{CLUSTER_TOPOLOGY}} update would _only_ contain destinations that are applicable for the _connector/protocol_ that has been used, or maybe even _ALL_ available destinations, as the client could potentially run a mix of protocols between invocations... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on WFLY-13132: -------------------------------------------- Any kind of preference for one protocol over another when choosing the target of the invocation would be set in DiscoveryEJBClientInterceptor, as this is where the results of a call to discovery are processed and a final choice of target is made (see doFirstMatchDiscovery(), doAnyDiscovery( ), doClusterDiscovery()). The results of the discovery calls (before processing required to choose the target) will include all URIs over all protocols which satisfy the filter spec. So some questions: - is there a need to constrain the protocol used to be consistent across a single client? -- e.g. maybe for use with transactions, all invocations need to arrive at the same port? or for some other added value feature (such as SSO)? -- maybe for performance reasons? - what happens with legacy versions of EJB client when discovery offers two possible protocols? > Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client > ----------------------------------------------------------- > > Key: WFLY-13132 > URL: https://issues.redhat.com/browse/WFLY-13132 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.0.0.Beta2 > Reporter: Joerg Baesner > Assignee: Richard Achmatowicz > Priority: Major > Labels: downstream_dependency > Attachments: playground.zip > > > h2. +Issue+ > h3. +General Client setup:+ > {code:java} > Properties p = new Properties(); > p.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory"); > p.put(Context.PROVIDER_URL, {see below}); > p.put(Context.SECURITY_PRINCIPAL, USER); > p.put(Context.SECURITY_CREDENTIALS, PWD); > Context context = new InitialContext(p); > {code} > ---- > h3. +Standard server configuration:+ > {code:xml} > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > ... > <remote connector-ref="http-remoting-connector" thread-pool-name="default"> > <channel-creation-options> > <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> > <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> > </channel-creation-options> > </remote> > ... > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> > <properties> > <property name="SSL_ENABLED" value="false"/> > </properties> > </connector> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > {code} > h5. +invocation from remote client to server with:+ > * {{remote://localhost:4447}} > * {{remote+http://localhost:8080}} > h5. +Client side topology update always:+ > {noformat} > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8080 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8180 > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb > {noformat} > ---- > h3. +Legacy server configuration:+ > {code:xml} > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > ... > <remote connector-ref="remoting-connector" thread-pool-name="default"> > <channel-creation-options> > <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> > <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> > </channel-creation-options> > </remote> > ... > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> > <properties> > <property name="SSL_ENABLED" value="false"/> > </properties> > </connector> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > {code} > h5. +invocation from remote client to server with:+ > * {{remote://localhost:4447}} > * {{remote+http://localhost:8080}} > h5. +Client side topology update always:+ > {noformat} > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4447 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4547 > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb > {noformat} > h2. +Conclusion+ > Depending on what is configured as {{connector-ref}} in the {{remote}} of the _ejb3_ subsystem the {{CLUSTER_TOPOLOGY}} update is different. From a client perspective it would be expected that either the {{CLUSTER_TOPOLOGY}} update would _only_ contain destinations that are applicable for the _connector/protocol_ that has been used, or maybe even _ALL_ available destinations, as the client could potentially run a mix of protocols between invocations... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4431) DMN REST endpoint requires stateful kie session

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4431?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-4431: ----------------------------------- Affects: Documentation (Ref Guide, User Guide, etc.),Release Notes > DMN REST endpoint requires stateful kie session > ----------------------------------------------- > > Key: DROOLS-4431 > URL: https://issues.redhat.com/browse/DROOLS-4431 > Project: Drools > Issue Type: Bug > Components: dmn engine > Environment: Noticed this is RHDM 7.3. Still exists in 7.4. Don't know which versions of Drools that coincides with. > Reporter: Justin Jarae > Assignee: Matteo Mortari > Priority: Major > Labels: field > Attachments: DMN-Test.zip > > > When trying to run DMN via the rest endpoint, if the default KIE session is stateless, an error is returned stating that "Cannot find a default KieSession". If the stateful session is specified as default, the DMN execution works as expected. This forces you to specify stateless for all other requests. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5281) DMN alignment DMNAssemblerService internal DMNRuntimeBuilder util

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5281: -------------------------------------- Summary: DMN alignment DMNAssemblerService internal DMNRuntimeBuilder util Key: DROOLS-5281 URL: https://issues.redhat.com/browse/DROOLS-5281 Project: Drools Issue Type: Enhancement Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13411) Optimize marshalling of offset time objects

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13411: ----------------------------------- Summary: Optimize marshalling of offset time objects Key: WFLY-13411 URL: https://issues.redhat.com/browse/WFLY-13411 Project: WildFly Issue Type: Task Components: Clustering Affects Versions: 19.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (SWSQE-1137) Build Kiali-Operator PRs

by Matthew Mahoney (Jira)

Matthew Mahoney created SWSQE-1137: -------------------------------------- Summary: Build Kiali-Operator PRs Key: SWSQE-1137 URL: https://issues.redhat.com/browse/SWSQE-1137 Project: Kiali QE Issue Type: QE Task Reporter: Matthew Mahoney Assignee: Filip Brychta In addition to being able to build Kiali by Kiali and Kiali-UI PRs, we now will need to build by Kiali-Operator PRs given that the operator is in it's own repo. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13058) JAXBEncoderDecoder failure when using IBM JDK and SecurityManager

by Sudeshna Sur (Jira)

[ https://issues.redhat.com/browse/WFLY-13058?page=com.atlassian.jira.plugi... ] Sudeshna Sur reassigned WFLY-13058: ----------------------------------- Assignee: Sudeshna Sur > JAXBEncoderDecoder failure when using IBM JDK and SecurityManager > ----------------------------------------------------------------- > > Key: WFLY-13058 > URL: https://issues.redhat.com/browse/WFLY-13058 > Project: WildFly > Issue Type: Bug > Components: Security Manager, Test Suite > Affects Versions: 19.0.0.Beta1 > Reporter: Francesco Marchioni > Assignee: Sudeshna Sur > Priority: Major > Attachments: surefire-reports.zip > > > When running the org.jboss.as.test.xts.suspend.wsba.BusinessActivitySuspendTestCase with IBM JDK 1.8 with Security Manager, an issue is raised by the JAXBEncoderDecoder: > {code:java} > [INFO] Running org.jboss.as.test.xts.suspend.wsba.BusinessActivitySuspendTestCase > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 18.351 s <<< FAILURE! - in org.jboss.as.test.xts.suspend.wsba.BusinessActivitySuspendTestCase > [ERROR] testCommitAfterSuspend(org.jboss.as.test.xts.suspend.wsba.BusinessActivitySuspendTestCase) Time elapsed: 2.313 s <<< ERROR! > java.lang.Exception: ARJUNA045061: No termination context! > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:83) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57) > at java.lang.reflect.Constructor.newInstance(Constructor.java:437) > at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshallException(JAXBEncoderDecoder.java:545) > at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:689) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13410) Optimize marshalling of BitSet and scalar Optional variants

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13410: ----------------------------------- Summary: Optimize marshalling of BitSet and scalar Optional variants Key: WFLY-13410 URL: https://issues.redhat.com/browse/WFLY-13410 Project: WildFly Issue Type: Task Components: Clustering Affects Versions: 19.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020