From mchoma at redhat.com Wed Feb 1 01:42:26 2017 From: mchoma at redhat.com (Martin Choma) Date: Wed, 1 Feb 2017 07:42:26 +0100 Subject: [wildfly-dev] New invocation merge In-Reply-To: <0D27DD3F-E93F-4EF0-BECB-D430531910DC@jboss.com> References: <4C4AB07B-56B0-4814-A1D4-6F0C0D59D974@redhat.com> <25BED3E9-ADD6-4ED1-966A-CEE4EE32265F@redhat.com> <0D27DD3F-E93F-4EF0-BECB-D430531910DC@jboss.com> Message-ID: Same could be achieved by annotating classes with JUnit @Category(InvocationIssue.class). Then you can: - run only InvocationIssue by specifying -Dgroups=InvocationIssue - run all tests except of InvocationIssue by specifying -DexcludedGroups=InvocationIssue - run all tests by omitting any additional system property Advandtage of @Category is you can annotate test method as well. On Tue, Jan 31, 2017 at 4:14 PM, Kabir Khan wrote: > > > > On 31 Jan 2017, at 15:09, Jason T. Greene > wrote: > > > > How about the tests are changed to require a sys prop. That way you > don't need a branch. > > So rather than @Ignore we add something like > > @BeforeClass > public static checkRunInvocationTests() { > //WFLY-XXXX > Assume.assumeTrue(System.getProperty("wildfly.temp. > disabled-invocation")) > } > > > > >> On Jan 31, 2017, at 9:07 AM, Jason T. Greene > wrote: > >> > >> I agree with this approach but we need a way to group these failures in > such a way that we know whether or not a change has regressions. > Can you elaborate a little bit? > >> > >>> On Jan 31, 2017, at 9:03 AM, Kabir Khan wrote: > >>> > >>> Hi, > >>> > >>> The new invocation library, which is the basis of for the ejb client > etc. is currently developed in a branch. There are still about 130-140 test > failures, but the team feels it is time to merge to wildfly master at some > stage later this week. This will get more visibility of the failures and > also lower the barrier of entry for whoever can jump in and help fix the > failures. > >>> > >>> Are there any objections to merging this? > >>> > >>>> From my point of view we would need to @Ignore the failing tests > since there are enough transient failures in our testsuite to make it hard > to find usual suspects if the number of failed tests is large. We could set > up another CI job against a branch which is master with the @Ignores > reverted, and I could keep that up to date as I merge to master, so that we > get a good picture of the current testsuite failures. > >>> > >>> Thanks, > >>> > >>> Kabir > >>> _______________________________________________ > >>> wildfly-dev mailing list > >>> wildfly-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170201/eb354359/attachment.html From kabir.khan at jboss.com Wed Feb 1 05:55:40 2017 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 1 Feb 2017 10:55:40 +0000 Subject: [wildfly-dev] New invocation merge In-Reply-To: References: <4C4AB07B-56B0-4814-A1D4-6F0C0D59D974@redhat.com> <25BED3E9-ADD6-4ED1-966A-CEE4EE32265F@redhat.com> <0D27DD3F-E93F-4EF0-BECB-D430531910DC@jboss.com> Message-ID: <363CC1E7-7D0E-4D47-8701-6D9374A17AA5@jboss.com> > On 1 Feb 2017, at 06:42, Martin Choma wrote: > > Same could be achieved by annotating classes with JUnit @Category(InvocationIssue.class). > > Then you can: > - run only InvocationIssue by specifying -Dgroups=InvocationIssue > - run all tests except of InvocationIssue by specifying -DexcludedGroups=InvocationIssue > - run all tests by omitting any additional system property > > Advandtage of @Category is you can annotate test method as well. That does sound nice, but it sounds like omitting the tests becomes opt-in, rather than opt-out. We would have to change all our CI jobs to use -DexcludedGroups=InvocationIssue, apart from the new one we want to create to catch regressions/give up to date progress. Or is there something which can be configured at pom level to reverse the behaviour? > > On Tue, Jan 31, 2017 at 4:14 PM, Kabir Khan wrote: > > > > On 31 Jan 2017, at 15:09, Jason T. Greene wrote: > > > > How about the tests are changed to require a sys prop. That way you don't need a branch. > > So rather than @Ignore we add something like > > @BeforeClass > public static checkRunInvocationTests() { > //WFLY-XXXX > Assume.assumeTrue(System.getProperty("wildfly.temp.disabled-invocation")) > } > > > > >> On Jan 31, 2017, at 9:07 AM, Jason T. Greene wrote: > >> > >> I agree with this approach but we need a way to group these failures in such a way that we know whether or not a change has regressions. > Can you elaborate a little bit? > >> > >>> On Jan 31, 2017, at 9:03 AM, Kabir Khan wrote: > >>> > >>> Hi, > >>> > >>> The new invocation library, which is the basis of for the ejb client etc. is currently developed in a branch. There are still about 130-140 test failures, but the team feels it is time to merge to wildfly master at some stage later this week. This will get more visibility of the failures and also lower the barrier of entry for whoever can jump in and help fix the failures. > >>> > >>> Are there any objections to merging this? > >>> > >>>> From my point of view we would need to @Ignore the failing tests since there are enough transient failures in our testsuite to make it hard to find usual suspects if the number of failed tests is large. We could set up another CI job against a branch which is master with the @Ignores reverted, and I could keep that up to date as I merge to master, so that we get a good picture of the current testsuite failures. > >>> > >>> Thanks, > >>> > >>> Kabir > >>> _______________________________________________ > >>> wildfly-dev mailing list > >>> wildfly-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From mchoma at redhat.com Wed Feb 1 08:41:30 2017 From: mchoma at redhat.com (Martin Choma) Date: Wed, 1 Feb 2017 14:41:30 +0100 Subject: [wildfly-dev] New invocation merge In-Reply-To: <363CC1E7-7D0E-4D47-8701-6D9374A17AA5@jboss.com> References: <4C4AB07B-56B0-4814-A1D4-6F0C0D59D974@redhat.com> <25BED3E9-ADD6-4ED1-966A-CEE4EE32265F@redhat.com> <0D27DD3F-E93F-4EF0-BECB-D430531910DC@jboss.com> <363CC1E7-7D0E-4D47-8701-6D9374A17AA5@jboss.com> Message-ID: Right, I see. You can add property in testsuite/pom.xml to switch InvocationIssue test by default (works for me) InvocationIssue New CI jobs have to be executed with empty excludedGroups, e.g. -DexcludedGroups= But I admit SP approach is more obvious here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170201/7872cd7f/attachment.html From tdiesler at redhat.com Thu Feb 2 03:31:50 2017 From: tdiesler at redhat.com (Thomas Diesler) Date: Thu, 2 Feb 2017 09:31:50 +0100 Subject: [wildfly-dev] WildFly-Camel 4.5.0 released Message-ID: Folks, I?m happy to announce the release of?wildfly-camel-4.5.0 . WildFly-Camel 4.5.0 provides Camel-2.18 integration with WildFly-10.1.0 This is a major upgrade release for supported components, dataformats and languages, which now reaches feature parity with other runtimes in terms of dataformats and languages. i.e. all available dataformats and languages are now also supported on WildFly. Additional components in the supported set are: camel-avro camel-context camel-elsql camel-exec camel-freemarker camel-git camel-jbpm camel-jcache camel-mllp camel-mybatis camel-optaplanner camel-paho camel-sap-netweaver camel-schematron camel-sjms camel-ssh camel-stax Additional data formats in the supported set are: Avro BeanIO JacksonXML JSON Tarfile Additional languages in the supported set are: JSonPath Component upgrades include Camel-2.18.2 HawtIO-1.4.67 In addition to that, we also resolved a number of other tasks and bugfixes . For details please see the 4.5.0 Milestone . Enjoy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170202/ec9e632f/attachment-0001.html From brian.stansberry at redhat.com Thu Feb 2 09:45:50 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 2 Feb 2017 08:45:50 -0600 Subject: [wildfly-dev] WildFly-Camel 4.5.0 released In-Reply-To: References: Message-ID: <033039FE-6CB9-4FA5-90EE-F14B77E1FF5C@redhat.com> That?s great! Thanks, and congrats, Thomas. > On Feb 2, 2017, at 2:31 AM, Thomas Diesler wrote: > > Folks, > > I?m happy to announce the release of wildfly-camel-4.5.0. > > WildFly-Camel 4.5.0 provides Camel-2.18 integration with WildFly-10.1.0 > > This is a major upgrade release for supported components, dataformats and languages, which now reaches feature parity with other runtimes in terms of dataformats and languages. i.e. all available dataformats and languages are now also supported on WildFly. > > Additional components in the supported set are: > > ? camel-avro > ? camel-context > ? camel-elsql > ? camel-exec > ? camel-freemarker > ? camel-git > ? camel-jbpm > ? camel-jcache > ? camel-mllp > ? camel-mybatis > ? camel-optaplanner > ? camel-paho > ? camel-sap-netweaver > ? camel-schematron > ? camel-sjms > ? camel-ssh > ? camel-stax > Additional data formats in the supported set are: > > ? Avro > ? BeanIO > ? JacksonXML > ? JSON > ? Tarfile > Additional languages in the supported set are: > > ? JSonPath > Component upgrades include > > ? Camel-2.18.2 > ? HawtIO-1.4.67 > In addition to that, we also resolved a number of other tasks and bugfixes. > > For details please see the 4.5.0 Milestone. > > Enjoy > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Thu Feb 2 10:50:26 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 2 Feb 2017 15:50:26 +0000 Subject: [wildfly-dev] New invocation merge In-Reply-To: References: <4C4AB07B-56B0-4814-A1D4-6F0C0D59D974@redhat.com> <25BED3E9-ADD6-4ED1-966A-CEE4EE32265F@redhat.com> <0D27DD3F-E93F-4EF0-BECB-D430531910DC@jboss.com> <363CC1E7-7D0E-4D47-8701-6D9374A17AA5@jboss.com> Message-ID: Is there any way we can get this to report when a test that was potentially excluded actually passed? I think David has pointed out elsewhere TeamCity is good at showing us new failures but not new passes. Regards, Darran Lofthouse. On 01/02/17 13:41, Martin Choma wrote: > Right, I see. > You can add property in testsuite/pom.xml to switch InvocationIssue test > by default (works for me) > > > InvocationIssue > > New CI jobs have to be executed with empty excludedGroups, e.g. > -DexcludedGroups= > > But I admit SP approach is more obvious here. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From darran.lofthouse at jboss.com Thu Feb 2 13:25:19 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 2 Feb 2017 18:25:19 +0000 Subject: [wildfly-dev] New invocation merge In-Reply-To: References: <4C4AB07B-56B0-4814-A1D4-6F0C0D59D974@redhat.com> <25BED3E9-ADD6-4ED1-966A-CEE4EE32265F@redhat.com> <0D27DD3F-E93F-4EF0-BECB-D430531910DC@jboss.com> <363CC1E7-7D0E-4D47-8701-6D9374A17AA5@jboss.com> Message-ID: <237fcb70-5e5a-f50b-b186-816282309651@jboss.com> I am going to give @Category a go - with Assume.assumeTrue I think we have the problem that some tests may be failing in their initialisation code and that risks leaving behind orphaned processes that break further tests. On 01/02/17 13:41, Martin Choma wrote: > Right, I see. > You can add property in testsuite/pom.xml to switch InvocationIssue test > by default (works for me) > > > InvocationIssue > > New CI jobs have to be executed with empty excludedGroups, e.g. > -DexcludedGroups= > > But I admit SP approach is more obvious here. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From darran.lofthouse at jboss.com Thu Feb 2 13:36:44 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 2 Feb 2017 18:36:44 +0000 Subject: [wildfly-dev] New invocation merge In-Reply-To: <237fcb70-5e5a-f50b-b186-816282309651@jboss.com> References: <4C4AB07B-56B0-4814-A1D4-6F0C0D59D974@redhat.com> <25BED3E9-ADD6-4ED1-966A-CEE4EE32265F@redhat.com> <0D27DD3F-E93F-4EF0-BECB-D430531910DC@jboss.com> <363CC1E7-7D0E-4D47-8701-6D9374A17AA5@jboss.com> <237fcb70-5e5a-f50b-b186-816282309651@jboss.com> Message-ID: That was a short lived decision. We can only use @Category with the Categories runner but we are already using the Arquillian runner. I think back to the system property. On 02/02/17 18:25, Darran Lofthouse wrote: > I am going to give @Category a go - with Assume.assumeTrue I think we > have the problem that some tests may be failing in their initialisation > code and that risks leaving behind orphaned processes that break further > tests. > > On 01/02/17 13:41, Martin Choma wrote: >> Right, I see. >> You can add property in testsuite/pom.xml to switch InvocationIssue test >> by default (works for me) >> >> >> InvocationIssue >> >> New CI jobs have to be executed with empty excludedGroups, e.g. >> -DexcludedGroups= >> >> But I admit SP approach is more obvious here. >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From mchoma at redhat.com Thu Feb 2 15:49:03 2017 From: mchoma at redhat.com (Martin Choma) Date: Thu, 2 Feb 2017 21:49:03 +0100 Subject: [wildfly-dev] New invocation merge In-Reply-To: References: <4C4AB07B-56B0-4814-A1D4-6F0C0D59D974@redhat.com> <25BED3E9-ADD6-4ED1-966A-CEE4EE32265F@redhat.com> <0D27DD3F-E93F-4EF0-BECB-D430531910DC@jboss.com> <363CC1E7-7D0E-4D47-8701-6D9374A17AA5@jboss.com> <237fcb70-5e5a-f50b-b186-816282309651@jboss.com> Message-ID: What do you mean? @Category is already used in testsuite in conjuction with Arquillian, e.g. WebSecurityBASICTestCase. On Thu, Feb 2, 2017 at 7:36 PM, Darran Lofthouse wrote: > That was a short lived decision. > > We can only use @Category with the Categories runner but we are already > using the Arquillian runner. > > I think back to the system property. > > On 02/02/17 18:25, Darran Lofthouse wrote: > > I am going to give @Category a go - with Assume.assumeTrue I think we > > have the problem that some tests may be failing in their initialisation > > code and that risks leaving behind orphaned processes that break further > > tests. > > > > On 01/02/17 13:41, Martin Choma wrote: > >> Right, I see. > >> You can add property in testsuite/pom.xml to switch InvocationIssue test > >> by default (works for me) > >> > >> > >> InvocationIssue > >> > >> New CI jobs have to be executed with empty excludedGroups, e.g. > >> -DexcludedGroups= > >> > >> But I admit SP approach is more obvious here. > >> > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170202/a2da9e2a/attachment.html From darran.lofthouse at jboss.com Thu Feb 2 15:54:23 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 2 Feb 2017 20:54:23 +0000 Subject: [wildfly-dev] New invocation merge In-Reply-To: References: <4C4AB07B-56B0-4814-A1D4-6F0C0D59D974@redhat.com> <25BED3E9-ADD6-4ED1-966A-CEE4EE32265F@redhat.com> <0D27DD3F-E93F-4EF0-BECB-D430531910DC@jboss.com> <363CC1E7-7D0E-4D47-8701-6D9374A17AA5@jboss.com> <237fcb70-5e5a-f50b-b186-816282309651@jboss.com> Message-ID: Maybe I misread the doc - it was suggesting to me you needed @RunWith(Categories) On 02/02/17 20:49, Martin Choma wrote: > What do you mean? > > @Category is already used in testsuite in conjuction with Arquillian, > e.g. WebSecurityBASICTestCase. > > On Thu, Feb 2, 2017 at 7:36 PM, Darran Lofthouse > > wrote: > > That was a short lived decision. > > We can only use @Category with the Categories runner but we are already > using the Arquillian runner. > > I think back to the system property. > > On 02/02/17 18:25, Darran Lofthouse wrote: > > I am going to give @Category a go - with Assume.assumeTrue I think we > > have the problem that some tests may be failing in their > initialisation > > code and that risks leaving behind orphaned processes that break > further > > tests. > > > > On 01/02/17 13:41, Martin Choma wrote: > >> Right, I see. > >> You can add property in testsuite/pom.xml to switch > InvocationIssue test > >> by default (works for me) > >> > >> > >> InvocationIssue > >> > >> New CI jobs have to be executed with empty excludedGroups, e.g. > >> -DexcludedGroups= > >> > >> But I admit SP approach is more obvious here. > >> > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > >> > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > From rory.odonnell at oracle.com Fri Feb 3 16:17:45 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 3 Feb 2017 21:17:45 +0000 Subject: [wildfly-dev] JDK 9 EA Build 155 is available on java.net Message-ID: Hi Jason/Tomaz, *JDK 9 Early Access* b155 is available on java.net Can you confirm fix for : * b152 - JDK-8172158 : Annotation processor not run with -source <= 8 There have been a number of fixes to bugs reported by Open Source projects since the last availability email : * b155 - JDK-8167273 : Calendar.getDisplayNames inconsistent with DateFormatSymbols * b154 - JDK-8157611 : field visiblePackages is null for the unnamed module producing NPE when accessed * b153 - JDK-8163449 : Allow per protocol setting for URLConnection defaultUseCaches Dalibor and I are presenting at FOSDEM this weekend, we would love to meet you there! * JDK 9 Outreach - The Awesome Parts Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170203/afeb8ff0/attachment-0001.html From hpehl at redhat.com Mon Feb 6 06:15:34 2017 From: hpehl at redhat.com (Harald Pehl) Date: Mon, 6 Feb 2017 12:15:34 +0100 Subject: [wildfly-dev] Analyse the management model Message-ID: TL;DR A tool to analyse the WildFly management model tree using a graph database. # Longer version As a heavy consumer of the WildFly management model I've always been looking for a way to analyse the management model. So I decided to start a little side project over the weekend. The result is a tool [1] which reads a (sub)tree of the WildFly management model and stores the results into a graph database using Neo4j [2]. To get started, you need a running WildFly and Neo4j instance. The tool writes nodes for each resource, attribute, operation, request property and capability. In addition it creates relationships between these nodes. You can use the data to - get alternatives and requires relations between attributes - get deprecated attributes and request parameters for one or all resources - find attributes which might miss a capability reference - find inconsistent attributes - see differences between resources (using external diff tools) See [3] for more use cases. I hope this is useful for others as well. Feedback, suggestions and critics are welcome! [1] https://github.com/hal/model-graph [2] https://neo4j.com/ [3] https://github.com/hal/model-graph#examples -- Harald Pehl JBoss by Red Hat http://hpehl.info From darran.lofthouse at jboss.com Mon Feb 6 06:37:32 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 6 Feb 2017 11:37:32 +0000 Subject: [wildfly-dev] Current Invocation / Elytron Integration Related Failures 2017-02-06 - 1 Message-ID: <9998ba60-d160-4f9f-5be6-f6db0c06c029@jboss.com> As discussed last week the invocation integration work has been merged into WildFly with the known failing tests being skipped. At the bottom of this e-mail is a list of the failures from the latest test run. The test run is here: - https://ci.wildfly.org/viewLog.html?buildId=44194&buildTypeId=WF_MasterIPv6&tab=buildResultsDiv The tests are disabled be default so they don't impact PR runs but can be re-enabled with -Dwildfly.tmp.enable.invocation.tests=true Stuart has contributed some appclient fixes today so I will kick off another run as they may could be fixed. Probably best for any discussions to happen within the 'WildFly Elytron' room within HipChat which can be found here https://www.hipchat.com/gKoTFkUyg. org.jboss.as.test.integration.ejb.mdb.containerstart.SendMessagesTestCase.testShutdown org.jboss.as.test.integration.ejb.transaction.mdb.timeout.MessageDrivenTimeoutTestCase.transactionTimeoutActivationProperty org.jboss.as.test.integration.batch.analyzer.transactiontimeout.AnalyzerTransactionTimeoutTestCase.testTransactionTimeoutDisabled org.jboss.as.test.integration.batch.transaction.BatchTransactionTimeoutTestCase.testThreadIsAvailableForNextJob org.jboss.as.test.integration.ee.appclient.basic.SimpleApplicationClientTestCase.testAppClientJBossDescriptor org.jboss.as.test.integration.ee.appclient.basic.SimpleApplicationClientTestCase.simpleAppClientTest org.jboss.as.test.integration.ee.appclient.basic.SimpleApplicationClientTestCase.descriptorBasedAppClientTest org.jboss.as.test.integration.ejb.async.AsyncMethodTestCase.testCancelRemoteAsyncMethod org.jboss.as.test.integration.ejb.client.descriptor.EJBClientDescriptorTestCase.testClientInvocationTimeout org.jboss.as.test.integration.ejb.client.descriptor.EJBClientDescriptorTestCase.testClientPropertiesReplacementInConfig org.jboss.as.test.integration.ejb.client.descriptor.EJBClientDescriptorTestCase.testEJBClientContextConfiguration org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testSecurityContextAssociation org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testClientLoginModule org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testSecurityContextAssociation org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testClientLoginModule org.jboss.as.test.integration.ejb.ejb2.reference.global.GlobalReferenceTestCase.testSession21 org.jboss.as.test.integration.ejb.home.remotehome.annotation.AnnotationHomeTestCase.testGetEjbLocalObject org.jboss.as.test.integration.ejb.home.remotehome.descriptor.SimpleHomeTestCase.testgetEjbLocalObject org.jboss.as.test.integration.ejb.mapbased.MapBasedInitialContextEjbClientTestCase.testScopedEJBClientContexts org.jboss.as.test.integration.ejb.remote.client.api.EJBClientAPIUsageTestCase.testNonExistentViewForEJB org.jboss.as.test.integration.ejb.remote.client.api.EJBClientAPIUsageTestCase.testGetBusinessObjectRemote org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientUserTransactionTestCase.testBatchOperationsInTx org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testSLSBMandatoryTx org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testClientTransactionManagement org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testNotSwitched org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testUnsecured org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testSwitched org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testDirect org.jboss.as.test.integration.ejb.remote.suspend.EjbRemoteSuspendTestCase.testSuspendedCallRejected org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSingleton org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSFSB org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSLSB org.jboss.as.test.integration.ejb.timerservice.tx.timeout.TxTimeoutTimerServiceTestCase.testPrivateScheduleMethod org.jboss.as.test.integration.ejb.timerservice.tx.timeout.TxTimeoutTimerServiceTestCase.testPublicTimeoutMethod org.jboss.as.test.integration.ejb.timerservice.tx.timeout.TxTimeoutTimerServiceTestCase.testPrivateTimeoutMethod org.jboss.as.test.integration.ejb.timerservice.tx.timeout.TxTimeoutTimerServiceTestCase.testPublicScheduleMethod org.jboss.as.test.integration.ejb.transaction.bmt.lazyenlist.LazyTransactionEnlistmentUnitTestCase.testRawSQL org.jboss.as.test.integration.ejb.transaction.bmt.timeout.StatelessTimeoutTestCase.timeoutMultiple org.jboss.as.test.integration.ejb.transaction.bmt.timeout.StatelessTimeoutTestCase.timeout org.jboss.as.test.integration.ejb.transaction.cmt.timeout.DefaultTransactionTimeoutTestCase.testDescriptor org.jboss.as.test.integration.ejb.transaction.cmt.timeout.TransactionTimeoutTestCase.testDescriptor org.jboss.as.test.integration.ejb.transaction.cmt.timeout.TransactionTimeoutTestCase.testBeanTimeouts org.jboss.as.test.integration.ejb.transaction.cmt.timeout.TransactionTimeoutTestCase.testDescriptorWithNestedExpressions org.jboss.as.test.integration.ejb.transaction.descriptor.EjbTransactionDescriptorTestCase.testRemoteMethodHasMandatory org.jboss.as.test.integration.ejb.transaction.descriptor.EjbTransactionDescriptorTestCase.testRemoteMethodHasMandatoryNoMethodIntf org.jboss.as.test.integration.jpa.datasourcedefinition.DataSourceDefinitionJPATestCase.testUserTxRollbackDiscardsChanges org.jboss.as.test.integration.jpa.transaction.TransactionTestCase.testUserTxRollbackDiscardsChanges org.jboss.as.test.integration.management.deploy.runtime.StatefulEJBRemoteHomeRuntimeNameTestCase.testStatefulLocalHome org.jboss.as.test.integration.management.deploy.runtime.StatelessEJBRemoteHomeRuntimeNameTestCase.testStatelessLocalHome org.jboss.as.test.integration.naming.connector.JMXConnectorTestCase.testMBeanCount org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap org.jboss.as.test.integration.naming.rmi.RmiContextLookupTestCase.testTaskSubmit org.jboss.as.test.iiop.client.IIOPTransactionPropagationTestCase.testIIOPInvocationWithRollbackOnly org.jboss.as.test.iiop.client.IIOPTransactionPropagationTestCase.testIIOPNeverCallInvocation org.jboss.as.test.iiop.client.IIOPTransactionPropagationTestCase.testIIOPInvocation org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSameTransactionEachCall org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnlyBeforeCompletion org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationSucceeded org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnly org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRemoteIIOPInvocation org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationFailed org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.noTimeoutStateless org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.noTimeoutStateful org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateless org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase.test org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase.test org.jboss.as.test.clustering.single.registry.RegistryTestCase.test org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSameTransactionEachCall org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnly org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRemoteInvocation org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationFailed org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase.testEjbTimeoutOnOtherNode org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase.testStatefulRemoteHomeFromRemoteHome org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase.testStatelessRemoteHomeFromRemoteHome org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase.testStatefulRemoteFromRemote org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase.testStatelessRemoteFromRemote org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerStartsLate From tomaz.cerar at gmail.com Mon Feb 6 08:02:11 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 6 Feb 2017 14:02:11 +0100 Subject: [wildfly-dev] Current Invocation / Elytron Integration Related Failures 2017-02-06 - 1 In-Reply-To: <9998ba60-d160-4f9f-5be6-f6db0c06c029@jboss.com> References: <9998ba60-d160-4f9f-5be6-f6db0c06c029@jboss.com> Message-ID: I've created separate CI job that has this tests enabled, so it will be easier to track. https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterNewInvocationTests -- tomaz On Mon, Feb 6, 2017 at 12:37 PM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > As discussed last week the invocation integration work has been merged > into WildFly with the known failing tests being skipped. At the bottom > of this e-mail is a list of the failures from the latest test run. > > The test run is here: - > https://ci.wildfly.org/viewLog.html?buildId=44194& > buildTypeId=WF_MasterIPv6&tab=buildResultsDiv > > The tests are disabled be default so they don't impact PR runs but can > be re-enabled with -Dwildfly.tmp.enable.invocation.tests=true > > Stuart has contributed some appclient fixes today so I will kick off > another run as they may could be fixed. > > Probably best for any discussions to happen within the 'WildFly Elytron' > room within HipChat which can be found here > https://www.hipchat.com/gKoTFkUyg. > > org.jboss.as.test.integration.ejb.mdb.containerstart.SendMessagesTestCase. > testShutdown > org.jboss.as.test.integration.ejb.transaction.mdb.timeout. > MessageDrivenTimeoutTestCase.transactionTimeoutActivationProperty > org.jboss.as.test.integration.batch.analyzer.transactiontimeout. > AnalyzerTransactionTimeoutTestCase.testTransactionTimeoutDisabled > org.jboss.as.test.integration.batch.transaction. > BatchTransactionTimeoutTestCase.testThreadIsAvailableForNextJob > org.jboss.as.test.integration.ee.appclient.basic. > SimpleApplicationClientTestCase.testAppClientJBossDescriptor > org.jboss.as.test.integration.ee.appclient.basic. > SimpleApplicationClientTestCase.simpleAppClientTest > org.jboss.as.test.integration.ee.appclient.basic. > SimpleApplicationClientTestCase.descriptorBasedAppClientTest > org.jboss.as.test.integration.ejb.async.AsyncMethodTestCase. > testCancelRemoteAsyncMethod > org.jboss.as.test.integration.ejb.client.descriptor. > EJBClientDescriptorTestCase.testClientInvocationTimeout > org.jboss.as.test.integration.ejb.client.descriptor. > EJBClientDescriptorTestCase.testClientPropertiesReplacementInConfig > org.jboss.as.test.integration.ejb.client.descriptor. > EJBClientDescriptorTestCase.testEJBClientContextConfiguration > org.jboss.as.test.integration.ejb.container.interceptor.security. > SwitchIdentityTestCase.testSecurityContextAssociation > org.jboss.as.test.integration.ejb.container.interceptor.security. > SwitchIdentityTestCase.testClientLoginModule > org.jboss.as.test.integration.ejb.container.interceptor.security.api. > SwitchIdentityTestCase.testSecurityContextAssociation > org.jboss.as.test.integration.ejb.container.interceptor.security.api. > SwitchIdentityTestCase.testClientLoginModule > org.jboss.as.test.integration.ejb.ejb2.reference.global. > GlobalReferenceTestCase.testSession21 > org.jboss.as.test.integration.ejb.home.remotehome.annotation. > AnnotationHomeTestCase.testGetEjbLocalObject > org.jboss.as.test.integration.ejb.home.remotehome. > descriptor.SimpleHomeTestCase.testgetEjbLocalObject > org.jboss.as.test.integration.ejb.mapbased.MapBasedInitialContextEjbClien > tTestCase.testScopedEJBClientContexts > org.jboss.as.test.integration.ejb.remote.client.api. > EJBClientAPIUsageTestCase.testNonExistentViewForEJB > org.jboss.as.test.integration.ejb.remote.client.api. > EJBClientAPIUsageTestCase.testGetBusinessObjectRemote > org.jboss.as.test.integration.ejb.remote.client.api.tx. > EJBClientUserTransactionTestCase.testBatchOperationsInTx > org.jboss.as.test.integration.ejb.remote.client.api.tx. > EJBClientXidTransactionTestCase.testSLSBMandatoryTx > org.jboss.as.test.integration.ejb.remote.client.api.tx. > EJBClientXidTransactionTestCase.testClientTransactionManagement > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase. > testNotSwitched > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase. > testUnsecured > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase. > testSwitched > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase. > testDirect > org.jboss.as.test.integration.ejb.remote.suspend.EjbRemoteSuspendTestCase. > testSuspendedCallRejected > org.jboss.as.test.integration.ejb.remote.view. > LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLoca > lViewOfSingleton > org.jboss.as.test.integration.ejb.remote.view. > LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLoca > lViewOfSFSB > org.jboss.as.test.integration.ejb.remote.view. > LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLoca > lViewOfSLSB > org.jboss.as.test.integration.ejb.timerservice.tx.timeout. > TxTimeoutTimerServiceTestCase.testPrivateScheduleMethod > org.jboss.as.test.integration.ejb.timerservice.tx.timeout. > TxTimeoutTimerServiceTestCase.testPublicTimeoutMethod > org.jboss.as.test.integration.ejb.timerservice.tx.timeout. > TxTimeoutTimerServiceTestCase.testPrivateTimeoutMethod > org.jboss.as.test.integration.ejb.timerservice.tx.timeout. > TxTimeoutTimerServiceTestCase.testPublicScheduleMethod > org.jboss.as.test.integration.ejb.transaction.bmt.lazyenlist. > LazyTransactionEnlistmentUnitTestCase.testRawSQL > org.jboss.as.test.integration.ejb.transaction.bmt.timeout. > StatelessTimeoutTestCase.timeoutMultiple > org.jboss.as.test.integration.ejb.transaction.bmt.timeout. > StatelessTimeoutTestCase.timeout > org.jboss.as.test.integration.ejb.transaction.cmt.timeout. > DefaultTransactionTimeoutTestCase.testDescriptor > org.jboss.as.test.integration.ejb.transaction.cmt.timeout. > TransactionTimeoutTestCase.testDescriptor > org.jboss.as.test.integration.ejb.transaction.cmt.timeout. > TransactionTimeoutTestCase.testBeanTimeouts > org.jboss.as.test.integration.ejb.transaction.cmt.timeout. > TransactionTimeoutTestCase.testDescriptorWithNestedExpressions > org.jboss.as.test.integration.ejb.transaction.descriptor. > EjbTransactionDescriptorTestCase.testRemoteMethodHasMandatory > org.jboss.as.test.integration.ejb.transaction.descriptor. > EjbTransactionDescriptorTestCase.testRemoteMethodHasMandatoryNoMethodIntf > org.jboss.as.test.integration.jpa.datasourcedefinition. > DataSourceDefinitionJPATestCase.testUserTxRollbackDiscardsChanges > org.jboss.as.test.integration.jpa.transaction.TransactionTestCase. > testUserTxRollbackDiscardsChanges > org.jboss.as.test.integration.management.deploy.runtime. > StatefulEJBRemoteHomeRuntimeNameTestCase.testStatefulLocalHome > org.jboss.as.test.integration.management.deploy.runtime. > StatelessEJBRemoteHomeRuntimeNameTestCase.testStatelessLocalHome > org.jboss.as.test.integration.naming.connector.JMXConnectorTestCase. > testMBeanCount > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase. > testDir > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase. > testLdap > org.jboss.as.test.integration.naming.rmi.RmiContextLookupTestCase. > testTaskSubmit > org.jboss.as.test.iiop.client.IIOPTransactionPropagationTestCase. > testIIOPInvocationWithRollbackOnly > org.jboss.as.test.iiop.client.IIOPTransactionPropagationTestCase. > testIIOPNeverCallInvocation > org.jboss.as.test.iiop.client.IIOPTransactionPropagationTest > Case.testIIOPInvocation > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase. > testSameTransactionEachCall > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase. > testRollbackOnlyBeforeCompletion > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase. > testSynchronizationSucceeded > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestC > ase.testRollbackOnly > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestC > ase.testRemoteIIOPInvocation > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestC > ase.testSynchronizationFailed > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase. > noTimeoutStateless > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase. > timeoutStateful > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase. > noTimeoutStateful > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase. > timeoutStateless > org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase( > SYNC-tcp).test > org.jboss.as.test.clustering.cluster.provider. > ServiceProviderRegistrationTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp). > test > org.jboss.as.test.clustering.cluster.ejb.remote. > RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover > org.jboss.as.test.clustering.cluster.ejb.remote. > RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover > org.jboss.as.test.clustering.cluster.ejb.remote. > RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover > org.jboss.as.test.clustering.cluster.ejb.remote. > RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover > org.jboss.as.test.clustering.cluster.ejb.remote. > RemoteFailoverTestCase(SYNC-tcp).testClientException > org.jboss.as.test.clustering.single.provider. > ServiceProviderRegistrationTestCase.test > org.jboss.as.test.clustering.single.dispatcher. > CommandDispatcherTestCase.test > org.jboss.as.test.clustering.single.registry.RegistryTestCase.test > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase. > testSameTransactionEachCall > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase. > testRollbackOnlyBeforeCompletion > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase. > testSynchronizationSucceeded > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase. > testRollbackOnly > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase. > testRemoteInvocation > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase. > testSynchronizationFailed > org.jboss.as.test.multinode.ejb.timer.database. > DatabaseTimerServiceMultiNodeTestCase.testEjbTimeoutOnOtherNode > org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase. > testStatefulRemoteHomeFromRemoteHome > org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase. > testStatelessRemoteHomeFromRemoteHome > org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase. > testStatefulRemoteFromRemote > org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase. > testStatelessRemoteFromRemote > org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase > org.jboss.as.test.multinode.remotecall.scoped.context. > DynamicJNDIContextEJBInvocationTestCase > org.jboss.as.test.manualmode.ejb.client.outbound.connection. > RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts > org.jboss.as.test.manualmode.ejb.client.outbound.connection. > RemoteOutboundConnectionReconnectTestCase.testRemoteServerStartsLate > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170206/ef241db8/attachment-0001.html From kabir.khan at jboss.com Mon Feb 6 08:14:53 2017 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 6 Feb 2017 13:14:53 +0000 Subject: [wildfly-dev] Analyse the management model In-Reply-To: References: Message-ID: <185A4078-FFD8-45AE-AB63-D958408B6EAA@jboss.com> Very cool. If we could have the neo4j server somewhere central, perhaps we could eventually do the comparisons of model versions from there? > On 6 Feb 2017, at 11:15, Harald Pehl wrote: > > TL;DR > > A tool to analyse the WildFly management model tree using a graph database. > > # Longer version > > As a heavy consumer of the WildFly management model I've always been > looking for a way to analyse the management model. So I decided to > start a little side project over the weekend. The result is a tool [1] > which reads a (sub)tree of the WildFly management model and stores the > results into a graph database using Neo4j [2]. To get started, you > need a running WildFly and Neo4j instance. > > The tool writes nodes for each resource, attribute, operation, request > property and capability. In addition it creates relationships between > these nodes. You can use the data to > > - get alternatives and requires relations between attributes > - get deprecated attributes and request parameters for one or all resources > - find attributes which might miss a capability reference > - find inconsistent attributes > - see differences between resources (using external diff tools) > > See [3] for more use cases. I hope this is useful for others as well. > Feedback, suggestions and critics are welcome! > > [1] https://github.com/hal/model-graph > [2] https://neo4j.com/ > [3] https://github.com/hal/model-graph#examples > > -- > Harald Pehl > JBoss by Red Hat > http://hpehl.info > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From darran.lofthouse at jboss.com Mon Feb 6 08:20:59 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 6 Feb 2017 13:20:59 +0000 Subject: [wildfly-dev] Current Invocation / Elytron Integration Related Failures 2017-02-06 - 1 In-Reply-To: References: <9998ba60-d160-4f9f-5be6-f6db0c06c029@jboss.com> Message-ID: <5e41d3c1-a598-fae3-daaa-f62d9b0d9b35@jboss.com> I am being lazy and haven't looked ;-), but do we have IPV6 enabled on that run? A couple of the failures we are experiencing are related to IPV6 addresses. Regards, Darran Lofthouse. On 06/02/17 13:02, Toma? Cerar wrote: > I've created separate CI job that has this tests enabled, so it will be > easier to track. > > https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterNewInvocationTests > > -- > tomaz > > On Mon, Feb 6, 2017 at 12:37 PM, Darran Lofthouse > > wrote: > > As discussed last week the invocation integration work has been merged > into WildFly with the known failing tests being skipped. At the bottom > of this e-mail is a list of the failures from the latest test run. > > The test run is here: - > https://ci.wildfly.org/viewLog.html?buildId=44194&buildTypeId=WF_MasterIPv6&tab=buildResultsDiv > > > The tests are disabled be default so they don't impact PR runs but can > be re-enabled with -Dwildfly.tmp.enable.invocation.tests=true > > Stuart has contributed some appclient fixes today so I will kick off > another run as they may could be fixed. > > Probably best for any discussions to happen within the 'WildFly Elytron' > room within HipChat which can be found here > https://www.hipchat.com/gKoTFkUyg . > > org.jboss.as.test.integration.ejb.mdb.containerstart.SendMessagesTestCase.testShutdown > org.jboss.as.test.integration.ejb.transaction.mdb.timeout.MessageDrivenTimeoutTestCase.transactionTimeoutActivationProperty > org.jboss.as.test.integration.batch.analyzer.transactiontimeout.AnalyzerTransactionTimeoutTestCase.testTransactionTimeoutDisabled > org.jboss.as.test.integration.batch.transaction.BatchTransactionTimeoutTestCase.testThreadIsAvailableForNextJob > org.jboss.as.test.integration.ee.appclient.basic.SimpleApplicationClientTestCase.testAppClientJBossDescriptor > org.jboss.as.test.integration.ee.appclient.basic.SimpleApplicationClientTestCase.simpleAppClientTest > org.jboss.as.test.integration.ee.appclient.basic.SimpleApplicationClientTestCase.descriptorBasedAppClientTest > org.jboss.as.test.integration.ejb.async.AsyncMethodTestCase.testCancelRemoteAsyncMethod > org.jboss.as.test.integration.ejb.client.descriptor.EJBClientDescriptorTestCase.testClientInvocationTimeout > org.jboss.as.test.integration.ejb.client.descriptor.EJBClientDescriptorTestCase.testClientPropertiesReplacementInConfig > org.jboss.as.test.integration.ejb.client.descriptor.EJBClientDescriptorTestCase.testEJBClientContextConfiguration > org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testSecurityContextAssociation > org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testClientLoginModule > org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testSecurityContextAssociation > org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testClientLoginModule > org.jboss.as.test.integration.ejb.ejb2.reference.global.GlobalReferenceTestCase.testSession21 > org.jboss.as.test.integration.ejb.home.remotehome.annotation.AnnotationHomeTestCase.testGetEjbLocalObject > org.jboss.as.test.integration.ejb.home.remotehome.descriptor.SimpleHomeTestCase.testgetEjbLocalObject > org.jboss.as.test.integration.ejb.mapbased.MapBasedInitialContextEjbClientTestCase.testScopedEJBClientContexts > org.jboss.as.test.integration.ejb.remote.client.api.EJBClientAPIUsageTestCase.testNonExistentViewForEJB > org.jboss.as.test.integration.ejb.remote.client.api.EJBClientAPIUsageTestCase.testGetBusinessObjectRemote > org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientUserTransactionTestCase.testBatchOperationsInTx > org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testSLSBMandatoryTx > org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testClientTransactionManagement > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testNotSwitched > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testUnsecured > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testSwitched > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testDirect > org.jboss.as.test.integration.ejb.remote.suspend.EjbRemoteSuspendTestCase.testSuspendedCallRejected > org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSingleton > org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSFSB > org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSLSB > org.jboss.as.test.integration.ejb.timerservice.tx.timeout.TxTimeoutTimerServiceTestCase.testPrivateScheduleMethod > org.jboss.as.test.integration.ejb.timerservice.tx.timeout.TxTimeoutTimerServiceTestCase.testPublicTimeoutMethod > org.jboss.as.test.integration.ejb.timerservice.tx.timeout.TxTimeoutTimerServiceTestCase.testPrivateTimeoutMethod > org.jboss.as.test.integration.ejb.timerservice.tx.timeout.TxTimeoutTimerServiceTestCase.testPublicScheduleMethod > org.jboss.as.test.integration.ejb.transaction.bmt.lazyenlist.LazyTransactionEnlistmentUnitTestCase.testRawSQL > org.jboss.as.test.integration.ejb.transaction.bmt.timeout.StatelessTimeoutTestCase.timeoutMultiple > org.jboss.as.test.integration.ejb.transaction.bmt.timeout.StatelessTimeoutTestCase.timeout > org.jboss.as.test.integration.ejb.transaction.cmt.timeout.DefaultTransactionTimeoutTestCase.testDescriptor > org.jboss.as.test.integration.ejb.transaction.cmt.timeout.TransactionTimeoutTestCase.testDescriptor > org.jboss.as.test.integration.ejb.transaction.cmt.timeout.TransactionTimeoutTestCase.testBeanTimeouts > org.jboss.as.test.integration.ejb.transaction.cmt.timeout.TransactionTimeoutTestCase.testDescriptorWithNestedExpressions > org.jboss.as.test.integration.ejb.transaction.descriptor.EjbTransactionDescriptorTestCase.testRemoteMethodHasMandatory > org.jboss.as.test.integration.ejb.transaction.descriptor.EjbTransactionDescriptorTestCase.testRemoteMethodHasMandatoryNoMethodIntf > org.jboss.as.test.integration.jpa.datasourcedefinition.DataSourceDefinitionJPATestCase.testUserTxRollbackDiscardsChanges > org.jboss.as.test.integration.jpa.transaction.TransactionTestCase.testUserTxRollbackDiscardsChanges > org.jboss.as.test.integration.management.deploy.runtime.StatefulEJBRemoteHomeRuntimeNameTestCase.testStatefulLocalHome > org.jboss.as.test.integration.management.deploy.runtime.StatelessEJBRemoteHomeRuntimeNameTestCase.testStatelessLocalHome > org.jboss.as.test.integration.naming.connector.JMXConnectorTestCase.testMBeanCount > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap > org.jboss.as.test.integration.naming.rmi.RmiContextLookupTestCase.testTaskSubmit > org.jboss.as.test.iiop.client.IIOPTransactionPropagationTestCase.testIIOPInvocationWithRollbackOnly > org.jboss.as.test.iiop.client.IIOPTransactionPropagationTestCase.testIIOPNeverCallInvocation > org.jboss.as.test.iiop.client.IIOPTransactionPropagationTestCase.testIIOPInvocation > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSameTransactionEachCall > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnlyBeforeCompletion > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationSucceeded > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnly > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRemoteIIOPInvocation > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationFailed > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.noTimeoutStateless > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.noTimeoutStateful > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateless > org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException > org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase.test > org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase.test > org.jboss.as.test.clustering.single.registry.RegistryTestCase.test > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSameTransactionEachCall > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnly > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRemoteInvocation > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationFailed > org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase.testEjbTimeoutOnOtherNode > org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase.testStatefulRemoteHomeFromRemoteHome > org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase.testStatelessRemoteHomeFromRemoteHome > org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase.testStatefulRemoteFromRemote > org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase.testStatelessRemoteFromRemote > org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase > org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts > org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerStartsLate > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > From darran.lofthouse at jboss.com Mon Feb 6 08:23:20 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 6 Feb 2017 13:23:20 +0000 Subject: [wildfly-dev] Analyse the management model In-Reply-To: <185A4078-FFD8-45AE-AB63-D958408B6EAA@jboss.com> References: <185A4078-FFD8-45AE-AB63-D958408B6EAA@jboss.com> Message-ID: If this can do model comparison that could be very useful to double check no incompatible changes have leaked in without an appropriate version bump. On 06/02/17 13:14, Kabir Khan wrote: > Very cool. If we could have the neo4j server somewhere central, perhaps we could eventually do the comparisons of model versions from there? >> On 6 Feb 2017, at 11:15, Harald Pehl wrote: >> >> TL;DR >> >> A tool to analyse the WildFly management model tree using a graph database. >> >> # Longer version >> >> As a heavy consumer of the WildFly management model I've always been >> looking for a way to analyse the management model. So I decided to >> start a little side project over the weekend. The result is a tool [1] >> which reads a (sub)tree of the WildFly management model and stores the >> results into a graph database using Neo4j [2]. To get started, you >> need a running WildFly and Neo4j instance. >> >> The tool writes nodes for each resource, attribute, operation, request >> property and capability. In addition it creates relationships between >> these nodes. You can use the data to >> >> - get alternatives and requires relations between attributes >> - get deprecated attributes and request parameters for one or all resources >> - find attributes which might miss a capability reference >> - find inconsistent attributes >> - see differences between resources (using external diff tools) >> >> See [3] for more use cases. I hope this is useful for others as well. >> Feedback, suggestions and critics are welcome! >> >> [1] https://github.com/hal/model-graph >> [2] https://neo4j.com/ >> [3] https://github.com/hal/model-graph#examples >> >> -- >> Harald Pehl >> JBoss by Red Hat >> http://hpehl.info >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From hpehl at redhat.com Mon Feb 6 08:33:54 2017 From: hpehl at redhat.com (Harald Pehl) Date: Mon, 6 Feb 2017 14:33:54 +0100 Subject: [wildfly-dev] Analyse the management model In-Reply-To: <185A4078-FFD8-45AE-AB63-D958408B6EAA@jboss.com> References: <185A4078-FFD8-45AE-AB63-D958408B6EAA@jboss.com> Message-ID: Good point. I guess this could easily be done by moving this to OpenShift. With dedicated WildFly / Neo4j instances for each major WildFly version. This way we could also provide an online Neo4j browser (similar to [1] and [2]). Even with a custom documentation and mini guides. [1] https://stackoverflow.com/questions/37370820/hosting-a-public-read-only-neo4j-instance-in-the-cloud [2] http://neo4j.het.io/browser/ On Mon, Feb 6, 2017 at 2:14 PM, Kabir Khan wrote: > Very cool. If we could have the neo4j server somewhere central, perhaps we could eventually do the comparisons of model versions from there? >> On 6 Feb 2017, at 11:15, Harald Pehl wrote: >> >> TL;DR >> >> A tool to analyse the WildFly management model tree using a graph database. >> >> # Longer version >> >> As a heavy consumer of the WildFly management model I've always been >> looking for a way to analyse the management model. So I decided to >> start a little side project over the weekend. The result is a tool [1] >> which reads a (sub)tree of the WildFly management model and stores the >> results into a graph database using Neo4j [2]. To get started, you >> need a running WildFly and Neo4j instance. >> >> The tool writes nodes for each resource, attribute, operation, request >> property and capability. In addition it creates relationships between >> these nodes. You can use the data to >> >> - get alternatives and requires relations between attributes >> - get deprecated attributes and request parameters for one or all resources >> - find attributes which might miss a capability reference >> - find inconsistent attributes >> - see differences between resources (using external diff tools) >> >> See [3] for more use cases. I hope this is useful for others as well. >> Feedback, suggestions and critics are welcome! >> >> [1] https://github.com/hal/model-graph >> [2] https://neo4j.com/ >> [3] https://github.com/hal/model-graph#examples >> >> -- >> Harald Pehl >> JBoss by Red Hat >> http://hpehl.info >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Harald Pehl JBoss by Red Hat http://hpehl.info From tomaz.cerar at gmail.com Mon Feb 6 08:36:36 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 6 Feb 2017 14:36:36 +0100 Subject: [wildfly-dev] Current Invocation / Elytron Integration Related Failures 2017-02-06 - 1 In-Reply-To: <5e41d3c1-a598-fae3-daaa-f62d9b0d9b35@jboss.com> References: <9998ba60-d160-4f9f-5be6-f6db0c06c029@jboss.com> <5e41d3c1-a598-fae3-daaa-f62d9b0d9b35@jboss.com> Message-ID: On Mon, Feb 6, 2017 at 2:20 PM, Darran Lofthouse wrote: > but do we have IPV6 enabled on that run? yes we do. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170206/1b00f804/attachment-0001.html From tomaz.cerar at gmail.com Mon Feb 6 08:41:37 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 6 Feb 2017 14:41:37 +0100 Subject: [wildfly-dev] Analyse the management model In-Reply-To: References: <185A4078-FFD8-45AE-AB63-D958408B6EAA@jboss.com> Message-ID: If OpenShift setup wouldn't cut for what you need, we could set it up somewhere in our public CI infrastructure as well. On Mon, Feb 6, 2017 at 2:33 PM, Harald Pehl wrote: > Good point. I guess this could easily be done by moving this to > OpenShift. With dedicated WildFly / Neo4j instances for each major > WildFly version. This way we could also provide an online Neo4j > browser (similar to [1] and [2]). Even with a custom documentation and > mini guides. > > [1] https://stackoverflow.com/questions/37370820/hosting-a- > public-read-only-neo4j-instance-in-the-cloud > [2] http://neo4j.het.io/browser/ > > On Mon, Feb 6, 2017 at 2:14 PM, Kabir Khan wrote: > > Very cool. If we could have the neo4j server somewhere central, perhaps > we could eventually do the comparisons of model versions from there? > >> On 6 Feb 2017, at 11:15, Harald Pehl wrote: > >> > >> TL;DR > >> > >> A tool to analyse the WildFly management model tree using a graph > database. > >> > >> # Longer version > >> > >> As a heavy consumer of the WildFly management model I've always been > >> looking for a way to analyse the management model. So I decided to > >> start a little side project over the weekend. The result is a tool [1] > >> which reads a (sub)tree of the WildFly management model and stores the > >> results into a graph database using Neo4j [2]. To get started, you > >> need a running WildFly and Neo4j instance. > >> > >> The tool writes nodes for each resource, attribute, operation, request > >> property and capability. In addition it creates relationships between > >> these nodes. You can use the data to > >> > >> - get alternatives and requires relations between attributes > >> - get deprecated attributes and request parameters for one or all > resources > >> - find attributes which might miss a capability reference > >> - find inconsistent attributes > >> - see differences between resources (using external diff tools) > >> > >> See [3] for more use cases. I hope this is useful for others as well. > >> Feedback, suggestions and critics are welcome! > >> > >> [1] https://github.com/hal/model-graph > >> [2] https://neo4j.com/ > >> [3] https://github.com/hal/model-graph#examples > >> > >> -- > >> Harald Pehl > >> JBoss by Red Hat > >> http://hpehl.info > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > -- > Harald Pehl > JBoss by Red Hat > http://hpehl.info > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170206/f921d53b/attachment.html From hpehl at redhat.com Mon Feb 6 08:44:33 2017 From: hpehl at redhat.com (Harald Pehl) Date: Mon, 6 Feb 2017 14:44:33 +0100 Subject: [wildfly-dev] Analyse the management model In-Reply-To: References: <185A4078-FFD8-45AE-AB63-D958408B6EAA@jboss.com> Message-ID: Comparisons are atm only possible by saving the results to a text file and by using external diff tools. To save the attributes of a resource one would use something like MATCH (r:Resource)-->(a:Attribute) WHERE r.address = "/subsystem=elytron/authentication-context=*" RETURN a On Mon, Feb 6, 2017 at 2:23 PM, Darran Lofthouse wrote: > If this can do model comparison that could be very useful to double check no > incompatible changes have leaked in without an appropriate version bump. > > > On 06/02/17 13:14, Kabir Khan wrote: >> >> Very cool. If we could have the neo4j server somewhere central, perhaps we >> could eventually do the comparisons of model versions from there? >>> >>> On 6 Feb 2017, at 11:15, Harald Pehl wrote: >>> >>> TL;DR >>> >>> A tool to analyse the WildFly management model tree using a graph >>> database. >>> >>> # Longer version >>> >>> As a heavy consumer of the WildFly management model I've always been >>> looking for a way to analyse the management model. So I decided to >>> start a little side project over the weekend. The result is a tool [1] >>> which reads a (sub)tree of the WildFly management model and stores the >>> results into a graph database using Neo4j [2]. To get started, you >>> need a running WildFly and Neo4j instance. >>> >>> The tool writes nodes for each resource, attribute, operation, request >>> property and capability. In addition it creates relationships between >>> these nodes. You can use the data to >>> >>> - get alternatives and requires relations between attributes >>> - get deprecated attributes and request parameters for one or all >>> resources >>> - find attributes which might miss a capability reference >>> - find inconsistent attributes >>> - see differences between resources (using external diff tools) >>> >>> See [3] for more use cases. I hope this is useful for others as well. >>> Feedback, suggestions and critics are welcome! >>> >>> [1] https://github.com/hal/model-graph >>> [2] https://neo4j.com/ >>> [3] https://github.com/hal/model-graph#examples >>> >>> -- >>> Harald Pehl >>> JBoss by Red Hat >>> http://hpehl.info >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > -- Harald Pehl JBoss by Red Hat http://hpehl.info From brian.stansberry at redhat.com Mon Feb 6 11:53:06 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 6 Feb 2017 10:53:06 -0600 Subject: [wildfly-dev] Analyse the management model In-Reply-To: References: <185A4078-FFD8-45AE-AB63-D958408B6EAA@jboss.com> Message-ID: <12B4B577-12B1-4C7A-A068-0E2526884A23@redhat.com> If version was an distinguishing property of a resource node then the relationship between versions becomes another edge. Or version is a node and the relationship between versions are edges. Either way those relationships aren?t really clear though. Version 1.7 and 2.0 may both be descendants of version 1.6 but 2.0 is not directly related to 1.7. And we don?t store the kind of version relationship data that would allow that to be worked out automatically. Anyway, this stuff is a bit of a tangent, although a worthy one. On the main point, cool! Good job. Just last week I was messing around looking for cases where we had attributes that were both required and had a default (which is wrong since the ?required? makes the default pointless). This would have saved me some time and probably still will as I?m sure I?ll have to redo the search to make sure I got it right. > On Feb 6, 2017, at 7:33 AM, Harald Pehl wrote: > > Good point. I guess this could easily be done by moving this to > OpenShift. With dedicated WildFly / Neo4j instances for each major > WildFly version. This way we could also provide an online Neo4j > browser (similar to [1] and [2]). Even with a custom documentation and > mini guides. > > [1] https://stackoverflow.com/questions/37370820/hosting-a-public-read-only-neo4j-instance-in-the-cloud > [2] http://neo4j.het.io/browser/ > > On Mon, Feb 6, 2017 at 2:14 PM, Kabir Khan wrote: >> Very cool. If we could have the neo4j server somewhere central, perhaps we could eventually do the comparisons of model versions from there? >>> On 6 Feb 2017, at 11:15, Harald Pehl wrote: >>> >>> TL;DR >>> >>> A tool to analyse the WildFly management model tree using a graph database. >>> >>> # Longer version >>> >>> As a heavy consumer of the WildFly management model I've always been >>> looking for a way to analyse the management model. So I decided to >>> start a little side project over the weekend. The result is a tool [1] >>> which reads a (sub)tree of the WildFly management model and stores the >>> results into a graph database using Neo4j [2]. To get started, you >>> need a running WildFly and Neo4j instance. >>> >>> The tool writes nodes for each resource, attribute, operation, request >>> property and capability. In addition it creates relationships between >>> these nodes. You can use the data to >>> >>> - get alternatives and requires relations between attributes >>> - get deprecated attributes and request parameters for one or all resources >>> - find attributes which might miss a capability reference >>> - find inconsistent attributes >>> - see differences between resources (using external diff tools) >>> >>> See [3] for more use cases. I hope this is useful for others as well. >>> Feedback, suggestions and critics are welcome! >>> >>> [1] https://github.com/hal/model-graph >>> [2] https://neo4j.com/ >>> [3] https://github.com/hal/model-graph#examples >>> >>> -- >>> Harald Pehl >>> JBoss by Red Hat >>> http://hpehl.info >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > Harald Pehl > JBoss by Red Hat > http://hpehl.info > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From hpehl at redhat.com Mon Feb 6 12:20:21 2017 From: hpehl at redhat.com (Harald Pehl) Date: Mon, 6 Feb 2017 18:20:21 +0100 Subject: [wildfly-dev] Analyse the management model In-Reply-To: <12B4B577-12B1-4C7A-A068-0E2526884A23@redhat.com> References: <185A4078-FFD8-45AE-AB63-D958408B6EAA@jboss.com> <12B4B577-12B1-4C7A-A068-0E2526884A23@redhat.com> Message-ID: Yeah I thought about versioning by reading the management model version from the root resource and include this data to the graph somehow. But versioning is not well supported in Neo4j, so I decided to start w/o version support. On Mon, Feb 6, 2017 at 5:53 PM, Brian Stansberry wrote: > If version was an distinguishing property of a resource node then the relationship between versions becomes another edge. > > Or version is a node and the relationship between versions are edges. > > Either way those relationships aren?t really clear though. Version 1.7 and 2.0 may both be descendants of version 1.6 but 2.0 is not directly related to 1.7. And we don?t store the kind of version relationship data that would allow that to be worked out automatically. > > Anyway, this stuff is a bit of a tangent, although a worthy one. On the main point, cool! Good job. Just last week I was messing around looking for cases where we had attributes that were both required and had a default (which is wrong since the ?required? makes the default pointless). This would have saved me some time and probably still will as I?m sure I?ll have to redo the search to make sure I got it right. > >> On Feb 6, 2017, at 7:33 AM, Harald Pehl wrote: >> >> Good point. I guess this could easily be done by moving this to >> OpenShift. With dedicated WildFly / Neo4j instances for each major >> WildFly version. This way we could also provide an online Neo4j >> browser (similar to [1] and [2]). Even with a custom documentation and >> mini guides. >> >> [1] https://stackoverflow.com/questions/37370820/hosting-a-public-read-only-neo4j-instance-in-the-cloud >> [2] http://neo4j.het.io/browser/ >> >> On Mon, Feb 6, 2017 at 2:14 PM, Kabir Khan wrote: >>> Very cool. If we could have the neo4j server somewhere central, perhaps we could eventually do the comparisons of model versions from there? >>>> On 6 Feb 2017, at 11:15, Harald Pehl wrote: >>>> >>>> TL;DR >>>> >>>> A tool to analyse the WildFly management model tree using a graph database. >>>> >>>> # Longer version >>>> >>>> As a heavy consumer of the WildFly management model I've always been >>>> looking for a way to analyse the management model. So I decided to >>>> start a little side project over the weekend. The result is a tool [1] >>>> which reads a (sub)tree of the WildFly management model and stores the >>>> results into a graph database using Neo4j [2]. To get started, you >>>> need a running WildFly and Neo4j instance. >>>> >>>> The tool writes nodes for each resource, attribute, operation, request >>>> property and capability. In addition it creates relationships between >>>> these nodes. You can use the data to >>>> >>>> - get alternatives and requires relations between attributes >>>> - get deprecated attributes and request parameters for one or all resources >>>> - find attributes which might miss a capability reference >>>> - find inconsistent attributes >>>> - see differences between resources (using external diff tools) >>>> >>>> See [3] for more use cases. I hope this is useful for others as well. >>>> Feedback, suggestions and critics are welcome! >>>> >>>> [1] https://github.com/hal/model-graph >>>> [2] https://neo4j.com/ >>>> [3] https://github.com/hal/model-graph#examples >>>> >>>> -- >>>> Harald Pehl >>>> JBoss by Red Hat >>>> http://hpehl.info >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> >> -- >> Harald Pehl >> JBoss by Red Hat >> http://hpehl.info >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > JBoss by Red Hat > > > -- Harald Pehl JBoss by Red Hat http://hpehl.info From ppalaga at redhat.com Mon Feb 6 16:00:29 2017 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 6 Feb 2017 22:00:29 +0100 Subject: [wildfly-dev] The final (?) property expression expander In-Reply-To: <68404560-a4b5-5820-87df-f5614e669ab2@redhat.com> References: <68404560-a4b5-5820-87df-f5614e669ab2@redhat.com> Message-ID: <0b599fc5-73b0-39ba-5290-e37df21bdb6e@redhat.com> Hi David, having this on one place from where other projects can consume it is clearly a good thing. I can remember having seen this kind of code copied to Hawkular and Keycloak because there was no reasonable way to reuse it. Could you please explain why you have chosen to place the new expression expander to Commons? I thought we had "commons must die" policy. Don't we have that kind of policy anymore? Thanks, Peter On 01/23/2017 05:59 PM, David M. Lloyd wrote: > The basic problem is that we have a variety of client libraries that > need property expansion, which are rolling their own or not doing it at > all at present. We have a couple implementations of property expansion > on the server. We have some potential future property expansion > requirements. Some or all of these things do (or need to do) property > expansion slightly differently. We've been balling up and depositing > the same properties code over and over again, evolving it slightly each > time, which in turn makes it harder to adapt to the next use case. So, > it's time to stop the madness. > > In wildfly-common I'm introducing a new properties expander, implemented > as a pure recursive-descent parser instead of the previous NFA-ish > parser. It is divided into two parts: syntax and expansion. > > Syntax is handled by the expression compiler, whose API consists of a > static factory method that accepts a pattern string and syntax flags, > and returns the resultant Expression. > > The syntax flags currently allow for the following syntax behaviors: > > ? NO_TRIM: Do not trim leading and trailing whitespace off of the > expression string before parsing it. > ? LENIENT_SYNTAX: Ignore syntax problems whenever possible instead of > throwing an exception. > ? MINI_EXPRS: Support single-character expressions that can be > interpreted without wrapping in curly braces. > ? NO_RECURSE_KEY: Do not support recursive expression expansion in the > key part of the expression. > ? NO_RECURSE_DEFAULT: Do not support recursion in default values. > ? NO_SMART_BRACES: Do not support smart braces (this is where you have > {something} inside of a key or default value). > ? GENERAL_EXPANSION: Support Policy file style "general" expansion > alternate expression syntax. "Smart" braces will only work if the > opening brace is not the first character in the expression key. > ? ESCAPES: Support standard Java escape sequences in plain text and > default value fields, which begin with a backslash character. > ? DOUBLE_COLON: Treat expressions containing a double-colon initial > delimiter as special, encoding the entire content into the key. > > More behaviors can be contributed (along with corresponding tests of > course). > > Once an Expression is compiled, the resultant object can be used for > expansion by providing an expansion function. The function is given a > context which allows introspection into the key sub-expression, the > default value sub-expression, and the string builder target. In > addition, the function may throw at most one checked exception type of > the user's choice, allowing expansion problems to be reported in any way. > > The API provides a few default expanders to support only simple system > properties and environment variables in the de-facto standard manner > that we have always done; this is useful for client libraries with basic > behavior. > > Find the initial code here: > https://github.com/wildfly/wildfly-common/pull/10 > > I'll merge it pending a bit more testing & any feedback. > From rareddy at redhat.com Mon Feb 6 16:20:36 2017 From: rareddy at redhat.com (Ramesh Reddy) Date: Mon, 6 Feb 2017 16:20:36 -0500 (EST) Subject: [wildfly-dev] Domain mode "Node" status? In-Reply-To: <646643046.27630547.1486415339663.JavaMail.zimbra@redhat.com> Message-ID: <628820101.27634211.1486416036297.JavaMail.zimbra@redhat.com> Hi, Is there is anyway in WF to register to listen lifecycle events from all the registered nodes in domain mode, without going to the JGroup's MembershipListener level? Thank you. Ramesh.. From david.lloyd at redhat.com Mon Feb 6 16:33:39 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 6 Feb 2017 15:33:39 -0600 Subject: [wildfly-dev] The final (?) property expression expander In-Reply-To: <0b599fc5-73b0-39ba-5290-e37df21bdb6e@redhat.com> References: <68404560-a4b5-5820-87df-f5614e669ab2@redhat.com> <0b599fc5-73b0-39ba-5290-e37df21bdb6e@redhat.com> Message-ID: <0c9e2c67-f8d2-2143-cf43-081369542f2f@redhat.com> The jboss-common-core project became a sort of 'dumping ground' for literally any utility that anyone could think of, no matter how broad or narrow its use, yet everyone required it because it contained a number of essential pieces of shared code. So to avoid repeating that, the wildfly-common project is very strictly curated with a policy that it's the last possible home for utilities that generally useful yet have no greater possible categorization. For example if I have 50 useful collections classes, maybe that's enough to justify a separate library (and release cycle) given that they share a categorization. But a one- or two-class utility that is very broadly useful (such as this expression parser) but doesn't really fit into another category might make sense to include in wildfly-common. On 02/06/2017 03:00 PM, Peter Palaga wrote: > Hi David, > > having this on one place from where other projects can consume it is > clearly a good thing. I can remember having seen this kind of code > copied to Hawkular and Keycloak because there was no reasonable way to > reuse it. > > Could you please explain why you have chosen to place the new expression > expander to Commons? I thought we had "commons must die" policy. Don't > we have that kind of policy anymore? > > Thanks, > > Peter > > On 01/23/2017 05:59 PM, David M. Lloyd wrote: >> The basic problem is that we have a variety of client libraries that >> need property expansion, which are rolling their own or not doing it at >> all at present. We have a couple implementations of property expansion >> on the server. We have some potential future property expansion >> requirements. Some or all of these things do (or need to do) property >> expansion slightly differently. We've been balling up and depositing >> the same properties code over and over again, evolving it slightly each >> time, which in turn makes it harder to adapt to the next use case. So, >> it's time to stop the madness. >> >> In wildfly-common I'm introducing a new properties expander, implemented >> as a pure recursive-descent parser instead of the previous NFA-ish >> parser. It is divided into two parts: syntax and expansion. >> >> Syntax is handled by the expression compiler, whose API consists of a >> static factory method that accepts a pattern string and syntax flags, >> and returns the resultant Expression. >> >> The syntax flags currently allow for the following syntax behaviors: >> >> ? NO_TRIM: Do not trim leading and trailing whitespace off of the >> expression string before parsing it. >> ? LENIENT_SYNTAX: Ignore syntax problems whenever possible instead of >> throwing an exception. >> ? MINI_EXPRS: Support single-character expressions that can be >> interpreted without wrapping in curly braces. >> ? NO_RECURSE_KEY: Do not support recursive expression expansion in the >> key part of the expression. >> ? NO_RECURSE_DEFAULT: Do not support recursion in default values. >> ? NO_SMART_BRACES: Do not support smart braces (this is where you have >> {something} inside of a key or default value). >> ? GENERAL_EXPANSION: Support Policy file style "general" expansion >> alternate expression syntax. "Smart" braces will only work if the >> opening brace is not the first character in the expression key. >> ? ESCAPES: Support standard Java escape sequences in plain text and >> default value fields, which begin with a backslash character. >> ? DOUBLE_COLON: Treat expressions containing a double-colon initial >> delimiter as special, encoding the entire content into the key. >> >> More behaviors can be contributed (along with corresponding tests of >> course). >> >> Once an Expression is compiled, the resultant object can be used for >> expansion by providing an expansion function. The function is given a >> context which allows introspection into the key sub-expression, the >> default value sub-expression, and the string builder target. In >> addition, the function may throw at most one checked exception type of >> the user's choice, allowing expansion problems to be reported in any way. >> >> The API provides a few default expanders to support only simple system >> properties and environment variables in the de-facto standard manner >> that we have always done; this is useful for client libraries with basic >> behavior. >> >> Find the initial code here: >> https://github.com/wildfly/wildfly-common/pull/10 >> >> I'll merge it pending a bit more testing & any feedback. >> > -- - DML From brian.stansberry at redhat.com Mon Feb 6 16:50:00 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 6 Feb 2017 15:50:00 -0600 Subject: [wildfly-dev] Domain mode "Node" status? In-Reply-To: <628820101.27634211.1486416036297.JavaMail.zimbra@redhat.com> References: <628820101.27634211.1486416036297.JavaMail.zimbra@redhat.com> Message-ID: <6E7C82B4-5E2A-4367-B257-109C56790A16@redhat.com> No, we don?t propagate lifecycle events up through the domain. > On Feb 6, 2017, at 3:20 PM, Ramesh Reddy wrote: > > Hi, > > Is there is anyway in WF to register to listen lifecycle events from all the registered nodes in domain mode, without going to the JGroup's MembershipListener level? > > Thank you. > > Ramesh.. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Tue Feb 7 13:28:01 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 7 Feb 2017 12:28:01 -0600 Subject: [wildfly-dev] Preventing duplicate registration of capabilities Message-ID: tl;dr; Currently on a server (let?s ignore an HC as it?s a tangent) we allow the same capability to be registered by more than one resource. In the large majority but not all cases a user doing this has made a mistake we should catch. I plan to make whether this is allowed configurable by the capability author. I *propose* making the default behavior ?false? which which is a behavior change and will require some cleanup. Only user impact is if some capability needs to allow multiple registrations and doesn?t pick this up and configure it, and that isn?t caught before release. Long version In most cases a server configuration should only have a single resource that registers a given capability. If more than one registers it, which really provides it? More than one will likely fail due to conflicts over things like MSC service names. But, the capability registry actually allows more than one registration point (i.e. resource address) for the same capability. In the large bulk of cases this doesn?t matter. Only one type of resource provides a capability, and if the user tries to configure two of that type of resource with the same name it will fail due to resource duplication (you can?t add socket-binding=http if there already is a resource at that address.) Elytron changes all this a bit as that subsystem has different resources with different types that all provide the same capability, but each with different implementation deals (*analogous* to an API providing Set but you can configure use of HashSet or LinkedHashSet or ConcurrentSkipListSet). Here we want to enforce that the user doesn?t configure two resources that provide the same capability. If they do, right now this will fail in runtime (due to MSC service name conflicts) but we want to detect the mistake earlier. OTOH there are some specialized cases where it is valid for two resources to register the same capability. Clustering has one (see WFLY-8040); there are others on a Host Controller. Basically the capability implementations know about each other, check for duplication at runtime and if present deal with it in a correct manner. I plan to make whether a capability allows multiple registration points to be configurable. See https://github.com/wildfly/wildfly-core/pull/2154 Question is whether the default behavior should remain ?true? (allow multiple registrations). Pros: 1) Any existing capabilties that really need multiple registration can remain unchanged. This is more problematic for other projects based on WildFly Core that use capabilities as they may not know about this until they switch to core 3.0. But are there such projects? (I specifically copied a few folks to directly check). 2) Some subsystem unit test setups that don?t need this but inadvertently rely on it still work. (I?ve already fixed these in WildFly and WildFly Core so this only relates to other projects based on WildFly Core that use capabilities.) Cons: 1) The Elytron use case is more standard, IMO, while the use cases like the clustering one that allow multiple registrations already require special logic to make that work. So I?d rather isolate any configuration to allow it to work to the cases that already are taking special steps. 2) The elytron team is really busy and doesn?t need more things to do. My thought is the Cons outweigh the Pros, so I plan to change the default behavior. But your thoughts are welcome. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Tue Feb 7 13:54:16 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 7 Feb 2017 18:54:16 +0000 Subject: [wildfly-dev] Preventing duplicate registration of capabilities In-Reply-To: References: Message-ID: It is not a problem for us to go through our subsystem and change a value across all resources if you need us to if the decision goes that way. BUT ;-) We do expect other subsystems to have resources that advertise our capabilities, 'security' is already one. An external one would be KeyCloak. If Elytron was fully configured for unique names and KeyCloak allowed duplicates would this be enough to get a Stage.MODEL error? On 07/02/17 18:28, Brian Stansberry wrote: > tl;dr; > > Currently on a server (let?s ignore an HC as it?s a tangent) we allow the same capability to be registered by more than one resource. In the large majority but not all cases a user doing this has made a mistake we should catch. I plan to make whether this is allowed configurable by the capability author. I *propose* making the default behavior ?false? which which is a behavior change and will require some cleanup. > > Only user impact is if some capability needs to allow multiple registrations and doesn?t pick this up and configure it, and that isn?t caught before release. > > Long version > > In most cases a server configuration should only have a single resource that registers a given capability. If more than one registers it, which really provides it? More than one will likely fail due to conflicts over things like MSC service names. > > But, the capability registry actually allows more than one registration point (i.e. resource address) for the same capability. > > In the large bulk of cases this doesn?t matter. Only one type of resource provides a capability, and if the user tries to configure two of that type of resource with the same name it will fail due to resource duplication (you can?t add socket-binding=http if there already is a resource at that address.) > > Elytron changes all this a bit as that subsystem has different resources with different types that all provide the same capability, but each with different implementation deals (*analogous* to an API providing Set but you can configure use of HashSet or LinkedHashSet or ConcurrentSkipListSet). Here we want to enforce that the user doesn?t configure two resources that provide the same capability. If they do, right now this will fail in runtime (due to MSC service name conflicts) but we want to detect the mistake earlier. > > OTOH there are some specialized cases where it is valid for two resources to register the same capability. Clustering has one (see WFLY-8040); there are others on a Host Controller. Basically the capability implementations know about each other, check for duplication at runtime and if present deal with it in a correct manner. > > I plan to make whether a capability allows multiple registration points to be configurable. See https://github.com/wildfly/wildfly-core/pull/2154 > > Question is whether the default behavior should remain ?true? (allow multiple registrations). > > Pros: > > 1) Any existing capabilties that really need multiple registration can remain unchanged. This is more problematic for other projects based on WildFly Core that use capabilities as they may not know about this until they switch to core 3.0. But are there such projects? (I specifically copied a few folks to directly check). > 2) Some subsystem unit test setups that don?t need this but inadvertently rely on it still work. (I?ve already fixed these in WildFly and WildFly Core so this only relates to other projects based on WildFly Core that use capabilities.) > > Cons: > > 1) The Elytron use case is more standard, IMO, while the use cases like the clustering one that allow multiple registrations already require special logic to make that work. So I?d rather isolate any configuration to allow it to work to the cases that already are taking special steps. > 2) The elytron team is really busy and doesn?t need more things to do. > > > My thought is the Cons outweigh the Pros, so I plan to change the default behavior. But your thoughts are welcome. > From brian.stansberry at redhat.com Tue Feb 7 14:17:21 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 7 Feb 2017 13:17:21 -0600 Subject: [wildfly-dev] Preventing duplicate registration of capabilities In-Reply-To: References: Message-ID: > On Feb 7, 2017, at 12:54 PM, Darran Lofthouse wrote: > > It is not a problem for us to go through our subsystem and change a > value across all resources if you need us to if the decision goes that way. > > BUT ;-) > > We do expect other subsystems to have resources that advertise our > capabilities, 'security' is already one. An external one would be KeyCloak. > > If Elytron was fully configured for unique names and KeyCloak allowed > duplicates would this be enough to get a Stage.MODEL error? > This is not possible because we require all registrations to use the exact same capability (x == y.) We could change that to x.equals(y) ? which I suspect you?ll reply asking for ;) ? but even there we?d include this field in the equality check. What you describe is an expansion on the point of my first ?Con?. In the elytron-style case, the people implementing the capability are not thinking about coordinating with other impls. They expect the kernel to make it just work. . > On 07/02/17 18:28, Brian Stansberry wrote: >> tl;dr; >> >> Currently on a server (let?s ignore an HC as it?s a tangent) we allow the same capability to be registered by more than one resource. In the large majority but not all cases a user doing this has made a mistake we should catch. I plan to make whether this is allowed configurable by the capability author. I *propose* making the default behavior ?false? which which is a behavior change and will require some cleanup. >> >> Only user impact is if some capability needs to allow multiple registrations and doesn?t pick this up and configure it, and that isn?t caught before release. >> >> Long version >> >> In most cases a server configuration should only have a single resource that registers a given capability. If more than one registers it, which really provides it? More than one will likely fail due to conflicts over things like MSC service names. >> >> But, the capability registry actually allows more than one registration point (i.e. resource address) for the same capability. >> >> In the large bulk of cases this doesn?t matter. Only one type of resource provides a capability, and if the user tries to configure two of that type of resource with the same name it will fail due to resource duplication (you can?t add socket-binding=http if there already is a resource at that address.) >> >> Elytron changes all this a bit as that subsystem has different resources with different types that all provide the same capability, but each with different implementation deals (*analogous* to an API providing Set but you can configure use of HashSet or LinkedHashSet or ConcurrentSkipListSet). Here we want to enforce that the user doesn?t configure two resources that provide the same capability. If they do, right now this will fail in runtime (due to MSC service name conflicts) but we want to detect the mistake earlier. >> >> OTOH there are some specialized cases where it is valid for two resources to register the same capability. Clustering has one (see WFLY-8040); there are others on a Host Controller. Basically the capability implementations know about each other, check for duplication at runtime and if present deal with it in a correct manner. >> >> I plan to make whether a capability allows multiple registration points to be configurable. See https://github.com/wildfly/wildfly-core/pull/2154 >> >> Question is whether the default behavior should remain ?true? (allow multiple registrations). >> >> Pros: >> >> 1) Any existing capabilties that really need multiple registration can remain unchanged. This is more problematic for other projects based on WildFly Core that use capabilities as they may not know about this until they switch to core 3.0. But are there such projects? (I specifically copied a few folks to directly check). >> 2) Some subsystem unit test setups that don?t need this but inadvertently rely on it still work. (I?ve already fixed these in WildFly and WildFly Core so this only relates to other projects based on WildFly Core that use capabilities.) >> >> Cons: >> >> 1) The Elytron use case is more standard, IMO, while the use cases like the clustering one that allow multiple registrations already require special logic to make that work. So I?d rather isolate any configuration to allow it to work to the cases that already are taking special steps. >> 2) The elytron team is really busy and doesn?t need more things to do. >> >> >> My thought is the Cons outweigh the Pros, so I plan to change the default behavior. But your thoughts are welcome. >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From kabir.khan at jboss.com Tue Feb 7 17:36:32 2017 From: kabir.khan at jboss.com (Kabir Khan) Date: Tue, 7 Feb 2017 22:36:32 +0000 Subject: [wildfly-dev] Preventing duplicate registration of capabilities In-Reply-To: References: Message-ID: <1186F306-37DE-4488-AFC8-F353792E3BE3@jboss.com> > On 7 Feb 2017, at 18:28, Brian Stansberry wrote: > > tl;dr; > > Currently on a server (let?s ignore an HC as it?s a tangent) we allow the same capability to be registered by more than one resource. In the large majority but not all cases a user doing this has made a mistake we should catch. I plan to make whether this is allowed configurable by the capability author. I *propose* making the default behavior ?false? which which is a behavior change and will require some cleanup. > > Only user impact is if some capability needs to allow multiple registrations and doesn?t pick this up and configure it, and that isn?t caught before release. > > Long version > > In most cases a server configuration should only have a single resource that registers a given capability. If more than one registers it, which really provides it? More than one will likely fail due to conflicts over things like MSC service names. > > But, the capability registry actually allows more than one registration point (i.e. resource address) for the same capability. > > In the large bulk of cases this doesn?t matter. Only one type of resource provides a capability, and if the user tries to configure two of that type of resource with the same name it will fail due to resource duplication (you can?t add socket-binding=http if there already is a resource at that address.) > > Elytron changes all this a bit as that subsystem has different resources with different types that all provide the same capability, but each with different implementation deals (*analogous* to an API providing Set but you can configure use of HashSet or LinkedHashSet or ConcurrentSkipListSet). Here we want to enforce that the user doesn?t configure two resources that provide the same capability. If they do, right now this will fail in runtime (due to MSC service name conflicts) but we want to detect the mistake earlier. > > OTOH there are some specialized cases where it is valid for two resources to register the same capability. Clustering has one (see WFLY-8040); there are others on a Host Controller. Basically the capability implementations know about each other, check for duplication at runtime and if present deal with it in a correct manner. > > I plan to make whether a capability allows multiple registration points to be configurable. See https://github.com/wildfly/wildfly-core/pull/2154 > > Question is whether the default behavior should remain ?true? (allow multiple registrations). > > Pros: > > 1) Any existing capabilties that really need multiple registration can remain unchanged. This is more problematic for other projects based on WildFly Core that use capabilities as they may not know about this until they switch to core 3.0. But are there such projects? (I specifically copied a few folks to directly check). > 2) Some subsystem unit test setups that don?t need this but inadvertently rely on it still work. (I?ve already fixed these in WildFly and WildFly Core so this only relates to other projects based on WildFly Core that use capabilities.) > > Cons: > > 1) The Elytron use case is more standard, IMO, while the use cases like the clustering one that allow multiple registrations already require special logic to make that work. So I?d rather isolate any configuration to allow it to work to the cases that already are taking special steps. > 2) The elytron team is really busy and doesn?t need more things to do. > > > My thought is the Cons outweigh the Pros, so I plan to change the default behavior. But your thoughts are welcome. +1 and it is a major version upgrade, so if we don't do it now it will be too late in the future > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > JBoss by Red Hat > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From darran.lofthouse at jboss.com Wed Feb 8 10:08:49 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 8 Feb 2017 15:08:49 +0000 Subject: [wildfly-dev] Current Invocation / Elytron Integration Related Failures 2017-02-08 Message-ID: Another round of merges have just been made against master for the latest Elytron / Invocation integration work - from the latest test run we are now down to 45 failures. https://ci.wildfly.org/viewLog.html?buildId=44766&buildTypeId=WF_MasterNewInvocationTests&tab=buildResultsDiv org.jboss.as.test.integration.ejb.client.descriptor.EJBClientDescriptorTestCase.testClientInvocationTimeout org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testSecurityContextAssociation org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testClientLoginModule org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testSecurityContextAssociation org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testClientLoginModule org.jboss.as.test.integration.ejb.mapbased.MapBasedInitialContextEjbClientTestCase.testScopedEJBClientContexts org.jboss.as.test.integration.ejb.remote.client.api.EJBClientAPIUsageTestCase.testNonExistentViewForEJB org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientUserTransactionTestCase.testBatchOperationsInTx org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testSLSBMandatoryTx org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testClientTransactionManagement org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testNotSwitched org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testUnsecured org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testSwitched org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testDirect org.jboss.as.test.integration.ejb.remote.suspend.EjbRemoteSuspendTestCase.testSuspendedCallRejected org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSingleton org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSFSB org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSLSB org.jboss.as.test.integration.ejb.transaction.bmt.lazyenlist.LazyTransactionEnlistmentUnitTestCase.testRawSQL org.jboss.as.test.integration.jpa.datasourcedefinition.DataSourceDefinitionJPATestCase.testUserTxRollbackDiscardsChanges org.jboss.as.test.integration.jpa.transaction.TransactionTestCase.testUserTxRollbackDiscardsChanges org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase.test org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase.test org.jboss.as.test.clustering.single.registry.RegistryTestCase.test org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnly org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationFailed org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBUsingEJB2xHomeView org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testEJBClientContextIdentiferIsNotSerialized org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerStartsLate org.jboss.as.test.manualmode.ejb.client.reconnect.EJBClientReconnectionTestCase.testReconnection From brian.stansberry at redhat.com Wed Feb 8 10:14:17 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 8 Feb 2017 09:14:17 -0600 Subject: [wildfly-dev] Current Invocation / Elytron Integration Related Failures 2017-02-08 In-Reply-To: References: Message-ID: <79B6D256-D4CA-4EFA-8BA6-8BE349AB895C@redhat.com> That?s great; that?s fast progress! > On Feb 8, 2017, at 9:08 AM, Darran Lofthouse wrote: > > Another round of merges have just been made against master for the > latest Elytron / Invocation integration work - from the latest test run > we are now down to 45 failures. > > https://ci.wildfly.org/viewLog.html?buildId=44766&buildTypeId=WF_MasterNewInvocationTests&tab=buildResultsDiv > > > org.jboss.as.test.integration.ejb.client.descriptor.EJBClientDescriptorTestCase.testClientInvocationTimeout > org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testSecurityContextAssociation > org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testClientLoginModule > org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testSecurityContextAssociation > org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testClientLoginModule > org.jboss.as.test.integration.ejb.mapbased.MapBasedInitialContextEjbClientTestCase.testScopedEJBClientContexts > org.jboss.as.test.integration.ejb.remote.client.api.EJBClientAPIUsageTestCase.testNonExistentViewForEJB > org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientUserTransactionTestCase.testBatchOperationsInTx > org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testSLSBMandatoryTx > org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testClientTransactionManagement > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testNotSwitched > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testUnsecured > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testSwitched > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testDirect > org.jboss.as.test.integration.ejb.remote.suspend.EjbRemoteSuspendTestCase.testSuspendedCallRejected > org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSingleton > org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSFSB > org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSLSB > org.jboss.as.test.integration.ejb.transaction.bmt.lazyenlist.LazyTransactionEnlistmentUnitTestCase.testRawSQL > org.jboss.as.test.integration.jpa.datasourcedefinition.DataSourceDefinitionJPATestCase.testUserTxRollbackDiscardsChanges > org.jboss.as.test.integration.jpa.transaction.TransactionTestCase.testUserTxRollbackDiscardsChanges > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap > org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException > org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase.test > org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase.test > org.jboss.as.test.clustering.single.registry.RegistryTestCase.test > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnly > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationFailed > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBUsingEJB2xHomeView > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testEJBClientContextIdentiferIsNotSerialized > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances > org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts > org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerStartsLate > org.jboss.as.test.manualmode.ejb.client.reconnect.EJBClientReconnectionTestCase.testReconnection > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From hpehl at redhat.com Mon Feb 13 17:41:27 2017 From: hpehl at redhat.com (Harald Pehl) Date: Mon, 13 Feb 2017 23:41:27 +0100 Subject: [wildfly-dev] Analyse the management model In-Reply-To: References: <185A4078-FFD8-45AE-AB63-D958408B6EAA@jboss.com> <12B4B577-12B1-4C7A-A068-0E2526884A23@redhat.com> Message-ID: With the help of Tomaz, I've managed to put the model-graph databases for the most recent WildFly versions online [1]. Have fun! [1] http://model-graph.ci.wildfly.org/ On Mon, Feb 6, 2017 at 6:20 PM, Harald Pehl wrote: > Yeah I thought about versioning by reading the management model > version from the root resource and include this data to the graph > somehow. But versioning is not well supported in Neo4j, so I decided > to start w/o version support. > > On Mon, Feb 6, 2017 at 5:53 PM, Brian Stansberry > wrote: >> If version was an distinguishing property of a resource node then the relationship between versions becomes another edge. >> >> Or version is a node and the relationship between versions are edges. >> >> Either way those relationships aren?t really clear though. Version 1.7 and 2.0 may both be descendants of version 1.6 but 2.0 is not directly related to 1.7. And we don?t store the kind of version relationship data that would allow that to be worked out automatically. >> >> Anyway, this stuff is a bit of a tangent, although a worthy one. On the main point, cool! Good job. Just last week I was messing around looking for cases where we had attributes that were both required and had a default (which is wrong since the ?required? makes the default pointless). This would have saved me some time and probably still will as I?m sure I?ll have to redo the search to make sure I got it right. >> >>> On Feb 6, 2017, at 7:33 AM, Harald Pehl wrote: >>> >>> Good point. I guess this could easily be done by moving this to >>> OpenShift. With dedicated WildFly / Neo4j instances for each major >>> WildFly version. This way we could also provide an online Neo4j >>> browser (similar to [1] and [2]). Even with a custom documentation and >>> mini guides. >>> >>> [1] https://stackoverflow.com/questions/37370820/hosting-a-public-read-only-neo4j-instance-in-the-cloud >>> [2] http://neo4j.het.io/browser/ >>> >>> On Mon, Feb 6, 2017 at 2:14 PM, Kabir Khan wrote: >>>> Very cool. If we could have the neo4j server somewhere central, perhaps we could eventually do the comparisons of model versions from there? >>>>> On 6 Feb 2017, at 11:15, Harald Pehl wrote: >>>>> >>>>> TL;DR >>>>> >>>>> A tool to analyse the WildFly management model tree using a graph database. >>>>> >>>>> # Longer version >>>>> >>>>> As a heavy consumer of the WildFly management model I've always been >>>>> looking for a way to analyse the management model. So I decided to >>>>> start a little side project over the weekend. The result is a tool [1] >>>>> which reads a (sub)tree of the WildFly management model and stores the >>>>> results into a graph database using Neo4j [2]. To get started, you >>>>> need a running WildFly and Neo4j instance. >>>>> >>>>> The tool writes nodes for each resource, attribute, operation, request >>>>> property and capability. In addition it creates relationships between >>>>> these nodes. You can use the data to >>>>> >>>>> - get alternatives and requires relations between attributes >>>>> - get deprecated attributes and request parameters for one or all resources >>>>> - find attributes which might miss a capability reference >>>>> - find inconsistent attributes >>>>> - see differences between resources (using external diff tools) >>>>> >>>>> See [3] for more use cases. I hope this is useful for others as well. >>>>> Feedback, suggestions and critics are welcome! >>>>> >>>>> [1] https://github.com/hal/model-graph >>>>> [2] https://neo4j.com/ >>>>> [3] https://github.com/hal/model-graph#examples >>>>> >>>>> -- >>>>> Harald Pehl >>>>> JBoss by Red Hat >>>>> http://hpehl.info >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >>> >>> -- >>> Harald Pehl >>> JBoss by Red Hat >>> http://hpehl.info >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> JBoss by Red Hat >> >> >> > > > > -- > Harald Pehl > JBoss by Red Hat > http://hpehl.info -- Harald Pehl JBoss by Red Hat http://hpehl.info From hpehl at redhat.com Mon Feb 13 18:40:32 2017 From: hpehl at redhat.com (Harald Pehl) Date: Tue, 14 Feb 2017 00:40:32 +0100 Subject: [wildfly-dev] Analyse the management model In-Reply-To: References: <185A4078-FFD8-45AE-AB63-D958408B6EAA@jboss.com> <12B4B577-12B1-4C7A-A068-0E2526884A23@redhat.com> Message-ID: Sorry, but the link only works over a VPN connection. The public available link will follow asap. On Mon, Feb 13, 2017 at 11:41 PM, Harald Pehl wrote: > With the help of Tomaz, I've managed to put the model-graph databases > for the most recent WildFly versions online [1]. > > Have fun! > > [1] http://model-graph.ci.wildfly.org/ > > On Mon, Feb 6, 2017 at 6:20 PM, Harald Pehl wrote: >> Yeah I thought about versioning by reading the management model >> version from the root resource and include this data to the graph >> somehow. But versioning is not well supported in Neo4j, so I decided >> to start w/o version support. >> >> On Mon, Feb 6, 2017 at 5:53 PM, Brian Stansberry >> wrote: >>> If version was an distinguishing property of a resource node then the relationship between versions becomes another edge. >>> >>> Or version is a node and the relationship between versions are edges. >>> >>> Either way those relationships aren?t really clear though. Version 1.7 and 2.0 may both be descendants of version 1.6 but 2.0 is not directly related to 1.7. And we don?t store the kind of version relationship data that would allow that to be worked out automatically. >>> >>> Anyway, this stuff is a bit of a tangent, although a worthy one. On the main point, cool! Good job. Just last week I was messing around looking for cases where we had attributes that were both required and had a default (which is wrong since the ?required? makes the default pointless). This would have saved me some time and probably still will as I?m sure I?ll have to redo the search to make sure I got it right. >>> >>>> On Feb 6, 2017, at 7:33 AM, Harald Pehl wrote: >>>> >>>> Good point. I guess this could easily be done by moving this to >>>> OpenShift. With dedicated WildFly / Neo4j instances for each major >>>> WildFly version. This way we could also provide an online Neo4j >>>> browser (similar to [1] and [2]). Even with a custom documentation and >>>> mini guides. >>>> >>>> [1] https://stackoverflow.com/questions/37370820/hosting-a-public-read-only-neo4j-instance-in-the-cloud >>>> [2] http://neo4j.het.io/browser/ >>>> >>>> On Mon, Feb 6, 2017 at 2:14 PM, Kabir Khan wrote: >>>>> Very cool. If we could have the neo4j server somewhere central, perhaps we could eventually do the comparisons of model versions from there? >>>>>> On 6 Feb 2017, at 11:15, Harald Pehl wrote: >>>>>> >>>>>> TL;DR >>>>>> >>>>>> A tool to analyse the WildFly management model tree using a graph database. >>>>>> >>>>>> # Longer version >>>>>> >>>>>> As a heavy consumer of the WildFly management model I've always been >>>>>> looking for a way to analyse the management model. So I decided to >>>>>> start a little side project over the weekend. The result is a tool [1] >>>>>> which reads a (sub)tree of the WildFly management model and stores the >>>>>> results into a graph database using Neo4j [2]. To get started, you >>>>>> need a running WildFly and Neo4j instance. >>>>>> >>>>>> The tool writes nodes for each resource, attribute, operation, request >>>>>> property and capability. In addition it creates relationships between >>>>>> these nodes. You can use the data to >>>>>> >>>>>> - get alternatives and requires relations between attributes >>>>>> - get deprecated attributes and request parameters for one or all resources >>>>>> - find attributes which might miss a capability reference >>>>>> - find inconsistent attributes >>>>>> - see differences between resources (using external diff tools) >>>>>> >>>>>> See [3] for more use cases. I hope this is useful for others as well. >>>>>> Feedback, suggestions and critics are welcome! >>>>>> >>>>>> [1] https://github.com/hal/model-graph >>>>>> [2] https://neo4j.com/ >>>>>> [3] https://github.com/hal/model-graph#examples >>>>>> >>>>>> -- >>>>>> Harald Pehl >>>>>> JBoss by Red Hat >>>>>> http://hpehl.info >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Harald Pehl >>>> JBoss by Red Hat >>>> http://hpehl.info >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> -- >>> Brian Stansberry >>> Manager, Senior Principal Software Engineer >>> JBoss by Red Hat >>> >>> >>> >> >> >> >> -- >> Harald Pehl >> JBoss by Red Hat >> http://hpehl.info > > > > -- > Harald Pehl > JBoss by Red Hat > http://hpehl.info -- Harald Pehl JBoss by Red Hat http://hpehl.info From rsvoboda at redhat.com Thu Feb 16 06:32:53 2017 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Thu, 16 Feb 2017 06:32:53 -0500 (EST) Subject: [wildfly-dev] Current Invocation / Elytron Integration Related Failures 2017-02-08 In-Reply-To: <79B6D256-D4CA-4EFA-8BA6-8BE349AB895C@redhat.com> References: <79B6D256-D4CA-4EFA-8BA6-8BE349AB895C@redhat.com> Message-ID: <1131118572.5743317.1487244773625.JavaMail.zimbra@redhat.com> https://ci.wildfly.org/viewLog.html?buildId=46451&buildTypeId=WF_MasterNewInvocationTests&tab=buildResultsDiv%3E Latest test run is on 42 failures Rostislav ----- Original Message ----- > That?s great; that?s fast progress! > > > On Feb 8, 2017, at 9:08 AM, Darran Lofthouse > > wrote: > > > > Another round of merges have just been made against master for the > > latest Elytron / Invocation integration work - from the latest test run > > we are now down to 45 failures. > > > > https://ci.wildfly.org/viewLog.html?buildId=44766&buildTypeId=WF_MasterNewInvocationTests&tab=buildResultsDiv > > > > > > org.jboss.as.test.integration.ejb.client.descriptor.EJBClientDescriptorTestCase.testClientInvocationTimeout > > org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testSecurityContextAssociation > > org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testClientLoginModule > > org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testSecurityContextAssociation > > org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testClientLoginModule > > org.jboss.as.test.integration.ejb.mapbased.MapBasedInitialContextEjbClientTestCase.testScopedEJBClientContexts > > org.jboss.as.test.integration.ejb.remote.client.api.EJBClientAPIUsageTestCase.testNonExistentViewForEJB > > org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientUserTransactionTestCase.testBatchOperationsInTx > > org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testSLSBMandatoryTx > > org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testClientTransactionManagement > > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testNotSwitched > > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testUnsecured > > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testSwitched > > org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testDirect > > org.jboss.as.test.integration.ejb.remote.suspend.EjbRemoteSuspendTestCase.testSuspendedCallRejected > > org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSingleton > > org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSFSB > > org.jboss.as.test.integration.ejb.remote.view.LocalViewRemoteInvocationTestCase.testServerInVMInvocationOnLocalViewOfSLSB > > org.jboss.as.test.integration.ejb.transaction.bmt.lazyenlist.LazyTransactionEnlistmentUnitTestCase.testRawSQL > > org.jboss.as.test.integration.jpa.datasourcedefinition.DataSourceDefinitionJPATestCase.testUserTxRollbackDiscardsChanges > > org.jboss.as.test.integration.jpa.transaction.TransactionTestCase.testUserTxRollbackDiscardsChanges > > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir > > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap > > org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test > > org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test > > org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test > > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover > > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover > > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover > > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover > > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException > > org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase.test > > org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase.test > > org.jboss.as.test.clustering.single.registry.RegistryTestCase.test > > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion > > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded > > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnly > > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationFailed > > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation > > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBUsingEJB2xHomeView > > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testEJBClientContextIdentiferIsNotSerialized > > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances > > org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts > > org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerStartsLate > > org.jboss.as.test.manualmode.ejb.client.reconnect.EJBClientReconnectionTestCase.testReconnection > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > JBoss by Red Hat > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From darran.lofthouse at jboss.com Thu Feb 16 06:47:46 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 16 Feb 2017 11:47:46 +0000 Subject: [wildfly-dev] Current Invocation Integration / Elytron Integration Related Failures 2017-02-16 Message-ID: The latest test results are available at: - https://ci.wildfly.org/viewLog.html?buildId=46451&buildTypeId=WF_MasterNewInvocationTests&tab=buildResultsDiv We currently stand at 42 failures, at the last count we were at 45 failures. However included in this latest we have 6 last minute failures related to graceful shut down related to EJB and transactions which is a known issue currently being worked on and one additional transnational failure to be worked on. The current failures are: - org.jboss.as.test.integration.ejb.mdb.MDBTestCase.testSuspendResumeWithMDB org.jboss.as.test.integration.ejb.mdb.MDBTestCase.testAnnoBasedMDB org.jboss.as.test.integration.ejb.mdb.MDBTestCase.testDDBasedMDB org.jboss.as.test.integration.ejb.client.descriptor.EJBClientDescriptorTestCase.testClientInvocationTimeout org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testSecurityContextAssociation org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testClientLoginModule org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testSecurityContextAssociation org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase.testClientLoginModule org.jboss.as.test.integration.ejb.mapbased.MapBasedInitialContextEjbClientTestCase.testScopedEJBClientContexts org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientUserTransactionTestCase.testBatchOperationsInTx org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testNotSwitched org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testUnsecured org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testSwitched org.jboss.as.test.integration.ejb.remote.security.RemoteIdentityTestCase.testDirect org.jboss.as.test.integration.ejb.remote.suspend.EjbRemoteSuspendTestCase.testSuspendedCallRejected org.jboss.as.test.integration.ejb.timerservice.suspend.TimerServiceSuspendTestCase.testSuspendWithIntervalTimer org.jboss.as.test.integration.ejb.timerservice.suspend.TimerServiceSuspendTestCase.testSingleActionTimerWhenSuspended org.jboss.as.test.integration.ejb.timerservice.suspend.TimerServiceSuspendTestCase.testIntervalTimersDoNotBackUp org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase.testNoTxEPCPropagation org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testNotAuthorizedClient org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testAuthorizedClient org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testNotAuthorizedClient org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testAuthorizedClient org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase.test org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase.test org.jboss.as.test.clustering.single.registry.RegistryTestCase.test org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBUsingEJB2xHomeView org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerStartsLate org.jboss.as.test.manualmode.ejb.client.reconnect.EJBClientReconnectionTestCase.testReconnection From sanne at hibernate.org Fri Feb 17 07:00:24 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 17 Feb 2017 12:00:24 +0000 Subject: [wildfly-dev] Apache Lucene modules for WildFly : evolution Message-ID: # Context historically the Hibernate Search project released modules for WildFly, so that people could use the latest version of it w/o having to wait for WildFly to upgrade it and release. This zip we distribute would also include updated modules for Apache Lucene. We have now separated the Lucene modules into their own repository, so that other projects (e.g. Infinispan) can use the same modules. In case you want to have a look, the POC is hosted at: - https://github.com/hibernate/lucene-modules We planned to deploy this zip file as a Maven artifact under coordinates "org.hibernate.lucene-modules:lucene-modules:lucene-modules". # I have three questions: ## Would it be useful to make this a "Feature Pack" ? Ideally we would like future versions of WildFly to use the same structure (and same content) of these modules, when it will come to upgrade the Lucene version within WildFly. That's because we will have already tested these in (at least) the Hibernate and Infinispan projects, while replicating the same structure within the WildFly build would not guarantee the same output, and would not be covered by the same amount and quality of integration tests. ## Would you prefer this to be hosted as github.com/wildfly ? We'd be happy to transfer ownership and still maintain it: having this under "Hibernate" probably sends the wrong message. It contains no Hibernate code and we'd like to encourage other people possibly using Lucene on WildFly to use the same modules, again for consistency reasons. ## Should we use a WildFly flavoured organization id? For the same reasons as in the previous question, yet I ask this separately as I guess we could still keep it on github/hibernate if you prefer, yet distribute it as "org.wildfly:lucene-modules" or something else you might want to suggest. Thanks, Sanne From sanne at hibernate.org Mon Feb 20 07:31:27 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 20 Feb 2017 12:31:27 +0000 Subject: [wildfly-dev] JPADependencyProcessor "infecting" classpath with the wrong Javassist version In-Reply-To: References: Message-ID: This is how we documented the procedure in the Hibernate guides: - http://docs.jboss.org/hibernate/orm/5.2/topical/html_single/wildfly/Wildfly.html I'd still prefer the Javassist module to not be enforced by the JPA integration code. Thanks, Sanne On 16 January 2017 at 11:13, Sanne Grinovero wrote: > Hi Stuart, > > On 15 January 2017 at 22:23, Stuart Douglas wrote: >> Is there any reason why we can't update to the latest version of Javassist? > > Sure we can update Javassist as well, as long as we pick a version > which is compatible with the (slightly old) version of Hibernate ORM > included in WildFly. > This might require a backport of the Javassist upgrade to the older > stable branch of Hibernate ORM and a new release though, so I'd treat > it as an orthogonal issue especially as such a plan would require its > own set of approvers. > >> I know this does not prevent similar issues in future, but we should >> probably be using the most recent version if there is no reason not to. > > Right, but bear with me the "not prevent similar issues in future" is > crucial to my problem here. We need to regularly test next-gen > Hibernate ORM while we work on it: we want to have ci.hibernate.org > run the WildFly integration tests on each commit of Hibernate ORM, so > upgrading Javassist - or any other dependency - is an event which > might happen multiple times a week and we don't want to wait for a > WildFly release each time this is needed. > It's really about controlling our own dependencies, to keep > development quick and practical. > >> My issue with https://github.com/wildfly/wildfly/pull/8474 is that in >> general we should not be using export="true", as it makes it impossible to >> exclude the dependency using jboss-deployment-structure.xml. As a result I >> don't really see how this PR is an improvement, as it goes from the >> javassist deployment being added directly to the deployment to it being >> added indirectly via an export. > > Interesting point, I hadn't thought about users of > jboss-deployment-structure.xml. But still, anyone making use of > `org.hibernate:main` (as it is today) will strictly require to have > `org.javassist:main` on their classpath, so one will not want to > exclude it; while people using say `org.hibernate:5.2.6.Final` will > definitely not want `org.javassist:main` on their classpath as it will > cause subtle problems. In short, it's not a grey area but it's very > clear when it's required or not and we can automate this decision. > So I think the modules definitions of each `org.hibernate:xyz` module > should point to the right instance of the javassist module, rather > than force the users to craft an appropriate structure xml file to > amend for our bad choices? > > I guess it is currently important for people to be able to exclude > `org.javassist` because it's being injected aggressively, for example > your apps get "infected" by javassist even if you want to use a > different JPA implementation which has no business at all with > Javassist. > On the other hand, I don't think we can support Hibernate users who > simply disable the right version of javassist using the deployment > structure, so if someone really wants to exclude org.javassist:main I > would suggest them to edit the module file of ORM, or better yet use > their own (and self-supported) ORM module. > > By moving it to the static definition of the module, at least I have > the option to use my own set of Hibernate ORM modules and choose an > updated Javassist slot. > > Hibernate ORM also has the option to use Byte Buddy now as an > alternative to Javassist; when using the new alternative enhancer one > might also want to get rid of the Javassist dependency altogether, > which power users can achieve by editing their own module, or using > the "next-gen" modules we regularly provide with each Hibernate > release. Fixing the JPADependencyProcessor would make it easy for > people to use newer modules by just layering the new edition. > > Thanks, > Sanne > > >> >> Stuart >> >> On Fri, Jan 13, 2017 at 11:03 PM, Sanne Grinovero >> wrote: >>> >>> Hi all, >>> >>> Scott sent a nice PR to Wildfly a while back to fix the problem: >>> - https://github.com/wildfly/wildfly/pull/9305 >>> >>> It wasn't merged, I guess it's not a priority for WildFly but let me >>> clarify that without such fixes it's impossible for people to use >>> newer versions of Hibernate ORM on WildFly, and I suspect lots of pain >>> as well for other libraries using Javassist. >>> >>> There's quite some people in the Hibernate community who expressed >>> interest in using a not-so-stale version as the one which is typically >>> available in the latest stable release of WildFly. >>> >>> To make this happen, all Hibernate projects are now publishing >>> "WildFly modules" which can be easily downloaded as additional drop-in >>> layer. >>> Granted these are not for everyone but we get good feedback from the >>> power users interested, and not least this allows us to develop all >>> our projects while regularly testing integration with WildFly, making >>> sure that the eventual integration goes smoother. >>> >>> The current problem is that the WildFly JPADependencyProcessor adds >>> the wrong version of javassist to the deployments, and there's no way >>> for us to prevent this or override this, making it impossible to use a >>> recent version of Hibernate ORM as it requires a newer version. >>> - >>> https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/jpa/subsystem/src/main/java/org/jboss/as/jpa/processor/JPADependencyProcessor.java#L95 >>> >>> We'd highly appreciate if that PR could be merged? Including on >>> product branches please, as enforcing a dependency which is neither >>> needed nor desired is going to break a long list of other frameworks >>> as well. >>> >>> Thanks, >>> Sanne >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> From brian.stansberry at redhat.com Thu Feb 23 17:43:29 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 23 Feb 2017 16:43:29 -0600 Subject: [wildfly-dev] Preventing duplicate registration of capabilities In-Reply-To: <1186F306-37DE-4488-AFC8-F353792E3BE3@jboss.com> References: <1186F306-37DE-4488-AFC8-F353792E3BE3@jboss.com> Message-ID: > On Feb 7, 2017, at 4:36 PM, Kabir Khan wrote: > >> >> On 7 Feb 2017, at 18:28, Brian Stansberry wrote: >> >> tl;dr; >> >> Currently on a server (let?s ignore an HC as it?s a tangent) we allow the same capability to be registered by more than one resource. In the large majority but not all cases a user doing this has made a mistake we should catch. I plan to make whether this is allowed configurable by the capability author. I *propose* making the default behavior ?false? which which is a behavior change and will require some cleanup. >> >> Only user impact is if some capability needs to allow multiple registrations and doesn?t pick this up and configure it, and that isn?t caught before release. >> >> Long version >> >> In most cases a server configuration should only have a single resource that registers a given capability. If more than one registers it, which really provides it? More than one will likely fail due to conflicts over things like MSC service names. >> >> But, the capability registry actually allows more than one registration point (i.e. resource address) for the same capability. >> >> In the large bulk of cases this doesn?t matter. Only one type of resource provides a capability, and if the user tries to configure two of that type of resource with the same name it will fail due to resource duplication (you can?t add socket-binding=http if there already is a resource at that address.) >> >> Elytron changes all this a bit as that subsystem has different resources with different types that all provide the same capability, but each with different implementation deals (*analogous* to an API providing Set but you can configure use of HashSet or LinkedHashSet or ConcurrentSkipListSet). Here we want to enforce that the user doesn?t configure two resources that provide the same capability. If they do, right now this will fail in runtime (due to MSC service name conflicts) but we want to detect the mistake earlier. >> >> OTOH there are some specialized cases where it is valid for two resources to register the same capability. Clustering has one (see WFLY-8040); there are others on a Host Controller. Basically the capability implementations know about each other, check for duplication at runtime and if present deal with it in a correct manner. >> >> I plan to make whether a capability allows multiple registration points to be configurable. See https://github.com/wildfly/wildfly-core/pull/2154 >> >> Question is whether the default behavior should remain ?true? (allow multiple registrations). >> >> Pros: >> >> 1) Any existing capabilties that really need multiple registration can remain unchanged. This is more problematic for other projects based on WildFly Core that use capabilities as they may not know about this until they switch to core 3.0. But are there such projects? (I specifically copied a few folks to directly check). >> 2) Some subsystem unit test setups that don?t need this but inadvertently rely on it still work. (I?ve already fixed these in WildFly and WildFly Core so this only relates to other projects based on WildFly Core that use capabilities.) >> >> Cons: >> >> 1) The Elytron use case is more standard, IMO, while the use cases like the clustering one that allow multiple registrations already require special logic to make that work. So I?d rather isolate any configuration to allow it to work to the cases that already are taking special steps. >> 2) The elytron team is really busy and doesn?t need more things to do. >> >> >> My thought is the Cons outweigh the Pros, so I plan to change the default behavior. But your thoughts are welcome. > +1 and it is a major version upgrade, so if we don't do it now it will be too late in the future This is done, so the default behavior beginning in WildFly Core 3.0.0.Beta5 will be that you have to specially configure to allow multiple resources to register the same capabiltity. I only found the two uses of this I mentioned in my first post. >> >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> JBoss by Red Hat >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From thofman at redhat.com Mon Feb 27 07:23:39 2017 From: thofman at redhat.com (Tomas Hofman) Date: Mon, 27 Feb 2017 13:23:39 +0100 Subject: [wildfly-dev] IPv6 related utility classes in Wildfly / Elytron / ... Message-ID: <3d313662-3d2b-22c9-d8dc-382938895860@redhat.com> Hello, I'm working on an issue in Elytron, which requires validation of IPv6 addresses. Potentially also normalizing IPv6 addresses and matching addresses by masks could be needed in future. For now I implemented my own validation code which may be good enough, but still, better would be to rely on proven utility class. Do we use some standard library for such purposes, or is there such functionality in JBoss codebase somewhere? I found NetworkUtils class in wildfly-network package, which does some of that, but that can't be used in Elytron. Are there some rules when considering new dependencies? For instance would Apache Commons Validator/Net represent conceivable dependencies for Elytron? Thanks, Tomas From darran.lofthouse at jboss.com Mon Feb 27 09:08:44 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 27 Feb 2017 14:08:44 +0000 Subject: [wildfly-dev] Latest WildFly Elytron / Invocation Integration Test Failures 2017-02-27 Message-ID: <33a3d2e7-439c-aa5e-2eab-819b3d3521fc@jboss.com> Here are the latest results for Elytron / Invocation related test failures: - https://ci.wildfly.org/viewLog.html?buildId=47710&buildTypeId=WF_MasterNewInvocationTests&tab=buildResultsDiv We currently stand at 19 failures. org.jboss.as.test.integration.ejb.client.descriptor.EJBClientDescriptorTestCase.testClientInvocationTimeout org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase.testNoTxEPCPropagation org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testNotAuthorizedClient org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testAuthorizedClient org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testNotAuthorizedClient org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testAuthorizedClient org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase.test org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase.test org.jboss.as.test.clustering.single.registry.RegistryTestCase.test From tomaz.cerar at gmail.com Mon Feb 27 09:17:52 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 27 Feb 2017 15:17:52 +0100 Subject: [wildfly-dev] IPv6 related utility classes in Wildfly / Elytron / ... In-Reply-To: <3d313662-3d2b-22c9-d8dc-382938895860@redhat.com> References: <3d313662-3d2b-22c9-d8dc-382938895860@redhat.com> Message-ID: On Mon, Feb 27, 2017 at 1:23 PM, Tomas Hofman wrote: > I'm working on an issue in Elytron, which requires validation of IPv6 > addresses. Potentially also normalizing IPv6 addresses and matching > addresses by masks could be needed in future. For now I implemented my > own validation code which may be good enough, but still, better would be > to rely on proven utility class. > > > Do we use some standard library for such purposes, or is there such > functionality in JBoss codebase somewhere? I found NetworkUtils class in > wildfly-network package, which does some of that, but that can't be used > in Elytron. > What is the use case? > > Are there some rules when considering new dependencies? For instance > would Apache Commons Validator/Net represent conceivable dependencies > for Elytron? > new runtime dependency? I would avoid them if possible. Especially when it comes to Apache Commons * ... -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170227/6bc3b735/attachment.html From darran.lofthouse at jboss.com Mon Feb 27 09:28:33 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 27 Feb 2017 14:28:33 +0000 Subject: [wildfly-dev] IPv6 related utility classes in Wildfly / Elytron / ... In-Reply-To: References: <3d313662-3d2b-22c9-d8dc-382938895860@redhat.com> Message-ID: <518b719b-8a92-0f88-3443-d30e3009d8b4@jboss.com> On 27/02/17 14:17, Toma? Cerar wrote: > > On Mon, Feb 27, 2017 at 1:23 PM, Tomas Hofman > wrote: > > I'm working on an issue in Elytron, which requires validation of IPv6 > addresses. Potentially also normalizing IPv6 addresses and matching > addresses by masks could be needed in future. For now I implemented my > own validation code which may be good enough, but still, better would be > to rely on proven utility class. > > > > Do we use some standard library for such purposes, or is there such > functionality in JBoss codebase somewhere? I found NetworkUtils class in > wildfly-network package, which does some of that, but that can't be used > in Elytron. > > What is the use case? Detection of and matching of IPv6 addresses including canonicalisation for different representations of the same address. Note: This is not DNS lookup or reverse DNS lookup. > > > > Are there some rules when considering new dependencies? For instance > would Apache Commons Validator/Net represent conceivable dependencies > for Elytron? > > new runtime dependency? I would avoid them if possible. > Especially when it comes to Apache Commons * ... +1 This code may be used by all remote clients and all deployments. > -- > tomaz > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From david.lloyd at redhat.com Mon Feb 27 09:30:47 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 27 Feb 2017 08:30:47 -0600 Subject: [wildfly-dev] IPv6 related utility classes in Wildfly / Elytron / ... In-Reply-To: <3d313662-3d2b-22c9-d8dc-382938895860@redhat.com> References: <3d313662-3d2b-22c9-d8dc-382938895860@redhat.com> Message-ID: <552ae6d0-6b63-48e5-f5eb-51ce1e99985d@redhat.com> There are a couple of answers to this. In https://github.com/wildfly/wildfly-common I've introduced a few IP address utilities which render IP addresses and perform CIDR functions, for the EJB client. It would make sense to have proper IP address parsing here; in fact this is something I've thought about a bit. New dependencies are fundamentally OK with justification, but ideally we want to get good usage out of them. If we're bringing in a 10MB JAR for one 6KB class, that is somewhat less than ideal. Also we'd want external dependencies to be well-maintained. In this case my opinion is that the best option is to add IPv4 and IPv6 address parsers into the org.wildfly.common.net.Inet class. On 02/27/2017 06:23 AM, Tomas Hofman wrote: > Hello, > > I'm working on an issue in Elytron, which requires validation of IPv6 > addresses. Potentially also normalizing IPv6 addresses and matching > addresses by masks could be needed in future. For now I implemented my > own validation code which may be good enough, but still, better would be > to rely on proven utility class. > > Do we use some standard library for such purposes, or is there such > functionality in JBoss codebase somewhere? I found NetworkUtils class in > wildfly-network package, which does some of that, but that can't be used > in Elytron. > > Are there some rules when considering new dependencies? For instance > would Apache Commons Validator/Net represent conceivable dependencies > for Elytron? > > Thanks, > Tomas > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML