[JBoss JIRA] (WFLY-11174) TransactionIntegration should be exposed as a capability
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-11174:
---------------------------------------
Summary: TransactionIntegration should be exposed as a capability
Key: WFLY-11174
URL: https://issues.jboss.org/browse/WFLY-11174
Project: WildFly
Issue Type: Bug
Components: JCA
Reporter: Brian Stansberry
Assignee: Brian Stansberry
A number of resources outside of the JCA subsystem depend on TransactionIntegrationService. So that wiring should be done via capability, which will result in the requirement being expressed in the configuration model (i.e. the jca subsystem must be part of the config if those resources are used.)
The capability can also depend on the relevant TX subsystem capabilities (see WFLY-9587 and subtasks), which then creates a model requirement for the tx subsystem if jca is used.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11173) The JPADefinition.DEPLOY_INSTANCE ResourceDefinition is not correct
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-11173:
---------------------------------------
Summary: The JPADefinition.DEPLOY_INSTANCE ResourceDefinition is not correct
Key: WFLY-11173
URL: https://issues.jboss.org/browse/WFLY-11173
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Reporter: Brian Stansberry
Assignee: Scott Marlow
Reusing JPADefinition for both the normal subsystem resource and the deployment subsystem resource causes some oddness.
The /deployment=*/subsystem=jpa resource should not have 'add' and 'remove' operations. A user invoking them would break things so they should not be present.
The 'default-datasource' and 'default-extended-persistence-inheritance' attributes don't make a lot of sense on the /deployment=*/subsystem=jpa resource either. But since they are part of the existing API and reading them doesn't do any harm, reads can be supported. Writes, no. And reads should be implemented by adding a step that reads the main subsystem value.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11172) Clean up the legacy subsystem dependency trees
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-11172:
---------------------------------------
Summary: Clean up the legacy subsystem dependency trees
Key: WFLY-11172
URL: https://issues.jboss.org/browse/WFLY-11172
Project: WildFly
Issue Type: Task
Components: Management
Reporter: Brian Stansberry
The legacy subsystems have a lot of unnecessary dependencies in their poms and their module.xml.
They mostly should just rely on org.jboss.as.controller and org.jboss.dmr. Perhaps org.jboss.as.cli if they provide CLI commands.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (JGRP-2300) DNS_PING in AWS ECS cannot cluster with dynamic port mappings
by Eric Thompson (Jira)
Eric Thompson created JGRP-2300:
-----------------------------------
Summary: DNS_PING in AWS ECS cannot cluster with dynamic port mappings
Key: JGRP-2300
URL: https://issues.jboss.org/browse/JGRP-2300
Project: JGroups
Issue Type: Bug
Affects Versions: 4.0.16
Environment: AWS ECS Cluster with DNS based service discovery using jboss/keycloak:latest containers
Reporter: Eric Thompson
Assignee: Bela Ban
When running an ECS cluster with jboss/keycloak:latest containers dynamic port mapping of all ports is required to allow more than one container to run per EC2 instance. Using SRV based service discovery records will allow each node to find the rest of the nodes, but when a discovery request is sent the receiving node sees the sender as IP:7600 instead of the dynamic port. It then sees this as a "new" node and tries to send discovery requests to it. And somehow it is also getting node IDs and trying to send requests to those!
See the following log, there are only 4 actual nodes and the each have a different 5 digit port number:
{code}
### Service discovery with dynamic port mapping
2018-10-10 20:17:44,178 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) Performing discovery of the following hosts [10.42.3.44:7600, 10.42.3.56:32949, 10.42.3.56:32951, 10.42.3.44:32954, c5b479b7b6d5, 10.42.3.44:32952, 10.42.3.56:7600, 17081c624290, 63976b7fae70, 557cbd7891a2]
2018-10-10 20:17:44,178 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:7600
2018-10-10 20:17:44,179 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:32949
2018-10-10 20:17:44,179 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:32951
2018-10-10 20:17:44,180 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:32954
2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to c5b479b7b6d5
2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:32952
2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:7600
2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 17081c624290, IP: 10.42.3.56:7600
2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 17081c624290
2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-238,ejb,17081c624290) Received discovery from: 17081c624290, IP: 10.42.3.56:7600
2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 63976b7fae70
2018-10-10 20:17:44,183 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 557cbd7891a2
2018-10-10 20:17:44,187 WARN [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,17081c624290) JGRP000032: 17081c624290: no physical address for c5b479b7b6d5, dropping message
{code}
This code seems to be part of the problem in this case: https://github.com/belaban/JGroups/blob/87d15ec848aa3d482ae792ef152f7e36e...
See that code uses the incoming address and adds it to the discocvered_hosts, but those addresses are ALWAYS inaccurate in this case.
Because this is what the recipient of the service discovery request sees (ie: all the ports are the default 7600):
{code}
2018-10-10 20:35:15,229 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:15,231 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:15,232 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-397,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:15,233 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:17,234 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:17,236 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:17,238 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-397,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:17,238 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:19,239 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:19,240 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:19,242 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:19,243 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:21,246 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:21,247 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:21,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:21,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:23,247 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:23,249 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:23,251 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:23,251 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:25,252 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:25,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:25,255 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
2018-10-10 20:35:25,256 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
{code}
In this state the cluster never seems to work properly and the Keycloak interface breaks in many frustrating ways.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (ELY-1680) IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/ELY-1680?page=com.atlassian.jira.plugin.s... ]
Farah Juma edited comment on ELY-1680 at 10/12/18 4:48 PM:
-----------------------------------------------------------
[~jondruse] Do you have the commands you used to generate the {{firefly_binary}} entry in this test LDIF file:
https://github.com/wildfly-security/wildfly-elytron/pull/1163/files#diff-...
I'm trying to look into why {{KeyStoreSuiteChild#testGetCertificateChain}} passes on IBM JDK but {{KeyStoreSuiteChild#testGetCertificateChainBinary}} fails. In particular, with IBM JDK, the certificate chain seems to be in the wrong order. So this may have something to do with the way the {{userSMIMECertificate;binary}} entry in the LDIF file was specified.
was (Author: fjuma):
[~jondruse] Do you have the commands you used to generate the {{firefly_binary}} entry in this test LDIF file:
https://github.com/wildfly-security/wildfly-elytron/pull/1163/files#diff-...
I'm trying to look into why {{KeyStoreSuiteChild#testGetCertificateChain}} passes on IBM JDK but {{KeyStoreSuiteChild#testGetCertificateChainBinary}} fails.
> IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
> -------------------------------------------------------------
>
> Key: ELY-1680
> URL: https://issues.jboss.org/browse/ELY-1680
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Priority: Major
> Fix For: 1.7.0.CR3
>
>
> {code}
> [ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...>
> at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> {code}
> If I switch order of certificates in chain, then test passes.
> {code}
> diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> index d8095867a..cda635beb 100644
> --- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> +++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> @@ -133,8 +133,8 @@ public class KeyStoreSuiteChild {
> Certificate[] chain = keyStore.getCertificateChain("firefly_binary");
> Assert.assertNotNull(chain);
> Assert.assertEquals(2, chain.length);
> - Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> - Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> }
> {code}
> -For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.-
> It takes long (5min) for debugger to attach to code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (ELY-1680) IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/ELY-1680?page=com.atlassian.jira.plugin.s... ]
Farah Juma commented on ELY-1680:
---------------------------------
[~jondruse] Do you have the commands you used to generate the {{firefly_binary}} entry in this test LDIF file:
https://github.com/wildfly-security/wildfly-elytron/pull/1163/files#diff-...
I'm trying to look into why {{KeyStoreSuiteChild#testGetCertificateChain}} passes on IBM JDK but {{KeyStoreSuiteChild#testGetCertificateChainBinary}} fails.
> IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
> -------------------------------------------------------------
>
> Key: ELY-1680
> URL: https://issues.jboss.org/browse/ELY-1680
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Priority: Major
> Fix For: 1.7.0.CR3
>
>
> {code}
> [ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...>
> at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> {code}
> If I switch order of certificates in chain, then test passes.
> {code}
> diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> index d8095867a..cda635beb 100644
> --- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> +++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> @@ -133,8 +133,8 @@ public class KeyStoreSuiteChild {
> Certificate[] chain = keyStore.getCertificateChain("firefly_binary");
> Assert.assertNotNull(chain);
> Assert.assertEquals(2, chain.length);
> - Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> - Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> }
> {code}
> -For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.-
> It takes long (5min) for debugger to attach to code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3131) [DMN Designer] Data Types - Add Item inconsistency
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3131?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3131:
--------------------------------
Description:
*Prerequisite:*
- Existing DMN model
*Step to reproduce:*
- Open manage custom data type dialog
- Click blue *Add* button
- Added entry will be immediately in edit mode to allow user change name and type
- Now click Insert Below, Insert Above or Insert Nested next to any entry
- Added entry won't be in edit mode
*Expected scenario:*
- Adding entries either via blue *Add* button or entries context menu options should be consistent
was:
*Prerequisite:*
- Existing custom item definitions in the model
*Step to reproduce:*
- Open manage custom data type dialog
- Click edit to entry 1
- Insert above from entry 2
- Notice entry 1 will stay in edit mode
- Insert above from entry 1
- Notice the edit mode of entry 1 will be canceled and changes done in name will be saved, changes in data type will be lost
*Expected scenario:*
- We should keep edit mode active regardless of the creation type.
Source: https://issues.jboss.org/browse/DROOLS-3024?focusedCommentId=13645851&pag...
> [DMN Designer] Data Types - Add Item inconsistency
> --------------------------------------------------
>
> Key: DROOLS-3131
> URL: https://issues.jboss.org/browse/DROOLS-3131
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.13.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Priority: Minor
> Labels: drools-tools
>
> *Prerequisite:*
> - Existing DMN model
> *Step to reproduce:*
> - Open manage custom data type dialog
> - Click blue *Add* button
> - Added entry will be immediately in edit mode to allow user change name and type
> - Now click Insert Below, Insert Above or Insert Nested next to any entry
> - Added entry won't be in edit mode
> *Expected scenario:*
> - Adding entries either via blue *Add* button or entries context menu options should be consistent
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3132) DMN assign null to ItemDefinition with allowedValues
by Matteo Mortari (Jira)
Matteo Mortari created DROOLS-3132:
--------------------------------------
Summary: DMN assign null to ItemDefinition with allowedValues
Key: DROOLS-3132
URL: https://issues.jboss.org/browse/DROOLS-3132
Project: Drools
Issue Type: Bug
Components: dmn engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
Attachments: image-2018-10-12-21-56-28-776.png
Currently engine allow to assign null to ItemDefinition with allowedValues.
But DMN spec mentions:
!image-2018-10-12-21-56-28-776.png!
So assigning null to ItemDefinition with allowedValues(not expliciting null) should raise a typeCheck error, either when assigned to InputData, either when assigned to a DRGElement(Decision), with such typeRef.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3131) [DMN Designer] Data Types - Add Item inconsistency
by Jozef Marko (Jira)
Jozef Marko created DROOLS-3131:
-----------------------------------
Summary: [DMN Designer] Data Types - Add Item inconsistency
Key: DROOLS-3131
URL: https://issues.jboss.org/browse/DROOLS-3131
Project: Drools
Issue Type: Bug
Components: DMN Editor
Reporter: Jozef Marko
Assignee: Guilherme Carreiro
*Prerequisite:*
- Existing custom item definitions in the model
*Step to reproduce:*
- Open manage custom data type dialog
- Click edit to entry 1
- Insert above from entry 2
- Notice entry 1 will stay in edit mode
- Insert above from entry 1
- Notice the edit mode of entry 1 will be canceled and changes done in name will be saved, changes in data type will be lost
*Expected scenario:*
- We should keep edit mode active regardless of the creation type.
Source: https://issues.jboss.org/browse/DROOLS-3024?focusedCommentId=13645851&pag...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months