[JBoss JIRA] (LOGMGR-272) Create release for Jakarta EE 9 APIs
by James Perkins (Jira)
[ https://issues.redhat.com/browse/LOGMGR-272?page=com.atlassian.jira.plugi... ]
James Perkins reassigned LOGMGR-272:
------------------------------------
Assignee: James Perkins
> Create release for Jakarta EE 9 APIs
> ------------------------------------
>
> Key: LOGMGR-272
> URL: https://issues.redhat.com/browse/LOGMGR-272
> Project: JBoss Log Manager
> Issue Type: Component Upgrade
> Components: core, ext
> Affects Versions: 3.0.0.Final
> Reporter: Scott Stark
> Assignee: James Perkins
> Priority: Major
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Our Jakarta EE reference implementations like Weld and Hibernate Validator have jboss-logmanager dependencies that have a conflict if the logmanager is configured to use the JsonFormatter since the Jakarta EE 9 version has changed the package to jakarta.json.* from javax.json.*.
> The core module does have a dependency on json for testing of the JsonFormatter.
> There are currently 2.0.0-RC2 versions of the jakarta.json:jakarta.json-api and org.glassfish:jakarta.json-api depednencies that support the jakarta.json.* packages. I'm not sure what branch/version numbering scheme would be wanted for this update, but I can create the PR for this once that is decided.
> Technically both javax and jakarta based versions could be used if a new version of the JsonFormatter was introduced under a new name, say JsonJkFormatter.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (LOGMGR-272) Create release for Jakarta EE 9 APIs
by Scott Stark (Jira)
[ https://issues.redhat.com/browse/LOGMGR-272?page=com.atlassian.jira.plugi... ]
Scott Stark updated LOGMGR-272:
-------------------------------
Summary: Create release for Jakarta EE 9 APIs (was: Create branch for Jakarta EE 9 APIs)
> Create release for Jakarta EE 9 APIs
> ------------------------------------
>
> Key: LOGMGR-272
> URL: https://issues.redhat.com/browse/LOGMGR-272
> Project: JBoss Log Manager
> Issue Type: Component Upgrade
> Components: core, ext
> Affects Versions: 3.0.0.Final
> Reporter: Scott Stark
> Priority: Major
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Our Jakarta EE reference implementations like Weld and Hibernate Validator have jboss-logmanager dependencies that have a conflict if the logmanager is configured to use the JsonFormatter since the Jakarta EE 9 version has changed the package to jakarta.json.* from javax.json.*.
> The core module does have a dependency on json for testing of the JsonFormatter.
> There are currently 2.0.0-RC2 versions of the jakarta.json:jakarta.json-api and org.glassfish:jakarta.json-api depednencies that support the jakarta.json.* packages. I'm not sure what branch/version numbering scheme would be wanted for this update, but I can create the PR for this once that is decided.
> Technically both javax and jakarta based versions could be used if a new version of the JsonFormatter was introduced under a new name, say JsonJkFormatter.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (LOGMGR-272) Create branch for Jakarta EE 9 APIs
by Scott Stark (Jira)
Scott Stark created LOGMGR-272:
----------------------------------
Summary: Create branch for Jakarta EE 9 APIs
Key: LOGMGR-272
URL: https://issues.redhat.com/browse/LOGMGR-272
Project: JBoss Log Manager
Issue Type: Component Upgrade
Components: core, ext
Affects Versions: 3.0.0.Final
Reporter: Scott Stark
Our Jakarta EE reference implementations like Weld and Hibernate Validator have jboss-logmanager dependencies that have a conflict if the logmanager is configured to use the JsonFormatter since the Jakarta EE 9 version has changed the package to jakarta.json.* from javax.json.*.
The core module does have a dependency on json for testing of the JsonFormatter.
There are currently 2.0.0-RC2 versions of the jakarta.json:jakarta.json-api and org.glassfish:jakarta.json-api depednencies that support the jakarta.json.* packages. I'm not sure what branch/version numbering scheme would be wanted for this update, but I can create the PR for this once that is decided.
Technically both javax and jakarta based versions could be used if a new version of the JsonFormatter was introduced under a new name, say JsonJkFormatter.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[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/24/20 3:59 PM:
---------------------------------------------------------------------
A test case TwoConnectorsEJBFailoverTestCase has been written which tests use of legacy "remote" protocol when both connectors have been initialised.
After the test case is run, looking at the server logs, I can see that client mappings for both remote://localhost:4447 and remote+http://localhost:8080 are getting passed back to the client:
{noformat}
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message from node node-1, registering cluster ejb to node node-1
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:4447
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:8080
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message from node node-1, registering cluster ejb to node node-2
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:4547
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:8180
{noformat}
However, what I can also see is that invocations may start off using the legacy protocol (remote) on port 4447 and then switch over to the HTTP Upgrade protocol (remote+http) at port 8080 at a later time. This will require further investigation but this makes sense: we use the proxy affinity to constrain the nodes chosen as targets of the invocation, in other words, where we want the invocation to go, but we don't constrain the protocol we use to get there.
So, when discovery looks for a target which satisfies strong = ClusterAffinity("ejb") and weak = NodeAffinity("node-1"), it searches through the Discovered Node Registry and finds two entries: one for remote://localhost:4447 and one for remote+http://localhost:8080. So we may need to add some logic to force the choice of protocol. Have to look into this in more detail.
was (Author: rachmato):
A test case TwoConnectorsEJBFailoverTestCase has been written which tests use of legacy "remote" protocol when both connectors have been initialised.
After the test case is run, looking at the server logs, I can see that client mappings for both remote://localhost:4447 and remote+http://localhost:8080 are getting passed back to the client:
{noformat}
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message from node node-1, registering cluster ejb to node node-1
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:4447
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:8080
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message from node node-1, registering cluster ejb to node node-2
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:4547
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:8180
{noformat}
However, what I can also see is that invocations may start off using the legacy protocol (remote) on port 4447 and then switch over to the HTTP Upgrade protocol (remote+http) at port 8080 at a later time. This will require further investigation but this makes sense: we use the proxy affinity to constrain the nodes chosen as targets of the invocation, in other words, when we want the invocation to go, but we don't constrain the protocol we use to get there.
So, when discovery looks for a target which satisfies strong = ClusterAffinity("ejb") and weak = NodeAffinity("node-1"), it searches through the Discovered Node Registry and finds two entries: one for remote://localhost:4447 and one for remote+http://localhost:8080. So we may need to add some logic to force the choice of protocol. Have to look into this in more detail.
> 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
[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/24/20 4:00 PM:
---------------------------------------------------------------------
A test case TwoConnectorsEJBFailoverTestCase has been written which tests use of legacy "remote" protocol when both connectors have been initialised.
After the test case is run, looking at the server logs, I can see that client mappings for both remote://localhost:4447 and remote+http://localhost:8080 are getting passed back to the client:
{noformat}
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message from node node-1, registering cluster ejb to node node-1
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:4447
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:8080
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message from node node-1, registering cluster ejb to node node-2
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:4547
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:8180
{noformat}
However, what I can also see is that invocations may start off using the legacy protocol (remote) on port 4447 and then switch over to the HTTP Upgrade protocol (remote+http) at port 8080 at a later time. This will require further investigation but this makes sense: we use the proxy affinity to constrain the nodes chosen as targets of the invocation, in other words, where we want the invocation to go, but we don't constrain the protocol we use to get there.
So, when discovery looks for a target which satisfies strong = ClusterAffinity("ejb") and weak = NodeAffinity("node-1"), it searches through the Discovered Node Registry and finds two entries: one for remote://localhost:4447 and one for remote+http://localhost:8080 and picks one. So we may need to add some logic to force the choice of protocol. Have to look into this in more detail.
was (Author: rachmato):
A test case TwoConnectorsEJBFailoverTestCase has been written which tests use of legacy "remote" protocol when both connectors have been initialised.
After the test case is run, looking at the server logs, I can see that client mappings for both remote://localhost:4447 and remote+http://localhost:8080 are getting passed back to the client:
{noformat}
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message from node node-1, registering cluster ejb to node node-1
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:4447
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:8080
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message from node node-1, registering cluster ejb to node node-2
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:4547
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:8180
{noformat}
However, what I can also see is that invocations may start off using the legacy protocol (remote) on port 4447 and then switch over to the HTTP Upgrade protocol (remote+http) at port 8080 at a later time. This will require further investigation but this makes sense: we use the proxy affinity to constrain the nodes chosen as targets of the invocation, in other words, where we want the invocation to go, but we don't constrain the protocol we use to get there.
So, when discovery looks for a target which satisfies strong = ClusterAffinity("ejb") and weak = NodeAffinity("node-1"), it searches through the Discovered Node Registry and finds two entries: one for remote://localhost:4447 and one for remote+http://localhost:8080. So we may need to add some logic to force the choice of protocol. Have to look into this in more detail.
> 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
[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:
--------------------------------------------
A test case TwoConnectorsEJBFailoverTestCase has been written which tests use of legacy "remote" protocol when both connectors have been initialised.
After the test case is run, looking at the server logs, I can see that client mappings for both remote://localhost:4447 and remote+http://localhost:8080 are getting passed back to the client:
{noformat}
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message from node node-1, registering cluster ejb to node node-1
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:4447
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:8080
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message from node node-1, registering cluster ejb to node node-2
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:4547
15:10:52,157 DEBUG [org.jboss.ejb.client.invocation] (XNIO-1 task-4) Received CLUSTER_TOPOLOGY(15) message block from node-1, registering block 0.0.0.0/0 to address localhost:8180
{noformat}
However, what I can also see is that invocations may start off using the legacy protocol (remote) on port 4447 and then switch over to the HTTP Upgrade protocol (remote+http) at port 8080 at a later time. This will require further investigation but this makes sense: we use the proxy affinity to constrain the nodes chosen as targets of the invocation, in other words, when we want the invocation to go, but we don't constrain the protocol we use to get there.
So, when discovery looks for a target which satisfies strong = ClusterAffinity("ejb") and weak = NodeAffinity("node-1"), it searches through the Discovered Node Registry and finds two entries: one for remote://localhost:4447 and one for remote+http://localhost:8080. So we may need to add some logic to force the choice of protocol. Have to look into this in more detail.
> 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
[JBoss JIRA] (DROOLS-5254) [DMN Designer] Generate SVG for use in Swagger documentation
by Roger Martinez (Jira)
[ https://issues.redhat.com/browse/DROOLS-5254?page=com.atlassian.jira.plug... ]
Roger Martinez commented on DROOLS-5254:
----------------------------------------
Hey [~tari_manga] [~manstis]
As far as I remember the actual SVG generation only takes care about the graph / representation itself, so I'm pretty sure it does not export any kind of "expressions" or any specific field related information in the SVG. The main entry point for the "export to SVG" feature is [here|https://github.com/kiegroup/kie-wb-common/blob/a14db66a0db9bca8be5ad...], so feel free also to take a deeper look as well.
PS: Maybe are you thinking on the "process runtime views", where the SVG for the process appears with other KPI's like the number of process instances, on each flow activity? If so, let you know that the KPI's information is not exported in the SVG declaration by the process editor, it's something added on top by the runtime view UI. Just for the records guys.
PS: Anyway lemme double check with [~tdolphine] - plz [~tdolphine], do u remember if we're doing something similar or just exporting the process representation? (Sorry for bothering, but maybe you just remember something...)
Thx!
> [DMN Designer] Generate SVG for use in Swagger documentation
> ------------------------------------------------------------
>
> Key: DROOLS-5254
> URL: https://issues.redhat.com/browse/DROOLS-5254
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Affects Versions: 7.36.0.Final
> Reporter: Matteo Mortari
> Assignee: Guilherme Gomes
> Priority: Minor
> Labels: drools-tools
>
> {quote}
> It'd be nice to have the ability to generate SVGs for a DMN XML model (including graph and boxed expressions) using a utility class/function that does not require the editor to be deployed or running. The resulting SVG would be used in the Swagger documentation.
> {quote}
> Apparently the _process_ people have been looking into something similar for processes; so it might be worth checking with [~roger600] first as whatever DMN does may simply follow on from BPMN2/CM.
> There is possibly an existing DMN JIRA for a similar requirement (as, IIRC, "Export as SVG" only generates SVG for the graph at present and not the boxed expressions).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-314) [EAP7-1386] additional ConfigSources are always initialized
by Petr Kremensky (Jira)
[ https://issues.redhat.com/browse/WFWIP-314?page=com.atlassian.jira.plugin... ]
Petr Kremensky updated WFWIP-314:
---------------------------------
Description:
I've noticed that three additional config sources provided by EAP7-1386 are always registered among config sources, even they are empty. I'll probably reject this one myself soon :) as I still have to look into the implementation of SPI for mp config, so I can assume that this is just out of box behaviour we have no control over.
Test with a simple servlet from [helloworld|https://github.com/wildfly/quickstart/tree/master/helloworld] quickstart with following addition:
{code:java}
ConfigProvider.getConfig().getConfigSources().forEach(configSource -> {
System.out.println("=================================");
System.out.println(configSource.getName());
System.out.println(configSource.getOrdinal());
System.out.println("Property names: " + configSource.getPropertyNames().stream().collect(Collectors.joining(", ")));
});
{code}
output:
{noformat}
=================================
SysPropConfigSource
400
[Standalone], awt.toolkit, ...
=================================
EnvConfigSource
300
PATH, INVOCATION_ID, ...
=================================
null:null:ServletConfigSource
60
=================================
null:null:FilterConfigSource
50
=================================
null:ServletContextConfigSource
40
{noformat}
Notice that {{PropertiesConfigSource}} is missing there as none was put to classpath. On the other hand {PropertiesConfigSource} is present once added to classpath, even it is empty.
{noformat}
...
=================================
PropertiesConfigSource[source=vfs:/content/helloworld.war/WEB-INF/classes/META-INF/microprofile-config.properties]
100
Property names:
=================================
null:null:ServletConfigSource
60
Property names:
=================================
null:null:FilterConfigSource
50
Property names:
=================================
null:ServletContextConfigSource
40
Property names:
{noformat}
As stated before, I'd probably close this one myself once I'll take deeper look into it.
was:
I've noticed that three additional config sources provided by EAP7-1386 are always registered among config sources, even they are empty. I'll probably reject this one myself soon :) as I still have to look into the implementation of SPI for mp config, so I can assume that this is just out of box behaviour we have no control over.
Test with a simple servlet from [helloworld|https://github.com/wildfly/quickstart/tree/master/helloworld] quickstart with following addition:
{code:java}
ConfigProvider.getConfig().getConfigSources().forEach(configSource -> {
System.out.println("=================================");
System.out.println(configSource.getName());
System.out.println(configSource.getOrdinal());
System.out.println("Property names: " + configSource.getPropertyNames().stream().collect(Collectors.joining(", ")));
});
{code}
output:
{noformat}
=================================
SysPropConfigSource
400
[Standalone], awt.toolkit, ...
=================================
EnvConfigSource
300
PATH, INVOCATION_ID, ...
=================================
null:null:ServletConfigSource
60
=================================
null:null:FilterConfigSource
50
=================================
null:ServletContextConfigSource
40
{noformat}
Notice that {PropertiesConfigSource} is missing there as none was put to classpath. On the other hand {PropertiesConfigSource} is present once added to classpath, even it is empty.
{noformat}
...
=================================
PropertiesConfigSource[source=vfs:/content/helloworld.war/WEB-INF/classes/META-INF/microprofile-config.properties]
100
Property names:
=================================
null:null:ServletConfigSource
60
Property names:
=================================
null:null:FilterConfigSource
50
Property names:
=================================
null:ServletContextConfigSource
40
Property names:
{noformat}
As stated before, I'd probably close this one myself once I'll take deeper look into it.
> [EAP7-1386] additional ConfigSources are always initialized
> -----------------------------------------------------------
>
> Key: WFWIP-314
> URL: https://issues.redhat.com/browse/WFWIP-314
> Project: WildFly WIP
> Issue Type: Quality Risk
> Reporter: Petr Kremensky
> Assignee: Ronald Sigal
> Priority: Minor
>
> I've noticed that three additional config sources provided by EAP7-1386 are always registered among config sources, even they are empty. I'll probably reject this one myself soon :) as I still have to look into the implementation of SPI for mp config, so I can assume that this is just out of box behaviour we have no control over.
> Test with a simple servlet from [helloworld|https://github.com/wildfly/quickstart/tree/master/helloworld] quickstart with following addition:
> {code:java}
> ConfigProvider.getConfig().getConfigSources().forEach(configSource -> {
> System.out.println("=================================");
> System.out.println(configSource.getName());
> System.out.println(configSource.getOrdinal());
> System.out.println("Property names: " + configSource.getPropertyNames().stream().collect(Collectors.joining(", ")));
> });
> {code}
> output:
> {noformat}
> =================================
> SysPropConfigSource
> 400
> [Standalone], awt.toolkit, ...
> =================================
> EnvConfigSource
> 300
> PATH, INVOCATION_ID, ...
> =================================
> null:null:ServletConfigSource
> 60
> =================================
> null:null:FilterConfigSource
> 50
> =================================
> null:ServletContextConfigSource
> 40
> {noformat}
> Notice that {{PropertiesConfigSource}} is missing there as none was put to classpath. On the other hand {PropertiesConfigSource} is present once added to classpath, even it is empty.
> {noformat}
> ...
> =================================
> PropertiesConfigSource[source=vfs:/content/helloworld.war/WEB-INF/classes/META-INF/microprofile-config.properties]
> 100
> Property names:
> =================================
> null:null:ServletConfigSource
> 60
> Property names:
> =================================
> null:null:FilterConfigSource
> 50
> Property names:
> =================================
> null:ServletContextConfigSource
> 40
> Property names:
> {noformat}
> As stated before, I'd probably close this one myself once I'll take deeper look into it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-314) [EAP7-1386] additional ConfigSources are always initialized
by Petr Kremensky (Jira)
Petr Kremensky created WFWIP-314:
------------------------------------
Summary: [EAP7-1386] additional ConfigSources are always initialized
Key: WFWIP-314
URL: https://issues.redhat.com/browse/WFWIP-314
Project: WildFly WIP
Issue Type: Quality Risk
Reporter: Petr Kremensky
Assignee: Ronald Sigal
I've noticed that three additional config sources provided by EAP7-1386 are always registered among config sources, even they are empty. I'll probably reject this one myself soon :) as I still have to look into the implementation of SPI for mp config, so I can assume that this is just out of box behaviour we have no control over.
Test with a simple servlet from [helloworld|https://github.com/wildfly/quickstart/tree/master/helloworld] quickstart with following addition:
{code:java}
ConfigProvider.getConfig().getConfigSources().forEach(configSource -> {
System.out.println("=================================");
System.out.println(configSource.getName());
System.out.println(configSource.getOrdinal());
System.out.println("Property names: " + configSource.getPropertyNames().stream().collect(Collectors.joining(", ")));
});
{code}
output:
{noformat}
=================================
SysPropConfigSource
400
[Standalone], awt.toolkit, ...
=================================
EnvConfigSource
300
PATH, INVOCATION_ID, ...
=================================
null:null:ServletConfigSource
60
=================================
null:null:FilterConfigSource
50
=================================
null:ServletContextConfigSource
40
{noformat}
Notice that {PropertiesConfigSource} is missing there as none was put to classpath. On the other hand {PropertiesConfigSource} is present once added to classpath, even it is empty.
{noformat}
...
=================================
PropertiesConfigSource[source=vfs:/content/helloworld.war/WEB-INF/classes/META-INF/microprofile-config.properties]
100
Property names:
=================================
null:null:ServletConfigSource
60
Property names:
=================================
null:null:FilterConfigSource
50
Property names:
=================================
null:ServletContextConfigSource
40
Property names:
{noformat}
As stated before, I'd probably close this one myself once I'll take deeper look into it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years