[JBoss JIRA] (WFCORE-2196) Copy ClientCompatibilityUnitTestCase into core from full
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2196?page=com.atlassian.jira.plugi... ]
Kabir Khan reassigned WFCORE-2196:
----------------------------------
Assignee: Kabir Khan (was: Brian Stansberry)
> Copy ClientCompatibilityUnitTestCase into core from full
> --------------------------------------------------------
>
> Key: WFCORE-2196
> URL: https://issues.jboss.org/browse/WFCORE-2196
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> [3:44 PM] Kabir Khan: @DarranLofthouse I see this in the logs
> [3:44 PM] Kabir Khan: 2017-01-16 15:38:55,589 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1919)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NoSuchMethodError: org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm$Builder.setDefaultRealm(Ljava/lang/String;)Lorg/wildfly/security/auth/realm/LegacyPropertiesSecurityRealm$Builder;
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:187)
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:171)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> ... 3 more
> [3:44 PM] Kabir Khan: @BrianStansberry perhaps ClientCompatibilityUnitTestCase should be in core rather than full?
> [3:47 PM] Darran Lofthouse: @KabirKhan do we have any error as to why it is not up?
> [3:47 PM] Kabir Khan: Yes, the NoSuchErrorException
> [3:48 PM] Kabir Khan: umm :)
> [3:48 PM] Kabir Khan: I invented a new class
> [3:48 PM] Kabir Khan: NoSuchMethodError
> [3:48 PM] Kabir Khan: I pasted it above my mention of Brian
> [3:49 PM] Kabir Khan: So PropertiesRealmDefinition is calling a non-existent setDefaultRealm() method on LegacyPropertiesSecurityRealm's builder
> [3:49 PM] Darran Lofthouse: @KabirKhan if the method doesn't exist that means the wrong Elytron version is being used
> [3:50 PM] Kabir Khan: Argh
> [3:50 PM] Kabir Khan: I released core without your PR merged
> [3:50 PM] Darran Lofthouse: LOL - that would explain how the wrong Elytron version is being used ;-)
> [3:51 PM] Kabir Khan: ok, I'll try again
> [3:53 PM] Brian Stansberry: @KabirKhan perhaps but I bet there was a reason we didn't move it
> [3:55 PM] Kabir Khan: On the positive side, it is not the night before the release
> [3:58 PM] Brian Stansberry: @KabirKhan if there is such a reason I don't see it in the code for that test
> [3:58 PM] Kabir Khan: yeah, me neither
> [3:59 PM] Kabir Khan: @BrianStansberry I'll rerelease core to fix my previous error
> [3:59 PM] Kabir Khan: but can look into this
> [3:59 PM] Kabir Khan: I'll create a Jira so I remember
> [3:59 PM] Brian Stansberry: @KabirKhan thanks
> [4:00 PM] Kabir Khan: although, I guess in this case it was a good thing
> [4:00 PM] Brian Stansberry: @KabirKhan tangent: do you recall if in the mixed domain tests we have the test driver invoke any ops against the legacy slave?
> [4:00 PM] Kabir Khan: this was what alerted e to the problem
> [4:00 PM] Kabir Khan: @BrianStansberry not off the top of my head, but I'd guess there should be at least some direct read-resource calls
> [4:00 PM] Brian Stansberry: @KabirKhan ah, you mean it was something in the full config that failed, that wouldn't be in core?
> [4:01 PM] Brian Stansberry: i'd say we shouldn't move that test but instead copy it
> [4:01 PM] Kabir Khan: @BrianStansberry there was an update to the elytron subsystem in full calling some stuff in Elytron
> [4:02 PM] Kabir Khan: that Elytron stuff wasn't there, because I had forgotten to merge the core PR that brought it in the Elytron upgrade
> [4:02 PM] Kabir Khan: so I saw NoSuchMethodErrors
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-2152) ASYM_ENCRYPT failure on Wildfly 10.1.0
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-2152?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-2152 at 1/16/17 10:54 AM:
---------------------------------------------------------------------
I re-ran my first test, this time using JGroups 3.6.12 with the current master version of Wildfly (11.0.0.Alpha1) and the same CDIFailoverTestCase now passes, along with all the other clustering tests.
I attach the log as org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean.txt
So, it looks as though the fix in 3.6.12 for [1] works with Wildfly. I will be also adding a basic security test to the Wildfly testuite to catch such basic errors in future. I'll provide the link here when completed.
I'll now run the same test with 10.1.0.Final to check that the issue is fixed there too.
was (Author: rachmato):
I re-ran my first test, this time using JGroups 3.6.12 with the current master version of Wildfly (11.0.0.Alpha1) and the same CDIFailoverTestCase now passes, along with all the other clustering tests.
I attach the log as org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean.txt
So, it looks as though the fix in 3.6.12 for [1] works with Wildfly. I will be also adding a basic security test to the Wildfly testuite to catch such basic errors in future. I'll provide the link here when completed.
> ASYM_ENCRYPT failure on Wildfly 10.1.0
> --------------------------------------
>
> Key: JGRP-2152
> URL: https://issues.jboss.org/browse/JGRP-2152
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Matt Wringe
> Assignee: Bela Ban
> Fix For: 4.0, 3.6.13
>
> Attachments: hawkular-metrics-1.log, hawkular-metrics-2.log, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean.txt, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output.txt, standalone.xml
>
>
> Using ASYM_ENCRYPT on Wildfly 10.1.0 seems to be broken.
> I am using the parameters for ASYM_ENCRYPT specified in http://www.jgroups.org/manual/index.html#Security
> Note: running with SYM_ENCRYPT doesn't cause any issues and it works fine with my setup. Its only ASYM_ENCRYPT which is currently failing.
> Note: running this on EAP fails in a similar manner.
> Eg:
> <protocol type="ASYM_ENCRYPT">
> <property name="encrypt_entire_message">true</property>
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">RSA</property>
> </protocol>
> If I run a single instance, then I don't see any problems appear in the logs. Its when I start a second instance that I start to see errors about unrecognised ciphers and timeouts.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-2152) ASYM_ENCRYPT failure on Wildfly 10.1.0
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-2152?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-2152 at 1/16/17 10:52 AM:
---------------------------------------------------------------------
I re-ran my first test, this time using JGroups 3.6.12 with the current master version of Wildfly (11.0.0.Alpha1) and the same CDIFailoverTestCase now passes, along with all the other clustering tests.
I attach the log as org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean.txt
So, it looks as though the fix in 3.6.12 for [1] works with Wildfly. I will be also adding a basic security test to the Wildfly testuite to catch such basic errors in future. I'll provide the link here when completed.
was (Author: rachmato):
I re-ran my first test, this time using JGroups 3.6.12 with the current master version of Wildfly (11.0.0.Alpha1) and the same CDIFailoverTestCase now passes, along with all the other clustering tests.
I attach the log as org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean.txt
So, it looks as though the fix in 3.6.12 for [1] works with Wildfly.
> ASYM_ENCRYPT failure on Wildfly 10.1.0
> --------------------------------------
>
> Key: JGRP-2152
> URL: https://issues.jboss.org/browse/JGRP-2152
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Matt Wringe
> Assignee: Bela Ban
> Fix For: 4.0, 3.6.13
>
> Attachments: hawkular-metrics-1.log, hawkular-metrics-2.log, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean.txt, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output.txt, standalone.xml
>
>
> Using ASYM_ENCRYPT on Wildfly 10.1.0 seems to be broken.
> I am using the parameters for ASYM_ENCRYPT specified in http://www.jgroups.org/manual/index.html#Security
> Note: running with SYM_ENCRYPT doesn't cause any issues and it works fine with my setup. Its only ASYM_ENCRYPT which is currently failing.
> Note: running this on EAP fails in a similar manner.
> Eg:
> <protocol type="ASYM_ENCRYPT">
> <property name="encrypt_entire_message">true</property>
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">RSA</property>
> </protocol>
> If I run a single instance, then I don't see any problems appear in the logs. Its when I start a second instance that I start to see errors about unrecognised ciphers and timeouts.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-2152) ASYM_ENCRYPT failure on Wildfly 10.1.0
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-2152?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-2152:
-------------------------------------------
I re-ran my first test, this time using JGroups 3.6.12 with the current master version of Wildfly (11.0.0.Alpha1) and the same CDIFailoverTestCase now passes, along with all the other clustering tests.
I attach the log as org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean.txt
So, it looks as though the fix in 3.6.12 for [1] works with Wildfly.
> ASYM_ENCRYPT failure on Wildfly 10.1.0
> --------------------------------------
>
> Key: JGRP-2152
> URL: https://issues.jboss.org/browse/JGRP-2152
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Matt Wringe
> Assignee: Bela Ban
> Fix For: 4.0, 3.6.13
>
> Attachments: hawkular-metrics-1.log, hawkular-metrics-2.log, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean.txt, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output.txt, standalone.xml
>
>
> Using ASYM_ENCRYPT on Wildfly 10.1.0 seems to be broken.
> I am using the parameters for ASYM_ENCRYPT specified in http://www.jgroups.org/manual/index.html#Security
> Note: running with SYM_ENCRYPT doesn't cause any issues and it works fine with my setup. Its only ASYM_ENCRYPT which is currently failing.
> Note: running this on EAP fails in a similar manner.
> Eg:
> <protocol type="ASYM_ENCRYPT">
> <property name="encrypt_entire_message">true</property>
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">RSA</property>
> </protocol>
> If I run a single instance, then I don't see any problems appear in the logs. Its when I start a second instance that I start to see errors about unrecognised ciphers and timeouts.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-2152) ASYM_ENCRYPT failure on Wildfly 10.1.0
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-2152?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated JGRP-2152:
--------------------------------------
Attachment: org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean.txt
> ASYM_ENCRYPT failure on Wildfly 10.1.0
> --------------------------------------
>
> Key: JGRP-2152
> URL: https://issues.jboss.org/browse/JGRP-2152
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Matt Wringe
> Assignee: Bela Ban
> Fix For: 4.0, 3.6.13
>
> Attachments: hawkular-metrics-1.log, hawkular-metrics-2.log, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean.txt, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output.txt, standalone.xml
>
>
> Using ASYM_ENCRYPT on Wildfly 10.1.0 seems to be broken.
> I am using the parameters for ASYM_ENCRYPT specified in http://www.jgroups.org/manual/index.html#Security
> Note: running with SYM_ENCRYPT doesn't cause any issues and it works fine with my setup. Its only ASYM_ENCRYPT which is currently failing.
> Note: running this on EAP fails in a similar manner.
> Eg:
> <protocol type="ASYM_ENCRYPT">
> <property name="encrypt_entire_message">true</property>
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">RSA</property>
> </protocol>
> If I run a single instance, then I don't see any problems appear in the logs. Its when I start a second instance that I start to see errors about unrecognised ciphers and timeouts.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7018) Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final
by Arnie Morein (JIRA)
[ https://issues.jboss.org/browse/WFLY-7018?page=com.atlassian.jira.plugin.... ]
Arnie Morein commented on WFLY-7018:
------------------------------------
That is counter-intuitive to the whole point of setting up a driver definition.
Why would this be necessary?
How is it that a complete definition doesn't work but a vague one should?
> Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final
> -------------------------------------------------------------------
>
> Key: WFLY-7018
> URL: https://issues.jboss.org/browse/WFLY-7018
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.1.0.Final
> Reporter: Mark S
> Assignee: Lin Gao
> Fix For: 11.0.0.Alpha1
>
>
> My current Wildfly 10.0.0.Final (Non-XA) Datasource configuration will not work for Wildfly 10.1.0.Final. See the "Steps to Reproduce" section.
> The stacktrace points to here:
> * https://source.jboss.org/browse/IronJacamar/adapters/src/main/java/org/jb...
> * https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.4.Final/a...
> h3. The work-around
> h3. Wildfly 10.1.0.Final Datasource configuration via CLI
> {code}
> # No parameter to set a connection property value.
> {code}
> h3. Wildfly 10.1.0.Final Datasource configuration via XML (standalone-full.xml)
> Note the addition of {{<connection-property name="databaseName">myapp</connection-property>}}
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:datasources:4.0">
> <datasources>
> <datasource jndi-name="java:/MY_APP_DS" pool-name="Postgres_MY_APP_DS">
> <connection-url>jdbc:postgresql://localhost:5432/myapp</connection-url>
> <connection-property name="databaseName">myapp</connection-property>
> <driver>postgres</driver>
> <security>
> <user-name>myapp</user-name>
> <password>myapp</password>
> </security>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> </validation>
> </datasource>
> <drivers>
> <driver name="postgres" module="org.postgres">
> <driver-class>org.postgresql.Driver</driver-class>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <datasource-class>org.postgresql.ds.PGSimpleDataSource</datasource-class>
> </driver>
> </drivers>
> </datasources>
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months