[JBoss JIRA] (WFCORE-4614) Remove org.jboss.as.cli import from AbstractMgmtTestBase
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4614?page=com.atlassian.jira.plug... ]
Brian Stansberry updated WFCORE-4614:
-------------------------------------
Summary: Remove org.jboss.as.cli import from AbstractMgmtTestBase (was: Remove org.jboss.as.cli import from AbstractManagementTestBase)
> Remove org.jboss.as.cli import from AbstractMgmtTestBase
> --------------------------------------------------------
>
> Key: WFCORE-4614
> URL: https://issues.redhat.com/browse/WFCORE-4614
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 10.0.0.Beta4, 10.0.0.Final
>
>
> AbstractMgmtTestBase imports org.jboss.as.cli.operation.OperationFormatException because executeAndRollbackOperation declares it throws it. But the method doesn't actually throw that exception.
> As a result there are a bunch of in-vm arquillian tests in WildFly that base on AbstractMgmtTestBase that are adding to their deployments the org.jboss.as.cli module as a MANIFEST>MF dependency. Remove this import and they won't need to do that. Don't do that and some of those test can then be executed against a Galleon-slimmed installation, i.e one without the CLI installed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13267) Convert EJB3 subsystem transformers to use chained transformers
by Richard Achmatowicz (Jira)
Richard Achmatowicz created WFLY-13267:
------------------------------------------
Summary: Convert EJB3 subsystem transformers to use chained transformers
Key: WFLY-13267
URL: https://issues.redhat.com/browse/WFLY-13267
Project: WildFly
Issue Type: Task
Components: EJB
Affects Versions: 19.0.0.Final
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 19.0.1.Final
The EJB3 subsystem defines its subsystem transformers in the class org.jboss.as.ejb3.subsystem.EJBTransformers.
This class organizes transformers in 'the old way' (see https://docs.jboss.org/author/display/WFLY/Domain+Mode+Subsystem+Transfor...), so that there is a lot of code duplication.
This issue will reorganize the transformers to use the chained transformer technique, where only the changes from the current version to the most recent legacy version need be specified.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[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:
--------------------------------------------
In order to permit the specification of multiple connectors to the <remote/> element, I am replacing the attribute connector-ref (as in <remote connector-ref="connector-name"/>) with a list of connector names <remote connectors="<list of connector names>"/>, so that a single or multiple connector references can be passed to the remote connector. So the current issue can be fixed by defining <remote connectors="remoting-connector http-remoting-connector"/>
The now legacy attribute connector-ref will be deprecated.
Transformers need to be set up to transform new configurations for the <remote/> element to legacy configurations of the remote element. The initial attempt at this will be as follows:
* connectors
** undefined -> discard attribute
** defined and list size == 1, convert to connector-ref attribute using that list element
** defined and list size > 1, reject attribute as no legacy configuration can handle two connectors
* connector-ref
** undefined - > discard attribute
** defined and connectors is undefined -> pass attribute through with message that connector-ref is deprecated
** defined and connectors is defined -> reject with message that connector-ref and connectors cannot both be defined and connector-ref is deprecated
> 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)
6 years, 1 month
[JBoss JIRA] (ELY-1850) CredentialStore API missing ability to check alias types
by Ahmed Haddad (Jira)
[ https://issues.redhat.com/browse/ELY-1850?page=com.atlassian.jira.plugin.... ]
Ahmed Haddad commented on ELY-1850:
-----------------------------------
i would like to start working onthis
> CredentialStore API missing ability to check alias types
> --------------------------------------------------------
>
> Key: ELY-1850
> URL: https://issues.redhat.com/browse/ELY-1850
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Affects Versions: 1.10.0.CR3
> Reporter: Darran Lofthouse
> Priority: Major
>
> The credential store allows different types to be stored under the same alias, removal requires the type to be specified so the correct entry can be removed.
> However there is no way to list the types stored under a specific alias so unless you know how the store was populated it can be impossible to remove an alias.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month