March 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5119) Workbench int value turns into 0.0 in drl

by Bhala Hadkar (Jira)

[ https://issues.redhat.com/browse/DROOLS-5119?page=com.atlassian.jira.plug... ] Bhala Hadkar updated DROOLS-5119: --------------------------------- Description: When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type int then the int value entered through literal text disappears and turns into 0.0B. For e.g. if you look at this Guided Rule screenshot the literal value 100 turned into 0.0. !Workbench-Guided-Rule.png|thumbnail! Also in the drools the value becomes 0.0B. !drools.png|thumbnail! was: When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type int then the int value entered through literal text disappears and turns into 0.0B. For e.g. if you look at this screenshot the literal value 100 turned into 0.0. > Workbench int value turns into 0.0 in drl > ----------------------------------------- > > Key: DROOLS-5119 > URL: https://issues.redhat.com/browse/DROOLS-5119 > Project: Drools > Issue Type: Bug > Components: Examples (Workbench) > Affects Versions: 7.34.0.Final > Reporter: Bhala Hadkar > Assignee: Michael Anstis > Priority: Major > Attachments: Workbench-Guided-Rule.png, drools.png > > > When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type int then the int value entered through literal text disappears and turns into 0.0B. > For e.g. if you look at this Guided Rule screenshot the literal value 100 turned into 0.0. > !Workbench-Guided-Rule.png|thumbnail! > Also in the drools the value becomes 0.0B. > !drools.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5119) Workbench int value turns into 0.0 in drl

by Bhala Hadkar (Jira)

[ https://issues.redhat.com/browse/DROOLS-5119?page=com.atlassian.jira.plug... ] Bhala Hadkar updated DROOLS-5119: --------------------------------- Attachment: drools.png > Workbench int value turns into 0.0 in drl > ----------------------------------------- > > Key: DROOLS-5119 > URL: https://issues.redhat.com/browse/DROOLS-5119 > Project: Drools > Issue Type: Bug > Components: Examples (Workbench) > Affects Versions: 7.34.0.Final > Reporter: Bhala Hadkar > Assignee: Michael Anstis > Priority: Major > Attachments: Workbench-Guided-Rule.png, drools.png > > > When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type int then the int value entered through literal text disappears and turns into 0.0B. > For e.g. if you look at this screenshot the literal value 100 turned into 0.0. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5119) Workbench int value turns into 0.0 in drl

by Bhala Hadkar (Jira)

[ https://issues.redhat.com/browse/DROOLS-5119?page=com.atlassian.jira.plug... ] Bhala Hadkar updated DROOLS-5119: --------------------------------- Attachment: Workbench-Guided-Rule.png > Workbench int value turns into 0.0 in drl > ----------------------------------------- > > Key: DROOLS-5119 > URL: https://issues.redhat.com/browse/DROOLS-5119 > Project: Drools > Issue Type: Bug > Components: Examples (Workbench) > Affects Versions: 7.34.0.Final > Reporter: Bhala Hadkar > Assignee: Michael Anstis > Priority: Major > Attachments: Workbench-Guided-Rule.png > > > When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type int then the int value entered through literal text disappears and turns into 0.0B. > For e.g. if you look at this screenshot the literal value 100 turned into 0.0. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5119) Workbench int value turns into 0.0 in drl

by Bhala Hadkar (Jira)

Bhala Hadkar created DROOLS-5119: ------------------------------------ Summary: Workbench int value turns into 0.0 in drl Key: DROOLS-5119 URL: https://issues.redhat.com/browse/DROOLS-5119 Project: Drools Issue Type: Bug Components: Examples (Workbench) Affects Versions: 7.34.0.Final Reporter: Bhala Hadkar Assignee: Michael Anstis When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type int then the int value entered through literal text disappears and turns into 0.0B. For e.g. if you look at this screenshot the literal value 100 turned into 0.0. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

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 3/2/20 3:30 PM: -------------------------------------------------------------------- Historically, the only way for a remote client to connect to EJBs on the server was via the URL scheme "remote" of the EJB client. This would effectively indicate a choice to use EJB over Remoting . This involved making use of the <remote connector-ref="remoting-connector"/> element in the EJB subsystem, where connector-ref pointed to the standard Remoting-based connector <connector/> defined in the Remoting subsystem. This in turn referenced the Remoting socket, port 4447. The EJB3RemoteServiceAdd operation in the EJB3 subsystem defines a service, EJBRemotingConnectorClientMappingsEntryProviderService, used to populate the client mapping entries used for topology updates. The default client mapping entries which the service creates are based on the socket host and port associated with the connector-ref. For the Remoting connector <connector/> , these are remote://<host>:4447 Later, the scheme "http+remote" was introduced. This would effectively use EJB over HTTP (with an upgrade to Remoting). This involved making use of the newer HTTP-based connector <http-connector /> also defined in the Remoting subsystem. This connector installs some special Undertow handlers, used to allow the upgrade to Remoting to take place when the incoming HTTP request has a header Upgrade: jboss-remoting: a connection is made to Undertow and this triggers a protocol upgrade to Remoting. After the upgrade, the Remoting handshake would take place as usual. However, unlike in the legacy case, the connector used would be the HTTP connector <http-connector/>, which by default is associated with the http socket, using port 8080. In order to have the correct client mapping entries generated (based on 8080 and not 4447), we needed to change the connector ref in the <remote/> element from connector-ref="remoting-connector" to connector-ref="http-remoting-connector". This effectively changes which socket is used to initialise the client mappings. The problem, if I understand correctly, occurs when we try to configure use of both "remote" and "remote+http" at the same time. The client mappings that are generated only reflect one of the two protocol options, because only one connector reference is passed to <remote/>. It would seem that the solution is to change the way EJBRemotingConnectorClientMappingsEntryProviderService is initialised, so that it takes both possible connector references as parameters and will create client mapping entries which will provide URIs for the "remote" protocol as well as the "remote+http" protocol for the node in question. This way, during discovery, the scheme can be used to select the correct URIs to choose. This might involve changing the <remote/> element to take a connector-ref and an htttp-connector-ref, or similar. This may also require some changes on the client side with the way the discovery search is carried out. Not sure at the moment. was (Author: rachmato): Historically, the only way for a remote client to connect to EJBs on the server was via the URL scheme "remote" of the EJB client. This would effectively indicate a choice to use EJB over Remoting . This involved making use of the <remote connector-ref="remoting-connector"/> element in the EJB subsystem, where connector-ref pointed to the standard Remoting-based connector <connector/> defined in the Remoting subsystem. This in turn referenced the Remoting socket, port 4447. The EJB3RemoteServiceAdd operation in the EJB3 subsystem defines a service, EJBRemotingConnectorClientMappingsEntryProviderService, used to populate the client mapping entries used for topology updates. The default client mapping entries which the service creates are based on the socket host and port associated with the connector-ref. For the Remoting connector <connector/> , these are remote://<host>:4447 Later, the scheme "http+remote" was introduced. This would effectively use EJB over HTTP (with an upgrade to Remoting). This involved making use of the newer HTTP-based connector <http-connector /> also defined in the Remoting subsystem. This connector installs some special Undertow handlers, used to allow the upgrade to Remoting to take place when the incoming HTTP request has a header Upgrade: jboss-remoting: a connection is made to Undertow and this triggers a protocol upgrade to Remoting. After the upgrade, the Remoting handshake would take place as usual. However, unlike in the legacy case, the connector used would be the HTTP connector <http-connector/>, which by default is associated with the http socket, using port 8080. In order to have the correct client mapping entries generated (based on 8080 and not 4447), we needed to change the connector ref in the <remote/> element from connector-ref="remoting-connector" to connector-ref="http-remoting-connector". This effectively changes which socket is used to initialise the client mappings. The problem, if I understand correctly, occurs when we try to configure use of both "remote" and "remote+http" at the same time. The client mappings that are generated only reflect one of the two protocol options, because only one connector reference is passed to <remote/>. It would seem that the solution is to change the way EJBRemotingConnectorClientMappingsEntryProviderService is initialised, so that it takes both possible connector references as parameters and will create client mapping entries which will provide URIs for the "remote" protocol as well as the "remote+http" protocol for the node in question. This way, during discovery, the scheme can be used to select the correct URIs to choose. This might involve changing the <remote/> element to take a connector-ref and an htttp-connector-ref, or similar. > 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 > 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)

4 years, 3 months

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 3/2/20 3:28 PM: -------------------------------------------------------------------- Historically, the only way for a remote client to connect to EJBs on the server was via the URL scheme "remote" of the EJB client. This would effectively indicate a choice to use EJB over Remoting . This involved making use of the <remote connector-ref="remoting-connector"/> element in the EJB subsystem, where connector-ref pointed to the standard Remoting-based connector <connector/> defined in the Remoting subsystem. This in turn referenced the Remoting socket, port 4447. The EJB3RemoteServiceAdd operation in the EJB3 subsystem defines a service, EJBRemotingConnectorClientMappingsEntryProviderService, used to populate the client mapping entries used for topology updates. The default client mapping entries which the service creates are based on the socket host and port associated with the connector-ref. For the Remoting connector <connector/> , these are remote://<host>:4447 Later, the scheme "http+remote" was introduced. This would effectively use EJB over HTTP (with an upgrade to Remoting). This involved making use of the newer HTTP-based connector <http-connector /> also defined in the Remoting subsystem. This connector installs some special Undertow handlers, used to allow the upgrade to Remoting to take place when the incoming HTTP request has a header Upgrade: jboss-remoting: a connection is made to Undertow and this triggers a protocol upgrade to Remoting. After the upgrade, the Remoting handshake would take place as usual. However, unlike in the legacy case, the connector used would be the HTTP connector <http-connector/>, which by default is associated with the http socket, using port 8080. In order to have the correct client mapping entries generated (based on 8080 and not 4447), we needed to change the connector ref in the <remote/> element from connector-ref="remoting-connector" to connector-ref="http-remoting-connector". This effectively changes which socket is used to initialise the client mappings. The problem, if I understand correctly, occurs when we try to configure use of both "remote" and "remote+http" at the same time. The client mappings that are generated only reflect one of the two protocol options, because only one connector reference is passed to <remote/>. It would seem that the solution is to change the way EJBRemotingConnectorClientMappingsEntryProviderService is initialised, so that it takes both possible connector references as parameters and will create client mapping entries which will provide URIs for the "remote" protocol as well as the "remote+http" protocol for the node in question. This way, during discovery, the scheme can be used to select the correct URIs to choose. This might involve changing the <remote/> element to take a connector-ref and an htttp-connector-ref, or similar. was (Author: rachmato): Historically, the only way for a remote client to connect to EJBs on the server was via the URL scheme "remote" of the EJB client. This would effectively indicate a choice to use EJB over Remoting . This involved making use of the <remote connector-ref="remoting-connector"/> element in the EJB subsystem, where connector-ref pointed to the standard Remoting-based connector <connector/> defined in the Remoting subsystem. This in turn referenced the Remoting socket, port 4447. The EJB3RemoteServiceAdd operation in the EJB3 subsystem defines a service, EJBRemotingConnectorClientMappingsEntryProviderService, used to populate the client mapping entries used for topology updates. The default client mapping entries which the service creates are based on the socket host and port associated with the connector-ref. For the Remoting connector <connector/> , these are remote://<host>:4447 Later, the scheme "http+remote" was introduced. This would effectively use EJB over HTTP (with an upgrade to Remoting). This involved making use of the newer HTTP-based connector <http-connector /> also defined in the Remoting subsystem. This involves using Remoting based protocols by connecting to Undertow and then triggering a protocol upgrade to Remoting. After the upgrade, the Remoting handshake would take place as usual. However, unlike in the legacy case, the connector used would be the HTTP connector <http-connector/>, which by default uses port 8080. In order to have the correct client mapping entries generated (based on 8080 and not 4447), we needed to change the connector ref in the <remote/> element from connector-ref="remoting-connector" to connector-ref="http-remoting-connector". This effectively changes which socket is used to initialise the client mappings. The problem, if I understand correctly, occurs when we try to configure use of both "remote" and "remote+http" at the same time. The client mappings that are generated only reflect one of the two protocol options. It would seem that the solution is to change the way EJBRemotingConnectorClientMappingsEntryProviderService is initialised, so that it takes both possible connector references as parameters and will create client mapping entries which will provide URIs for the "remote" protocol as well as the "remote+http" protocol for the node in question. This way, during discovery, the scheme can be used to select the correct URIs to choose. > 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 > 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)

4 years, 3 months

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 3/2/20 3:21 PM: -------------------------------------------------------------------- Historically, the only way for a remote client to connect to EJBs on the server was via the URL scheme "remote" of the EJB client. This would effectively indicate a choice to use EJB over Remoting . This involved making use of the <remote connector-ref="remoting-connector"/> element in the EJB subsystem, where connector-ref pointed to the standard Remoting-based connector <connector/> defined in the Remoting subsystem. This in turn referenced the Remoting socket, port 4447. The EJB3RemoteServiceAdd operation in the EJB3 subsystem defines a service, EJBRemotingConnectorClientMappingsEntryProviderService, used to populate the client mapping entries used for topology updates. The default client mapping entries which the service creates are based on the socket host and port associated with the connector-ref. For the Remoting connector <connector/> , these are remote://<host>:4447 Later, the scheme "http+remote" was introduced. This would effectively use EJB over HTTP (with an upgrade to Remoting). This involved making use of the newer HTTP-based connector <http-connector /> also defined in the Remoting subsystem. This involves using Remoting based protocols by connecting to Undertow and then triggering a protocol upgrade to Remoting. After the upgrade, the Remoting handshake would take place as usual. However, unlike in the legacy case, the connector used would be the HTTP connector <http-connector/>, which by default uses port 8080. In order to have the correct client mapping entries generated (based on 8080 and not 4447), we needed to change the connector ref in the <remote/> element from connector-ref="remoting-connector" to connector-ref="http-remoting-connector". This effectively changes which socket is used to initialise the client mappings. The problem, if I understand correctly, occurs when we try to configure use of both "remote" and "remote+http" at the same time. The client mappings that are generated only reflect one of the two protocol options. It would seem that the solution is to change the way EJBRemotingConnectorClientMappingsEntryProviderService is initialised, so that it takes both possible connector references as parameters and will create client mapping entries which will provide URIs for the "remote" protocol as well as the "remote+http" protocol for the node in question. This way, during discovery, the scheme can be used to select the correct URIs to choose. was (Author: rachmato): Historically, the only way for a remote client to connect to EJBs on the server was via the URL scheme "remote" of the EJB client. This would effectively indicate a choice to use EJB over Remoting . This involved making use of the <remote connector-ref="remoting-connector"/> element in the EJB subsystem, where connector-ref pointed to the standard Remoting-based connector <connector/> defined in the Remoting subsystem. This in turn referenced the Remoting socket, port 4447. The EJB3RemoteServiceAdd operation in the EJB3 subsystem defines a service, EJBRemotingConnectorClientMappingsEntryProviderService, used to populate the client mapping entries. The default client mapping entries which EJBRemotingConnectorClientMappingsEntryProviderService creates are based on the socket host and port associated with the connector-ref. For the Remoting connector <connector/> , these are remote://<host>:4447 Later, the scheme "http+remote" was introduced. This would effectively use EJB over HTTP (with an upgrade to Remoting). This involved making use of the newer HTTP-based connector <http-connector /> also defined in the Remoting subsystem. This involves using Remoting based protocols by connecting to Undertow and then triggering a protocol upgrade to Remoting. After the upgrade, the Remoting handshake would take place as usual. However, unlike in the legacy case, the connector used would be the HTTP connector <http-connector/>, which by default uses port 8080. In order to have the correct client mapping entries generated (based on 8080 and not 4447), we needed to change the connector ref in the <remote/> element from connector-ref="remoting-connector" to connector-ref="http-remoting-connector". This effectively changes which socket is used to initialise the client mappings. The problem, if I understand correctly, occurs when we try to configure use of both "remote" and "remote+http" at the same time. The client mappings that are generated only reflect one of the two protocol options. It would seem that the solution is to change the way EJBRemotingConnectorClientMappingsEntryProviderService is initialised, so that it takes both possible connector references as parameters and will create client mapping entries which will provide URIs for the "remote" protocol as well as the "remote+http" protocol for the node in question. This way, during discovery, the scheme can be used to select the correct URIs to choose. > 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 > 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)

4 years, 3 months

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: -------------------------------------------- Historically, the only way for a remote client to connect to EJBs on the server was via the URL scheme "remote" of the EJB client. This would effectively indicate a choice to use EJB over Remoting . This involved making use of the <remote connector-ref="remoting-connector"/> element in the EJB subsystem, where connector-ref pointed to the standard Remoting-based connector <connector/> defined in the Remoting subsystem. This in turn referenced the Remoting socket, port 4447. The EJB3RemoteServiceAdd operation in the EJB3 subsystem defines a service, EJBRemotingConnectorClientMappingsEntryProviderService, used to populate the client mapping entries. The default client mapping entries which EJBRemotingConnectorClientMappingsEntryProviderService creates are based on the socket host and port associated with the connector-ref. For the Remoting connector <connector/> , these are remote://<host>:4447 Later, the scheme "http+remote" was introduced. This would effectively use EJB over HTTP (with an upgrade to Remoting). This involved making use of the newer HTTP-based connector <http-connector /> also defined in the Remoting subsystem. This involves using Remoting based protocols by connecting to Undertow and then triggering a protocol upgrade to Remoting. After the upgrade, the Remoting handshake would take place as usual. However, unlike in the legacy case, the connector used would be the HTTP connector <http-connector/>, which by default uses port 8080. In order to have the correct client mapping entries generated (based on 8080 and not 4447), we needed to change the connector ref in the <remote/> element from connector-ref="remoting-connector" to connector-ref="http-remoting-connector". This effectively changes which socket is used to initialise the client mappings. The problem, if I understand correctly, occurs when we try to configure use of both "remote" and "remote+http" at the same time. The client mappings that are generated only reflect one of the two protocol options. It would seem that the solution is to change the way EJBRemotingConnectorClientMappingsEntryProviderService is initialised, so that it takes both possible connector references as parameters and will create client mapping entries which will provide URIs for the "remote" protocol as well as the "remote+http" protocol for the node in question. This way, during discovery, the scheme can be used to select the correct URIs to choose. > 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 > 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)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5009) DMN Designer convert java class with invalid DMN identiefier

by Daniel José dos Santos (Jira)

[ https://issues.redhat.com/browse/DROOLS-5009?page=com.atlassian.jira.plug... ] Daniel José dos Santos updated DROOLS-5009: ------------------------------------------- Sprint: 2020 Week 10-12 (from Mar 2) > DMN Designer convert java class with invalid DMN identiefier > ------------------------------------------------------------ > > Key: DROOLS-5009 > URL: https://issues.redhat.com/browse/DROOLS-5009 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.33.0.Final > Reporter: Jozef Marko > Assignee: Daniel José dos Santos > Priority: Minor > Labels: drools-tools > Attachments: Screenshot from 2020-02-05 16-21-10.png > > > There is an issue if user convert java class to DMN data type while the java class contains field name, that is invalid identifier for DMN. > for example assume this java class and try to convert it into DMN data type, you will get an error as attached. > {code:java} > public class Address { > private int number; > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13024) Integrate MP Fault Tolerance 2.1

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13024?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13024: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13003, https://github.com/wildfly/wildfly/pull/13022 (was: https://github.com/wildfly/wildfly/pull/13003) > Integrate MP Fault Tolerance 2.1 > -------------------------------- > > Key: WFLY-13024 > URL: https://issues.redhat.com/browse/WFLY-13024 > Project: WildFly > Issue Type: Feature Request > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1, 19.0.0.Beta2 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Blocker > Fix For: 19.0.0.Beta3, 20.0.0.Beta1 > > > The gist here being: > * SR FT 4.1.x > * Eclipse MP FT 2.1 > * remove hystrix, hdr, commons-config, rxjava (v1) > * update docs > Changes in 2.1: > https://download.eclipse.org/microprofile/microprofile-fault-tolerance-2.... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2020